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 8 October 1999
SS7 MTP3-User Adaptation Layer (M3UA)
<draft-ietf-sigtran-m3ua-00.txt>
Status of This Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as 'work in progress.'
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
To learn the current status of any Internet-Draft, please check the
'1id-abstracts.txt' listing contained in the Internet- Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This Internet Draft defines a protocol for transport of 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, or as seamless as possible, 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 but could also be used between two SGs
if desired. It is assumed that the SG receives SS7 signaling
over a standard SS7 interface using the SS7 Message Transfer Part
(MTP) to provide transport.
NOTE: THIS DRAFT REPLACES <draft-ietf-sigtran-itun-00.txt>
1
Internet Draft SS7 MTP3-User Adaptation Layer Oct 1999
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
2
Internet Draft SS7 MTP3-User Adaptation Layer Oct 1999
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). The
delivery mechanism should meet the following criteria:
* Support for transfer of SS7 MTP3-User Part messages (e.g., ISUP,
SCCP, TUP, etc.)
* Support for the seamless operation of MTP3-User peers
* Support for the management of SCTP
transport associations between an SG and an MGC or IP Database)
* Support for the asynchronous reporting of status changes to
management
In other words, the SG will terminate SS7 MTP2 and MTP3 protocols and
deliver ISUP, SCCP and/or any other MTP3-User protocols to IP-resident
Application Server Processes over an SCTP transport association
1.2 Terminology
Application Server (AS) - A logical entity serving a specific
application instance. An example of an Application Server is a virtual
switch handling all call processing for a particular SS7
OPC/DPC/CIC_range. Practically speaking, an AS is modeled at the SG as
an ordered list of one or more related Application Server Processes
(e.g., primary, secondary, tertiary, ...).
Application Server Process (ASP) - A process instance of an Application
Server. Examples of Application Server Processes are primary or backup
MGC instances.
Application Server Process Path (ASP Path or just Path) - A Path to a
remote Application Server Process instance. A Path maps 1:1 to an SCTP
association
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 will provide 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
a next-preferred Application Server Process within an Application
Server in the event of failure or unavailability of the currently used
3
Internet Draft SS7 MTP3-User Adaptation Layer Oct 1999
Application Server Process (e.g., from primary MGC to back-up MGC).
Fail-over may also apply upon the return to service of a previously
unavailable Application Server Process.
MTP3-User - Any protocol normally using the services of the SS7 MTP3
(e.g., ISUP, SCCP, TUP, etc.).
Stream - A stream refers to an SCTP stream.
1.3 Signaling Transport Architecture
The architecture that has been defined for SCN signaling transport
over IP uses multiple components, including an IP transport
protocol, a signaling common transport protocol and an adaptation
module to support the services expected by a particular SCN signaling
protocol from its underlying protocol layer.
In reference to the SIGTRAN framework architecture [xx], This document
defines an MTP3-User adaptation module that is suitable for the
transport of SS7 ISDN User Part (ISUP) and Signalling Connection
Control Part (SCCP) messages but could be used equally to transport
other SS7 MTP3-User Part messages such as, for example, TUP. Note:
SCCP-Users (e.g., INAP/TC or ISUP) are supported implicitly as SCCP
payload.
In a Signaling Gateway, it is expected that the SS7 ISUP/SCCP signaling
is transmitted and received over a standard SS7 network interface,
using the SS7 Message Transfer Part (MTP) to provide transport of
ISUP/SCCP signaling messages to and from an SS7 Signaling End Point
(SEP) or Signaling Transfer Point (STP). The SG then provides
interworking of transport functions with IP Signaling Transport, in
order to transfer the ISUP/SCCP signaling messages to and from the ASP
where the peer ISUP/SCCP protocol layer exists. Three general cases
are shown below to cover the routing options in the event of ISUP or
SCCP transport across the SG as shown below:
1.3.1 Case 1: ISUP transport
****** SS7 ****** IP ******
*SEP *-----------* SG *-----------*ASP *
****** ****** ******
+----+ +----+
|ISUP| |ISUP|
+----+ +---------+ +----+
|MTP | |MTP |M3UA| |M3UA|
|L3 | |L3 +----+ +----+
|L2 | |L2 |SCTP| |SCTP|
|L1 | |L1 +----+ +----+
| | | |UDP | |UDP |
+----+ +---------+ +----+
SEP - SS7 Signaling End Point
SCTP - Simple Control Transport Protocol [5]
4
Internet Draft SS7 MTP3-User Adaptation Layer Oct 1999
Note: The use of MTP Level 2 signaling links in the SS7 network is
shown as an example. ATM-based High Speed Links could also be used,
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
MTP3-User peers in the SS7 and IP domains, the SG implements for
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
the final IP destination. This internal SG function also delivers MTP-
TRANSFER request primitives to the MTP Level 3 upper layer interface
from the M3UA network address translation and mapping function for
ongoing MTP Level 3 routing to the SS7 node. This nodal interworking
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
invoked:
****** SS7 ****** IP *******
*SEP *-----------* SG *------------* ASP *
* or * * * * *
*STP * * * * *
****** ****** *******
+----+ +---------+ +-----+
|SCCP| | SCCP | |SCCP |
+----+ +---------+ +-----+
|MTP | |MTP |M3UA| |M3UA |
|L3 | |L3 +----+ +-----+
|L2 | |L2 |SCTP| |SCTP |
|L1 | |L1 +----+ +-----+
| | | |UDP | | UDP |
+----+ +---------+ +-----+
Note: An SEP can be an SCP or SSP
In this case, the SCCP at the SG performs Global Title Translation
(GTT) for messages in either direction that do not yet have a final SS7
MTP Destination Point Code address (and possibly SCCP Subsystem). Use
of the SCCP at the SG will avoid a requirement for a GTT function
within the M3UA protocol. The SG nodal interworking function delivers
an MTP-TRANSFER indication primitive incoming from the SS7 network to
5
Internet Draft SS7 MTP3-User Adaptation Layer Oct 1999
an M3UA-resident network address translation and mapping function for
ongoing routing to the final IP destination, but only after the SCCP
GTT has been performed and a new Destination Point Code (and possibly
Subsystem) have been determined. The M3UA network address translation
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
SCCP GTT. The SG nodal interworking function would deliver these MTP-
TRANSFER request primitives to the SCCP from M3UA. The SCCP GTT will
then determine an SS7 Destination Point Code (and possibly Subsystem)
before delivery into the SS7 network. It is possible that after SCCP
GTT the DPC (and possibly Subsystem) result could represent an IP-based
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
invoked:
****** SS7 ****** IP *******
*SEP *-----------* SG *------------* ASP *
* or * * * * *
*STP * * * * *
****** ****** *******
+----+ +-----+
|SCCP| |SCCP |
+----+ +---------+ +-----+
|MTP | |MTP |M3UA| |M3UA |
|L3 | |L3 +----+ +-----+
|L2 | |L2 |SCTP| |SCTP |
|L1 | |L1 +----+ +-----+
| | | |UDP | | UDP |
+----+ +---------+ +-----+
For this case, the SG nodal interworking function operates as in Case
1.
1.3.4 UDP Port
A request will be made to IANA to assign a UDP port for M3UA.
1.4 Services Provided by the M3UA Layer
1.4.1 Support for the transport of MTP3-User/MTP boundary primitives
6
Internet Draft SS7 MTP3-User Adaptation Layer Oct 1999
The SS7 MTP Level 3 upper layer interface is retained at the ASP, so
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:
M3UA provides the ability to transfer MTP3-User messages (in this
Case, ISUP/SCCP PDUs) across SCTP associations. Note that M3UA does
not itself impose a 256 octet user information block limit as specified
by the MTP Level 3. Larger blocks can be accommodated directly by
M3UA/SCTP without the need for an upper layer segmentation/re-assembly
procedure such as in the ITU White Book SCCP [6] or ISUP segmentation
procedures. However, in the context of an SG the maximum 256 octet
block size must be followed when interworking to an SS7 network that
does not support the transfer of larger blocks to the final
destination. This will avoid ISUP or SCCP fragmentation at the SG.
However,if the SS7 network supports the Broadband MTP [7] the
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
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
MTP3-User peer in the SS7 network is not
reachable, as expected by all MTP3-User protocols.
- Providing an indication to MTP-Users at an ASP that a remote MTP3-
User peer in the SS7 network is now reachable, as expected by all MTP3-
User protocols.
- 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 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
SG and ASP
An M-ERROR primitive is used to indicate an error with a received M3UA
message (e.g., unknown parameter value).
*********
Ed Note: This section is ffs
*********
1.4.3 Support for management of SCTP associations and ASP Paths between
the SG and ASP
The M3UA layer at the SG keeps the state of all configured ASPs. A set
7
Internet Draft SS7 MTP3-User Adaptation Layer Oct 1999
of primitives between the Layer Management and the M3UA layer are
defined below for the layer Management to manage the ASP Paths and the
traffic between the SG and the ASPs.
The M3UA layer can be instructed by the Layer 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 to a peer M3UA node.
The M3UA layer may also need to inform Layer Management of the status
of the underlying SCTP associations using the M-SCTP STATUS request and
indication primitive. For example, the M3UA may inform Layer 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.
Layer Management may inform the M3UA layer of a change in the local
M3UA User status (e.g., failure, available). Also the M3UA layer may
need to inform the Layer Management of the change in 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.1 Address Translation and Mapping
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
maintain a network address translation table of incoming SS7
address/routing information keys to Application Servers. The
Application Server represents an ordered list of one or more possible
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
Internet Draft SS7 MTP3-User Adaptation Layer Oct 1999
This table is required in order to route the SS7 ISUP/SCCP messages
incoming from the SS7 network domain to the appropriate ASP in the IP
network domain. This mapping is dynamic, taking into account the
availability status of the individual ASP Paths in the list,
configuration changes, and possible fail-over mechanisms.
Possible SS7 address/routing information to be considered as a routing
key entry includes, for example, the OPC, DPC, SIO, ISUP CIC range or
SCCP Called Party Address. The network address translation function in
effect defines the SS7 address representation of the Application
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
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
traffic into streams within an SCTP association. Traffic that requires
sequencing should be assigned to the same stream. For example, SS7
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. Traffic that does not require sequencing can be assigned
to an unsequenced stream.
1.5.3 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 Application
Server 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. Congestion Control mechanisms are for
further study.
9
Internet Draft SS7 MTP3-User Adaptation Layer Oct 1999
1.5.4 Seamless Network Management Interworking.
(Ed. Note: It is ffs if this function is modeled in the M3UA layer at
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
Cluster status in their respective domains in order to perform as
seamless as possible interworking of the two domains. For example, SG
knowledge of the availability and/or congestion status of Application
Server Clusters and SS7 nodes must be maintained and disseminated in
the respective networks so that end-to-end operation is transparent to
the communicating SCN protocol peers at the SS7 node and ASP.
When an SG determines that the transport of SS7 messages to an
Application Server Cluster is encountering congestion, the SG may
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
Application Server Cluster is interrupted, the SG may optionally issue
MTP Transfer Prohibited (TFP) messages to the adjacent SS7 nodes which
are generating signalling traffic to the affected Application Server
Clusters per current MTP procedures [2].
When an SG determines that the transport of SS7 messages to an
Application Server Cluster can now be resumed, the SG may optionally
issue MTP Transfer Allowed (TFA) messages to the adjacent SS7 nodes to
resume signalling traffic to the affected Application Server Clusters
per current MTP procedures [2].
Triggering of the MTP-3 management messages is an implementation
dependent function.
1.5.5 Management Inhibit/Uninhibit
Local Management may wish to stop traffic across an SCTP association in
order to temporarily remove the association from service or to perform
testing and maintenance activity. The function could optionally be
used to manage the start of traffic on to a newly-available SCTP
association.
1.5.6 Active Association Control
An Application Server Process can have associated back-up process.
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
Internet Draft SS7 MTP3-User Adaptation Layer Oct 1999
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 [5]
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
The general message format includes a Common Message Header together
with a list of zero or more parameters as defined by the Message Type.
For forward compatability, 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 7 8 15 16 31
+-------+-------+---------------+
| Vers | Spare | Msg Type |
+-------+-------+---------------+
| Message Length |
+---------------+---------------+
2.1.1 M3UA Protocol Version
The version field (vers) contains the version of the M3UA adaptation
11
Internet Draft SS7 MTP3-User Adaptation Layer Oct 1999
layer. The supported versions are:
01 Release 1.0 protocol
2.1.2 Message Types
The following list contains the message types for the defined messages.
ISUP/SCCP Tunneling (ITUN) Messages
Data Message 0101
SS7 Signalling 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 ITUN Messages
The following section describes the ITUN messages and parameter
contents. The general ITUN 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, normally including the complete MTP3 Routing Label.
The Data message contains the following parameters:
SCN PROTOCOL IDENTIFIER (Optional)
INTERFACE IDENTIFIER (Optional)
PROTOCOL DATA
12
Internet Draft SS7 ISUP/SCCP Tunneling Oct 1999
The format for the Data Message parameters is as follows:
0 15 16 31
+---------------+---------------+
| Tag (0xx) | Length |
+---------------+---------------+
| SCN Protocol Identifier* |
+---------------+---------------+
| Tag (0xx) | Length |
+---------------+---------------+
| Interface Identifier* |
+-------------------------------+
| Tag (0xx) | Length |
+---------------+---------------+
...
| 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.
***********
ED Note: The SCN Protocol Identifier parameter format is for further
study. The protocol identifier values should be maintained outside of
this document by IANA to allow registration of values without re-
issuing the adaptation layer protocol document. We need decision on
encoding of mime-type value or fixed string/integer. If mime-type need
to refer to "draft-ietf-sigtran-mime-isup.txt" for an example of an
application/ISUP media type defined according to the rules defined in
RFC 2048.
************
The Interface Identifier optionally identifies the physical interface,
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
Internet Draft SS7 ISUP/SCCP Tunneling Oct 1999
**************
Ed Note: The identification of the interface can be very useful at MGCs
that are receiving signaling from multiple national networks and cannot
rely on the SS7 NI value to tell their signalling traffic apart.
However, no procedures are specified.
**************
The Protocol Data field contains the MTP3-User application message,
which is an MTP-TRANSFER primitive. As defined for a specific value of
the Protocol Identifier, this will include the MTP-User Data and
normally includes the MTP Routing Label (SS7 OPC, DPC, SLS), and the
SIO (Network Indicator & optional Message Priority codes).
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 the ASP to indicate that
the SG has determined that an SS7 destination is unreachable. The MTP-
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)
Affected Destination Point Code
Info String (Optional)
The format for DUNA parameter is as follows:
0 7 8 15 16 31
+---------------+---------------+
| Tag (0xx) | Length |
+---------------+---------------+
| Protocol Identifier* |
+---------------+---------------+
| Tag (0xx) | Length |
+---------------+---------------+
| Affected DPC |
+---------------+---------------+
| Tag (0xx) | Length |
+---------------+---------------+
| INFO String* |
+-------------------------------+
The Protocol Identifier parameter is defined similarly to the SCN
14
Internet Draft SS7 ISUP/SCCP Tunneling Oct 1999
Protocol Id 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 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
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 can 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 the ASP 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)
Affected Destination Point Code
Info String (Optional)
The parameter format and definitions for the DAVA message is the same
as for the DUNA message (See Section 2.3.2.2).
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 is 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
interruption of the transport path to the SG.
Protocol Identifier (Optional)
Affected Destination Point Code
Info String (Optional)
The format and description of DAUD parameters is the same as for the
DUVA 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
Internet Draft SS7 MTP3-User Adaptation Layer Oct 1999
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)
The SCON message can be sent from the SG to the ASP 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)
Affected Destination Point Code
Info String (Optional)
Congestion Level (Optional)
0 7 8 15 16 31
+---------------+---------------+
| Tag (0xx) | Length |
+---------------+---------------+
| Protocol Identifier* |
+---------------+---------------+
| Tag (0xx) | Length |
+---------------+---------------+
| Affected DPC |
+---------------+---------------+
| Tag (0xx) | Length |
+---------------+---------------+
| INFO String* |
+-------------------------------+
| Tag (0xx) | Length |
+---------------+---------------+
| Congestion Level* |
+-------------------------------+
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 valid values for the optional Congestion Level are shown in the
following table.
16
Internet Draft SS7 ISUP/SCCP Tunneling Oct 1999
Define Value Description
Level 0 0000 No Congestion or Undefined
Level 1 0001 Congestion Level 1
Level 2 0002 Congestion Level 2
Level 3 0003 Congestion Level 3
The congestion levels are as defined in the national congestion method
in the ITU MTP recommendation [2] or in the ANSI MTP standard [10].
For MTPs without congestion levels, for example the ITU international
method, the parameter is omitted.
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)
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)
Affected Destination Point Code
Info String (Optional)
Reason
The format for optional DUPU message is as follows:
0 7 8 15 16 31
+---------------+---------------+
| Tag (0xx) | Length |
+---------------+---------------+
| Protocol Identifier* |
+---------------+---------------+
| Tag (0xx) | Length |
+---------------+---------------+
| Affected DPC |
+---------------+---------------+
| Tag (0xx) | Length |
+---------------+---------------+
| INFO String* |
+-------------------------------+
| Tag (0xx) | Length |
+---------------+---------------+
| Reason |
+-------------------------------+
17
Internet Draft SS7 MTP3-User Adaptation Layer Oct 1999
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 valid values for Reason are shown in the following table.
Define Value Description
UPU-Unknown 0x4 MTP User Part Unavailable, No Reason Given
UPU-Unequipped 0x5 MTP User Part Unavailable, Unequipped
UPU-Inaccessible 0x6 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.1 ASP Up (ASPUP)
The ASP-UP 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)
SCN Protocol Identifier (optional)
INFO String (optional)
The format for the ASPUP message is as follows:
0 15 16 31
+---------------+---------------+
| Tag (0x2) | Length |
+---------------+---------------+
| Adaptation Layer Identifier* |
+---------------+---------------+
| Tag (0x3) | Length |
+---------------+---------------+
| Protocol Identifier* |
+---------------+---------------+
| Tag (0x4) | Length |
+---------------+---------------+
| INFO String* |
+---------------+---------------+
18
Internet Draft SS7 MTP3-User Adaptation Layer Oct 1999
The format and description of the optional Protocol Identifier and Info
String parameters is the same as for the DUVA message (See Section
2.3.2.1.)
The optional Adaptation Layer Identifier 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-DN 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:
INFO String (Optional)
The format for the ASPDN message is as follows:
0 15 16 31
+---------------+---------------+
| Tag (0x4) | Length |
+---------------+---------------+
| INFO String* |
+---------------+---------------+
****************
Ed Note: Need to add a reason code parameter. Reasons could be failure
or 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
the active ASP to be used from within a list of primary and back-up
ASPs for a particular AS.
The ASPAC message contains the following parameters:
INFO String (Optional)
The format for the ASPAC message is as follows:
19
Internet Draft SS7 MTP3-User Adaptation Layer Oct 1999
0 15 16 31
+---------------+---------------+
| Tag (0x4) | Length |
+---------------+---------------+
| INFO String* |
+---------------+---------------+
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 the the active ASP to be used from within a list of primary
and back-up ASP for a particular AS. The SG will respond with an ASPIA
message and either discard incoming messages or buffer for a timed
period and then discard.
The ASPIA message contains the following parameters:
INFO String (Optional)
The format for the ASPIA message is as follows:
0 15 16 31
+---------------+---------------+
| Tag (0x4) | Length |
+---------------+---------------+
| INFO String* |
+---------------+---------------+
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 7 8 15 16 31
+---------------+---------------+
| Error Code |
+---------------+---------------+
20
Internet Draft SS7 MTP3-User Adaptation Layer Oct 1999
The Error Code can be one of the following values:
Invalid Version 0x1
Invalid Interface Identifier 0x2
Invalid SCN Version 0x3
Invalid Adaptation Layer Identifier 0x4
Invalid Stream Identifier 0x5
Invalid Message Type 0x6
3.0 Procedures
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 M3UA services 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 a primitive from the upper layer, the M3UA layer will
send the corresponding ITUN or SSNM message (see Section 2) to its
peer. The M3UA layer must fill in various fields of the common and
specific headers correctly. In addition the message needs to be sent
on the appropriate SCTP stream.
3.1.2 Receipt of ITUN or SSNM Messages from the Peer M3UA
On receiving ITUN or SSNM messages from the remote M3UA Peer, the M3UA
layer invokes the appropriate primitive indications to the M3UA-User
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
the local layer management.
3.3 Procedures to support the M3UA services in Section 1.4.3
21
Internet Draft SS7 MTP3-User Adaptation Layer Oct 1999
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
well as the state of the related ASs.
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. At most one ASP per AS can be in the active state.
Figure 4: ASP State Transition Diagram
+-------------+
|-------->| |
| | ASP-ACTIVE |
| +-------------+
| ^ |
| ASP | | ASP
| Active | | Inactive
| | v
| +-------------+
ASP Down / | | |
SCTP CDI | | ASP-UP |
| +-------------+
| ^ |
| ASP | | ASP Down /
| Up | | SCTP CDI
| | v
| +-------------+
| | |
|-------->| |
| ASP-DOWN |
+-------------+
22
Internet Draft SS7 MTP3-User Adaptation Layer Oct 1999
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.
AS-PENDING: The Active ASP has transitioned from active to inactive or
down. 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.
23
Internet Draft SS7 MTP3-User Adaptation Layer Oct 1999
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".
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
24
Internet Draft SS7 MTP3-User Adaptation Layer Oct 1999
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
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 MGC even if that path was already marked as UP at the SG.
The paths are controlled by the MGC. The SG will only send ASPUP in
response to the reception of a ASPUP message.
The MGC will send ASPUP messages every 2 (add text regarding this being
a configurable timer) seconds until the path comes up (i.e. until it
receives a ASPUP message from the SG for that path). The MGC may decide
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
ASP maintenance messages (ASPIA or ASPAC) or M2UA messages or it will
risk message loss. The ASPUP message received from the SG is not
acknowledged by the MGC.
3.3.3.2 ASP Down
The SG will mark the ASP as down and send a ASPDN message to the MGC if
one of the following events occur:
- a ASP Down(ASPDN) message is received from the MGC,
- the ASP is locked by local maintenance.
The SG will also send a ASPDN message when the ASP is already down and
a ASPDN) message is received from the MGC.
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
Internet Draft SS7 MTP3-User Adaptation Layer Oct 1999
(for example, during a MGC node failover), 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 a 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
are, by default, down.
4.0 Examples of M3UA Procedures
4.1 Establishment of associations between an SG and an ASP
An example of the message flows for establishing an active association
between an SG and ASP is shown below.
SG ASP1
<----------- ASP Up
ASP Up ---------->
(ACK)
<----------- ASP Active
ASP Active ---------->
(ACK)
An example of message flows for establishment of associations with two
ASPs and the message flows for take-over of the primary (ASP1) by the
secondary (ASP2).
26
Internet Draft SS7 MTP3-User Adaptation Layer Oct 1999
SG ASP1 ASP2
<----------- ASP Up
ASP Up ---------->
(ACK)
<------------------------------ ASP Up
ASP Up ------------------------------>
(ACK)
<----------- ASP Active
ASP Active ---------->
(ACK)
...
<----------- ASP Inactive
ASP Inactive ---------->
(ACK)
(this message is optional)
ASP Inactive ------------------------------>
<------------------------------ ASP Active
ASP Active ------------------------------>
(ACK)
4.2 M3UA/MTP3-User Boundary Examples
*****************
Ed Note: Text to be added
*****************
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 for his valuable comments
and suggestions.
7.0 References
[1] ITU-T Recommendation Q.700, 'Introduction To ITU-T Signalling
System No. 7 (SS7)'
[2] ITU-T Recommendation Q.701-Q.705, 'Signalling System No. 7
(SS7) - Message Transfer Part (MTP)'
[3] ITU-T Recommendation Q.2140 'B-ISDN ATM Adaptation Layer -
27
Internet Draft SS7 MTP3-User Adaptation Layer Oct 1999
Service Specific Coordination Function for signaling at the Network
Node Interface (SSCF at NNI)
[4] ITU-T Recommendation Q.2110 'B-ISDN ATM Adaptation Layer -
Service Specific Connection Oriented Protocol (SSCOP)
[5] Simple Control Transport Protocol
draft-ietf-sigtran-sctp-00.txt, Sept. 1999, Work in Progress
[6] ITU-T Recommendation Q.711-714 'Signalling System No. 7
(SS7) - Signaling Connection Control Part (SCCP)'
[7] ITU-T Recommendation Q.2210 'B-ISDN MTP'
[8] ITU-T Recommendation Q.xxxx 'ISUP BICC'
[9] ITU-T Recommendation Q.771-775 'Signalling System No. 7
(SS7) - Transaction Capabilities (TCAP)
[10] ANSI T1.111 'Signaling System Number 7 - Message Transfer Part'
5.0 Author's Addresses
Lyndon Ong
Nortel Networks
4401 Great America Pkwy
Santa Clara, CA, USA 95054
long@nortelnetworks.com
Greg Sidebottom
Nortel Networks
3685 Richmond Rd,
Nepean, Ontario, Canada K2H 5B7
gregside@nortelnetworks.com
Guy Mousseau
Nortel Networks
3685 Richmond Rd
Nepean, Ontario, Canada K2H 5B7
Ian Rytina
Ericsson Australia
37/360 Elizabeth Street
Melbourne, Victoria 3000, Australia
ian.rytina@ericsson.com
Hanns Juergen Schwarzbauer
SIEMENS AG
Hofmannstr. 5181359
Munich, Germany
HannsJuergen.Schwarzbauer@icn.siemens.de
28
Internet Draft SS7 MTP3-User Adaptation Layer Oct 1999
Ken Morneault
Cisco Systems Inc.
13615 Dulles Technology Drive
Herndon, VA, USA 20171
EMail: kmorneau@cisco.com
Malleswar Kalla
Telcordia Technologies
MCC 1J211R
445 South Street
Morristown, NJ, USA 07960
EMail: kalla@research.telcordia.com
This draft expires April 2000.
29
Datatracker
Report a datatracker bug
draft-ietf-sigtran-m3ua-00
Internet-Draft
| Document | Document type |
This is an older version of an Internet-Draft that was ultimately published as RFC 3332.
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | |||
| RFC stream |
|
||
| Other formats | |||
| Additional resources | Mailing list discussion |