draft-ietf-sigtran-m2ua-02.txt   draft-ietf-sigtran-m2ua-03.txt 
Network Working Group Ken Morneault Network Working Group Ken Morneault
INTERNET-DRAFT Cisco Systems INTERNET-DRAFT Cisco Systems
Mallesh Kalla Mallesh Kalla
Telcordia Telcordia
Greg Sidebottom Greg Sidebottom
Nortel Networks Nortel Networks
Ram Dantu Ram Dantu
IPMobile
Tom George Tom George
Alcatel Alcatel
Expires in six months December 1999 Expires in six months March 2000
SS7 MTP2-User Adaptation Layer SS7 MTP2-User Adaptation Layer
<draft-ietf-sigtran-m2ua-02.txt> <draft-ietf-sigtran-m2ua-03.txt>
Status of This Memo Status of This Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026. Internet-Drafts are working provisions of Section 10 of RFC 2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 1, line 46 skipping to change at page 1, line 47
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
'1id-abstracts.txt' listing contained in the Internet- Drafts Shadow '1id-abstracts.txt' listing contained in the Internet- Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast). ftp.isi.edu (US West Coast).
Abstract Abstract
This Internet Draft defines a protocol for backhauling of SS7 MTP2 This Internet Draft defines a protocol for backhauling of SS7 MTP2
User signaling messages over IP using the Simple Control Transmission User signaling messages over IP using the Simple Control Transmission
Protocol (SCTP). One application of this protocol would be to use it Protocol (SCTP). This protocol would be used between a Signaling
between a Signaling Gateway (SG) and Media Gateway Controller (MGC). Gateway (SG) and Media Gateway Controller (MGC). It is assumed that
In this case, the Signaling Gateway would be acting as a Signaling
Link Terminal. Another application of this protocol would be to use
it between a SG and a SCP. In either application, it is assumed that
the SG receives SS7 signaling over a standard SS7 interface using the the SG receives SS7 signaling over a standard SS7 interface using the
SS7 Message Transfer Part (MTP) to provide transport. SS7 Message Transfer Part (MTP) to provide transport. The Signaling
Gateway would act as a Signaling Link Terminal.
TABLE OF CONTENTS TABLE OF CONTENTS
1. Introduction..............................................2 1. Introduction..............................................2
1.1 Scope..................................................2 1.1 Scope..................................................2
1.2 Terminology............................................3 1.2 Terminology............................................3
1.3 Signaling Transport Architecture.......................3 1.3 Signaling Transport Architecture.......................3
1.4 Services Provide by the M2UA Adaptation Layer..........4 1.4 Services Provide by the M2UA Adaptation Layer..........6
1.5 Function Provided by the M2UA Layer....................6 1.5 Function Provided by the M2UA Layer....................8
1.6 Definition of the M2UA Boundaries......................7 1.6 Definition of the M2UA Boundaries......................9
2. Protocol Elements.........................................8 2. Protocol Elements.........................................9
2.1 Common Message Header..................................8 2.1 Common Message Header.................................10
2.2 M2UA Message Header....................................9 2.2 M2UA Message Header...................................11
2.3 M2UA Messages.........................................10 2.3 M2UA Messages.........................................11
3. Procedures...............................................17 3. Procedures...............................................20
3.1 Procedures to Support Service in Section 1.4.1........17 3.1 Procedures to Support Service in Section 1.4.1........20
3.2 Procedures to Support Service in Section 1.4.2........17 3.2 Procedures to Support Service in Section 1.4.2........21
3.3 Procedures to Support Service in Section 1.4.3........17 3.3 Procedures to Support Service in Section 1.4.3........21
4. Examples of MTP2 User Adaptation (M2UA) Procedures.......22 4. Examples of MTP2 User Adaptation (M2UA) Procedures.......26
4.1 Establishment of associations between SG and MGC......22 4.1 Establishment of associations between SG and MGC......26
examples examples
4.2 MTP Level 2 / MTP Level 3 Boundary Examples...........23 4.2 MTP Level 2 / MTP Level 3 Boundary Examples...........28
4.3 Layer Management Communication Examples................25 4.3 Layer Management Communication Examples...............29
5. Security.................................................31 5. Security.................................................30
6. Acknowledgements.........................................31 6. IANA Considerations......................................31
7. References...............................................31 7. Acknowledgements.........................................31
8. Author's Addresses.......................................32 8. References...............................................32
9. Author's Addresses.......................................33
1. Introduction 1. Introduction
1.1 Scope 1.1 Scope
There is a need for SCN signaling protocol delivery from an Signaling There is a need for SCN signaling protocol delivery from an Signaling
Gateway (SG) to a Media Gateway Controller (MGC) or IP Signaling Point Gateway (SG) to a Media Gateway Controller (MGC) or IP Signaling Point
(IPSP). The delivery mechanism should meet the following criteria: (IPSP). The delivery mechanism should meet the following criteria:
* Support for MTP Level 2 / MTP Level 3 interface boundary * Support for MTP Level 2 / MTP Level 3 interface boundary
* Support for communication between Layer Management modules on SG and * Support for communication between Layer Management modules on SG and
MGC MGC
* Support for management of active associations between the SG and MGC * Support for management of active associations between the SG and MGC
In other words, the Signaling Gateway will transport MTP Level 3 messages In other words, the Signaling Gateway will transport MTP Level 3
to a Media Gateway Controller (MGC) or IP Signaling Point (IPSP). In the messages to a Media Gateway Controller (MGC) or IP Signaling Point
case of delivery from an SG to an IPSP, the SG and IPSP function as (IPSP). In the case of delivery from an SG to an IPSP, both the SG and
traditional SS7 nodes using the IP network as a new type of SS7 link. IPSP function as traditional SS7 nodes using the IP network as a new
This allows for full MTP Level 3 message handling and network management type of SS7 link. This allows for full MTP Level 3 message handling
capabilities. and network management capabilities.
1.2 Terminology 1.2 Terminology
MTP2-User - A protocol that normally uses the services of MTP Level 2 MTP2-User - A protocol that normally uses the services of MTP Level 2
(i.e. MTP3). (i.e. MTP3).
Interface - For the purposes of this document, an interface is a SS7 Interface - For the purposes of this document, an interface is a SS7
signaling link. signaling link.
Association - An association refers to a SCTP association. The Association - An association refers to a SCTP association. The
association will provide the transport for the delivery of protocol association will provide the transport for the delivery of protocol
data units for one or more interfaces. data units for one or more interfaces.
Stream - A stream refers to a SCTP stream.
Backhaul - Refers to the transport of signaling from the point of Backhaul - Refers to the transport of signaling from the point of
interface for the associated data stream (i.e., SG function in the MGU) interface for the associated data stream (i.e., SG function in the MGU)
back to the point of call processing (i.e., the MGCU), if this is not back to the point of call processing (i.e., the MGCU), if this is not
local [4]. local [4].
Application Server (AS) - A logical entity serving a specific application Application Server (AS) - A logical entity serving a specific application
instance. An example of an Application Server is a MGC handling the instance. An example of an Application Server is a MGC handling the
MTP Level 3 and call processing for SS7 links terminated by the Signaling MTP Level 3 and call processing for SS7 links terminated by the
Gateways. Practically speaking, an AS is modeled at the SG as an ordered Signaling Gateways. Practically speaking, an AS is modeled at the SG
list of one or more related Application Server Processes (e.g., primary, as an ordered list of one or more related Application Server Processes
secondary, tertiary, Ó). (e.g., primary, secondary, tertiary, ...).
Application Server Process (ASP) - A process instance of an Application Application Server Process (ASP) - A process instance of an Application
Server. Examples of Application Server Processes are primary or backup Server. Examples of Application Server Processes are primary or backup
MGC instances. MGC instances.
Application Server Process Path (ASP Path or just Path) - A Path to a 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 remote Application Server Process instance. A Path maps 1:1 to an SCTP
association. association.
Fail-over - The capability to re-route signaling traffic as required Fail-over - The capability to re-route signaling traffic as required
to a next-preferred Application Server Process within an Application to an alternate Application Server Process, or group of ASPs, within
Server in the event of failure or unavailability of the currently used an Application Server in the event of failure or unavailability of a
Application Server Process (e.g., from primary MGC to back-up MGC). currently used Application Server Process. Fail-back may apply upon
Fail-over may also apply upon the return to service of a previously the return to service of a previously unavailable Application Server
unavailable Application Server Process. Process.
Signaling Link Terminal (SLT) - Refers to the means of performing all Signaling Link Terminal (SLT) - Refers to the means of performing all
of the functions defined at MTP level 2 regardless of their of the functions defined at MTP level 2 regardless of their
implementation [2]. implementation [2].
Network Byte Order: Most significant byte first, a.k.a Big Endian.
Layer Management - Layer Management is a nodal function in an SG or
ASP that handles the inputs and outputs between the M2UA layer and a
local management entity.
Host - The computing platform that the ASP process is running on.
Stream - A stream refers to an SCTP stream.
1.3 Signaling Transport Architecture 1.3 Signaling Transport Architecture
The architecture that has been defined [4] for SCN signaling transport The framework architecture that has been defined for SCN signaling
over IP uses multiple components, including an IP transport transport over IP [5] uses multiple components, including a signaling
protocol, a signaling common transport protocol (SCTP) and an adaptation common transport protocol and an adaptation module to support the
module to support the functions expected by a particular SCN signaling services expected by a particular SCN signaling protocol from its
protocol from its underlying protocol layer. underlying protocol layer.
In reference to the SIGTRAN framework architecture [4], this document Within this framework architecture, this document defines a SCN
defines a SCN adaptation module that is suitable for the transport of adaptation module that is suitable for the transport of SS7 MTP2 User
SS7 MTP2 User. The only SS7 MTP2 User is MTP3. messages. The only SS7 MTP2 User is MTP3. The M2UA uses the services
of the Simple Common Transport protocol [6] as the underlying reliable
signaling common transport protocol.
1.3.1 Case 1: SG to MGC In a Signaling Gateway, it is expected that the SS7 MTP2-User signaling
is transmitted and received from the PSTN over a standard SS7 network
interface, using the SS7 Message Transfer Part Level 1 and Level 2 [3,4]
to provide reliable transport of the MTP3-User 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 MTP2-User signaling
messages to and from an Application Server Process where the peer MTP2-
User protocol layer exists.
1.3.1 Example - SG to MGC
In a Signaling Gateway, it is expected that the SS7 signaling is In a Signaling Gateway, it is expected that the SS7 signaling is
received over a standard SS7 network termination, using the SS7 Message received over a standard SS7 network termination, using the SS7 Message
Transfer Part (MTP) to provide transport of SS7 signaling messages to Transfer Part (MTP) to provide transport of SS7 signaling messages to
and from an SS7 Signaling End Point (SEP) or SS7 Signaling Transfer and from an SS7 Signaling End Point (SEP) or SS7 Signaling Transfer
Point (STP). In other words, the SG acts as a Signaling Link Terminal Point (STP). In other words, the SG acts as a Signaling Link Terminal
(SLT) [2]. The SG then provides interworking of transport functions (SLT) [2]. The SG then provides interworking of transport functions
with IP Signaling Transport, in order to transport the MTP3 signaling with IP Signaling Transport, in order to transport the MTP3 signaling
messages to the MGC where the peer MTP3 protocol layer exists, as shown messages to the MGC where the peer MTP3 protocol layer exists, as shown
below: below:
****** SS7 ****** IP ******* ****** SS7 ****** IP *******
*SEP *-----------* SG *-------------* MGC * *SEP *-----------* SG *-------------* MGC *
****** ****** ******* ****** ****** *******
+----+ +----+ +----+
|S7UP| |S7UP| |S7UP|
+----+ +----+ +----+
+----+ |MTP | |MTP + |MTP |
|S7UP| |L3 | | L3 | (NIF) |L3 |
+----+ +----+----+ +----+ +----+ +----+----+ +----+
|MTP | |MTP |M2UA| |M2UA| |MTP | |MTP |M2UA| |M2UA|
|L3 | | +----+ +----+ | | | +----+ +----+
|L2 | |L2 |SCTP| |SCTP| |L2 | |L2 |SCTP| |SCTP|
|L1 | |L1 +----+ +----+ |L1 | |L1 +----+ +----+
| | | |UDP | |UDP | | | | |IP | |IP |
+----+ +---------+ +----+ +----+ +---------+ +----+
NIF - Nodal Interworking Function
SEP - SS7 Signaling Endpoint SEP - SS7 Signaling Endpoint
UDP - User Datagram Protocol IP - Internet Protocol
SCTP - Simple Control Transmission Protocol SCTP - Simple Control Transmission Protocol
(Refer to Reference [5]) (Refer to Reference [5])
Figure 1: M2UA in the SG to MGC Application Figure 1 M2UA in the SG to MGC Application
Note: STPs may be present in the SS7 path between the SEP and the SG. Note: STPs may be present in the SS7 path between the SEP and the SG.
1.3.2 Case 2: SG to IPSP 1.3.2 Signaling Network Architecture
The following figure shows the seamless interworking at the MTP3 A Signaling Gateway will support the transport of MTP2-User signaling
layer. MTP3 is adapted to the SCTP layer using MTP2 User Adaptation traffic received from the SS7 network to one or more distributed ASPs
Layer (M2UA). In this example, the Signaling Gateway could be an STP. (e.g., MGCs). Clearly, the M2UA protocol description cannot in itself
All the primitives between MTP3 and MTP2 are supported by M2UA. Any meet any performance and reliability requirements for such transport.
of the nodes in the diagram could have SCCP or other SS7 user parts. 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. However, the M2UA protocol must
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.
****** SS7 ****** IP ************ To meet the stringent SS7 signaling reliability and performance
*SEP *-------* SG *-------------* IPSP * 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 node and an IP ASP. Depending
of course on the reliability of the SG and ASP functional elements, this
can typically be met by the spreading links in a linkset across SGs, the
provision of redundant QOS-bounded IP network paths for SCTP Associations
between SCTP End Points, and redundant Hosts. The distribution of ASPs
within the available Hosts is also important. For a particular
Application Server, the related ASPs should be distributed over at least
two Hosts.
+----+ +---------+ An example physical network architecture relevant to carrier-grade
|TCAP| | TCAP | operation in the IP network domain is shown in Figure 2 below:
+----+ +---------+
|SCCP| | SCCP |
+----+ +---------+ +---------+
|MTP | | MTP | | MTP |
|L3 | | L3 | | L3 |
|L2 | +----+----+ +----+----+
|L1 | |MTP |M2UA| |M2UA|MTP |
| | |L2 +----+ +----+L2 |
| | |L1 |SCTP| |SCTP|L1 |
| | | |----| |----| |
| | | |UDP | |UDP | |
+----+ +----+----+ +----+----+
SEP - SS7 Signaling Endpoint ******** **************
IPSP - IP Signaling Point * *_________________________________________* ******** * Host1
UDP - User Datagram Protocol * * _________* * ASP1 * *
SCTP - Simple Control Transmission Protocol * SG1 * SCTP Associations | * ******** *
(Refer to Reference [5]) * *_______________________ | * *
******** | | **************
| |
******** | |
* *_______________________________|
* * |
* SG2 * SCTP Associations |
* *____________ |
* * | |
******** | | **************
| |_________________* ******** * Host2
|____________________________* * ASP1 * *
* ******** *
* *
**************
.
.
.
Figure 2: M2UA in the SG to IPSP Application Figure 2 - Physical Model Example
In this case, the SCTP association acts as an SS7 link between the SG For carrier grade networks, Operators should ensure that under failure
and the IPSP. The association contains two streams, one in each or isolation of a particular ASP, stable calls or transactions are not
direction. The IPSP may or may not have a termination to the SS7 lost. This implies that ASPs need, in some cases, to share the call/-
network. transaction state or be able to pass the call/transaction state between
each other. Also, in the case of ASPs performing call processing,
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 UDP port 1.3.4 ASP Fail-over Model and Terminology
A request will be made to IANA to assign a UDP port for M2UA. The M2UA supports ASP fail-over functions in order to support a high
availability of call and transaction processing capability. All MTP2-
User messages incoming to an SG from the SS7 network are assigned to a
unique Application Server, based on the Interface Identifier of the
message.
The Application Server is in practical terms a list of all ASPs currently
registered to process MTP2-User messages from certain Interface
Identifiers. One or more ASPs in the list are normally active (i.e.,
handling traffic) while any others may be unavailable or inactive, to be
possibly used 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 in the list, resident in separate hosts 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 Host1 or ASP1 in Host2. The AS list at SG1 might look like this:
Interface Identiers - Application Server #1
ASP1/Host1 - State=Up, Active
ASP1/Host2 - State=Up, Inactive
In this ˘1+1÷ redundancy case, ASP1 in Host1 would be sent any incoming
message for the Interface Identifiers registered. ASP1 in Host2 would
normally be brought to the active state upon failure of, or loss of
connectivity to, ASP1/Host1. In this example, both ASPs are Up, meaning
that the related SCTP association and far-end M2UA peer is ready.
The AS List at SG1 might also be set up in loadshare mode:
Interface Identifiers - Application Server #1
ASP1/Host1 - State = Up, Active
ASP1/Host2 - State = Up, Active
In this case, both the ASPs would be sent a portion of the traffic.
In the process of fail-over or fail-back, it is recommended that in the
case of ASPs supporting call processing, stable calls do not fail. It
is possible that calls in ˘transition÷ may fail, although measures of
communication between the ASPs involved can be used to mitigate this.
For example, the two ASPs may share call state via shared memory, or may
use an ASP to ASP protocol to pass call state information.
1.3.5 Client/Server Model
The SG takes on the role of server while the ASP is the client. ASPs
must initiate the SCTP association to the SG.
The SCTP (and UDP/TCP) Registered User Port Number Assignment for M2UA
is 2904.
1.4 Services Provided by the M2UA Adaptation Layer 1.4 Services Provided by the M2UA Adaptation Layer
The SS7 MTP3/MTP2(MTP2-User) interface is retained at the termination The SS7 MTP3/MTP2(MTP2-User) interface is retained at the termination
point in the IP network, so that the M2UA protocol layer is required to point in the IP network, so that the M2UA protocol layer is required to
provide the equivalent set of services to its users as provided by the provide the equivalent set of services to its users as provided by the
MTP Level 2 to MTP Level 3. MTP Level 2 to MTP Level 3.
This includes the following services: This includes the following services:
skipping to change at page 6, line 37 skipping to change at page 8, line 24
that SS7 link(s) have gone out-of-service. that SS7 link(s) have gone out-of-service.
Link State Link State
Provides the ability to request state change or information on a Provides the ability to request state change or information on a
per link basis. Some examples would be the forcing of Local Processor per link basis. Some examples would be the forcing of Local Processor
Outage or flushing buffers. Outage or flushing buffers.
Link Status Link Status
Provides a means for asychronous notification of link state changes to Provides a means for asynchronous notification of link state changes to
be reported to the upper layer (MTP Level 3). An examples would be the be reported to the upper layer (MTP Level 3). An example would be the
reporting of remote processor reporting of remote processor outage event.
outage event.
Data Retrieval Data Retrieval
Provides a mechanism to perform SS7 link changeover procedure in Provides a mechanism to perform SS7 link changeover procedure in
the case of a SS7 link failure. the case of a SS7 link failure.
1.4.2 Support for communication between Layer Management modules 1.4.2 Support for communication between Layer Management modules
on SG and MGC on SG and MGC
It is envisioned that the M2UA layer needs to provide some messages that It is envisioned that the M2UA layer needs to provide some messages that
skipping to change at page 7, line 48 skipping to change at page 9, line 27
The M-ASP STATUS primitive is used by the Layer Management to indicate The M-ASP STATUS primitive is used by the Layer Management to indicate
the status of the local M2UA user to the M2UA layer. the status of the local M2UA user to the M2UA layer.
1.5 Functions Provided by the M2UA Layer 1.5 Functions Provided by the M2UA Layer
1.5.1 Mapping 1.5.1 Mapping
The M2UA layer must maintain a map of a Interface ID to a physical The M2UA layer must maintain a map of a Interface ID to a physical
interface on the Signaling Gateway. A physical interface would be a interface on the Signaling Gateway. A physical interface would be a
V.35 line, T1 line/timeslot, E1 line/timeslot, etc. The M2UA layer V.35 line, T1 line/timeslot, E1 line/timeslot, etc. The M2UA layer
must also maintain a map of Interface ID to SCTP association and to a must also maintain a map of Interface Identifier to SCTP association
stream within the association. and to the related stream within the association.
1.5.2 Status of ASPs
The M2UA layer on the Signaling Gateway must maintain the state of one or
more Application Server Process(es) it is associated with. The state of
an ASP changes because of reception of peer-to-peer messages or reception
of indications from the local SCTP association. ASP state transition
procedures are described in Section Section 3.3.
1.5.3 Flow Control / Congestion 1.5.2 Flow Control / Congestion
It is possible for the M2UA layer to be informed of IP network congestion It is possible for the M2UA layer to be informed of IP network congestion
by means of an implementation-dependent function (i.e. an indication by means of an implementation-dependent function (i.e. an indication
from the SCTP). If the M2UA layer receives this indication, the action(s) from the SCTP). If the M2UA layer receives this indication, the action(s)
taken are implementation dependent. taken are implementation dependent.
1.5.4 SCTP Stream Management 1.5.3 SCTP Stream Management
SCTP allows user specified number of streams to be opened during the SCTP allows user specified number of streams to be opened during the
initialization. It is the responsibility of the M2UA layer to ensure initialization. It is the responsibility of the M2UA layer to ensure
proper management of these streams. SCTP streams provide a means for proper management of these streams. SCTP streams provide a means for
avoiding head of line blocking. For that reason, a stream will be used avoiding head of line blocking. For that reason, a stream should be used
per SS7 signaling link terminated by the Signaling Gateway. The SS7 per SS7 signaling link terminated by the Signaling Gateway. The SS7
signaling link can be identified by the optional Interface Identifier signaling link can be identified by the optional Interface Identifier
in the M2UA specific message header (refer to Section 2.2). in the M2UA specific message header (refer to Section 2.2).
1.5.5 Seamless SS7 Network Management Interworking 1.5.4 Seamless SS7 Network Management Interworking
If the SG loses the SCTP association to the MGC, it should follow If the SG loses the SCTP association to the MGC, it should follow
MTP 2 processor outage procedures [2]. MTP 2 processor outage procedures [2].
1.5.6 Management Inhibit/Uninhibit 1.5.5 Management Inhibit/Uninhibit
Local Management may wish to stop traffic across an SCTP association in Local Management at an ASP or SG may wish to stop traffic across an
order to temporarily remove the association from service or to perform SCTP association in order to temporarily remove the association from
testing and maintenance activity. The function could optionally be used service or to perform testing and maintenance activity. The function
to manage the start of traffic on to a newly-available SCTP association. could optionally be used to control the start of traffic on to a newly-
available SCTP association.
1.5.6 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, M2UA peer
protocol is required to control which ASP is currently active. The
ordered list of ASPs within a logical Application Server is kept
updated in the SG to reflect the active Application Server Process(es).
1.6 Definition of the M2UA Boundaries 1.6 Definition of the M2UA Boundaries
1.6.1 Definition of the M2UA / MTP Level 3 boundary 1.6.1 Definition of the M2UA / MTP Level 3 boundary
DATA DATA
ESTABLISH ESTABLISH
RELEASE RELEASE
STATE STATE
STATUS STATUS
skipping to change at page 9, line 35 skipping to change at page 11, line 7
M-SCTP STATUS M-SCTP STATUS
M-ASP STATUS M-ASP STATUS
2.0 Protocol Elements 2.0 Protocol Elements
This section describes the format of various messages used in this This section describes the format of various messages used in this
protocol. protocol.
2.1 Common Message Header 2.1 Common Message Header
The protocol messages for MTP2 User Adaptation require a message header The protocol messages for MTP2-User Adaptation require a message
structure which contains a version, message type and message length. This structure which contains a version, message type, message length, and
message header is common among all SCN adaptation layers. message contents. This message header is common among all signaling
protocol adaptation layers:
0 7 8 15 16 31 0 1 2 3
+---------------+---------------+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
| Vers | Spare | Msg Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+---------------+---------------+ | Version | Spare | Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length | | Message Length |
+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 Common Message Header Figure 3 Common Message Header
All fields in an M2UA message MUST be transmitted in the network byte
order, unless otherwise stated.
2.1.1 Version 2.1.1 Version
The version field (vers) contains the version of the M2UA adapation The version field (vers) contains the version of the M2UA adapation
layer. The supported versions are: layer. The supported versions are:
01 Release 1.0 of M2UA adaptation protocol 0000 0001 Release 1.0 protocol
2.1.2 Message Type 2.1.2 Message Type
The valid message types are defined in Section 2.2.2 and the message The valid message types are defined in Section 2.2.2 and the message
contents are described in Section 2.3. Each message can contain contents are described in Section 2.3. Each message can contain
parameters. parameters.
The following list contains the message types for the defined messages. The following list contains the message types for the defined messages.
MTP2 User Adaptatation (MAUP) Messages MTP2 User Adaptatation (MAUP) Messages
Data Request 0601 Data 0601
Data Indication 0602 Establish Request 0602
Establish Request 0603 Establish Confirm 0603
Establish Confirm 0604 Release Request 0604
Release Request 0605 Release Confirm 0605
Release Confirm 0606 Release Indication 0606
Release Indication 0607 State Request 0607
State Request 0608 State Confirm 0608
State Confirm 0609 State Indication 0609
State Indication 060a Data Retrieval Request 060a
Data Retrieval Request 060b Data Retrieval Confirm 060b
Data Retrieval Confirm 060c Data Retrieval Indication 060c
Data Retrieval Indication 060d Data Retrieval Complete Indication 060d
Data Retrieval Complete Indication 060e
Application Server Process Maintenance (ASPM) Messages Application Server Process Maintenance (ASPM) Messages
ASP Up (ASPUP) 0301 ASP Up (ASPUP) 0301
ASP Down (ASPDN) 0302 ASP Down (ASPDN) 0302
ASP Active (ASPAC) 0401 ASP Active (ASPAC) 0401
ASP Inactive (ASPIA) 0402 ASP Inactive (ASPIA) 0402
Management (MGMT) Messages Management (MGMT) Messages
Error 0001 Error 0000
2.1.3 Message Length 2.1.3 Message Length
The Message length defines the length of the message in octets, not The Message length defines the length of the message in octets, not
including the header. including the header.
2.2 M2UA Message Header 2.2 M2UA Message Header
In addition to the common message header, there will be a M2UA specific In addition to the common message header, there will be a M2UA specific
message header. The M2UA specific message header will immediately message header. The M2UA specific message header will immediately
follow the common message header, but will only be used with MAUP and follow the common message header, but will only be used with MAUP and
MGMT messages. MGMT messages.
This message header will contain the Interface Identifier. The Interface This message header will contain the Interface Identifier. The
Identifier identifies the physical interface at the SG for which the Interface Identifier identifies the physical interface at the SG for
signaling messages are sent/received. Or, the Interface Identifier which the signaling messages are sent/received. The format of the
Interface Identifier parameter is an integer, the values of which are
can be left empty (a null string of length zero). The Interface Identifier assigned according to network operator policy. The values used are of
follows the same endpoint naming scheme provided in MGCP [7]. For example, local significance only, coordinated between the SG and ASP.
if a Signaling Gateway terminates a E1 and the SS7 signaling link is one
timeslot 16, the interface identifier could be the following:
e1/16@sgw1.example.net
The use of wildcards is not acceptable.
Ed's Note: The Interface Identifier string should be padded to 32-bit
boundaries. The length field indicates the end of the string.
0 15 16 31
+---------------+---------------+
| Tag (0x1) | Length |
+-------------------------------+
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 (0x1) | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier | | Interface Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-------------------------------+ Figure 4 M2UA Message Header
Figure 3 M2UA Message Header
The Tag value for Interface Identifier is 0x1. The length provides the The Tag value for Interface Identifier is 0x1. The length is always
length of the Interface Identifier string in bytes. set to a value of 4.
2.3 M2UA Messages 2.3 M2UA Messages
The following section defines the messages and parameter contents. The The following section defines the messages and parameter contents. The
M2UA messages will use the command header and the M2UA specific header. M2UA messages will use the common message header (Figure 3) and the
M2UA message header (Figure 4).
2.3.1 MTP2 User Adaptation Messages 2.3.1 MTP2 User Adaptation Messages
2.3.1.1 Data (Request, Indication) 2.3.1.1 Data
The Data message contains an SS7 MTP2-User Protocol Data Unit (PDU). The The Data message contains an SS7 MTP2-User Protocol Data Unit (PDU). The
Data message contains the protocol data. Data message contains the protocol data.
The format for the Data Message parameters is as follows: The format for the Data Message parameters is as follows:
0 15 16 31 0 1 2 3
+-------------------------------+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Data | | Protocol Data |
...
+---------------+---------------+
The Protocol Data field contains the MTP2-User application message. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Protocol Data field contains the MTP2-User application message in
network byte order.
2.3.1.2 Establish (Request, Confirmation) 2.3.1.2 Establish (Request, Confirmation)
The Establish Request message is used to establish the channel or to The Establish Request message is used to establish the link or to
indicate that the channel has been established. Note that the gateway indicate that the channel has been established. Note that the gateway
may already have the channel established at its layer. If so, upon may already have the SS7 link established at its layer. If so, upon
receipt of an Establish Request, the gateway takes no action except to receipt of an Establish Request, the gateway takes no action except to
send an Establish Confirm. send an Establish Confirm.
0 15 16 31 The mode (Normal of Emergency) for bringing the link in service is
+---------------+---------------+ defaulted to Normal. The State Request (described in Section 2.3.1.4
| State | below) can be used to change the mode to Emergency.
+---------------+---------------+
The valid values for State are shown in the following table.
Define Value Description
ESTABLISH_NORMAL 0x0 Follow normal procedure for
establishing a SS7 link
ESTABLISH_EMERGENCY 0x1 Follow emergency procedure for
establishing a SS7 link
2.3.1.3 Release (Request, Indication, Confirmation) 2.3.1.3 Release (Request, Indication, Confirmation)
This Release Request message is used to release the channel. The Release This Release Request message is used to release the channel. The
Confirm and Indication messages are used to indicate that the channel has Release Confirm and Indication messages are used to indicate that the
been released. channel has been released.
0 15 16 31 0 1 2 3
+---------------+---------------+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason | | Reason |
+---------------+---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for Reason are shown in the following table. The valid values for Reason are shown in the following table.
Define Value Description Define Value Description
RELEASE_MGMT 0x0 Management layer generated release. RELEASE_MGMT 0x0 Management layer generated release
RELEASE_PHYS 0x1 Physical layer alarm generated release. RELEASE_PHYS 0x1 Physical layer alarm generated release
RELEASE_SIOS 0x2 Receipt of SIOS RELEASE_SIOS 0x2 Receipt of SIOS
RELEASE_OTHER 0x3 Other reason SS7 link out-of-service RELEASE_T6 0x3 Release due to expiration of Timer T6
RELEASE_T7 0x4 Release due to expiration of Timer T7
(should we keep it simple, or provide list of reasons that would RELEASE_BSN 0x5 Release due to invalid BSN (2 of 3)
enable debugging) RELEASE_FIB 0x6 Release due to invalid FIB (2 of 3)
RELEASE_SUERM 0x7 Release due to failure reported by SUERM
RELEASE_IAC 0x8 Release due to initial alignment failed
RELEASE_OTHER 0x9 Other reason SS7 link out-of-service
2.3.1.4 State (Request, Confirm) 2.3.1.4 State (Request, Confirm)
The State Request message can be sent from a MGC to cause an action The State Request message can be sent from a MGC to cause an action
on a particular SS7 link supported by the Signaling Gateway. The on a particular SS7 link supported by the Signaling Gateway. The
gateway sends a State Confirm to the MGC if the action has been success- gateway sends a State Confirm to the MGC if the action has been success-
fully completed. The State Confirm reflects that state value received fully completed. The State Confirm reflects that state value received
in the State Request message. in the State Request message.
0 15 16 31 0 1 2 3
+---------------+---------------+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| State | | State |
+---------------+---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for State are shown in the following table. The valid values for State are shown in the following table.
Define Value Description Define Value Description
STATUS_LOC_PROC_SET 0x0 Request local processor outage. STATUS_LPO_SET 0x0 Request local processor outage
STATUS_LOC_PROC_CLEAR 0x1 Request local processor outage STATUS_LPO_CLEAR 0x1 Request local processor outage
recovered. recovered
STATUS_EMER_SET 0x2 Request emergency alignment STATUS_EMER_SET 0x2 Request emergency alignment
procedure. procedure
STATUS_EMER_CLEAR 0x3 Request normal alignment (cancel STATUS_EMER_CLEAR 0x3 Request normal alignment (cancel
emergency) procedure. emergency) procedure
STATUS_FLUSH_BUFFERS 0x4 Flush transmit and retransmit buffers. STATUS_FLUSH_BUFFERS 0x4 Flush transmit and retransmit
STATUS_CONTINUE 0x5 Continue. buffers
STATUS_CONTINUE 0x5 Continue
2.3.1.5 State Indication 2.3.1.5 State Indication
The MTP2 State Indication message can be sent from a gateway to a call The MTP2 State Indication message can be sent from a gateway to an
agent to indicate a condition on a channel. ASP to indicate a condition on a link.
0 15 16 31 0 1 2 3
+---------------+---------------+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| State | | State |
+---------------+---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for State are shown in the following table. The valid values for State are shown in the following table.
Define Value Description Define Value Description
EVENT_ENTER_LPO 0x0 Entered local processor outage. EVENT_ENTER_LPO 0x0 Entered local processor outage
EVENT_EXIT_LPO 0x1 Exited local processor outage. EVENT_EXIT_LPO 0x1 Exited local processor outage
EVENT_ENTER_CONG 0x2 Entered a congested state. EVENT_ENTER_CONG 0x2 Entered a congested state
EVENT_EXIT_CONG 0x3 Exited a congested state. EVENT_EXIT_CONG 0x3 Exited a congested state
EVENT_PHYS_UP 0x4 Physical interface up. EVENT_PHYS_UP 0x4 Physical interface up
EVENT_PHYS_DOWN 0x5 Physical interface down. EVENT_PHYS_DOWN 0x5 Physical interface down
EVENT_PROTOCOL_ERR 0x6 Protocol error occurred. EVENT_PROTOCOL_ERR 0x6 Protocol error occurred
EVENT_REM_ENTER_CONG 0xc Remote entered congestion. EVENT_REM_ENTER_CONG 0xc Remote entered congestion
EVENT_REM_EXIT_CONG 0xd Remote exited congestion. EVENT_REM_EXIT_CONG 0xd Remote exited congestion
EVENT_REM_ENTER_PO 0xe Remote entered processor outage. EVENT_REM_ENTER_PO 0xe Remote entered processor outage
EVENT_REM_EXIT_PO 0xf Remote exited processor outage. EVENT_REM_EXIT_PO 0xf Remote exited processor outage
2.3.1.6 Retrieval (Request, Confirm) 2.3.1.6 Retrieval (Request, Confirm)
The MTP2 Retrieval Request message is used during the MTP Level 3 The MTP2 Retrieval Request message is used during the MTP Level 3
changeover procedure to request the BSN, to retrieve PDUs from the changeover procedure to request the BSN, to retrieve PDUs from the
retransmit queue or to flush PDUs from the retransmit queue. retransmit queue or to flush PDUs from the retransmit queue.
0 15 16 31 0 1 2 3
+---------------+---------------+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | | Action |
+---------------+---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fsn_bsn | | fsn_bsn |
+---------------+---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for Action are shown in the following table. The valid values for Action are shown in the following table.
Define Value Description Define Value Description
ACTION_RTRV_BSN 0x1 Retrieve the backward sequence number. ACTION_RTRV_BSN 0x1 Retrieve the backward sequence number
ACTION_RTRV_MSGS 0x2 Retrieve the PDUs from the retransmit ACTION_RTRV_MSGS 0x2 Retrieve the PDUs from the retransmit
queue. queue
ACTION_DROP_MSGS 0x3 Drop the PDUs in the retransmit queue. ACTION_DROP_MSGS 0x3 Drop the PDUs in the retransmit queue
In the Retrieval Request message, the fsn_bsn field contains the FSN of In the Retrieval Request message, the fsn_bsn field contains the FSN of
the far end if the action is ACTION_RTRV_MSGS. the far end if the action is ACTION_RTRV_MSGS.
When the Signaling Gateway sends a Retrieval Confirm to this request, When the Signaling Gateway sends a Retrieval Confirm to this request,
it echos the action and puts the BSN in the fsn_bsn field if the action it echos the action and puts the BSN in the fsn_bsn field if the action
was ACTION_RTRV_BSN. was ACTION_RTRV_BSN. If there is a failure in retrieving the BSN, the
fsn_bsn should contain a -1 (0xffffffff).
2.3.1.7 Retrieval Indication 2.3.1.7 Retrieval Indication
The Retrieval Indication message is sent by the Signaling Gateway The Retrieval Indication message is sent by the Signaling Gateway
with a PDU from the retransmit queue. The Retrieval Indication with a PDU from the retransmit queue. The Retrieval Indication
message does not contain the Action or fsn_bsn fields, just a PDU from message does not contain the Action or fsn_bsn fields, just a PDU from
the retransmit queue. the retransmit queue.
0 15 16 31 0 1 2 3
+---------------+---------------+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. PDU from retransmit . | PDU from retransmit queue |
. queue .
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+---------------+---------------+
2.3.1.8 Retrieval Complete Indication 2.3.1.8 Retrieval Complete Indication
The MTP2 Retrieval Complete Indication message is exactly the same as The MTP2 Retrieval Complete Indication message is exactly the same as
the MTP2 Retrieval Indication message except that it also indicates that the MTP2 Retrieval Indication message except that it also indicates that
it contains the last PDU from the retransmit queue. it contains the last PDU from the retransmit queue.
2.3.2 Application Server Process Maintenance (ASPM) Messages 2.3.2 Application Server Process Maintenance (ASPM) Messages
The ASPM messages will only use the common header. The ASPM messages will only use the common message header.
2.3.2.1 ASP UP (ASPUP) 2.3.2.1 ASP UP (ASPUP)
The ASPUP message is used to indicate to a remote M2UA peer that the The ASP UP (ASPUP) message is used to indicate to a remote M2UA peer
layer is ready to receive traffic or maintenance messages. that the Adaptation layer is ready to receive traffic or maintenance
messages.
The ASPUP message contains the following parameters: The ASPUP message contains the following parameters:
Adaptation Layer Identifer (optional) Adaptation Layer Identifer (optional)
SCN Protocol Identifier (optional) Protocol Identifier (optional)
INFO String (optional)
The Adaptation Layer Identifier is a string that identifies the
adaptation layer. This string must be set to "M2UA" which means
the length will be 4.
The Protocol Identifier field contains the identity of the specific SCN
signaling protocol being transported. The Protocol ID defines the
protocol type, variant, and version, and thereby specifies the components
and encoding of the PROTOCOL DATA field. The Protocol Identifier also
defines what SCN protocol message components are included in the PROTOCOL
DATA.
(Ed. Note: Need encoding of mime-type value or OID or fixed
string/integer that will be administered outside of this document
(IANA). Also, perhaps bring in text from Christian's mime document - See
"draft-ietf-sigtran-mime-isup.txt" for an example of an application/ISUP
media type defined according to the rules defined in RFC 2048.?)
The format for the ASPUP message is as follows: The format for ASPUP Message parameters is as follows:
0 15 16 31 0 1 2 3
+---------------+---------------+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x2) | Length | | Tag (0x2) | Length |
+---------------+---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adaptation Layer Identifier | | Adaptation Layer Identifier* |
+---------------+---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3) | Length | | Tag (0x4) | Length |
+---------------+---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Identifier | | INFO String* |
+---------------+---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+---------------+---------------+
| INFO String | The optional 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 for debugging
purposes.
+---------------+---------------+ The optional Adaptation Layer Identifier (ALI) is a string that
identifies the adaptation layer. This string must be set to "M2UA"
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 Note: Strings are padded to 32-bit boundaries. The length field
indicates the end of the string. indicates the end of the string.
2.3.2.2 ASP Down (ASPDN) 2.3.2.2 ASP Down (ASPDN)
The ASPDN message is used to indicate to a remote M2UA peer that the The ASP Down (ASPDN) message is used to indicate to a remote M2UA peer
layer is not ready to receive traffic or maintenance messages. that the adaptation layer is not ready to receive traffic or maintenance
messages.
The ASPDN message contains the following parameters: The ASPDN message contains the following parameters:
INFO String Reason
INFO String (Optional)
The format for the ASPDN message is as follows: The format for the ASPDN message parameters is as follows:
0 15 16 31 0 1 2 3
+---------------+---------------+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length | | Tag (0x4) | Length |
+---------------+---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INFO String | | INFO String* |
+---------------+---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
##### The format and description of the optional Info String parameter is the
We discussed adding a reason code. Reason could be failure or same as for the ASP Up message (See Section 2.3.2.1.)
management inhibit.
##### The Reason parameter indicates the reason that the remote M2UA
adaptation layer is unavailable. The valid values for Reason are shown
in the following table.
Value Description
0x1 Management Inhibit
2.3.2.3 ASP Active (ASPAC) 2.3.2.3 ASP Active (ASPAC)
The ASPAC message is sent by an ASP to indicate to an SG that it is The ASPAC message is sent by an ASP to indicate to an SG that it is
the active ASP to be used from within a list of primary and back-up ASPs Active and ready to be used.
for a particular signaling mapping relationship.
The ASPAC message contains the following parameters: The ASPAC message contains the following parameters:
Controlled/Forced flag (C/F flag) Type
INFO String Interface Identifier (Optional)
INFO String (Optional)
The format for the ASPAC message is as follows: The format for the ASPAC message is as follows:
0 15 16 31 0 1 2 3
+---------------+---------------+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
| C/F flag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+---------------+---------------+ | Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xx) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifiers* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length | | Tag (0x4) | Length |
+---------------+---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INFO String | | INFO String* |
+---------------+---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for C/F flag are shown in the following table. The Type parameter identifies the traffic mode of operation of the ASP
within an AS. The valid values for Type are shown in the following table.
Define Value Description Value Description
FORCED 0x0 Force sending of all messages to ASP 0x1 Over-ride
CONTROLLED 0x1 Only send "new work" to ASP 0x2 Load-share
0x3 New traffic
Within a particular Routing Context, only one Type can be used. The
Over-ride value indicates that the ASP is operating in Over-ride mode,
where the ASP takes over all traffic in an Application Server (i.e.,
primary/back-up operation), over-riding any currently active ASPs in
the AS. In loadshare mode, the ASP will share in the traffic distribution
with any other currently active ASPs. In New Traffic mode the ASP wishes
to take on traffic in the AS but does not expect to receive messages
related to calls/transactions that are pending completion in another ASP.
An SG that receives an ASPAC with an incorrect type for a particular
Interface Identifier will respond with an Error Message.
The optional Interface Identifiers parameter contains a list of
Interface Identifier integers indexing the Application Server traffic
that the sending ASP is configured/registered to receive. There is
one-to-one relationship between an Interface Identifier and an AS Name.
If no Interface Identifiers are present, then the message is intended
for all Interface Identifiers supported by the SG.
The format and description of the optional Info String parameter is the
same as for the ASP Up message (See Section 2.3.2.1.)
2.3.2.4 ASP Inactive (ASPIA) 2.3.2.4 ASP Inactive (ASPIA)
The ASPIA message is sent by an ASP to indicate to an SG that it is The ASPIA message is sent by an ASP to indicate to an SG that it is no
no longer the the active ASP to be used from within a list of primary longer an active ASP to be used from within a list of ASPs. The SG will
and back-up ASP for a particular signaling mapping relationship. The respond with an ASPIA message and either discard incoming messages or
SG will respond with an ASPIA message and either buffer or discard buffer for a timed period and then discard.
incoming messages for a timed period and then discard.
The ASPIA message contains the following parameters: The ASPIA message contains the following parameters:
INFO String Type
Interface Identifiers (Optional)
INFO String (Optional)
The format for the ASPIA message is as follows: The format for the ASPIA message parameters is as follows:
0 15 16 31 0 1 2 3
+---------------+---------------+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xx) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifiers* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length | | Tag (0x4) | Length |
+---------------+---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INFO String | | INFO String* |
+---------------+---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type parameter identifies the traffic mode of operation of the ASP
within an AS. The valid values for Type are shown in the following table.
Value Description
0x1 Over-ride
0x2 Load-share
0x3 Graceful Withdrawal
The format and description of the optional Interface Identifiers and
Info String parameters is the same as for the ASP Active message (See
Section 2.3.2.3.) If no Interface Identifiers are present, then the
message is intended for all Interface Identifiers supported by the SG.
2.3.3 Layer Management (MGMT) Messages 2.3.3 Layer Management (MGMT) Messages
2.3.3.1 Error (ERR) 2.3.3.1 Error (ERR)
The ERR message is sent when an invalid value is found in an incoming The ERR message is sent when an invalid value is found in an incoming
messages. message.
The ERR message contains the following parameters: The ERR message contains the following parameters:
Error Code Error Code
Diagnostic Information (optional)
The format for the ERR message is as follows: The format for the ERR message is as follows:
0 7 8 15 16 31 0 1 2 3
+---------------+---------------+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | | Error Code |
+---------------+---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xx) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Error Code can be one of the following values: | Diagnostic Information* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Error Code parameter indicates the reason for the Error Message.
The Error parameter value can be one of the following values:
Invalid Version 0x1 Invalid Version 0x1
Invalid Interface Identifier 0x2 Invalid Interface Identifier 0x2
Invalid SCN Version 0x3 Invalid Adaptation Layer Identifier 0x3
Invalid Adaptation Layer Identifier 0x4 Invalid Message Type 0x4
Invalid Traffic Handling Mode 0x5
Invalid Stream Identifier 0x5 Invalid Stream Identifier 0x5
Invalid Message Type 0x6
The optional Diagnostic information can be any information germain to
the error condition, to assist in identification of the error condition.
In the case of an Invalid Version Error Code the Diagnostic information
includes the supported Version parameter. In the other cases, the
Diagnostic information may be the first 40 bytes of the offending message.
2.3.3.2 Notify (NTFY)
The Notify message used to provide autonomous notification of M2UA events.
The NTFY message contains the following parameters:
Status Type
Status Identification
Interface Identifiers (Optional)
INFO String (Optional)
The format for the NTFY 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Type | Status Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xx) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifiers* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INFO String* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Status Type parameter identifies the type of the Notify message. Following are the valid Status Type values:
Value Description
0x1 Application Server state change (AS_State_Change)
0x2 Application Server Process state change (ASP_State_Change)
0x3 Other
The Status Information parameter contains more detailed information for the notification, based on the value of the Status Type. If the Status Type is AS_State_Change the following Status Information values are used:
Value Description
0x1 Application Server Down (AS_Down)
0x2 Application Server Up (AS_Up)
0x3 Application Server Active (AS_Active)
0x4 Application Server Pending (AS_Pending)
These notifications are sent from an SG to an ASP upon a change in status of a particular Application Server. The value reflects the new state of the Application Server.
If the Status type is ASP_State_Change, the Status Information values are:
Value Description
0x1 Application Server Process (ASP) Down
0x2 Application Server Process (ASP) Up
0x3 Application Server Process (ASP) Active
0x4 Application Server Process (ASP) Active_Old
0x5 Application Server Process (ASP) Active_New
These notifications are sent from an SG to an ASP upon a change in status
of a particular Application Server process within the ASP list of a
particular Application Server. The value reflects the new state of the
Application Server Process.
If the Status Type is Other, then the following Status Information values
are defined:
Value Description
0x1 Insufficient ASP resources active in AS
This notification is not based on the SG reporting the state change of an
ASP or AS. For the value defined the SG is indicating to an ASP(s) in
the AS that another ASP is required in order to handle the load of the AS.
The format and description of the optional Interface Identifiers and Info
String parameters is the same as for the ASP Active message (See
Section 2.3.2.3.)
3.0 Procedures 3.0 Procedures
The M2UA layers needs to respond to various primitives it receives from The M2UA layers needs to respond to various primitives it receives from
other layers as well as messages it receives from the peer-to-peer other layers as well as messages it receives from the peer-to-peer
messages. This section describes various procedures involved in messages. This section describes various procedures involved in
response to these events. response to these events.
3.1 Procedures to Support Service in Section 1.4.1 3.1 Procedures to Support Service in Section 1.4.1
These procedures achieve the M2UA layer's "Transport of MTP Level 2 / These procedures achieve the M2UA layer's "Transport of MTP Level 2 /
MTP Level 3 boundary" service. MTP Level 3 boundary" service.
3.1.1 MTP Level 2 / MTP Level 3 Boundary Procedures 3.1.1 MTP Level 2 / MTP Level 3 Boundary Procedures
On receiving a primitives from the local layer, the M2UA layer will On receiving a primitive from the local upper layer, the M2UA layer will
send the corresponding MAUP message (see Section 2) to its peer. The send the corresponding MAUP message (see Section 2) to its peer. The
M2UA layer must fill in various fields of the common and specific headers M2UA layer must fill in various fields of the common and specific headers
correctly. In addition the message needs to be sent on the SCTP stream correctly. In addition the message needs to be sent on the SCTP stream
that corresponds to the SS7 link. that corresponds to the SS7 link.
3.1.2 MAUP Message Procedures 3.1.2 MAUP Message Procedures
On receiving MAUP messages from a peer M2UA layer, the M2UA layer on an On receiving MAUP messages from a peer M2UA layer, the M2UA layer on an
SG or MGC needs to invoke the corresponding layer primitives to the SG or MGC needs to invoke the corresponding layer primitives to the
local MTP Level 2 or MTP Level 3 layer. local MTP Level 2 or MTP Level 3 layer.
3.2 Procedures to Support Service in Section 1.4.2 3.2 Procedures to Support Service in Section 1.4.2
These procedures achieve the IUA layer's "Support for Communication These procedures achieve the M2UA layer's "Support for Communication
between Layer Managements" service. between Layer Managements" service.
3.2.1 Layer Management Primitives Procedure 3.2.1 Layer Management Primitives Procedure
On receiving these primitives from the local layer, the M2UA layer will On receiving these primitives from the local layer, the M2UA layer will
send the corresponding MGMT message (Error) to its peer. The M2UA layer send the corresponding MGMT message (Error) to its peer. The M2UA layer
must fill in the various fields of the common and specific headers must fill in the various fields of the common and specific headers
correctly. correctly.
3.2.2 MGMT message procedures 3.2.2 MGMT message procedures
skipping to change at page 19, line 7 skipping to change at page 22, line 29
Upon receipt of MGMT messages the M2UA layer must invoke the corresponding Upon receipt of MGMT messages the M2UA layer must invoke the corresponding
Layer Management primitives (M-ERROR) to the local layer management. Layer Management primitives (M-ERROR) to the local layer management.
3.3 Procedures to Support Service in Section 1.4.3 3.3 Procedures to Support Service in Section 1.4.3
These procedures achieve the M2UA layer's "Support for management of These procedures achieve the M2UA layer's "Support for management of
active associations between SG and MGC" service. active associations between SG and MGC" service.
3.3.1 State Maintenance 3.3.1 State Maintenance
The M2UA layer on the SG maintains the state of each AS, in each
Appliction Server that it is configured to receive traffic.
3.3.1.1 ASP States 3.3.1.1 ASP States
The state of the each ASP is maintained in the M2UA layer on the SG. The The state of each ASP, in each AS that it is configured, is maintained
state of an ASP changes due to events. The events include: in the M2UA layer in the SG. The state of a particular ASP in a
particular AS changes due to events. The events include:
* Reception messages from peer M2UA layer * Reception of messages from the peer M2UA layer at the ASP
* Reception of indications from layers below * Reception of some messages from the peer M2UA layer at other ASPs
in the AS
* Reception of indications from the SCTP layer
* Switch-over Time triggers
The ASP state transition diagram is shown in Figure 4. The possible states The ASP state transition diagram is shown in Figure 4. The possible
of an ASP are: states of an ASP are:
ASP-DOWN: Application Server Process is unavailable. Initially all ASPs ASP-DOWN: The remote M2UA peer at the ASP is unavailable and/or the SCTP
are in this state. association is down. Initially all ASPs will be in this state.
ASP-UP: Application Server Process is available but application traffic is ASP-UP: The remote M2UA peer at the ASP is available (and the SCTP
stopped. association is up) but application traffic is stopped.
ASP-ACTIVE: Application Server Process is available and application traffic ASP-ACTIVE: The remote M2UA peer at the ASP is available and application
is active. At most one ASP per AS can be in the active state. traffic is active (for a particular Routing Context or set of Routing
Contexts).
Figure 4: ASP State Transition Diagram ASP-ACT-OLD: The remote M2UA peer at the ASP is available and application
traffic is active (for a particular Routing Context or set of Routing
Contexts), but for draining of current call/transactions only (i.e., no
new calls/transactions)
ASP-ACT-NEW: The remote M2UA peer at the ASP is available and application
traffic is active (for a particular Routing Context or set of Routing
Contexts), but for new calls/transactions only (i.e., not for traffic
related to completing calls/transactions in another ASP).
+-------------+ +-------------+
|-------->| | +----------------------| |
| | ASP-ACTIVE | | Some other /| ASP-ACTIVE |<--------\
| | | | ASP / +-------------+ |
| | | | Takeover / ^ | | Ts
| +-------------+ | / ASP | | ASP |
| ^ | | / Active | | Inactive |
| ASP | | ASP | v | v |
| Active | | Inactive | +-------------+ +-------------+ +-------------+
| | v | | | | | | |
| +-------------+ | | ASP-ACT-OLD |----->| ASP-UP |------>| ASP-ACT-NEW |
| | | | +-------------+ Ts / +-------------+ ASP +-------------+
ASP Down / | | | | | ASP Inactive ^ | Takeover |
SCTP CDI | | ASP-UP | |<---| | | |
| | | | | | |
| | | ASP Down/ | ASP | | ASP Down / | ASP
| +-------------+ SCTP CDI | Up | | SCTP CDI | Down/
| ^ | | | v | SCTP
| ASP | | ASP Down / | +-------------+ | CDI
| Up | | SCTP CDI | | | |
| | v +------------------>| |<-------------+
| +-------------+
| | |
|-------->| |
| ASP-DOWN | | ASP-DOWN |
| |
| |
+-------------+ +-------------+
SCTP CDI: Local SCTP layer's Communication Down Indication to the Upper Layer SCTP CDI: The local SCTP layer's Communication Down Indication to the
Protocol (M2UA) on an SG. SCTP will send this indication when it Upper Layer Protocol (M2UA) on an SG. The local SCTP will send this
detects the loss of connectivity to ASP's SCTP layer. indication when it detects the loss of connectivity to the ASP's peer
SCTP layer.
Ts: Switch-over Time Triggers. This timer is configurable by the
Operator on a per AS basis.
3.3.1.2 AS States 3.3.1.2 AS States
The state of the AS is maintained in the ITUN layer on the SG. The The state of the AS is maintained in the M2UA layer on the SG. The
state of an AS changes due to events. These events include: state of an AS changes due to events. These events include:
* ASP state transitions * ASP state transitions
* Recovery timer triggers * Recovery timer triggers
The possible states of an AS are: The possible states of an AS are:
AS-DOWN: Application Server is unavailable. This state implies that all AS-DOWN: The Application Server is unavailable. This state implies that
ASPs are in the ASP-DOWN state for this AS. all related ASPs are in the ASP-DOWN state for this AS. Initially the
AS will be in this state.
AS-UP: One or more ASPs are in the ASP-UP state.
AS-ACTIVE: Application Server is available and application traffic is AS-UP: The Application Server is available but no application traffic is
active. This state implies that one ASP is in the ASP-ACTIVE state. active (i.e., one or more related ASPs are in the ASP-UP state, but
none in the ASP-Active state).
AS-PENDING: Currently Active ASP became inactive or SCTP association with AS-ACTIVE: The Application Server is available and application traffic
it is lost. A Recovery timer will be started and in coming SCN messages is active. This state implies that one ASP is in the ASP-ACTIVE state.
will be queuedby the SG. If an ASP becomes Active before the recovery
timer (Tr) expires, the AS will move to AS-ACTIVE state and all the
queued messages will be sent to the active ASP. If the recovery timer
expires before an ASP becomes active, SG stops queuing messages and
discards all queued messages. AS will move to AS-UP if at least one
ASP is in ASP-UP state, otherwise it will move to AS-DOWN state.
If Tr expires before an ASP becomes active, the SG stops queuing messages AS-PENDING: An active ASP has transitioned from active to inactive or
and discards all previously queued messages. The AS will move to AS-UP if down and it was the last remaining active ASP in the AS. A recovery
at least one ASP is in ASP-UP state, otherwise it will move to AS-DOWN state. 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.
Ed's Note: If AS moves from AS-PENDING state to AS-UP or AS-DOWN If T(r) expires before an ASP becomes active, the SG stops queuing
states, the Layer Management on MG may take appropriate SCN messages and discards all previously queued messages. The AS will move
notification actions. to AS-UP if at least one ASP is in ASP-UP state, otherwise it will move
to AS-DOWN state.
+----------+ one ASP trans ACTIVE +-------------+ +----------+ one ASP trans ACTIVE +-------------+
| |------------------------>| | | |------------------------>| |
| AS-UP | | AS-ACTIVE | | AS-UP | | AS-ACTIVE |
| | | | | | | |
| |< -| | | |< -| |
+----------+ \ / +-------------+ +----------+ \ / +-------------+
^ | \ Tr Trigger / ^ | ^ | \ Tr Trigger / ^ |
| | \ at least one / | | | | \ at least one / | |
| | \ ASP in UP / | | | | \ ASP in UP / | |
| | \ / | | | | \ / | |
| | \ / | | | | \ / | |
| | \ /---/ | | | | \ /---/ | |
one ASP | | \ / one ASP | | ACTIVE ASP one ASP | | \ / one ASP | | ACTIVE ASP
trans | | all ASP \-/----\ trans | | trans to UP or trans | | all ASP \-/----\ trans | | trans to UP or
to UP | | trans to / \ ACTIVE | | ACTIVE ASP to UP | | trans to / \ ACTIVE | | ACTIVE ASP
| | DOWN / \ | | SCTP CDI | | DOWN / \ | | SCTP CLN
| | / \ | | | | / \ | |
| | / \ | | | | / \ | |
| | /all ASP \ | | | | /all ASP \ | |
| v / trans to \ | v | v / trans to \ | v
+----------+ / DOWN \ +-------------+ +----------+ / DOWN \ +-------------+
| |<--/ -| | | |<--/ -| |
| AS-DOWN | | AS-PENDING | | AS-DOWN | | AS-PENDING |
| | | (queueing) | | | | (queueing) |
| |<------------------------| | | |<------------------------| |
+----------+ Tr Trigger no ASP +-------------+ +----------+ Tr Trigger no ASP +-------------+
in UP state or in UP state
prev ACTIVE ASP trans
to DOWN state
Tr = Recovery Timer Tr = Recovery Timer
Figure 5: AS State Transition Diagram Figure 5: AS State Transition Diagram
3.3.2 ASPM procedures for primitives 3.3.2 ASPM procedures for primitives
Before the establishment of an SCTP association the ASP state at both the Before the establishment of an SCTP association the ASP state at both
SG and ASP is assumed to be "Down". the SG and ASP is assumed to be "Down".
When the M2UA layer receives an M-SCTP ESTABLISH request primitive from As the ASP is responsible for initiating the setup of an SCTP
the Layer Management, the M2UA layer will try to establish an SCTP association to an SG, the M2UA layer at an ASP receives an M-SCTP
association with the remote M2UA peer. Upon reception of an eventual ESTABLISH request primitive from the Layer Management, the M2UA layer
SCTP-Communication Up confirm primitive from the SCTP, the M2UA layer will try to establish an SCTP association with the remote M2UA peer at
will invoke the primitive M-SCTP ESTABLISH confirm to the Layer Management. an SG. Upon reception of an eventual SCTP-Communication Up confirm
primitive from the SCTP, the M2UA layer will invoke the primitive M-SCTP
ESTABLISH confirm to the Layer Management.
Alternatively, if the remote M2UA-peer establishes the SCTP association At the SG, the M2UA layer will receive an SCTP Communication Up
first, the M2UA layer will receive an SCTP Communication Up indication indication primitive from the SCTP. The M2UA layer will then invoke the
primitive from the SCTP. The M2UA layer will then invoke the primitive primitive M-SCTP ESTABLISH indication to the Layer Management.
M-SCTP ESTABLISH indication to the Layer Management.
Once the SCTP association is established, The M2UA layer at an ASP will Once the SCTP association is established, The M2UA layer at an ASP will
then find out the state of its local M2UA-user from the Layer Management then find out the state of its local M2UA-user from the Layer Management
using the primitive M-ASP STATUS. Based on the status of the local using the primitive M-ASP STATUS. Based on the status of the local
M2UA-User, the local ASP ITUN Application Server Process Maintenance (ASPM) M2UA-User, the local ASP M2UA Application Server Process Maintenance
function will initiate the ASPM procedures, using the ASP-Up/-Down/-Active/ (ASPM) function will initiate the ASPM procedures, using the ASP-Up/-
-Inactive messages to convey the ASP-state to the SG - see Section 3.3.3. Down/-Active/-Inactive messages to convey the ASP-state to the SG - see
Section 3.3.3.
If the M2UA layer subsequently receives an SCTP-Communication Down If the M2UA layer subsequently receives an SCTP-Communication Down
indication from the underlying SCTP layer, it will inform the Layer indication from the underlying SCTP layer, it will inform the Layer
Management by invoking the M-SCTP STATUS indication primitive. The state Management by invoking the M-SCTP STATUS indication primitive. The
of the ASP will be moved to "Down" at both the SG and ASP. state of the ASP will be moved to "Down" at both the SG and ASP.
At an ASP, the Layer Management may try to reestablish the SCTP association At an ASP, the Layer Management may try to reestablish the SCTP
using M-SCTP ESTABLISH request primitive. association using M-SCTP ESTABLISH request primitive.
3.3.3 ASPM procedures for peer-to-peer messages 3.3.3 ASPM procedures for peer-to-peer messages
3.3.3.1 ASP UP All ASPM messages are sent on a sequenced stream to ensure ordering.
SCTP stream Š0Ă is used.
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
(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.4 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 with the will
indicate the version supported by the node.
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 N 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.
3.3.6 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.
4.0 Examples of MTP2 User Adaptation (M2UA) Procedures
4.1 Establishment of associations between SG and MGC examples
An example of the message flows for establishing active associations between
SG and MGC is shown below.
SG ASP1
<----------- ASP Up
ASP Up ---------->
(ACK)
<----------- ASP Active
ASP Active ---------->
(ACK)
An example of message flows for establishment of associations with two
ASPs and the message flows for take-over of the primary (ASP1) by the
secondary (ASP2).
SG ASP1 ASP2
<----------- ASP Up
ASP Up ---------->
(ACK)
<------------------------------ ASP Up
ASP Up ------------------------------>
(ACK)
<----------- ASP Active
ASP Active ---------->
(ACK)
...
<----------- ASP Inactive
ASP Inactive ---------->
(ACK)
(this message is optional)
ASP Inactive ------------------------------>
<------------------------------ ASP Active
ASP Active ------------------------------>
(ACK)
An example of message flows for establishment of associations with two
ASPs and the message flows for controlled take-over of the primary (ASP1)
by the secondary (ASP2). In this case, the SG sends new work to ASP2.
SG ASP1 ASP2
<----------- ASP Up
ASP Up ---------->
(ACK)
<------------------------------ ASP Up
ASP Up ------------------------------>
(ACK)
<----------- ASP Active
ASP Active ---------->
(ACK)
...
<------------------------------ ASP Active
(New Work)
ASP Active ------------------------------>
(ACK)
<----------- ASP Inactive
ASP Inactive ---------->
(ACK)
4.2 Case 1: SG to MGC, MTP Level 2 to MTP Level 3 Boundary Procedures
4.2.1 SS7 Link Alignment
The MGC can request that a SS7 link be brought into alignment using the
normal or emergency procedure. An example of the message flow to bring
a SS7 link in-service using the normal alignment procedure is shown
below.
SG MGC
<----------- Establish Request (ESTABLISH_NORMAL)
Establish Response ---------->
An example of the message flow to bring a SS7 link in-service using the
emergency alignment procedure.
SG MGC
<----------- Establish Request (ESTABLISH_EMER)
Establish Response ---------->
4.2.2 SS7 Link Release
The MGC can request that a SS7 link be taken out-of-service. It uses
the Release Request message as shown below.
SG MGC
<------------ Release Request (RELEASE_MGMT)
Release Response ------------>
The SG can autonomously indicate that a SS7 link has gone out-of-service
as shown below.
SG MGC
Release Indication ------------>
(RELEASE_PHYS)
4.2.3 Set and Clear Local Processor Outage
to be added
4.2.4 Notification of Processor Outage (local or remote)
to be added
4.2.5 Flush Buffers or Continue
to be added
4.2.6 SS7 Link Changeover
An example of the message flow for a changeover is shown below. 3.3.3.2 ASP-Up
SG MGC After an ASP has successfully established an SCTP association to an SG,
the SG waits for the ASP to send an ASP-Up message, indicating that the
ASP M2UA peer is available. The ASP is always the initiator of the
ASP-Up exchange.
<---------- Retrieval Request (MTP2_RTRV_BSN) When an ASP-Up message is received at an SG and internally the ASP is not
Retrieval Confirm ----------> locked-out for local management reasons, the SG marks the remote ASP as
(with BSN) ŠUpĂ. The SG responds with an Notify (ASP-Up) message to the ASP in
<---------- Retrieval Request (MTP2_RTRV_MSGS acknowledgement. The SG sends a Notify (ASP-Up) message in response to
with FSN) a received ASP-Up message from the ASP even if the ASP is already marked
Retrieval Confirm ----------> as ˘Up÷ at the SG.
Retrieval Ind -----------> If for any local reason the SG cannot respond with an ASP-Up, the SG
Retrieval Ind -----------> responds to a ASP-Up with a ASP-Down message.
Rtrvl Complete Ind ---------->
Note: The number of Retrieval Indication is dependent on the number of At the ASP, the Notify (ASP-Up) message received from the SG is not
messages in the retransmit queue that have been requested. Only one acknowledged by the ASP. If the ASP does not receive a response from
Retrieval Complete Indication should be sent. the SG, or an ASP-Down is received, the ASP may resend ASP-Up messages
every 2 seconds until it receives a Notify (ASP-Up) message from the SG.
The ASP may decide to reduce the frequency (say to every 5 seconds) if a
Notify (ASP-Up) is not received after a few tries.
4.3 Case 2: SG to IPSP, MTP Level 2 to MTP Level 3 Boundary Procedures The ASP must wait for the Notify (ASP-Up) message from the SG before
sending any ASP traffic control messages (ASPAC or ASPIA) or Data
messages or it will risk message loss. If the SG receives Data messages
before an ASP Up is received, the SG should discard.
In general, messages passed between MTP3 and M2UA are the same as 3.3.3.2 ASP-Down
those passed between MTP3 and MTP2. M2UA interprets messages from MTP3
and sends the appropriate message to SCTP. Likewise, messages from
SCTP are used to generate a meaningful message to MTP3.
4.3.1 Link Initialization (Alignment) The ASP will send an ASP-Down to an SG when the ASP is to be removed from
the list of ASPs in all Application Servers that it is a member.
The MTP3 layer can request that an SS7 link be brought into alignment The SG marks the ASP as ˘Down÷ and returns an Notify (ASP-Down) message
using the normal or emergency procedure. An example of the message to the ASP if one of the following events occur:
flow to bring an SS7 link in-service is shown below.
There are two alignment procedures normal alignment and emergency - an ASP-Down message is received from the ASP,
alignment. During normal alignment, communication to the other end is - another ASPM message is received from the ASP and the SG has
tested for a period of time to make sure that the communication link locked out the ASP for management reasons.
satisfies the performance requirements of the application. The
examples are RTT and packet loss. Normal alignment is used when there
are other links available to the same destination. Emergency alignment
is used when there are no other links to the same destination. During
emergency, the link is not tested for a long period of time. Instead,
an indication from the SCTP layer is used to bring the link in
service.
The procedure for beginning an Association is described in the SCTP The SG sends a Notify (ASP-Down) message in response to a received ASP-
standard [5]. Down message from the ASP even if the ASP is already marked as ˘Down÷ at
the SG.
MTP3 M2UA SCTP SCTP M2UA MTP3 If the ASP does not receive a response from the SG, the ASP may send ASP-
---- ---- ---- ---- ---- ---- Down messages every 2 seconds until it receives a ASP-Down message from
the SG or the SCTP association goes down. The ASP may decide to reduce
the frequency (say to every 5 seconds) if an ASP-Down is not received
after a few tries.
Power On 3.3.3.3 M2UA Version Control
------------>
Out of Service If a ASP-Up message with an unsupported version is received, the
<------------ receiving end responds with an Error message, indicating the version the
receiving node supports.
Emergency OR This is useful when protocol version upgrades are being performed in a
Emergency Ceases network. A node upgraded to a newer version should support the older
------------> versions used on other nodes it is communicating with. Because ASPs
initiate the ASP-Up procedure it is assumed that the Error message would
normally come from the SG.
Start 3.3.3.4 ASP-Active
------------>
Associate Anytime after the ASP has received a Notify (ASP-Up) acknowledgement from
------------> the SG, the ASP sends an ASP-Active (ASPAC) to the SG indicating that the
ASP is ready to start processing traffic. In the case where an ASP is
configured/registered to process the traffic for more than one Application
Server across an SCTP association, the ASPAC contains one or more
Interface Identifiers to indicate for which Application Servers the
ASPAC applies.
(SCTP Association When an ASP Active (ASPAC) message is received, the SG responds to the
procedure) ASP with a Notify message acknowledging that the ASPAC was received and
starts sending traffic for the associated Application Server(s) to that
ASP.
Communication Up Communication Up There are two modes of Application Server traffic handling in the SG
<------------ ------------> M2UA - Over-ride, Load-balancing and New Traffic. The Type parameter in
the ASPAC messge indicates the mode used in a particular Application
Server. If the SG determines that the mode indicates in an ASPAC is
incompatible with the traffic handling mode currently used in the AS,
the SG responds with an Error message indicating ˘Invalid Traffic
Handling Mode÷.
Indication Indication In the case of an Over-ride mode AS, reception of an ASPAC message at an
(Link In Service) (Link In Service) SG causes the redirection of all traffic for the AS to the ASP which sent
<------------ ------------> the ASPAC. Any previously active ASP in the AS is now considered Inactive
and will no longer receive traffic within the AS. The SG responds to the
ASPAC with a Notify (ASP-Active) message to the ASP. The SG sends a
Notify (ASP-Inactive) to any previously active ASP in the AS.
For the Emergency Ceases case, proving begins at this time. See the In the case of a Loadshare mode AS, reception of an ASPAC message at an
section on Link Proving below. SG causes the direction of traffic to the ASP sending the ASPAC, in
addition to all the other ASPs that are currently active in the AS.
The algorithm at the SG for loadsharing traffic within an AS to all the
active ASPs is application and network dependent. The SG responds to
the ASPAC with a Notify (ASP-Active) message to the ASP.
4.3.2 Link Proving In the case of a New Traffic mode AS, reception of an ASPAC message at
an SG causes the direction of traffic to the ASP sending the ASPAC.
However, traffic related to completing calls/transactions in another ASP
is not sent to the new ASP (i.e., new calls/transactions only). How an
SG accomplishes the differentiation of old and new transactions and any
loadsharing of traffic is application and implementation dependent. The
SG responds to the ASPAC with a Notify (ASP-Active_New) message to the ASP.
After a configurable time Ts, the ASP is moved to the ASP-Active state and
a Notify (ASP-Active) is sent to the ASP. Most likely, the New Traffic
mode would not be used in M2UA.
One function of the adaptation layer is to make sure that the link 3.3.3.5 ASP Inactive
meets the performance requirements of the application. This is
usually done by proving the link. For example, for proving the link,
we need the adaptation layer to issue an heartbeat/RTT to its peer.
This is done before declaring link is in service to its application.
For this purpose, the existing "status" command is used. Note how the
link meets performance requirements is implementation dependent.
Also, the proving period can be configurable.
Proving is done by both ends of the link. To simplify the diagram, When an ASP wishes to withdraw from receiving traffic the ASP sends an
proving is shown on one end only. ASP Inactive (ASPIA) to the SG. In the case where an ASP is configured/-
registered to process the traffic for more than one Application Server
across an SCTP association, the ASPIA contains one or more Routing
Contexts to indicate for which Application Servers the ASPIA applies.
In the following diagram the Link has just completed the alignment There are two modes of Application Server traffic handling in the SG
procedure. M2UA when withdrawing an ASP from service - Over-ride, Load-balancing
and Graceful Withdrawal. The Type parameter in the ASPIA messge
indicates the mode used in a particular Application Server. If the SG
determines that the mode indicates in an ASPAC is incompatible with
the traffic handling mode currently used in the AS, the SG responds
with an Error message indicating ˘Invalid Traffic Handling Mode÷.
The Status primitive is sent to determine if the Heartbeats were In the case of an Over-ride mode AS, where normally another ASP has
delivered successfully within the desired time period. already taken over the traffic within the AS with an Over-ride ASPAC,
the ASP which sent the ASPIA is already considered by the SG to be
˘Inactive÷. A Notify (ASP_Up) message is resent to the ASP.
MTP3 M2UA SCTP SCTP M2UA MTP3 In the case of a Loadshare mode AS, the SG moves the ASP to the
---- ---- ---- ---- ---- ---- ˘Inactive÷ state and the AS traffic is re-allocated across the remaining
˘active÷ ASPs per the laoadsharing algorithm currently used within the
AS. A Notify (ASP-Up) message is sent to the ASP after the traffic is
halted to the ASP.
Request Heartbeat In the case of Graceful Withdrawal, the SG diverts all traffic related
------------> to new calls/transactions to other "active" ASPs and therafter sends only
(Heartbeat sent traffic related to incomplete transactons to the ASP. A Notify (ASP-
and acknowledged) Act_Old) is sent to the ASP and the ASP is moved to the "Active_Old" state.
Request Heartbeat When the outstanding calls/transactions are drained, or after a
------------> configurable time Ts, the SG moves the ASP to the "Up" state and sends
(Heartbeat sent a Notify (ASP-Up) message to the ASP. Most likely, Graceful Withdrawal
and acknowledged) will not be used with M2UA.
Request Heartbeat If no other ASPs are ˘Active÷ in the Application Server, the SG either
------------> discards all incoming messages (except messages related to an ˘Active_Old÷
(Heartbeat sent ASP) for the AS or starts buffering the incoming messages for T(r)seconds
and acknowledged) after which messages will be discarded. T(r) is configurable by the
network operator. If the SG receives an ASPAC from an ASP in the AS
before expiry of T(r), the buffered traffic is directed to the ASP and
the timer is cancelled.
Heartbeats are sent for M seconds (Note A). 4.0 Examples of MTP2 User Adaptation (M2UA) Procedures
Status 4.1 Establishment of associations between SG and MGC examples
------------>
Indication 4.1.1 Single ASP in an Application Server (˘1+0÷ sparing)
(Link In Service) (After checking that link is sane)
<------------
Note A M is implementation-dependent. This scenario shows the example M2UA message flows for the establishment
of traffic between an SG and an ASP, where only one ASP is configured
within an AS (no backup). It is assumed that the SCTP association is
already set-up.
4.3.3 Message Transmission and Reception SG ASP1
|
|<---------ASP Up----------|
|------NTFY (ASP-Up)------>|
| |
|<-------ASP Active--------|
|----NTFY (ASP_Active)---->|
| |
Messages are transmitted using the Data Request primitive from MTP3 to 4.1.2 Two ASPs in Application Server (˘1+1÷ sparing)
M2UA. The diagram shows the case where the Link is In Service. The
message is passed from MTP3 of the source to MTP3 of the destination.
MTP3 M2UA SCTP SCTP M2UA MTP3 This scenario shows the example M2UA message flows for the establishment
---- ---- ---- ---- ---- ---- of traffic between an SG and two ASPs in the same Application Server,
where ASP1 is configured to be ˘active÷ and ASP2 a ˘standby÷ in the event
of communication failure or the withdrawal from service of ASP1. ASP2 may
act as a hot, warm, or cold standby depending on the extent to which ASP1
and ASP2 share call/transaction state or can communicate call state under
failure/withdrawal events. The example message flow is the same whether
the ASP-Active messages are Over-ride or Load-share mode although typically
this example would use an Over-ride mode.
Request SG ASP1 ASP2
(Message for | | |
transmission) |<--------ASP Up----------| |
------------> |-------TFY (ASP-Up)----->| |
| | |
|<-----------------------------ASP Up----------------|
|----------------------------NTFY (ASP-Up)---------->|
| | |
| | |
|<-------ASP Active-------| |
|----NTFY(ASP-Active)---->| |
| | |
Send 4.1.3 Two ASPs in an Application Server (˘1+1÷ sparing, load-sharing case)
------------>
(SCTP sends message) This scenario shows a similar case to Section 4.1.2 but where the two
ASPs are brought to ˘active÷ and loadshare the traffic load. In this
case, one ASP is sufficient to handle the total traffic load.
Receive SG ASP1 ASP2
------------> | | |
|<---------ASP Up---------| |
|-------NTFY(ASP-Up)----->| |
| | |
|<------------------------------ASP Up---------------|
|-----------------------------NTFY(ASP Up)---------->|
| | |
| | |
|<--ASP Active (Ldshr)----| |
|----NTFY(ASP-Active)---->| |
| | |
|<----------------------------ASP Active (Ldshr)-----|
|-----------------------------NTFY(ASP-Active)------>|
| | |
Indication 4.1.4 Three ASPs in an Application Server (˘n+k÷ sparing, load-sharing case)
(Received message)
------------>
4.3.4 Link Status Indication This scenario shows the example M2UA message flows for the establishment
of traffic between an SG and three ASPs in the same Application Server,
where two of the ASPs are brought to ˘active÷ and share the load. In
this case, a minimum of two ASPs are required to handle the total traffic
load (2+1 sparing).
The M2UA layer sends an indication that the Link is In Service or Out SG ASP1 ASP2 ASP3
of Service after receiving a Communication indication from the SCTP | | | |
layer. In either case, MTP3 responds in its usual way. |<------ASP Up-------| | |
|----NTFY(ASP-Up)--->| | |
| | | |
|<--------------------------ASP Up-------| |
|------------------------NTFY(ASP-Up)--->| |
| | | |
|<---------------------------------------------ASP Up--------|
|--------------------------------------------NTFY(ASP-Up)--->|
| | | |
| | | |
|<-ASP Act. (Ldshr)--| | |
|---NTFY(ASP-Act.)-->| | |
| | | |
|<--------------------ASP Act. (Ldshr)---| |
|----------------------NTFY(ASP-Act.)--->| |
| | | |
MTP3 M2UA SCTP SCTP M2UA MTP3 4.2 ASP Traffic Fail-over Examples
---- ---- ---- ---- ---- ----
Communication Up 4.2.1 (1+1 Sparing, withdrawal of ASP, Back-up Over-ride)
<------------
(If Emergency Ceases, Following on from the example in Section 4.1.2, and ASP withdraws from
Link proving is done service:
by M2UA now.)
Indication SG ASP1 ASP2
(Link In Service) | | |
<------------ |<-----ASP Inactive-------| |
|---NTFY(ASP Inactive)--->| |
|--------------------NTFY(ASP-Inactive) (Optional)-->|
| | |
|<------------------------------ ASP Active----------|
|-----------------------------NTFY(ASP-Active)------>|
| |
MTP3 M2UA SCTP SCTP M2UA MTP3 Note: If the SG detects loss of the M2UA peer (M2UA heartbeat loss or
---- ---- ---- ---- ---- ---- detection of SCTP failure), the initial SG-ASP1 ASP Inactive message
exchange would not occur.
Communication Lost 4.2.2 (1+1 Sparing, Back-up Over-ride)
<------------
Indication Following on from the example in Section 4.1.2, and ASP2 wishes to over-
(Link Out of Service) ride ASP1 and take over the traffic:
<------------
4.3.5 Congestion Notification to Upper layer SG ASP1 ASP2
| | |
|<------------------------------ ASP Active----------|
|-----------------------------NTFY(ASP-Active)------>|
|----NTFY(ASP-Inactive)-->|
| | |
MTP3 layer expects notification of the link congestion. For example, 4.2.3 (n+k Sparing, Load-sharing case, withdrawal of ASP)
this is accomplished by two messages 1) Link Congestion Onset 2) Link
Congestion Abated. Congestion is assumed if M2UA layer notices
repeated failures to send requests to SCTP (this is implementation
dependent and it is assumed that the SEND Failure has an error code
"life time expired"). Subsequently M2UA can start polling status of
SCTP. If all the messages are successfully transmitted over a period
of time (implementation dependent) then it is assumed that the
congestion is abated. If the congestion condition should continue,
the link will be taken out of service. In this case, it is possible
to start the link changeover procedure.
The US National version of SS7 has congestion levels. For US National Following on from the example in Section 4.1.4, and ASP1 withdraws from
SS7, the Indication primitive for Congestion Onset should report the service:
congestion level.
In the example below, M2UA has sent a message to SCTP. SG ASP1 ASP2 ASP3
| | | |
|<----ASP Inact.-----| | |
|--NTFY(ASP-Inact.)->| | |
| | | |
|---------------------------------NTFY(Ins. ASPs)(Optional)->|
| | | |
|<-----------------------------------------ASP Act. (Ldshr)--|
|-------------------------------------------ASP Act. (Ack)-->|
| | | |
MTP3 M2UA SCTP SCTP M2UA MTP3 The Notify message to ASP3 is optional, as well as the ASP-Active from
---- ---- ---- ---- ---- ---- ASP3. The optional Notify can only occur if the SG maintains knowledge
of the minimum ASP resources required - for example if the SG knows that
˘n+k÷ = ˘2+1÷ for a loadshare AS and ˘n÷ currently equals ˘1÷.
Send Failure Note: If the SG detects loss of the ASP1 M2UA peer (M2UA heartbeat loss
<------------ or detection of SCTP failure), the first SG-ASP1 ASP Inactive message
Send Failure exchange would not occur.
<------------
Send Failure 4.3 SG to MGC, MTP Level 2 to MTP Level 3 Boundary Procedures
<------------
"N" consecutive fails -
implementation specific
Indication 4.3.1 SS7 Link Alignment
(Congestion Onset)
<------------
Status The MGC can request that a SS7 link be brought into alignment using the
------------> normal or emergency procedure. An example of the message flow to bring
Status a SS7 link in-service using the normal alignment procedure is shown
------------> below.
Status SG ASP
------------> | |
polled for certain time until |<---------Establish Req--------------|
congestion ceases - | |
implementation specific |----------Establish Cfm------------->|
| |
Indication An example of the message flow to bring a SS7 link in-service using the
(Congestion Abatement) emergency alignment procedure.
<------------
4.3.6 Link Deactivation SG ASP
| |
|<----State Req (STATUS_EMER_SET)-----|
| |
|-----State Cfm (STATUS_EMER_SET)---->|
| |
|<---------Establish Req--------------|
| |
|----------Establish Cfm------------->|
| |
The MTP3 can request that a SS7-IP link be taken out-of-service. It 4.3.2 SS7 Link Release
uses the Release Request message as shown below.
MTP3 M2UA SCTP SCTP M2UA MTP3 The MGC can request that a SS7 link be taken out-of-service. It uses
---- ---- ---- ---- ---- ---- the Release Request message as shown below.
Request SG ASP
(Deactivate Link) | |
------------> |<-----Release Req (RELEASE_MGMT)-----|
| |
|------------Release Cfm------------->|
| |
Terminate The SG can autonomously indicate that a SS7 link has gone out-of-service
------------> as shown below.
Terminate Successful SG ASP
<------------ | |
|------Release Ind (RELEASE_PHYS)---->|
| |
Communication Lost 4.3.3 Set and Clear Local Processor Outage
<------------
Indication The MGC can set a Local Processor Outage condition. It uses the
(Link Out of Service) State Request message as shown below.
<------------
4.3.7 Link Changeover SG ASP
| |
|<-----State Req (STATUS_LPO_SET)-----|
| |
|------State Cfm (STATUS_LPO_SET)---->|
| |
The objective of the changeover is to ensure that signaling traffic The MGC can clear a Local Processor Outage condition. It uses the
carried by the unavailable signaling link is diverted to the State Request message as shown below.
alternative signaling link as quickly as possible while avoiding
message loss, duplication, or mis-sequencing. For this purpose, the
changeover procedure includes data retrieval, which is performed
before reopening the alternative signaling links to the diverted
traffic. Data retrieval consists of identifying all those messages in
the retransmission buffer of the unavailable signaling link which have
not been received by the far end. Retrieval includes transferring the
concerned messages to the transmission buffers of the alternative
links. In order to support changeover, the SCTP SSN must be used in
place of the FSN/BSN of SS7.
Stream Sequence Numbers used by SCTP (Signaling Control Transport SG ASP
Protocol) are sixteen bits long. MTP2's forward and backward sequence | |
numbers are only seven bits long. Hence it is necessary to modify |<----State Req (STATUS_LPO_CLEAR)----|
MTP3 to accomodate the larger SSNs. Reference [7] can be used as a guide | |
for the MTP3 changes. |-----State Cfm (STATUS_LPO_CLEAR)--->|
| |
For data retrieval, MTP3 requests Backward Sequence Number (BSN) from 4.3.4 Notification of Processor Outage (local or remote)
M2UA. This is the sequence number of the last message received by the
local end. During normal period, SCTP delivers ordered messages to
the application. However, during congestion or failure condition, the
sequence numbers of the acknowledged messages can have gaps. In
particular, the SACK (selective acknowledgement message) message can
have several of these gaps. Hence, it is important to scan through
these gaps and find the sequence number before first gap. This is the
number from which the remote end has to transmit the messages. So,
this is the number considered as the Backward Sequence Number and
communicated to the remote end. In a similar way, the remote end also
detects the BSN and indicates to local end. As soon as the MTP3 of the
local end receives this BSN, MTP3 retrieves all the unacknowledged
messages starting from BSN. This is accomplished through "Retrieve
FSN" message. After all the messages are sent from M2UA to MTP3, a
retrieval complete message is sent.
Note that the sequence numbers and messages requested by MTP3 are sent The SG can indicate a Local or Remote Processor Outage condition. It
from SCTP to M2UA in the Communication Lost primitive. uses the State Indication message as shown below.
MTP3 M2UA SCTP SCTP M2UA MTP3 SG ASP
---- ---- ---- ---- ---- ---- | |
|-----State Ind (EVENT_ENTER_LPO)---->|
| |
|-----State Ind (EVENT_EXIT_LPO)----->|
| |
Communication Lost SG ASP
<------------ | |
|-----State Ind (EVENT_ENTER_RPO)---->|
| |
|-----State Ind (EVENT_EXIT_RPO)----->|
| |
Indication 4.3.5 SS7 Link Changeover
(Link Out of Service)
<------------
Request An example of the message flow for a changeover is shown below. In this
(Retrieve BSN) example, there were three messages in the retransmission queue that
------------> needed to be retrieved.
(M2UA locates SG ASP
first gap in | |
received messages) |----Retrieval Req (MTP2_RTRV_BSN)--->|
| |
|------Retrieval Cfm (with BSN)------>|
| |
|---Retrieval Req (MTP2_RTRV_MSGS)--->|
| with FSN |
| |
|-----------Retrieval Cfm------------>|
| |
|-----------Retrieval Ind------------>|
|-----------Retrieval Ind------------>|
|-------Retrieval Complete Ind------->|
| |
Indication Note: The number of Retrieval Indication is dependent on the number of
(Indicate BSN) messages in the retransmit queue that have been requested. Only one
<------------ Retrieval Complete Indication should be sent.
Request - COO (BSN) on another link 5.0 Security
------------------------------------------------------------>
Request 5.1 Introduction
(Retrieve BSN)
<------------
Indication M2UA is designed to carry signaling messages for telephony services. As such,
(Indicate BSN) M2UA must involve the security needs of several parties: the end users
------------> of the services; the network providers and the applications involved.
Additional requirements may come from local regulation. While having some
overlapping security needs, any security solution should fulfill all of the
different parties' needs.
Request - COA (BSN) 5.2 Threats
<------------------------------------------------------------
Request There is no quick fix, one-size-fits-all solution for security. As a
(Retrieve FSN) transport protocol, M2UA has the following security objectives:
------------>
(M2UA locates * Availability of reliable and timely user data transport.
first gap in * Integrity of user data transport.
acknowledgements) * Confidentiality of user data.
Indication M2UA runs on top of SCTP. SCTP [6] provides certain transport related
(FSB Not retrievable) (in case) security features, such as:
<------------
Indication * Blind Denial of Service Attacks
(Retrieved Message) * Flooding
<------------ * Masquerade
* Improper Monopolization of Services
Indication When M2UA is running in professionally managed corporate or service
(Retrieved Message) provider network, it is reasonable to expect that this network includes
<------------ an appropriate security policy framework. The "Site Security Handbook" [9]
should be consulted for guidance.
Indication When the network in which M2UA runs in involves more than one party, it
(Retrieval Complete) may not be reasonable to expect that all parties have implemented security
<------------ in a sufficient manner. In such a case, it is recommended that IPSEC is
used to ensure confidentiality of user payload. Consult [10] for more
information on configuring IPSEC services.
Send messages on another link. 5.3 Protecting Confidentiality
4.4 Layer Management Communication Examples Particularly for mobile users, the requirement for confidentiality may
include the masking of IP addresses and ports. In this case application
level encryption is not sufficient; IPSEC ESP should be used instead.
Regardless of which level performs the encryption, the IPSEC ISAKMP
service should be used for key management.
An example of the message flows for communication between Layer Manage- 6.0 IANA Considerations
ment modules between SG and MGC is shown below. An active association
between MGC and SG is established (section 4.1) prior to the following
message flows.
SG MGC A request will be made to IANA to assign an M2UA value for the Payload
Protocol Identifier in SCTP Payload Data chunk. The following SCTP Payload
Protocol Identifier will be registered:
<----------- Establish Request M2UA tbd
Error ---------->
(Invalid Interface Id)
5.0 Security The SCTP Payload Protocol Identifier is included in each SCTP Data chunk,
to indicate which protocol the SCTP is carrying. This Payload Protocol
Identifier is not directly used by SCTP but may be used by certain network
entities to identify the type of information being carried in a Data chunk.
SCN adaptation layers rely on SCTP to provide security. The User Adaptation peer may use the Payload Protocol Identifier as a way
of determining additional information about the data being presented to it
by SCTP.
6.0 Acknowledgements 7.0 Acknowledgements
The authors would like to thank Ian Rytina for his valuable comments and The authors would like to thank Ian Rytina, Hanns Juergen Schwarzbauer
suggestions. and ZhangYi for their valuable comments and suggestions.
7.0 References 8.0 References
[1] ITU-T Recommendation Q.700, 'Introduction To ITU-T Signalling [1] ITU-T Recommendation Q.700, 'Introduction To ITU-T Signalling
System No. 7 (SS7)' System No. 7 (SS7)'
[2] ITU-T Recommendation Q.701-Q.705, 'Signalling System No. 7 (SS7) - [2] ITU-T Recommendation Q.701-Q.705, 'Signalling System No. 7 (SS7) -
Message Transfer Part (MTP)' Message Transfer Part (MTP)'
[3] Bellcore GR-246-CORE 'Bell Communications Research Specification [3] ANSI T1.111 'Signalling System Number 7 - Message Transfer Part'
[4] Bellcore GR-246-CORE 'Bell Communications Research Specification
of Signaling System Number 7', Volume 1, December 1995 of Signaling System Number 7', Volume 1, December 1995
[4] Framework Architecture for Signaling Transport, draft-ietf-sigtran- [5] Framework Architecture for Signaling Transport, draft-ietf-sigtran-
framework-arch-03.txt, June 1999 framework-arch-03.txt, June 1999
[5] Simple Control Transmission Protocol, draft-ietf-sigtran-sctp-00.txt, [6] Simple Control Transmission Protocol, draft-ietf-sigtran-sctp-07.txt,
August 1999 March 2000
[6] Media Gateway Control Protocol (MGCP), draft-huitema-megaco-mgcp- [7] Media Gateway Control Protocol (MGCP), draft-huitema-megaco-mgcp-
v1-03.txt, August 1999 v1-03.txt, August 1999
[7] ITU-T Recommendation Q.2210, 'Message transfer part level 3 [8] ITU-T Recommendation Q.2210, 'Message transfer part level 3
functions and messages using the services of ITU-T functions and messages using the services of ITU-T
Recommendation Q.2140' Recommendation Q.2140'
8.0 Author's Addresses [9] RFC 2196, "Site Security Handbook", B. Fraser Ed., September 1997
[10] RFC 2401, "Security Architecture for the Internet Protocol", S.
Kent, R. Atkinson, November 1998.
9.0 Author's Addresses
Ken Morneault Tel: +1-703-484-3323 Ken Morneault Tel: +1-703-484-3323
Cisco Systems Inc. EMail: kmorneau@cisco.com Cisco Systems Inc. EMail: kmorneau@cisco.com
13615 Dulles Technology Drive 13615 Dulles Technology Drive
Herndon, VA. 20171 Herndon, VA. 20171
USA USA
Malleswar Kalla Tel: +1-973-829-5212 Malleswar Kalla Tel: +1-973-829-5212
Telcordia Technologies EMail: kalla@research.telcordia.com Telcordia Technologies EMail: kalla@research.telcordia.com
MCC 1J211R MCC 1J211R
445 South Street 445 South Street
Morristown, NJ 07960 Morristown, NJ 07960
USA USA
Greg Sidebottom Tel: +1-613-763-7305 Greg Sidebottom Tel: +1-613-763-7305
Nortel Networks EMail: gregside@nortelnetworks.com Nortel Networks EMail: gregside@nortelnetworks.com
3685 Richmond Rd, 3685 Richmond Rd,
Nepean, Ontario Nepean, Ontario
Canada K2H5B7 Canada K2H5B7
Ram Dantu, Ph.D. Tel: +1-972-477-8446 Ram Dantu, Ph.D. Tel +1-972-234-6070 extension 211
Alcatel USA EMail: ram.dantu@usa.alcatel.com IPmobile EMail rdantu@ipmobile.com
1000 Coit Road 1651 North Glenville, Suite 216
Plano, TX 74075 Richardson, TX 75081
USA
Tom George Tel: +1-972-519-3168 Tom George Tel: +1-972-519-3168
Alcatel USA EMail: tom.george@usa.alcatel.com Alcatel USA EMail: tom.george@usa.alcatel.com
1000 Coit Road 1000 Coit Road
Plano, TX 74075 Plano, TX 74075
USA
This Internet Draft expires June 2000. This Internet Draft expires September 2000.
 End of changes. 

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