draft-ietf-sigtran-m3ua-09.txt   draft-ietf-sigtran-m3ua-10.txt 
Network Working Group Greg Sidebottom Network Working Group Greg Sidebottom
INTERNET-DRAFT gregside consulting INTERNET-DRAFT gregside consulting
Javier Pastor-Balb▀s Javier Pastor-Balb×s, Ian Rytina
Ian Rytina
Ericsson Ericsson
Guy Mousseau Guy Mousseau
Nortel Networks Nortel Networks
Lyndon Ong Lyndon Ong
Ciena Ciena
Hanns Juergen Schwarzbauer Hanns Juergen Schwarzbauer
Siemens Siemens
Klaus Gradischnig Klaus Gradischnig
NeuStar NeuStar
Ken Morneault Ken Morneault
Cisco Cisco
Mallesh Kalla Mallesh Kalla
Telcordia Telcordia
Normand Glaude Normand Glaude
Performance Technologies Performance Technologies
Brian Bidulock Brian Bidulock
OpenSS7 OpenSS7
John Loughney John Loughney
Nokia Nokia
Expires in six months Oct 2001 Expires in six months Nov 2001
SS7 MTP3-User Adaptation Layer (M3UA) SS7 MTP3-User Adaptation Layer (M3UA)
<draft-ietf-sigtran-m3ua-09.txt> <draft-ietf-sigtran-m3ua-10.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, and documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working its working groups. Note that other groups may also distribute working
documents as Internet-Drafts. 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 3, line 11 skipping to change at page 3, line 11
Gateway Controller (MGC) or IP-resident Database. It is assumed that Gateway Controller (MGC) or IP-resident Database. It is assumed that
the SG receives SS7 signalling over a standard SS7 interface using the the SG receives SS7 signalling over a standard SS7 interface using the
SS7 Message Transfer Part (MTP) to provide transport. SS7 Message Transfer Part (MTP) to provide transport.
TABLE OF CONTENTS TABLE OF CONTENTS
1. Introduction.......................................................4 1. Introduction.......................................................4
1.1 Scope.........................................................4 1.1 Scope.........................................................4
1.2 Terminology...................................................4 1.2 Terminology...................................................4
1.3 M3UA Overview.................................................6 1.3 M3UA Overview.................................................6
1.4 Functional Areas.............................................12 1.4 Functional Areas.............................................10
1.5 Sample Configurations........................................20 1.5 Sample Configurations........................................16
1.6 Definition of M3UA Boundaries................................23 1.6 Definition of M3UA Boundaries................................19
2. Conventions.......................................................28 2. Conventions.......................................................24
3. M3UA Protocol Elements............................................28 3. M3UA Protocol Elements............................................24
3.1 Common Message Header........................................28 3.1 Common Message Header........................................24
3.2 Variable Length Parameter....................................31 3.2 Variable Length Parameter....................................26
3.3 Transfer Messages............................................33 3.3 Transfer Messages............................................29
3.4 SS7 Signalling Network management (SSNM) Messages............36 3.4 SS7 Signalling Network management (SSNM) Messages............32
3.5 ASP State Maintenance (ASPM) Messages........................45 3.5 ASP State Maintenance (ASPM) Messages........................41
3.6 Routing Key Management (RKM) Messages........................48 3.6 Routing Key Management (RKM) Messages........................44
3.7 ASP Traffic Maintenance (ASPTM) Messages.....................58 3.7 ASP Traffic Maintenance (ASPTM) Messages.....................54
3.8 Management(MGMT) Messages....................................62 3.8 Management(MGMT) Messages....................................58
4. Procedures........................................................66 4. Procedures........................................................63
4.1 Procedures to Support the M3UA-User .........................66 4.1 Procedures to Support the M3UA-User .........................63
4.2 Procedures to Support the Management of SCTP Associations ...69 4.2 Procedures to Support the Management of SCTP Associations ...66
4.3 AS and ASP State Maintenance.................................69 4.3 AS and ASP State Maintenance.................................66
4.4 Routing Key Management Procedures............................81 4.4 Routing Key Management Procedures............................79
4.5 Procedures to Support the Availability or Congestion Status 4.5 Procedures to Support the Availability or Congestion Status
of SS7 Destination...........................................83 of SS7 Destination...........................................81
4.6 MTP3 Restart.................................................86 4.6 MTP3 Restart.................................................84
5. Examples of M3UA Procedures.......................................86 5. Examples of M3UA Procedures.......................................85
5.1 Establishment of Association and Traffic 5.1 Establishment of Association and Traffic
Between SGs and ASPs.........................................86 Between SGs and ASPs.........................................85
5.2 ASP traffic Failover Examples................................91 5.2 ASP traffic Failover Examples................................89
5.3 Normal Withdrawal of an ASP from an Application Server 5.3 Normal Withdrawal of an ASP from an Application Server
and Teardown of an Association...............................92 and Teardown of an Association...............................91
5.4.M3UA/MTP3-User Boundary Examples.............................93 5.4.M3UA/MTP3-User Boundary Examples.............................91
5.5.Examples for IPSP Communication..............................95
6. Security..........................................................97 6. Security..........................................................97
6.1 Introduction.................................................97 6.1 Introduction.................................................97
6.2 Threats......................................................97 6.2 Threats......................................................97
6.3 Protecting Confidentiality...................................98 6.3 Protecting Confidentiality...................................97
7. IANA Considerations...............................................98 7. IANA Considerations...............................................98
7.1 SCTP Payload Protocol Identifier.............................98 7.1 SCTP Payload Protocol Identifier.............................98
7.2 M3UA Port Number.............................................98 7.2 M3UA Port Number.............................................98
7.3 M3UA Protocol Extensions.....................................99 7.3 M3UA Protocol Extensions.....................................99
8. Acknowledgements.................................................100 8. Acknowledgements..................................................99
9. References.......................................................100 9. References........................................................99
11. Author's Addresses.............................................102 11. Author's Addresses.............................................101
Appendix A..........................................................104
1. Introduction 1. Introduction
This draft defines a protocol for supporting the transport of
any SS7 MTP3-User signalling (e.g., ISUP and SCCP messages) over IP
using the services of the Stream Control Transmission Protocol [13]. Also, provision is made for protocol elements that enable a seamless
operation of the MTP3-User peers in the SS7 and IP domains. This
protocol would be used between a Signalling Gateway (SG) and a Media
Gateway Controller (MGC) or IP-resident Database [1].
1.1 Scope 1.1 Scope
There is a need for Switched Circuit Network (SCN) signalling protocol There is a need for Switched Circuit Network (SCN) signalling protocol
delivery from an SS7 Signalling Gateway (SG) to a Media Gateway delivery from an SS7 Signalling Gateway (SG) to a Media Gateway
Controller (MGC) or IP-resident Database as described in the Framework Controller (MGC) or IP-resident Database as described in the Framework
Architecture for Signalling Transport [1]. The delivery mechanism Architecture for Signalling Transport [1]. The delivery mechanism
SHOULD meet the following criteria: should meet the following criteria:
* Support for the transfer of all SS7 MTP3-User Part messages (e.g., * Support for the transfer of all SS7 MTP3-User Part messages (e.g.,
ISUP, SCCP, TUP, etc.) ISUP [2,3,4], SCCP [5,6,7], TUP [8] , etc.)
* Support for the seamless operation of MTP3-User protocol peers * Support for the seamless operation of MTP3-User protocol peers
* Support for the management of SCTP transport associations and * Support for the management of SCTP transport associations and
traffic between an SG and one or more MGCs or IP-resident Databases traffic between an SG and one or more MGCs or IP-resident Databases
* Support for MGC or IP-resident Database process failover and load * Support for MGC or IP-resident Database process failover and load
sharing sharing
* Support for the asynchronous reporting of status changes to * Support for the asynchronous reporting of status changes to
management management
In simplistic transport terms, the SG will terminate SS7 MTP2 and MTP3 In simplistic transport terms, the SG will terminate SS7 MTP2 and MTP3
protocol layers and deliver ISUP, SCCP and/or any other MTP3-User protocol layers [14,15,16] and deliver ISUP, SCCP and/or any other
protocol messages, as well as certain MTP network management events, MTP3-User protocol messages, as well as certain MTP network management
over SCTP transport associations to MTP3-User peers in MGCs or IP- events, over SCTP transport associations to MTP3-User peers in MGCs or
resident Databases. IP-resident Databases.
1.2 Terminology 1.2 Terminology
Application Server (AS) - A logical entity serving a specific Routing Application Server (AS) - A logical entity serving a specific Routing
Key. An example of an Application Server is a virtual switch element Key. An example of an Application Server is a virtual switch element
handling all call processing for a unique range of PSTN trunks, handling all call processing for a unique range of PSTN trunks,
identified by an SS7 SIO/DPC/OPC/CIC_range. Another example is a identified by an SS7 SIO/DPC/OPC/CIC_range. Another example is a
virtual database element, handling all HLR transactions for a virtual database element, handling all HLR transactions for a
particular SS7 DPC/OPC/SCCP_SSN combination. The AS contains a set of particular SS7 DPC/OPC/SCCP_SSN combination. The AS contains a set of
one or more unique Application Server Processes, of which one or more one or more unique Application Server Processes, of which one or more
skipping to change at page 5, line 12 skipping to change at page 5, line 18
endpoint and may be configured to process signalling traffic within endpoint and may be configured to process signalling traffic within
more than one Application Server. more than one Application Server.
Association - An association refers to an SCTP association. The Association - An association refers to an SCTP association. The
association provides the transport for the delivery of MTP3-User association provides the transport for the delivery of MTP3-User
protocol data units and M3UA adaptation layer peer messages. protocol data units and M3UA adaptation layer peer messages.
IP Server Process (IPSP) - A process instance of an IP-based IP Server Process (IPSP) - A process instance of an IP-based
application. An IPSP is essentially the same as an ASP, except that it application. An IPSP is essentially the same as an ASP, except that it
uses M3UA in a point-to-point fashion. Conceptually, an IPSP does not uses M3UA in a point-to-point fashion. Conceptually, an IPSP does not
use the services of a Signalling Gateway. use the services of a Signalling Gateway node.
Signalling Gateway Process (SGP) - A process instance of a Signalling
Gateway. It serves as an active, backup, loadsharing or broadcast
process of a Signalling Gateway.
Signalling Gateway - An SG is a signaling agent that receives/sends SCN
native signaling at the edge of the IP network [1]. An SG appears to
the SS7 network as an SS7 Signalling Point. An SG contains a set of
one or more unique Signalling Gateway Processes, of which one or more
is normally actively processing traffic. Where an SG contains more
than one SGP, the SG is a logical entity and the contained SGPs are
assumed to be coordinated into a single management view to the SS7
network and to the supported Application Servers.
Signalling Process - A process instance that uses M3UA to communicate
with other signalling processes. An ASP, an SGP and an IPSP are all
signalling processes.
Routing Key: A Routing Key describes a set of SS7 parameters and
parameter values that uniquely define the range of signalling traffic
to be handled by a particular Application Server. Parameters within the
Routing Key cannot extend across more than a single Signalling Point
Management Cluster.
Routing Context - A value that uniquely identifies a Routing Key.
Routing Context values are either configured using a configuration
management interface, or by using the routing key management procedures
defined in this document.
Failover - The capability to reroute signalling traffic as required Failover - The capability to reroute signalling traffic as required
to an alternate Application Server Process, or group of ASPs, within an to an alternate Application Server Process, or group of ASPs, within an
Application Server in the event of failure or unavailability of a Application Server in the event of failure or unavailability of a
currently used Application Server Process. Failover also applies upon currently used Application Server Process. Failover also applies upon
the return to service of a previously unavailable Application Server the return to service of a previously unavailable Application Server
Process. Process.
Signalling Point Management Cluster (SPMC) - The complete set of Host - The computing platform that the process (SGP, ASP or IPSP) is
Application Servers represented to the SS7 network under a single MTP running on.
entity (Signalling Point) in one specific Network Appearance. SPMCs
are used to aggregate the availability, congestion, and user part status
of an MTP entity (Signalling Point) that is distributed in the IP domain,
for the purpose of supporting MTP3 management procedures
towards the SS7 network. In some cases, the SG itself may also be a Layer Management - Layer Management is a nodal function that handles
member of the SPMC. In this case, the SG availability /congestion the inputs and outputs between the M3UA layer and a local management
/User_Part status should also be taken into account when considering any entity.
supporting MTP3 management actions.
Linkset - A number of signalling links that directly interconnect two
signalling points, which are used as a module.
MTP - The Message Transfer Part of the SS7 protocol. MTP - The Message Transfer Part of the SS7 protocol.
MTP3 - MTP Level 3, the signalling network layer of SS7 MTP3 - MTP Level 3, the signalling network layer of SS7
MTP3-User - Any protocol normally using the services of the SS7 MTP3 MTP3-User - Any protocol normally using the services of the SS7 MTP3
(e.g., ISUP, SCCP, TUP, etc.). (e.g., ISUP, SCCP, TUP, etc.).
Network Appearance - The Network Appearance is a M3UA local reference Network Appearance - The Network Appearance is a M3UA local reference
shared by SG and AS (typically an integer) that together with an shared by SG and AS (typically an integer) that together with an
Signaling Point Code uniquely identifies an SS7 node by indicating Signaling Point Code uniquely identifies an SS7 node by indicating
the specific SS7 network it belongs to. It can be used to distinguish the specific SS7 network it belongs to. It can be used to distinguish
between signalling traffic associated with different networks being between signalling traffic associated with different networks being
sent between the SG and the ASP over a common SCTP association. An sent between the SG and the ASP over a common SCTP association. An
example scenario is where an SG appears as an element in multiple example scenario is where an SG appears as an element in multiple
separate national SS7 networks and the same Signaling Point Code separate national SS7 networks and the same Signaling Point Code
value may be reused in different networks. value may be reused in different networks.
Network Byte Order: Most significant byte first, a.k.a Big Endian. Network Byte Order: Most significant byte first, a.k.a Big Endian.
Layer Management - Layer Management is a nodal function that handles Routing Key: A Routing Key describes a set of SS7 parameters and
the inputs and outputs between the M3UA layer and a local management parameter values that uniquely define the range of signalling traffic
entity. to be handled by a particular Application Server. Parameters within the
Routing Key cannot extend across more than a single Signalling Point
Management Cluster.
Host - The computing platform that the process (SGP, ASP or IPSP) is Routing Context - A value that uniquely identifies a Routing Key.
running on. Routing Context values are either configured using a configuration
management interface, or by using the routing key management procedures
defined in this document.
Signalling Gateway Process (SGP) - A process instance of a Signalling
Gateway. It serves as an active, backup, loadsharing or broadcast
process of a Signalling Gateway.
Signalling Gateway - An SG is a signaling agent that receives/sends SCN
native signaling at the edge of the IP network [1]. An SG appears to
the SS7 network as an SS7 Signalling Point. An SG contains a set of
one or more unique Signalling Gateway Processes, of which one or more
is normally actively processing traffic. Where an SG contains more
than one SGP, the SG is a logical entity and the contained SGPs are
assumed to be coordinated into a single management view to the SS7
network and to the supported Application Servers.
Signalling Process - A process instance that uses M3UA to communicate
with other signalling processes. An ASP, an SGP and an IPSP are all
signalling processes.
Signalling Point Management Cluster (SPMC) - The complete set of
Application Servers represented to the SS7 network under a single MTP
entity (Signalling Point) in one specific Network Appearance. SPMCs
are used to aggregate the availability, congestion, and user part status
of an MTP entity (Signalling Point) that is distributed in the IP domain,
for the purpose of supporting MTP3 management procedures
towards the SS7 network. In some cases, the SG itself may also be a
member of the SPMC. In this case, the SG availability /congestion
/User_Part status should also be taken into account when considering any
supporting MTP3 management actions.
Stream - A stream refers to an SCTP stream; a unidirectional logical Stream - A stream refers to an SCTP stream; a unidirectional logical
channel established from one SCTP endpoint to another associated SCTP channel established from one SCTP endpoint to another associated SCTP
endpoint, within which all user messages are delivered in-sequence endpoint, within which all user messages are delivered in-sequence
except for those submitted to the unordered delivery service. except for those submitted to the unordered delivery service.
1.3 M3UA Overview 1.3 M3UA Overview
1.3.1 Protocol Architecture. 1.3.1 Protocol Architecture.
skipping to change at page 6, line 46 skipping to change at page 7, line 4
Stream - A stream refers to an SCTP stream; a unidirectional logical Stream - A stream refers to an SCTP stream; a unidirectional logical
channel established from one SCTP endpoint to another associated SCTP channel established from one SCTP endpoint to another associated SCTP
endpoint, within which all user messages are delivered in-sequence endpoint, within which all user messages are delivered in-sequence
except for those submitted to the unordered delivery service. except for those submitted to the unordered delivery service.
1.3 M3UA Overview 1.3 M3UA Overview
1.3.1 Protocol Architecture. 1.3.1 Protocol Architecture.
The framework architecture that has been defined for SCN signalling The framework architecture that has been defined for SCN signalling
transport over IP [1] uses multiple components, including a common transport over IP [1] uses multiple components, including a common
signalling transport protocol and an adaptation module to support the signalling transport protocol and an adaptation module to support the
services expected by a particular SCN signalling protocol from its services expected by a particular SCN signalling protocol from its
underlying protocol layer. underlying protocol layer.
Within the framework architecture, this document defines an MTP3-User Within the framework architecture, this document defines an MTP3-User
adaptation module suitable for supporting the transfer of messages of adaptation module suitable for supporting the transfer of messages of
any protocol layer that is identified to the MTP Level 3 as an MTP any protocol layer that is identified to the MTP Level 3 as an MTP
User. The list of these protocol layers include, but is not limited User. The list of these protocol layers includes, but is not limited
to, ISDN User Part (ISUP) [2,3,4], Signalling Connection Control Part to, ISDN User Part (ISUP) [2,3,4], Signalling Connection Control Part
(SCCP) [5,6,7] and Telephone User Part (TUP) [8]. TCAP [9,10,11] or (SCCP) [5,6,7] and Telephone User Part (TUP) [8]. TCAP [9,10,11] or
RANAP [12] messages are transferred transparently by the M3UA protocol RANAP [12] messages are transferred transparently by the M3UA protocol
as SCCP payload, as they are SCCP-User protocols. as SCCP payload, as they are SCCP-User protocols.
It is recommended that M3UA use the services of the Stream Control It is recommended that M3UA use the services of the Stream Control
Transmission Protocol (SCTP) [13] as the underlying reliable common Transmission Protocol (SCTP) [13] as the underlying reliable common
signalling transport protocol. This is to take advantage of various signalling transport protocol. This is to take advantage of various
SCTP features such as: SCTP features such as:
skipping to change at page 9, line 26 skipping to change at page 9, line 35
1.3.2.4 Support for the Management of SCTP Associations between the SGP 1.3.2.4 Support for the Management of SCTP Associations between the SGP
and ASPs. and ASPs.
The M3UA layer at the SGP maintains the availability state of all The M3UA layer at the SGP maintains the availability state of all
configured remote ASPs, to manage the SCTP Associations and configured remote ASPs, to manage the SCTP Associations and
the traffic between the M3UA peers. As well, the active/inactive and the traffic between the M3UA peers. As well, the active/inactive and
congestion state of remote ASPs is maintained. congestion state of remote ASPs is maintained.
The M3UA layer MAY be instructed by local management to establish an The M3UA layer MAY be instructed by local management to establish an
SCTP association to a peer M3UA node. This can be achieved using the SCTP association to a peer M3UA node. This can be achieved using the
M-SCTP_ESTABLISH primitives to request, indicate and confirm the M-SCTP_ESTABLISH primitives (See Section 1.6.3 for a description of
management primitives) to request, indicate and confirm the
establishment of an SCTP association with a peer M3UA node. In order establishment of an SCTP association with a peer M3UA node. In order
to avoid redundant SCTP associations between two M3UA peers, one side to avoid redundant SCTP associations between two M3UA peers, one side
(client) SHOULD be designated to establish the SCTP association, or (client) SHOULD be designated to establish the SCTP association, or
M3UA configuration information maintained to detect redundant M3UA configuration information maintained to detect redundant
associations (e.g., via knowledge of the expected local and remote SCTP associations (e.g., via knowledge of the expected local and remote SCTP
endpoint addresses). endpoint addresses).
Local management MAY request from the M3UA layer the status of the Local management MAY request from the M3UA layer the status of the
underlying SCTP associations using the M-SCTP_STATUS request and underlying SCTP associations using the M-SCTP_STATUS request and
confirm primitives. Also, the M3UA MAY autonomously inform local confirm primitives. Also, the M3UA MAY autonomously inform local
skipping to change at page 10, line 8 skipping to change at page 10, line 18
a case a particular SS7 destination may be reachable via more than one a case a particular SS7 destination may be reachable via more than one
SGP and/or SG, i.e., via more than one route. As MTP3 users only SGP and/or SG, i.e., via more than one route. As MTP3 users only
maintain status on a destination and not on a route basis, the M3UA maintain status on a destination and not on a route basis, the M3UA
layer must maintain the status (availability, restriction, and/or layer must maintain the status (availability, restriction, and/or
congestion of route to destination) of the individual routes, derive congestion of route to destination) of the individual routes, derive
the overall availability or congestion status of the destination the overall availability or congestion status of the destination
from the status of the individual routes, and inform the MTP3 users from the status of the individual routes, and inform the MTP3 users
of this derived status whenever it changes. of this derived status whenever it changes.
1.3.3 Signalling Network Architecture
A Signalling Gateway is used to support the transport of MTP3-User
signalling traffic received from the SS7 network to multiple
distributed ASPs (e.g., MGCs and IP Databases). Clearly, the M3UA
protocol is not designed to meet the performance and reliability
requirements for such transport by itself. However, the conjunction
of distributed architecture and redundant networks provides support
for reliable transport of signalling traffic over IP. The M3UA
protocol is flexible enough to allow its operation and management
in a variety of physical configurations, enabling Network Operators
to meet their performance and reliability requirements.
To meet the stringent SS7 signalling reliability and performance
requirements for carrier grade networks, Network Operators SHOULD
ensure that no single point of failure is present in the end-to-end
network architecture between an SS7 node and an IP-based application.
This can typically be achieved through the use of redundant SGPs or
SGs, redundant hosts, and the provision of redundant QOS-bounded IP
network paths for SCTP Associations between SCTP End Points. Obviously,
the reliability of the SG, the MGC and other IP-based functional
elements also needs to be taken into account. The distribution of ASPs
and SGPs within the available Hosts MAY also be considered. As an
example, for a particular Application Server, the related ASPs could
be distributed over at least two Hosts.
One example of a physical network architecture relevant to SS7 carrier-
grade operation in the IP network domain is shown in Figure 1 below:
SG MGC
Host#1 ************** ************** Host#3
= * ********__*__________________________*__******** * =
* * SGP1 *__*_____ _______________*__* ASP1 * * MGC1
* ******** * \ / * ******** *
* ********__*______\__/________________*__******** *
* * SGP2 *__*_______\/______ _____*__* ASP2 * *
* ******** * /\ | | * ******** *
* : * / \ | | * : *
* ******** * / \ | | * ******** *
* * SGPn * * | | | | * * ASPn * *
* ******** * | | | | * ******** *
************** | | | | **************
| | \ /
Host#2 ************** | | \ / ************** Host#4
= * ********__*_____| |______\/_______*__******** * =
* * SGP1 *__*_________________/\_______*__* ASP1 * * MGC2
* ******** * / \ * ******** *
* ********__*_______________/ \_____*__******** *
* * SGP2 *__*__________________________*__* ASP2 * *
* ******** * * ******** *
* : * SCTP Associations * : *
* ******** * * ******** *
* * SGPn * * * * ASPn * *
* ******** * * ******** *
************** **************
Figure 1 - Physical Model
In this model, each host MAY have many application processes. In the
case of the MGC, an ASP may provide service to one or more Application
Servers, and is identified as an SCTP end point. One or more
Signalling Gateway Processes make up a single Signalling Gateway.
This example model can also be applied to IPSP-IPSP signalling. In
this case, each IPSP MAY have its services distributed across 2 hosts
or more, and may have multiple server processes on each host.
In the example above, each signalling process (SGP, ASP or IPSP) is the
end point to more than one SCTP association, leading to more than one
other signalling processes. To support this, a signalling process must
be able to support distribution of M3UA messages to many simultaneous
active associations. This message distribution function is based on
the status of provisioned Routing Keys, the status of the signalling
routes to signalling points in the SS7 network , and the redundancy
model (active-standby, load sharing, broadcast, n+k) of the remote
signalling processes.
For carrier grade networks, the failure or isolation of a particular
signalling process should not cause stable calls or transactions to be
lost. This implies that signalling processes need, in some cases, to
share the call/transaction state or be able to pass the call state
information between each other. In the case of ASPs performing call
processing, coordination may also be required with the related Media
Gateway to transfer the MGC control for a particular trunk termination.
However, this sharing or communication of call/transaction state
information is outside the scope of this document.
This model serves as an example. M3UA imposes no restrictions as to
the exact layout of the network elements, the message distribution
algorithms and the distribution of the signalling processes. Instead,
it provides a framework and a set of messages that allow for a flexible
and scalable signalling network architecture, aiming to provide
reliability and performance.
1.4 Functional Areas 1.4 Functional Areas
1.4.1 Signalling Point Code Representation 1.4.1 Signalling Point Code Representation
For example, within an SS7 network, a Signalling Gateway might be For example, within an SS7 network, a Signalling Gateway might be
charged with representing a set of nodes in the IP domain into the SS7 charged with representing a set of nodes in the IP domain into the SS7
network for routing purposes. The SG itself, as a signalling point in network for routing purposes. The SG itself, as a signalling point in
the SS7 network, might also be addressable with an SS7 Point Code for the SS7 network, might also be addressable with an SS7 Point Code for
MTP3 Management purposes. The SG Point Code might also be used for MTP3 Management purposes. The SG Point Code might also be used for
addressing any local MTP3-Users at the SG such as a local SCCP layer. addressing any local MTP3-Users at the SG such as a local SCCP layer.
An SG may be logically partitioned to operate in multiple SS7 network An SG may be logically partitioned to operate in multiple SS7 network
appearances. In such a case, the SG could be addressable with a Point appearances. In such a case, the SG could be addressable with a Point
Code in each network appearance, and represents a set of nodes in the Code in each network appearance, and represents a set of nodes in the
IP domain into each SS7 network. Alias Point Codes [15] may also be IP domain into each SS7 network. Alias Point Codes [15] may also be
used within an SG network appearance. used within an SG network appearance.
Where an SG contains more than one SGP, the MTP3 routeset, SPMC and Where an SG contains more than one SGP, the MTP3 routeset, SPMC and
remote AS/ASP states of each SGP SHOULD be coordinated across all the remote AS/ASP states of each SGP SHOULD be coordinated across all the
SGPs. Rerouting of traffic between the SGPs SHOULD also be supported. SGPs. Rerouting of traffic between the SGPs MAY also be supported.
Application Servers can be represented under the same Point Application Servers can be represented under the same Point
Code of the SG, their own individual Point Codes or grouped with other Code of the SG, their own individual Point Codes or grouped with other
Application Servers for Point Code preservation purposes. A single Application Servers for Point Code preservation purposes. A single
Point Code may be used to represent the SG and all the Application Point Code may be used to represent the SG and all the Application
Servers together, if desired. Servers together, if desired.
If an ASP or group of ASPs is available to the SS7 network via more If an ASP or group of ASPs is available to the SS7 network via more
than one SG, each with its own Point Code, the ASP(s) will typically be than one SG, each with its own Point Code, the ASP(s) will typically be
represented by a Point Code that is separate from any SG Point Code. represented by a Point Code that is separate from any SG Point Code.
skipping to change at page 13, line 4 skipping to change at page 10, line 50
Code of the SG, their own individual Point Codes or grouped with other Code of the SG, their own individual Point Codes or grouped with other
Application Servers for Point Code preservation purposes. A single Application Servers for Point Code preservation purposes. A single
Point Code may be used to represent the SG and all the Application Point Code may be used to represent the SG and all the Application
Servers together, if desired. Servers together, if desired.
If an ASP or group of ASPs is available to the SS7 network via more If an ASP or group of ASPs is available to the SS7 network via more
than one SG, each with its own Point Code, the ASP(s) will typically be than one SG, each with its own Point Code, the ASP(s) will typically be
represented by a Point Code that is separate from any SG Point Code. represented by a Point Code that is separate from any SG Point Code.
This allows, for example, these SGs to be viewed from the SS7 network This allows, for example, these SGs to be viewed from the SS7 network
as "STPs", each as "STPs", each
having an ongoing "route" to the same ASP(s). Under failure conditions having an ongoing "route" to the same ASP(s). Under failure conditions
where the ASP(s) become(s) unavailable from one of the SGs, this where the ASP(s) become(s) unavailable from one of the SGs, this
approach enables MTP3 route management messaging between the SG and SS7 approach enables MTP3 route management messaging between the SG and SS7
network, allowing simple SS7 rerouting through an alternate SG without network, allowing simple SS7 rerouting through an alternate SG without
changing the Destination Point Code Address of SS7 traffic to the changing the Destination Point Code Address of SS7 traffic to the
ASP(s). ASP(s).
Where a particular AS can be reached via more than one SGP, the Where a particular AS can be reached via more than one SGP, the
corresponding Routing Keys in the SGPs should be identical. (Note: corresponding Routing Keys in the SGPs should be identical. (Note:
It is possible for the SGP Routing Key configuration data to be It is possible for the SGP Routing Key configuration data to be
temporarily out-of-synch during configuration updates). temporarily out-of-sync during configuration updates).
+--------+ +--------+
| | | |
+------------+ SG 1 +--------------+ +------------+ SG 1 +--------------+
+-------+ | SS7 links | "STP" | IP network | ---- +-------+ | SS7 links | "STP" | IP network | ----
| SEP +---+ +--------+ +---/ \ | SEP +---+ +--------+ +---/ \
| or | |* | ASPs | | or | |* | ASPs |
| STP +---+ +--------+ +---\ / | STP +---+ +--------+ +---\ /
+-------+ | | | | ---- +-------+ | | | | ----
+------------+ SG 2 +--------------+ +------------+ SG 2 +--------------+
skipping to change at page 17, line 34 skipping to change at page 15, line 30
interworking is not necessary for this model. interworking is not necessary for this model.
1.4.4 Redundancy Models 1.4.4 Redundancy Models
1.4.4.1 Application Server Redundancy 1.4.4.1 Application Server Redundancy
All MTP3-User messages (e.g., ISUP, SCCP) which match a provisioned All MTP3-User messages (e.g., ISUP, SCCP) which match a provisioned
Routing Key at an SGP are mapped to an Application Server. Routing Key at an SGP are mapped to an Application Server.
The Application Server is the set of all ASPs associated with a The Application Server is the set of all ASPs associated with a
specific Routing Key. Each ASP in this set may be active inactive or specific Routing Key. Each ASP in this set may be active, inactive or
unavailable. Active ASPs handle traffic; inactive ASPs might be used unavailable. Active ASPs handle traffic; inactive ASPs might be used
when active ASPs become unavailable. when active ASPs become unavailable.
The failover model supports an "n+k" redundancy model, where "n" ASPs The failover model supports an "n+k" redundancy model, where "n" ASPs
is the minimum number of redundant ASPs required to handle traffic and 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. A "k" ASPs are available to take over for a failed or unavailable ASP. A
"1+1" active/backup redundancy is a subset of this model. A simplex "1+1" active/backup redundancy is a subset of this model. A simplex
"1+0" model is also supported as a subset, with no ASP redundancy. "1+0" model is also supported as a subset, with no ASP redundancy.
At the SGP, an Application Server list contains active and inactive
ASPs to support ASP broadcast, loadsharing and failover procedures.
The list of ASPs within a logical Application Server is kept updated in
the SGP to reflect the active Application Server Process(es).
For example, in the network shown in Figure 1, all messages to DPC x
could be sent to ASP1 in Host3 or ASP1 in Host4. The AS list at SGP1
in Host 1 might look like the following:
Routing Key {DPC=x) - "Application Server #1"
ASP1/Host3 - State = Active
ASP1/Host4 - State = Inactive
In this "1+1" redundancy case, ASP1 in Host3 would be sent any incoming
message with DPC=x. ASP1 in Host4 would normally be brought to the
"active" state upon failure of, or loss of connectivity to, ASP1/Host1.
The AS List at SGP1 in Host1 might also be set up in loadshare mode:
Routing Key {DPC=x) - "Application Server #1"
ASP1/Host3 - State = Active
ASP1/Host4 - State = Active
In this case, both the ASPs would be sent a portion of the traffic.
For example the two ASPs could together form a database, where incoming
queries may be sent to any active ASP.
Care might need to be exercised by a Network Operator in the selection
of the routing information to be used as the Routing Key for a
particular AS.
For example, where Application Servers are defined using ranges of ISUP
CIC values, the Operator is implicitly splitting up control of the
related circuit groups. Some CIC value range assignments may interfere
with ISUP circuit group management procedures.
In the process of failover, 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. Any ASP-to-ASP
protocol to support this function is outside the scope of this
document.
1.4.4.2 Signalling Gateway Redundancy
Signalling Gateways MAY also be distributed over multiple hosts. Much
like the AS model, SGs may comprise one or more SG Processes (SGPs),
distributed over one or more hosts, using an active/backup or a
loadsharing model. Should an SGP lose all or partial SS7
connectivity and other SGPs exist, the SGP MUST terminate the SCTP
associations to the concerned ASPs.
It is therefore possible for an ASP to route signalling messages
destined to the SS7 network using more than one SGP. In this model, a
Signalling Gateway is deployed as a cluster of hosts acting as a single
SG. A primary/backup redundancy model is possible, where the
unavailability of the SCTP association to a primary SGP could be used
to reroute affected traffic to an alternate SGP. A loadsharing model
is possible, where the signalling messages are loadshared between
multiple SGPs. A broadcast model is also possible, where signalling
messages are sent to each active SGP in the SG. The distribution of the
MTP3-user messages over the SGPs should be done in such a way to
minimize message missequencing, as required by the SS7 User Parts.
It may also be possible for an ASP to use more than one SG to access a
specific SS7 end point, in a model that resembles an SS7 STP mated
pair. Typically, SS7 STPs are deployed in mated pairs, with traffic
loadshared between them. Other models are also possible, subject to
the limitations of the local SS7 network provisioning guidelines.
>From the perspective of the M3UA layer at an ASP, a particular SG is
capable of transferring traffic to a provisioned SS7 destination X if
an SCTP association with at least one SGP of the SG is established,
the SGP has returned an acknowledgement to the ASP to indicate that
the ASP is actively handling traffic for that destination X, the SGP
has not indicated that the destination X is inaccessible and the SGP
has not indicated MTP Restart. When an ASP is configured to use
multiple SGPs for transferring traffic to the SS7 network, the ASP
must maintain knowledge of the current capability of the SGPs to
handle traffic to destinations of interest. This information is
crucial to the overall reliability of the service, for active/backup,
loadsharing and broadcast models, in the event of failures, recovery
and maintenance activities. The ASP M3UA may also use this
information for congestion avoidance purposes. The distribution of
the MTP3-user messages over the SGPs should be done in such a way to
minimize message missequencing, as required by the SS7 User Parts.
1.4.5 Flow Control 1.4.5 Flow Control
Local Management at an ASP may wish to stop traffic across an SCTP Local Management at an ASP may wish to stop traffic across an SCTP
association to temporarily remove the association from service association to temporarily remove the association from service
or to perform testing and maintenance activity. The function could or to perform testing and maintenance activity. The function could
optionally be used to control the start of traffic on to a newly optionally be used to control the start of traffic on to a newly
available SCTP association. available SCTP association.
1.4.6 Congestion Management 1.4.6 Congestion Management
skipping to change at page 20, line 44 skipping to change at page 16, line 48
other the role of server for initiating SCTP associations. The default other the role of server for initiating SCTP associations. The default
orientation would be for the SGP to take on the role of server while orientation would be for the SGP to take on the role of server while
the ASP is the client. In this case, ASPs SHOULD initiate the the ASP is the client. In this case, ASPs SHOULD initiate the
SCTP association to the SGP. SCTP association to the SGP.
In the case of IPSP to IPSP communication, the peer endpoints using In the case of IPSP to IPSP communication, the peer endpoints using
M3UA SHOULD be configured so that one always takes on the role of M3UA SHOULD be configured so that one always takes on the role of
client and the other the role of server for initiating SCTP client and the other the role of server for initiating SCTP
associations. associations.
The SCTP Registered User Port Number Assignment for M3UA is 2905. The SCTP and TCP Registered User Port Number Assignment for M3UA is
2905.
1.5 Sample Configurations 1.5 Sample Configurations
1.5.1 Example 1: ISUP Message Transport 1.5.1 Example 1: ISUP Message Transport
******** SS7 ***************** IP ******** ******** SS7 ***************** IP ********
* SEP *---------* SGP *--------* ASP * * SEP *---------* SGP *--------* ASP *
******** ***************** ******** ******** ***************** ********
+------+ +---------------+ +------+ +------+ +---------------+ +------+
skipping to change at page 28, line 5 skipping to change at page 24, line 5
M-RK_DEREG confirm M-RK_DEREG confirm
Direction: M3UA -> LM Direction: M3UA -> LM
Purpose: ASP reports that it has received DEREG REQ message with Purpose: ASP reports that it has received DEREG REQ message with
deregistration status as successful from its peer. deregistration status as successful from its peer.
M-RK_DEREG indication M-RK_DEREG indication
Direction: M3UA -> LM Direction: M3UA -> LM
Purpose: M3UA informs LM that it has successfully processed an Purpose: M3UA informs LM that it has successfully processed an
incoming DEREG REQ from its peer. incoming DEREG REQ from its peer.
2.0 Conventions 2. Conventions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD
NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear
in this document, are to be interpreted as described in [RFC2119]. in this document, are to be interpreted as described in [RFC2119].
3. M3UA Protocol Elements 3. M3UA Protocol Elements
The general M3UA message format includes a Common Message Header The general M3UA message format includes a Common Message Header
followed by zero or more parameters as defined by the Message Type. followed by zero or more parameters as defined by the Message Type.
For forward compatibility, all Message Types may have attached For forward compatibility, all Message Types may have attached
skipping to change at page 32, line 38 skipping to change at page 28, line 38
Reserved by the IETF 0x0214 to 0xffff Reserved by the IETF 0x0214 to 0xffff
The value of 65535 is reserved for IETF-defined extensions. Values The value of 65535 is reserved for IETF-defined extensions. Values
other than those defined in specific parameter description are other than those defined in specific parameter description are
reserved for use by the IETF. reserved for use by the IETF.
Parameter Length: 16 bits (unsigned integer) Parameter Length: 16 bits (unsigned integer)
The Parameter Length field contains the size of the parameter in The Parameter Length field contains the size of the parameter in
bytes, including the Parameter Tag, Parameter Length, and Parameter bytes, including the Parameter Tag, Parameter Length, and Parameter
Value fields. The Parameter Length does not include any padding Value fields. Thus, a parameter with a zero-length Parameter Value
bytes. field would have a Length field of 4. The Parameter Length does
not include any padding bytes.
Parameter Value: variable length. Parameter Value: variable length.
The Parameter Value field contains the actual information to be The Parameter Value field contains the actual information to be
transferred in the parameter. transferred in the parameter.
The total length of a parameter (including Tag, Parameter Length and The total length of a parameter (including Tag, Parameter Length and
Value fields) MUST be a multiple of 4 bytes. If the length of the Value fields) MUST be a multiple of 4 bytes. If the length of the
parameter is not a multiple of 4 bytes, the sender pads the parameter is not a multiple of 4 bytes, the sender pads the
Parameter at the end (i.e., after the Parameter Value field) with Parameter at the end (i.e., after the Parameter Value field) with
skipping to change at page 33, line 21 skipping to change at page 29, line 21
The DATA message contains the SS7 MTP3-User protocol data, which is an The DATA message contains the SS7 MTP3-User protocol data, which is an
MTP-TRANSFER primitive, including the complete MTP3 Routing Label. The MTP-TRANSFER primitive, including the complete MTP3 Routing Label. The
DATA message contains the following variable length parameters: DATA message contains the following variable length parameters:
Network Appearance Optional Network Appearance Optional
Routing Context Optional Routing Context Optional
Protocol Data Mandatory Protocol Data Mandatory
Correlation Id Optional Correlation Id Optional
3.3 Transfer Messages
The following section describes the Transfer messages and parameter
contents.
3.3.1 Payload Data Message (DATA)
The DATA message contains the SS7 MTP3-User protocol data, which is an
MTP-TRANSFER primitive, including the complete MTP3 Routing Label. The
DATA message contains the following variable length parameters:
Network Appearance Optional
Routing Context Optional
Protocol Data Mandatory
Correlation Id Optional
The following format MUST be used for the Data Message: The following format MUST be used for the Data Message:
0 1 2 3 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 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 = 0x0200 | Length = 8 | | Tag = 0x0200 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance | | Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length = 8 | | Tag = 0x0006 | Length = 8 |
skipping to change at page 34, line 31 skipping to change at page 30, line 7
/ Protocol Data / / Protocol Data /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0211 | Length = 8 | | Tag = 0x0211 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Correlation Id | | Correlation Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Network Appearance: 32-bits (unsigned integer) Network Appearance: 32-bits (unsigned integer)
The optional Network Appearance parameter identifies the SS7 network The Network Appearance parameter identifies the SS7 network
context for the message, for the purposes of logically separating context for the message and implicitly identifies the SS7
the signalling traffic between the SGP and the ASP over a common
SCTP association. An example is where an SG is logically
partitioned to appear as an element in four different national SS7
networks.
In a DATA message, the Network Appearance implicitly defines the SS7
Point Code format used, the SS7 Network Indicator value, and the Point Code format used, the SS7 Network Indicator value, and the
MTP3 and possibly the MTP3-User protocol type/variant/version used MTP3 and possibly the MTP3-User protocol type/variant/version used
within the specific SS7 network. Where an SG operates in the within the specific SS7 network. Where an SG operates in the
context of a single SS7 network, or individual SCTP associations context of a single SS7 network, or individual SCTP associations
are dedicated to each SS7 network context, the Network Appearance are dedicated to each SS7 network context, the Network Appearance
parameter is not required. In other cases the parameter MUST be parameter is not required. In other cases the parameter may be
included. configured to be present for the use of the receiver.
The Network Appearance parameter value is of local significance The Network Appearance parameter value is of local significance
only, coordinated between the SGP and ASP. Therefore, in the case only, coordinated between the SGP and ASP. Therefore, in the case
where an ASP is connected to more than one SGP, the same SS7 network where an ASP is connected to more than one SGP, the same SS7 network
context may be identified by different Network Appearance values context may be identified by different Network Appearance values
depending over which SGP a message is being transmitted/received. depending over which SGP a message is being transmitted/received.
Where the optional Network Appearance parameter is present, it must Where the optional Network Appearance parameter is present, it must
be the first parameter in the message as it defines the format of be the first parameter in the message as it defines the format of
the Protocol Data field. the Protocol Data field.
IMPLEMENTATION NOTE: For simplicity of configuration it may be
desirable to use the same NA value across all nodes sharing a
particular network context.
Routing Context: 32-bits (unsigned integer) Routing Context: 32-bits (unsigned integer)
The optional Routing Context parameter contains the Routing Context The Routing Context parameter contains the Routing Context
value associated with the DATA message. Where multiple Routing value associated with the DATA message. Where a Routing Key has
not been coordinated between the SGP and ASP, sending of Routing
Context is not required. Where multiple Routing
Keys and Routing Contexts are used across a common association, the Keys and Routing Contexts are used across a common association, the
Routing Context may identify to the receiver the traffic flow, Routing Context MUST be sent to identify the traffic flow,
assisting in the internal distribution of Data messages. assisting in the internal distribution of Data messages.
Protocol Data 1 or 2: variable length Protocol Data 1 or 2: variable length
The Protocol Data parameter contains the original SS7 MTP3 The Protocol Data parameter contains the original SS7 MTP3
message, including the Service Information Octet and Routing Label. message, including the Service Information Octet and Routing Label.
The Protocol Data parameter contains the following fields: The Protocol Data parameter contains the following fields:
Service Indicator, Service Indicator,
skipping to change at page 38, line 8 skipping to change at page 33, line 42
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Network Appearance: 32-bit unsigned integer Network Appearance: 32-bit unsigned integer
See Section 3.3.1 See Section 3.3.1
Routing Context: n x 32-bits (unsigned integer) Routing Context: n x 32-bits (unsigned integer)
The optional Routing Context parameter contains the Routing Context The optional Routing Context parameter contains the Routing Context
values associated with the DUNA message. Where multiple Routing values associated with the DUNA message. Where a Routing Key has
Keys and Routing Contexts are used across a common association, the not been coordinated between the SGP and ASP, sending of Routing
Routing Context(s) may identify to the receiver the concerned Context is not required. Where multiple Routing Keys and Routing
traffic flows for which the DUNA message applies, assisting in Contexts are used across a common association, the Routing
outgoing traffic management and internal distribution of MTP-PAUSE Context(s) MUST be sent to identify the concerned traffic flows
indications to MTP3-Users at the receiver. for which the DUNA message applies, assisting in outgoing traffic
management and internal distribution of MTP-PAUSE indications to
MTP3-Users at the receiver.
Affected Point Code: n x 32-bits Affected Point Code: n x 32-bits
The Affected Point Code parameter contains up to sixteen Affected The Affected Point Code parameter contains up to sixteen Affected
Destination Point Code fields, each a three-octet parameter to allow Destination Point Code fields, each a three-octet parameter to allow
for 14-, 16- and 24-bit binary formatted SS7 Point Codes. Affected for 14-, 16- and 24-bit binary formatted SS7 Point Codes. Affected
Point Codes that are less than 24-bits, are padded on the left to Point Codes that are less than 24-bits, are padded on the left to
the 24-bit boundary. The encoding is shown below for ANSI and ITU the 24-bit boundary. The encoding is shown below for ANSI and ITU
Point Code examples. Point Code examples.
skipping to change at page 38, line 46 skipping to change at page 34, line 36
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask |0 0 0 0 0 0 0 0 0 0|Zone | Region | SP | | Mask |0 0 0 0 0 0 0 0 0 0|Zone | Region | SP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MSB--------------------LSB| |MSB--------------------LSB|
It is optional to send an Affected Point Code parameter with more It is optional to send an Affected Point Code parameter with more
than one Affected PC but it is mandatory to receive it. All the than one Affected PC but it is mandatory to receive it. All the
Affected PCs included must be within the same Routing Context. Affected PCs included must be within the same Network Appearance
Including multiple Affected PCs may be useful when reception of an and/or (set of) Routing Context values included in a Routing Context
MTP3 management message or a linkset event simultaneously affects parameter. Including multiple Affected PCs may be useful when
the availability status of a list of destinations at an SG. reception of an MTP3 management message or a linkset event
simultaneously affects the availability status of a list of
destinations at an SG.
Mask: 8-bits (unsigned integer) Mask: 8-bits (unsigned integer)
The Mask field can be used to identify a contiguous range of The Mask field can be used to identify a contiguous range of
Affected Destination Point Codes, independent of the point code Affected Destination Point Codes, independent of the point code
format. Identifying a contiguous range of Affected DPCs may be format. Identifying a contiguous range of Affected DPCs may be
useful when reception of an MTP3 management message or a linkset useful when reception of an MTP3 management message or a linkset
event simultaneously affects the availability status of a series of event simultaneously affects the availability status of a series of
destinations at an SG. destinations at an SG.
skipping to change at page 41, line 50 skipping to change at page 37, line 50
\ \ \ \
/ INFO String / / INFO String /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the Network Appearance, Routing The format and description of the Network Appearance, Routing
Context, Affected Point Code, and INFO String parameters is the same Context, Affected Point Code, and INFO String parameters is the same
as for the DUNA message (See Section 3.4.1). as for the DUNA message (See Section 3.4.1).
The Affected Point Code parameter can be used to indicate congestion The Affected Point Code parameter can be used to indicate congestion
of multiple destinations or ranges of destinations. However, an of multiple destinations or ranges of destinations.
SCON message MUST not be delayed to "collect" individual congested
destinations into a single SCON message as any delay might affect
the timing of congestion indications to the M3UA Users. One use for
including a range of Congested DPCs is when the SG supports an ANSI
cluster route set to the SS7 network that becomes congested due to
outgoing link set congestion.
Concerned Destination: 32-bits Concerned Destination: 32-bits
The optional Concerned Destination parameter is only used if the The optional Concerned Destination parameter is only used if the
SCON message is sent from an ASP to the SGP. It contains the point SCON message is sent from an ASP to the SGP. It contains the point
code of the originator of the message that triggered the SCON code of the originator of the message that triggered the SCON
message. The Concerned Destination parameter contains one Concerned message. The Concerned Destination parameter contains one Concerned
Destination Point Code field, a three-octet parameter to allow for Destination Point Code field, a three-octet parameter to allow for
14-, 16- and 24-bit binary formatted SS7 Point Codes. A Concerned 14-, 16- and 24-bit binary formatted SS7 Point Codes. A Concerned
Point Code that is less than 24-bits is padded on the left to the Point Code that is less than 24-bits is padded on the left to the
skipping to change at page 50, line 30 skipping to change at page 46, line 30
| Originating Point Code List (optional) | | Originating Point Code List (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Circuit Range List (optional) | | Circuit Range List (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ ... / / ... /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Point Code | | Destination Point Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Indicators (optional) | | Service Indicators (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originating Point Code List (optional) | | Originating Point Code List (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Circuit Range List (optional) | | Circuit Range List (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Local-RK-Identifier: 32-bit integer Local-RK-Identifier: 32-bit integer
The mandatory Local-RK-Identifier field is used to uniquely identify The mandatory Local-RK-Identifier field is used to uniquely identify
skipping to change at page 51, line 39 skipping to change at page 47, line 37
The valid values for Traffic Mode Type are shown in the The valid values for Traffic Mode Type are shown in the
following table: following table:
1 Override 1 Override
2 Loadshare 2 Loadshare
3 Broadcast 3 Broadcast
If the receiver of the REG REQ creates a new Routing Key entry, then If the receiver of the REG REQ creates a new Routing Key entry, then
the Traffic Mode Type sets the traffic mode for the new Application the Traffic Mode Type sets the traffic mode for the new Application
Server. If the receiver of the REG REQ determines that a matching Server. If the receiver of the REG REQ determines that a matching
Routing Key already exists, the Traffic Mode Type MUST match the Routing Key already exists, and the traffic mode was specified in the Routing Key, the Traffic Mode Type MUST match the
existing traffic mode for the AS. existing traffic mode for the AS.
Destination Point Code: Destination Point Code:
The Destination Point Code parameter is mandatory, and identifies The Destination Point Code parameter is mandatory, and identifies
the Destination Point Code of incoming SS7 traffic for which the ASP the Destination Point Code of incoming SS7 traffic for which the ASP
is registering. The format is the same as described for the is registering. The format is the same as described for the
Affected Destination parameter in the DUNA message (See Section Affected Destination parameter in the DUNA message (See Section
3.4.1). Its format is: 3.4.1). Its format is:
skipping to change at page 52, line 28 skipping to change at page 48, line 28
| Network Appearance | | Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Service Indicators (SI): n X 8-bit integers Service Indicators (SI): n X 8-bit integers
The optional SI field contains one or more Service Indicators from The optional SI field contains one or more Service Indicators from
the values as described in the MTP3-User Identity field of the DUPU the values as described in the MTP3-User Identity field of the DUPU
message. The absence of the SI parameter in the Routing Key message. The absence of the SI parameter in the Routing Key
indicates the use of any SI value, excluding of course MTP indicates the use of any SI value, excluding of course MTP
management. Where an SI parameter does not contain a multiple of management. Where an SI parameter does not contain a multiple of
four SIs, the parameter is padded out to 32-byte alignment. An four SIs, the parameter is padded out to 32-byte alignment.
SI value of zero is not valid in M3UA. The SI format is:
The SI format is:
0 1 2 3 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 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 = 0x020c | Length | | Tag = 0x020c | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SI #1 | SI #2 | SI #3 | SI #4 | | SI #1 | SI #2 | SI #3 | SI #4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ... / / ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 54, line 17 skipping to change at page 50, line 17
The REG RSP message is used as a response to the REG REQ message from a The REG RSP message is used as a response to the REG REQ message from a
remote M3UA peer. It contains indications of success/failure for remote M3UA peer. It contains indications of success/failure for
registration requests and returns a unique Routing Context value for registration requests and returns a unique Routing Context value for
successful registration requests, to be used in subsequent M3UA Traffic successful registration requests, to be used in subsequent M3UA Traffic
Management protocol. Management protocol.
The REG RSP message contains the following parameters: The REG RSP message contains the following parameters:
Registration Result Mandatory Registration Result Mandatory
One or more Registration Result parameters MAY be included. The format One or more Registration Result parameters MUST be included. The format
for the REG RSP message is as follows: for the REG RSP message is as follows:
0 1 2 3 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 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 = 0x0208 | Length | | Tag = 0x0208 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Result 1 | | Registration Result 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
skipping to change at page 54, line 40 skipping to change at page 50, line 40
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0208 | Length | | Tag = 0x0208 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Result n | | Registration Result n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Registration Results: Registration Results:
The Registration Result parameter contains the registration result The Registration Result parameter contains the registration result
for a single Routing Key in an REG REQ message. The number of for a single Routing Key in an REG REQ message. The number of
results in a single REG RSP message MAY be anywhere from one to the results in a single REG RSP message MAY MUST be anywhere from one to the
total number of number of Routing Key parameters found in the total number of number of Routing Key parameters found in the
corresponding REG REQ message. Where multiple REG RSP messages are corresponding REG REQ message. Where multiple REG RSP messages are
used in reply to REG REQ message, a specific result SHOULD be in used in reply to REG REQ message, a specific result SHOULD be in
only one REG RSP message. The format of each result is as follows: only one REG RSP message. The format of each result is as follows:
0 1 2 3 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 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 = 0x020a | Length = 8 | | Tag = 0x020a | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 56, line 43 skipping to change at page 52, line 43
3.6.4 Deregistration Response (DEREG RSP) 3.6.4 Deregistration Response (DEREG RSP)
The DEREG RSP message is used as a response to the DEREG REQ message The DEREG RSP message is used as a response to the DEREG REQ message
from a remote M3UA peer. from a remote M3UA peer.
The DEREG RSP message contains the following parameters: The DEREG RSP message contains the following parameters:
Deregistration Result Mandatory Deregistration Result Mandatory
One or more Deregistration Result parameters MAY be included. The One or more Deregistration Result parameters MUST be included. The
format for the DEREG RSP message is as follows: format for the DEREG RSP message is as follows:
0 1 2 3 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 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 = 0x0209 | Length | | Tag = 0x0209 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Deregistration Result 1 | | Deregistration Result 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
skipping to change at page 59, line 10 skipping to change at page 55, line 10
The Traffic Mode Type parameter identifies the traffic mode of The Traffic Mode Type parameter identifies the traffic mode of
operation of the ASP within an AS. The valid values for Traffic Mode operation of the ASP within an AS. The valid values for Traffic Mode
Type are shown in the following table: Type are shown in the following table:
1 Override 1 Override
2 Loadshare 2 Loadshare
3 Broadcast 3 Broadcast
Within a particular Routing Context, Override, Loadshare and Within a particular Routing Context, Override, Loadshare and
Broadcast MUST NOT be mixed. The Override value indicates that the Broadcast SHOULD NOT be mixed. The Override value indicates that the
ASP is operating in Override mode, and the ASP takes over all ASP is operating in Override mode, and the ASP takes over all
traffic in an Application Server (i.e., primary/backup operation), traffic in an Application Server (i.e., primary/backup operation),
overriding any currently active ASPs in the AS. In Loadshare mode, overriding any currently active ASPs in the AS. In Loadshare mode,
the ASP will share in the traffic distribution with any other the ASP will share in the traffic distribution with any other
currently active ASPs. In Broadcast mode, the ASP will receive the currently active ASPs. In Broadcast mode, the ASP will receive the
same messages as any other currently active ASP. same messages as any other currently active ASP.
Routing Context: n X 32-bit integers Routing Context: n X 32-bit integers
The optional Routing Context parameter contains (a list of) integers The optional Routing Context parameter contains (a list of) integers
skipping to change at page 62, line 27 skipping to change at page 58, line 27
3.8.1 Error 3.8.1 Error
The Error message is used to notify a peer of an error event associated The Error message is used to notify a peer of an error event associated
with an incoming message. For example, the message type might be with an incoming message. For example, the message type might be
unexpected given the current state, or a parameter value might be unexpected given the current state, or a parameter value might be
invalid. invalid.
The Error message contains the following parameters: The Error message contains the following parameters:
Error Code Mandatory Error Code Mandatory
Routing Context Mandatory*
Network Appearance Mandatory*
Affected Point Code Mandatory*
Diagnostic Information Optional Diagnostic Information Optional
(*) Only mandatory for specific Error Codes
The format for the Error message is as follows: The format for the Error message is as follows:
0 1 2 3 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 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 = 0x000c | Length = 8 | | Tag = 0x000c | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | | Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag - 0x0012 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Affected Point Code 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Affected Point Code n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0200 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0007 | Length | | Tag = 0x0007 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ Diagnostic Information / / Diagnostic Information /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Error Code: 32-bits (unsigned integer) Error Code: 32-bits (unsigned integer)
The Error Code parameter indicates the reason for the Error Message. The Error Code parameter indicates the reason for the Error Message.
skipping to change at page 63, line 22 skipping to change at page 60, line 17
0x0c Not used in M3UA 0x0c Not used in M3UA
0x0d Refused - Management Blocking 0x0d Refused - Management Blocking
0x0e ASP Identifier Required 0x0e ASP Identifier Required
0x0f Invalid ASP Identifier 0x0f Invalid ASP Identifier
0x10 Invalid Routing Context 0x10 Invalid Routing Context
0x11 Invalid Parameter Value 0x11 Invalid Parameter Value
0x12 Parameter Field Error 0x12 Parameter Field Error
0x13 Unexpected Parameter 0x13 Unexpected Parameter
0x14 Destination Status Unknown 0x14 Destination Status Unknown
0x15 Invalid Network Appearance 0x15 Invalid Network Appearance
0x16 No configured AS for ASP
The "Invalid Version" error is sent if a message was received with an The "Invalid Version" error is sent if a message was received with an
invalid or unsupported version. The Error message contains the invalid or unsupported version. The Error message contains the
supported version in the Common header. The Error message could supported version in the Common header. The Error message could
optionally provide the supported version in the Diagnostic Information optionally provide the supported version in the Diagnostic Information
area. area.
The "Invalid Network Appearance" error is sent by a SGP if an ASP sends The "Invalid Network Appearance" error is sent by a SGP if an ASP sends
a message with an invalid (unconfigured) Network Appearance value. a message with an invalid (unconfigured) Network Appearance value.
For this error, the invalid (unconfigured) Network Appearance MUST be
included in the Network Appearance parameter.
The "Unsupported Message Class" error is sent if a message with an The "Unsupported Message Class" error is sent if a message with an
unexpected or unsupported Message Class is received. unexpected or unsupported Message Class is received.
The "Unsupported Message Type" error is sent if a message with an The "Unsupported Message Type" error is sent if a message with an
unexpected or unsupported Message Type is received. unexpected or unsupported Message Type is received.
The "Unsupported Traffic Handling Mode" error is sent by a SGP The "Unsupported Traffic Handling Mode" error is sent by a SGP
if an ASP sends an ASP Active message with an unsupported Traffic Mode if an ASP sends an ASP Active message with an unsupported Traffic Mode
Type or a Traffic Mode Type that is inconsistent with the presently Type or a Traffic Mode Type that is inconsistent with the presently
configured mode for the Application Server. An example would be a case configured mode for the Application Server. An example would be a case
in which the SGP did not support loadsharing. in which the SGP did not support loadsharing.
The "Unexpected Message" error MAY be sent if a defined and recognized The "Unexpected Message" error MAY be sent if a defined and recognized
message is received that is not expected in the current state (in some message is received that is not expected in the current state (in some
cases the ASP may optionally silently discard the message and not send cases the ASP may optionally silently discard the message and not send
an Error message). For example, silent discard is used by an ASP if it an Error message). For example, silent discard is used by an ASP if it
received a DATA message from an SGP while it was in the ASP-INACTIVE received a DATA message from an SGP while it was in the ASP-INACTIVE
state. state. If the Unexpected message contained Routing Context(s), the Routing Context(s) SHOULD be included in the Error message.
The "Protocol Error" error is sent for any protocol anomaly (i.e., The "Protocol Error" error is sent for any protocol anomaly (i.e.,
reception of a parameter that is syntactically correct but unexpected reception of a parameter that is syntactically correct but unexpected
in the current situation. in the current situation.
The "Invalid Routing Context" error is sent if a message is received The "Invalid Routing Context" error is sent if a message is received
from a peer with an invalid (unconfigured) Routing Context value, or from a peer with an invalid (unconfigured) Routing Context value, or
if a message is received from a peer without a Routing Context if a message is received from a peer without a Routing Context
parameter and it is not known by configuration data which parameter and it is not known by configuration data which
Application Servers are referenced. Application Servers are referenced. For this error, the invalid Routing Context(s) MUST be included in the Error message.
The "No Configured AS for ASP" error is sent if a message is received
from a peer without a Routing Context parameter and it is not known by
configuration data which Application Servers are referenced.
The "Invalid Stream Identifier" error is sent if a message is received The "Invalid Stream Identifier" error is sent if a message is received
on an unexpected SCTP stream (e.g., a Management message was received on an unexpected SCTP stream (e.g., a Management message was received
on a stream other than "0"). on a stream other than "0").
The " Invalid Parameter Value " error is sent if a message is received The " Invalid Parameter Value " error is sent if a message is received
with an invalid parameter value (e.g., a DUPU message was received with with an invalid parameter value (e.g., a DUPU message was received with
a Mask value other than "0"). a Mask value other than "0" or a Data message was received on stream
"0").
The "Refused - Management Blocking" error is sent when an ASP Up or The "Refused - Management Blocking" error is sent when an ASP Up or
ASP Active message is received and the request is refused for ASP Active message is received and the request is refused for
management reasons (e.g., management lockout"). management reasons (e.g., management lockout"). If this error is in
response to an ASP Active message, the Routing Context(s) in the ASP
Active message SHOULD be included in the Error message.
The "ASP Identifier Required" is sent by a SGP in response The "ASP Identifier Required" is sent by a SGP in response
to an ASP Up message which does not contain an ASP Identifier to an ASP Up message which does not contain an ASP Identifier
parameter when the SGP requires one. The ASP should resend the parameter when the SGP requires one. The ASP SHOULD resend the
ASP Up message with an ASP Identifier. ASP Up message with an ASP Identifier.
The "Invalid ASP Identifier" is send by a SGP in response The "Invalid ASP Identifier" is send by a SGP in response
to an ASP Up message with an invalid (i.e., non-unique) ASP Identifier. to an ASP Up message with an invalid (i.e., non-unique) ASP Identifier.
The "Parameter Field Error" would be sent if a message is received
with a parameter having a wrong length field.
The "Unexpected Parameter" error would be sent if a message contains
an invalid parameter.
The "Destination Status Unknown" Error MAY be sent if a DAUD is The "Destination Status Unknown" Error MAY be sent if a DAUD is
received at an SG enquiring of the availability/congestion status of received at an SG enquiring of the availability/congestion status of
a destination, and the SG does not wish to provide the status (e.g., a destination, and the SG does not wish to provide the status (e.g.,
the sender is not authorized to know the status). the sender is not authorized to know the status). For this error, the
invalid or unauthorized Point Code(s) MUST be included along with the
Network Appearance and/or Routing Context associated with the Point
Code(s).
Diagnostic Information: variable length Diagnostic Information: variable length
When included, the optional Diagnostic information can be any When included, the optional Diagnostic information can be any
information germane to the error condition, to assist in information germane to the error condition, to assist in
identification of the error condition. In the case of an Invalid identification of the error condition. The Diagnostic information
Network Appearance, Traffic Handling Mode, Routing Context or SHOULD contain the offending message.
Parameter Value, the Diagnostic information parameter MUST be added
and include the offending parameter. In the case of Destination
Status Unknown, the Diagnostic information SHOULD include the Point
Code in the original DAUD request. In the other cases, the
Diagnostic information MAY be the first 40 bytes of the offending
message.
Error messages MUST NOT be generated in response to other Error Error messages MUST NOT be generated in response to other Error
messages. messages.
3.8.2 Notify 3.8.2 Notify
The Notify message used to provide an autonomous indication of M3UA The Notify message used to provide an autonomous indication of M3UA
events to an M3UA peer. events to an M3UA peer.
The Notify message contains the following parameters: The Notify message contains the following parameters:
skipping to change at page 66, line 33 skipping to change at page 63, line 45
These notifications are not based on the SGP reporting the state change These notifications are not based on the SGP reporting the state change
of an ASP or AS. In the Insufficent ASP Resources case, the SGP is of an ASP or AS. In the Insufficent ASP Resources case, the SGP is
indicating to an ASP_INACTIVE ASP in the AS that another ASP is indicating to an ASP_INACTIVE ASP in the AS that another ASP is
required to handle the load of the AS (Loadsharing or Broadcast mode). required to handle the load of the AS (Loadsharing or Broadcast mode).
For the Alternate ASP Active case, an ASP is informed when an alternate For the Alternate ASP Active case, an ASP is informed when an alternate
ASP transitions to the ASP-ACTIVE state in Override mode. ASP transitions to the ASP-ACTIVE state in Override mode.
The format and description of the optional ASP Identifier, Routing The format and description of the optional ASP Identifier, Routing
Context and Info String parameters is the same as for the ASP Active Context and Info String parameters is the same as for the ASP Active
message (See Section 3.5.5.) message (See Section 3.5.1)
4. Procedures 4. Procedures
The M3UA layer needs to respond to various local primitives it receives The M3UA layer needs to respond to various local primitives it receives
from other layers as well as the messages that it receives from the from other layers as well as the messages that it receives from the
peer M3UA layer. This section describes the M3UA procedures in peer M3UA layer. This section describes the M3UA procedures in
response to these events. response to these events.
4.1 Procedures to Support the M3UA-User 4.1 Procedures to Support the M3UA-User
skipping to change at page 67, line 13 skipping to change at page 64, line 27
MTP-TRANSFER request primitive with a provisioned Routing Key. MTP-TRANSFER request primitive with a provisioned Routing Key.
>From the list of ASPs within the AS table, an ASP in the ASP-ACTIVE >From the list of ASPs within the AS table, an ASP in the ASP-ACTIVE
state is selected and a DATA message is constructed and issued on the state is selected and a DATA message is constructed and issued on the
corresponding SCTP association. If more than one ASP is in the ASP- corresponding SCTP association. If more than one ASP is in the ASP-
ACTIVE state (i.e., traffic is to be loadshared across more than one ACTIVE state (i.e., traffic is to be loadshared across more than one
ASP), one of the ASPs in the ASP_ACTIVE state is selected from the ASP), one of the ASPs in the ASP_ACTIVE state is selected from the
list. If the ASPs are in Broadcast Mode, all active ASPs will be list. If the ASPs are in Broadcast Mode, all active ASPs will be
selected and the message sent to each of the active ASPs. The selected and the message sent to each of the active ASPs. The
selection algorithm is implementation dependent but could, for selection algorithm is implementation dependent but could, for
example, be round-robin or based on the SLS or ISUP CIC. The a example, be round robin or based on the SLS or ISUP CIC. The a
appropriate selection algorithm must be chosen carefully as it is appropriate selection algorithm must be chosen carefully as it is
dependent on application assumptions and understanding of the dependent on application assumptions and understanding of the
degree of state coordination between the ASP_ACTIVE ASPs in the AS. degree of state coordination between the ASP_ACTIVE ASPs in the AS.
In addition, the message needs to be sent on the appropriate SCTP In addition, the message needs to be sent on the appropriate SCTP
stream, again taking care to meet the message sequencing needs of the stream, again taking care to meet the message sequencing needs of the
signalling application. DATA messages SHOULD be sent on an SCTP stream signalling application. DATA messages MUST be sent on an SCTP stream
other than stream '0'. other than stream '0'.
When there is no Routing Key match, or only a partial match, for an When there is no Routing Key match, or only a partial match, for an
incoming SS7 message, a default treatment MUST be specified. Possible incoming SS7 message, a default treatment MAY be specified. Possible
solutions are to provide a default Application Server at the SGP that solutions are to provide a default Application Server at the SGP that
directs all unallocated traffic to a (set of) default ASP(s), or to directs all unallocated traffic to a (set of) default ASP(s), or to
drop the message and provide a notification to Layer Management in an drop the message and provide a notification to Layer Management in an
M-ERROR indication primitive. The treatment of unallocated traffic is M-ERROR indication primitive. The treatment of unallocated traffic is
implementation dependent. implementation dependent.
4.1.2 Receipt of Primitives from the Layer Management 4.1.2 Receipt of Primitives from the Layer Management
On receiving primitives from the local Layer Management, the M3UA layer On receiving primitives from the local Layer Management, the M3UA layer
will take the requested action and provide an appropriate response will take the requested action and provide an appropriate response
skipping to change at page 69, line 11 skipping to change at page 66, line 24
provided in the primitive. These requests result in outgoing ASP Up, provided in the primitive. These requests result in outgoing ASP Up,
ASP Down, ASP Active and ASP Inactive messages to the remote M3UA ASP Down, ASP Active and ASP Inactive messages to the remote M3UA
peer at an SGP or IPSP. peer at an SGP or IPSP.
4.2 Procedures to Support the Management of SCTP Associations 4.2 Procedures to Support the Management of SCTP Associations
4.2.1 Receipt of M3UA Peer Management Messages 4.2.1 Receipt of M3UA Peer Management Messages
Upon successful state changes resulting from reception of ASP Up, Upon successful state changes resulting from reception of ASP Up,
ASP Down, ASP Active and ASP Inactive messages from a peer M3UA, the ASP Down, ASP Active and ASP Inactive messages from a peer M3UA, the
M3UA layer SHOULD invoke corresponding M-ASP_UP, M-ASP_DOWN, M- M3UA layer MAY invoke corresponding M-ASP_UP, M-ASP_DOWN, M-
ASP_ACTIVE and M-ASP_INACTIVE, M-AS_ACTIVE, M-AS_INACTIVE, and M- ASP_ACTIVE and M-ASP_INACTIVE, M-AS_ACTIVE, M-AS_INACTIVE, and M-
AS_DOWN indication primitives to the local Layer Management. AS_DOWN indication primitives to the local Layer Management.
M-NOTIFY indication and M-ERROR indication primitives indicate to Layer M-NOTIFY indication and M-ERROR indication primitives indicate to Layer
Management the notification or error information contained in a Management the notification or error information contained in a
received M3UA Notify or Error message. These indications can also be received M3UA Notify or Error message. These indications can also be
generated based on local M3UA events. generated based on local M3UA events.
All Non-Transfer messages, except BEAT and BEAT Ack, SHOULD be sent All Non-Transfer messages, except BEAT and BEAT Ack, SHOULD be sent
with sequenced delivery to ensure ordering. All Non-Transfer with sequenced delivery to ensure ordering. All Non-Transfer
skipping to change at page 70, line 8 skipping to change at page 67, line 24
in the AS (e.g., ASP Active message indicating "Override"); in the AS (e.g., ASP Active message indicating "Override");
* Reception of indications from the SCTP layer; or * Reception of indications from the SCTP layer; or
* Local Management intervention. * Local Management intervention.
The ASP state transition diagram is shown in Figure 4. The possible The ASP state transition diagram is shown in Figure 4. The possible
states of an ASP are: states of an ASP are:
ASP-DOWN: The remote M3UA peer at the ASP is unavailable and/or the ASP-DOWN: The remote M3UA peer at the ASP is unavailable and/or the
related SCTP association is down. Initially all ASPs will be in this related SCTP association is down. Initially all ASPs will be in this
state. An ASP in this state SHOULD NOT be sent any M3UA messages, state. An ASP in this state SHOULD NOT be sent any M3UA messages,
with the exception of Heartbeat messages. with the exception of Heartbeat, ASP Down Ack and Error messages.
ASP-INACTIVE: The remote M3UA peer at the ASP is available (and the ASP-INACTIVE: The remote M3UA peer at the ASP is available (and the
related SCTP association is up) but application traffic is stopped. In related SCTP association is up) but application traffic is stopped. In
this state the ASP MAY be sent any non-DATA M3UA messages. this state the ASP SHOULD NOT be sent any DATA or SNMM messages for the
AS for which the ASP is inactive.
ASP-ACTIVE: The remote M3UA peer at the ASP is available and ASP-ACTIVE: The remote M3UA peer at the ASP is available and
application traffic is active (for a particular Routing Context or set application traffic is active (for a particular Routing Context or set
of Routing Contexts). of Routing Contexts).
SCTP CDI: The SCTP CDI denotes the local SCTP layer's Communication
Down Indication to the Upper Layer Protocol (M3UA) on an SGP. The local
SCTP layer will send this indication when it detects the loss of
connectivity to the ASP's peer SCTP layer. SCTP CDI is understood as
either a SHUTDOWN_COMPLETE notification or COMMUNICATION_LOST
notification from the SCTP layer.
SCTP RI: The local SCTP layer's Restart indication to the upper layer
protocol (M3UA) on an SG. The local SCTP will send this indication
when it detects a restart from the ASP's peer SCTP layer.
Figure 4: ASP State Transition Diagram, per AS Figure 4: ASP State Transition Diagram, per AS
+--------------+ +--------------+
| | | |
+----------------------| ASP-ACTIVE | +----------------------| ASP-ACTIVE |
| Other +-------| | | Other +-------| |
| ASP in AS | +--------------+ | ASP in AS | +--------------+
| Overrides | ^ | | Overrides | ^ |
| | ASP | | ASP | | ASP | | ASP
| | Active | | Inactive | | Active | | Inactive
skipping to change at page 70, line 43 skipping to change at page 68, line 30
| ^ | | ^ |
ASP Down/ | ASP | | ASP Down / ASP Down/ | ASP | | ASP Down /
SCTP CDI/ | Up | | SCTP CDI/ SCTP CDI/ | Up | | SCTP CDI/
SCTP RI | | v SCTP RI SCTP RI | | v SCTP RI
| +--------------+ | +--------------+
| | | | | |
+--------------------->| ASP-DOWN | +--------------------->| ASP-DOWN |
| | | |
+--------------+ +--------------+
SCTP CDI: The SCTP CDI denotes the local SCTP layer's Communication
Down Indication to the Upper Layer Protocol (M3UA) on an SGP. The local
SCTP layer will send this indication when it detects the loss of
connectivity to the ASP's peer SCTP layer. SCTP CDI is understood as
either a SHUTDOWN_COMPLETE notification or COMMUNICATION_LOST
notification from the SCTP layer.
SCTP RI: The local SCTP layer's Restart indication to the upper layer
protocol (M3UA) on an SG. The local SCTP will send this indication
when it detects a restart from the ASP's peer SCTP layer.
4.3.2 AS States 4.3.2 AS States
The state of the AS is maintained in the M3UA layer on the SGP. The The state of the AS is maintained in the M3UA layer on the SGPs. 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: The Application Server is unavailable. This state implies AS-DOWN: The Application Server is unavailable. This state implies
that all related ASPs are in the ASP-DOWN state for this AS. Initially that all related ASPs are in the ASP-DOWN state for this AS. Initially
the AS will be in this state. An Application Server MUST be in the AS- the AS will be in this state. An Application Server is in the AS-DOWN
DOWN state before it can be removed from a configuration. state when it is removed from a configuration.
AS-INACTIVE: The Application Server is available but no application AS-INACTIVE: The Application Server is available but no application
traffic is active (i.e., one or more related ASPs are in the ASP- traffic is active (i.e., one or more related ASPs are in the ASP-
INACTIVE state, but none in the ASP-ACTIVE state). The recovery INACTIVE state, but none in the ASP-ACTIVE state). The recovery
timer T(r) is not running or has expired. timer T(r) is not running or has expired.
AS-ACTIVE: The Application Server is available and application traffic AS-ACTIVE: The Application Server is available and application traffic
is active. This state implies that at least one ASP is in the ASP- is active. This state implies that at least one ASP is in the ASP-
ACTIVE state. ACTIVE state.
AS-PENDING: An active ASP has transitioned to ASP-INACTIVE or ASP-DOWN AS-PENDING: An active ASP has transitioned to ASP-INACTIVE or ASP-DOWN
and it was the last remaining active ASP in the AS. A recovery timer and it was the last remaining active ASP in the AS. A recovery timer
T(r) SHOULD be started and all incoming signalling messages SHOULD be T(r) SHOULD be started and all incoming signalling messages SHOULD be
queued by the SGP. If an ASP becomes ASP-ACTIVE before T(r) expires, queued by the SGP. If an ASP becomes ASP-ACTIVE before T(r) expires,
the AS is moved to the AS-ACTIVE state and all the queued messages the AS is moved to the AS-ACTIVE state and all the queued messages
will be sent to the ASP. will be sent to the ASP.
If T(r) expires before an ASP becomes ASP-ACTIVE, the SGP stops queuing If T(r) expires before an ASP becomes ASP-ACTIVE, and the SGP has no
messages and discards all previously queued messages. The AS will move alternative, the SGP may stops queuing messages and discards all
to the AS-INACTIVE state if at least one ASP is in ASP-INACTIVE state, previously queued messages. The AS will move to the AS-INACTIVE state
otherwise it will move to AS-DOWN state. if at least one ASP is in ASP-INACTIVE state, otherwise it will move
to AS-DOWN state.
Figure 5 shows an example AS state machine for the case where the Figure 5 shows an example AS state machine for the case where the
AS/ASP data is preconfigured. For other cases where the AS/ASP AS/ASP data is preconfigured. For other cases where the AS/ASP
configuration data is created dynamically, there would be differences configuration data is created dynamically, there would be differences
in the state machine, especially at creation of the AS. in the state machine, especially at creation of the AS.
For example, where the AS/ASP configuration data is not created until
Registration of the first ASP, the AS-INACTIVE state is entered
directly upon the first successful REG REQ from an ASP. Another
example is where the AS/ASP configuration data is not created until the
first ASP successfully enters the ASP-ACTIVE state. In this case the
AS-ACTIVE state is entered directly.
Figure 5: AS State Transition Diagram Figure 5: AS State Transition Diagram
+----------+ one ASP trans to ACTIVE +-------------+ +----------+ one ASP trans to ACTIVE +-------------+
| AS- |---------------------------->| AS- | | AS- |---------------------------->| AS- |
| INACTIVE | | ACTIVE | | INACTIVE | | ACTIVE |
| |<--- | | | |<--- | |
+----------+ \ +-------------+ +----------+ \ +-------------+
^ | \ Tr Expiry, ^ | ^ | \ Tr Expiry, ^ |
| | \ at least one | | | | \ at least one | |
| | \ ASP in ASP-INACTIVE | | | | \ ASP in ASP-INACTIVE | |
skipping to change at page 72, line 36 skipping to change at page 70, line 5
+----------+ \ +-------------+ +----------+ \ +-------------+
| | --| | | | --| |
| AS-DOWN | | AS-PENDING | | AS-DOWN | | AS-PENDING |
| | | (queueing) | | | | (queueing) |
| |<----------------------------| | | |<----------------------------| |
+----------+ Tr Expiry and no ASP +-------------+ +----------+ Tr Expiry and no ASP +-------------+
in ASP-INACTIVE state) in ASP-INACTIVE state)
Tr = Recovery Timer Tr = Recovery Timer
For example, where the AS/ASP configuration data is not created until
Registration of the first ASP, the AS-INACTIVE state is entered
directly upon the first successful REG REQ from an ASP. Another
example is where the AS/ASP configuration data is not created until the
first ASP successfully enters the ASP-ACTIVE state. In this case the
AS-ACTIVE state is entered directly.
4.3.3 M3UA Management Procedures for Primitives 4.3.3 M3UA Management Procedures for Primitives
Before the establishment of an SCTP association the ASP state at both Before the establishment of an SCTP association the ASP state at both
the SGP and ASP is assumed to be in the state ASP-DOWN. the SGP and ASP is assumed to be in the state ASP-DOWN.
Once the SCTP association is established (see Section 4.2.1) and Once the SCTP association is established (see Section 4.2.1) and
assuming that the local M3UA-User is ready, the local M3UA ASP assuming that the local M3UA-User is ready, the local M3UA ASP
Maintenance (ASPM) function will initiate the relevant procedures, Maintenance (ASPM) function will initiate the relevant procedures,
using the ASP Up/ASP Down/ASP Active/ASP Inactive messages to convey using the ASP Up/ASP Down/ASP Active/ASP Inactive messages to convey
the ASP state to the SGP (see Section 4.4.3). the ASP state to the SGP (see Section 4.4.3).
skipping to change at page 73, line 51 skipping to change at page 71, line 27
should save the ASP Identifier for that ASP. The SGP MUST send an should save the ASP Identifier for that ASP. The SGP MUST send an
ASP Up Ack message in response to a received ASP Up message even if ASP Up Ack message in response to a received ASP Up message even if
the ASP is already marked as ASP-INACTIVE at the SGP. the ASP is already marked as ASP-INACTIVE at the SGP.
If for any local reason (e.g., management lockout) the SGP cannot If for any local reason (e.g., management lockout) the SGP cannot
respond with an ASP Up Ack message, the SGP responds to an ASP Up respond with an ASP Up Ack message, the SGP responds to an ASP Up
message with an Error message with reason "Refused - Management message with an Error message with reason "Refused - Management
Blocking". Blocking".
At the ASP, the ASP Up Ack message received is not acknowledged. Layer At the ASP, the ASP Up Ack message received is not acknowledged. Layer
Management is informed with an M-ASP_UP confirm primitive. When an ASP Management is informed with an M-ASP_UP confirm primitive.
enters the ASP-Inactive state from the ASP-Down state towards an SGP
the M3UA MUST mark all SS7 destinations configured to be reachable via
this SGP as available.
When the ASP sends an ASP Up message it starts timer T(ack). If the When the ASP sends an ASP Up message it starts timer T(ack). If the
ASP does not receive a response to an ASP Up message within T(ack), the ASP does not receive a response to an ASP Up message within T(ack), the
ASP MAY restart T(ack) and resend ASP Up messages until it receives an ASP MAY restart T(ack) and resend ASP Up messages until it receives an
ASP Up Ack message. T(ack) is provisionable, with a default of 2 ASP Up Ack message. T(ack) is provisionable, with a default of 2
seconds. Alternatively, retransmission of ASP Up messages MAY be put seconds. Alternatively, retransmission of ASP Up messages MAY be put
under control of Layer Management. In this method, expiry of T(ack) under control of Layer Management. In this method, expiry of T(ack)
results in an M-ASP_UP confirm primitive carrying a negative results in an M-ASP_UP confirm primitive carrying a negative
indication. indication.
The ASP must wait for the ASP Up Ack message before sending any other The ASP must wait for the ASP Up Ack message before sending any other
M3UA messages (e.g., ASP Active or REG REQ). If the SGP receives any M3UA messages (e.g., ASP Active or REG REQ). If the SGP receives any
other M3UA messages before an ASP Up message is received, the SGP other M3UA messages before an ASP Up message is received (other than
SHOULD discard them. ASP Down - see Section 4.3.4.2), the SGP MAY discard them.
If an ASP Up message is received and internally the remote ASP is in If an ASP Up message is received and internally the remote ASP is in
the ASP-ACTIVE state, an ASP-Up Ack message is returned, as well as an the ASP-ACTIVE state, an ASP Up Ack message is returned, as well as an
Error message ("Unexpected Message), and the remote ASP state is Error message ("Unexpected Message), and the remote ASP state is
changed to ASP-INACTIVE in all relevant Application Servers. changed to ASP-INACTIVE in all relevant Application Servers.
If an ASP Up message is received and internally the remote ASP is If an ASP Up message is received and internally the remote ASP is
already in the ASP-INACTIVE state, an ASP Up Ack message is returned already in the ASP-INACTIVE state, an ASP Up Ack message is returned
and no further action is taken. and no further action is taken.
4.3.4.1.1 M3UA Version Control 4.3.4.1.1 M3UA Version Control
If an ASP Up message with an unsupported version is received, the If an ASP Up message with an unsupported version is received, the
skipping to change at page 74, line 36 skipping to change at page 72, line 4
changed to ASP-INACTIVE in all relevant Application Servers. changed to ASP-INACTIVE in all relevant Application Servers.
If an ASP Up message is received and internally the remote ASP is If an ASP Up message is received and internally the remote ASP is
already in the ASP-INACTIVE state, an ASP Up Ack message is returned already in the ASP-INACTIVE state, an ASP Up Ack message is returned
and no further action is taken. and no further action is taken.
4.3.4.1.1 M3UA Version Control 4.3.4.1.1 M3UA Version Control
If an ASP Up message with an unsupported version is received, the If an ASP Up message with an unsupported version is received, the
receiving end responds with an Error message, indicating the version receiving end responds with an Error message, indicating the version
the receiving node supports and notifies Layer Management. the receiving node supports and notifies Layer Management.
This is useful when protocol version upgrades are being performed in a This is useful when protocol version upgrades are being performed in a
network. A node upgraded to a newer version should support the older network. A node upgraded to a newer version should support the older
versions used on other nodes it is communicating with. Because ASPs versions used on other nodes it is communicating with. Because ASPs
initiate the ASP Up procedure it is assumed that the Error message initiate the ASP Up procedure it is assumed that the Error message
would normally come from the SGP. would normally come from the SGP.
4.3.4.1.2 IPSP Considerations 4.3.4.1.2 IPSP Considerations (ASP Up)
In the case of peer-to-peer IPSPs, either of the IPSPs (IPSP_A) may An IPSP may be considered in the ASP-INACTIVE state after an ASP Up or ASP Up Ack has been received from it. An IPSP can be considered in the ASP-DOWN state after an ASP Down or ASP Down Ack has been received from it. The IPSP may inform Layer Management of the change in state of the remote IPSP using M-ASP_UP or M-ASP_DN indication or confirmation primitives.
start operations by sending an ASP Up message to the remote peer
(IPSP_B). When the ASP Up message is received at IPSP_B and internally
the remote IPSP_A is in the ASP-DOWN state and not considered locked
out for local management reasons, IPSP_B marks the remote IPSP_A in the
state ASP-INACTIVE and informs Layer Management with an M-ASP_Up
indication primitive. IPSP_B returns an ASP Up Ack message to IPSP_A.
IPSP_A moves IPSP_B to the ASP-INACTIVE state upon reception of an ASP
Up Ack message, if is not already in the ASP_INACTIVE state, and
informs Layer Management with an M-ASP_UP confirmation primitive.
If for any local reason (e.g., management lockout) the IPSP_B cannot Alternatively, an interchange of ASP Up messages from each end can be performed. This option follows the ASP state transition diagram. It would need four messages for completion.
respond with an ASP Up Ack message, it responds to an ASP Up message
with an Error message with reason "Refused - Management Blocking" and If for any local reason (e.g., management lockout) an IPSP cannot
leaves IPSP_A in the ASP-DOWN state. respond to an ASP Up message with an ASP Up Ack message, it responds to an ASP Up message with an Error message with reason "Refused -
Management Blocking" and leaves the remote IPSP in the ASP-DOWN state.
4.3.4.2 ASP-Down Procedures 4.3.4.2 ASP-Down Procedures
The ASP will send an ASP Down message to an SGP when the ASP wishes to The ASP will send an ASP Down message to an SGP when the ASP wishes to
be removed from service in all Application Servers that it is a be removed from service in all Application Servers that it is a
member and no longer receive any DATA, SSNM or ASPTM messages. member and no longer receive any DATA, SSNM or ASPTM messages.
This action MAY be initiated at the ASP by an M-ASP_DOWN request This action MAY be initiated at the ASP by an M-ASP_DOWN request
primitive from Layer Management or MAY be initiated automatically primitive from Layer Management or MAY be initiated automatically
by an M3UA management function. by an M3UA management function.
Whether the ASP is permanently removed from any AS is a function of Whether the ASP is permanently removed from any AS is a function of
configuration management. In the case where the ASP previously used configuration management. In the case where the ASP previously used
the Registration procedures (see Section 4.3.5) to register within the Registration procedures (see Section 4.3.5) to register within
Application Servers but has not deregistered from all of them prior to Application Servers but has not deregistered from all of them prior to
sending the ASP Down message, the SGP SHOULD consider the ASP as sending the ASP Down message, the SGP MUST consider the ASP as
Deregistered in all Application Servers that it is still a member. Deregistered in all Application Servers that it is still a member.
The SGP marks the ASP as ASP-DOWN, informs Layer Management with an M- The SGP marks the ASP as ASP-DOWN, informs Layer Management with an M-
ASP_Down indication primitive, and returns an ASP Down Ack message to ASP_Down indication primitive, and returns an ASP Down Ack message to
the ASP. the ASP.
The SGP MUST send an ASP Down Ack message in response to a received The SGP MUST send an ASP Down Ack message in response to a received
ASP Down message from the ASP even if the ASP is already marked as ASP Down message from the ASP even if the ASP is already marked as
ASP-DOWN at the SGP. ASP-DOWN at the SGP.
skipping to change at page 75, line 51 skipping to change at page 73, line 22
When the ASP sends an ASP Down message it starts timer T(ack). If the When the ASP sends an ASP Down message it starts timer T(ack). If the
ASP does not receive a response to an ASP Down message within T(ack), ASP does not receive a response to an ASP Down message within T(ack),
the ASP MAY restart T(ack) and resend ASP Down messages until it the ASP MAY restart T(ack) and resend ASP Down messages until it
receives an ASP Down Ack message. T(ack) is provisionable, with a receives an ASP Down Ack message. T(ack) is provisionable, with a
default of 2 seconds. Alternatively, retransmission of ASP Down default of 2 seconds. Alternatively, retransmission of ASP Down
messages MAY be put under control of Layer Management. In this method, messages MAY be put under control of Layer Management. In this method,
expiry of T(ack) results in an M-ASP_DOWN confirm primitive carrying a expiry of T(ack) results in an M-ASP_DOWN confirm primitive carrying a
negative indication. negative indication.
4.3.4.4 ASP Active Procedures 4.3.4.3 ASP Active Procedures
Anytime after the ASP has received an ASP Up Ack message from the SGP Anytime after the ASP has received an ASP Up Ack message from the SGP
or IPSP, the ASP MAY send an ASP Active message to the SGP indicating or IPSP, the ASP MAY send an ASP Active message to the SGP indicating
that the ASP is ready to start processing traffic. This action MAY be that the ASP is ready to start processing traffic. This action MAY be
initiated at the ASP by an M-ASP_ACTIVE request primitive from Layer initiated at the ASP by an M-ASP_ACTIVE request primitive from Layer
Management or MAY be initiated automatically by an M3UA management Management or MAY be initiated automatically by an M3UA management
function. In the case where an ASP wishes to process the traffic for function. In the case where an ASP wishes to process the traffic for
more than one Application Server across a common SCTP association, the more than one Application Server across a common SCTP association, the
ASP Active message(s) SHOULD contain a list of one or more Routing ASP Active message(s) SHOULD contain a list of one or more Routing
skipping to change at page 76, line 35 skipping to change at page 74, line 4
The Routing Context parameter MUST be included in the ASP Active The Routing Context parameter MUST be included in the ASP Active
Ack message(s) if the received ASP Active message contained any Ack message(s) if the received ASP Active message contained any
Routing Contexts. Depending on any Traffic Mode Type request in Routing Contexts. Depending on any Traffic Mode Type request in
the ASP Active message, or local configuration data if there is no the ASP Active message, or local configuration data if there is no
request, the SGP moves the ASP to the correct ASP traffic state request, the SGP moves the ASP to the correct ASP traffic state
within the associated Application Server(s). Layer Management is within the associated Application Server(s). Layer Management is
informed with an M-ASP_Active indication. If the SGP or IPSP informed with an M-ASP_Active indication. If the SGP or IPSP
receives any Data messages before an ASP Active message is receives any Data messages before an ASP Active message is
received, the SGP or IPSP MAY discard them. By sending an ASP received, the SGP or IPSP MAY discard them. By sending an ASP
Active Ack message, the SGP or IPSP is now ready to receive and Active Ack message, the SGP or IPSP is now ready to receive and
send traffic for the related Routing Context(s). The ASP SHOULD send traffic for the related Routing Context(s). The ASP SHOULD
NOT send Data messages for the related Routing Context(s) before NOT send Data or SNMM messages for the related Routing Context(s) before
receiving an ASP Active Ack message, or it will risk message loss. receiving an ASP Active Ack message, or it will risk message loss.
Multiple ASP Active Ack messages MAY be used in response to an ASP Multiple ASP Active Ack messages MAY be used in response to an ASP
Active message containing multiple Routing Contexts, allowing the SGP Active message containing multiple Routing Contexts, allowing the SGP
or IPSP to independently acknowledge the ASP Active message for or IPSP to independently acknowledge the ASP Active message for
different (sets of) Routing Contexts. The SGP or IPSP MUST send an different (sets of) Routing Contexts. The SGP or IPSP MUST send an
Error message ("Invalid Routing Context") for each Routing Context Error message ("Invalid Routing Context") for each Routing Context
value that the ASP cannot be successfully activated . value that the ASP cannot be successfully activated .
In the case where an "out-of-the-blue" ASP Active message is received In the case where an "out-of-the-blue" ASP Active message is received
skipping to change at page 78, line 35 skipping to change at page 76, line 5
handle the expected load (e.g., until there are "n" ASPs in state handle the expected load (e.g., until there are "n" ASPs in state
ASP-ACTIVE in the AS). ASP-ACTIVE in the AS).
Whenever an ASP in a Broadcast mode AS becomes ASP-ACTIVE, the SGP Whenever an ASP in a Broadcast mode AS becomes ASP-ACTIVE, the SGP
MUST tag the first DATA message broadcast in each SCTP stream with MUST tag the first DATA message broadcast in each SCTP stream with
a unique Correlation Id parameter. The purpose of this a unique Correlation Id parameter. The purpose of this
Id is to permit the newly active ASP to synchronize its processing Id is to permit the newly active ASP to synchronize its processing
of traffic in each ordered stream with the other ASPs in the of traffic in each ordered stream with the other ASPs in the
broadcast group. broadcast group.
4.3.4.5 ASP Inactive Procedures 4.3.4.3.1 IPSP Considerations (ASP Active)
Either of the IPSPs can initiate communication. When an IPSP receives an ASP Active, it should mark the peer as ASP-ACTIVE and return an ASP Active Ack message. An ASP receiving an ASP Active Ack message may mark the peer as ASP-Active, if it is not already in the ASP-ACTIVE state.
Alternatively, an interchange of ASP Active messages from each end can be performed. This option follows the ASP state transition diagram and gives the additional advantage of selecting a particular AS to be activated from each end. It is especially useful when an IPSP is serving more than one AS. It would need four messages for completion.
4.3.4.4 ASP Inactive Procedures
When an ASP wishes to withdraw from receiving traffic within an AS, the When an ASP wishes to withdraw from receiving traffic within an AS, the
ASP sends an ASP Inactive message to the SGP or IPSP. This action MAY ASP sends an ASP Inactive message to the SGP or IPSP. This action MAY
be initiated at the ASP by an M-ASP_INACTIVE request primitive from be initiated at the ASP by an M-ASP_INACTIVE request primitive from
Layer Management or MAY be initiated automatically by an M3UA Layer Management or MAY be initiated automatically by an M3UA
management function. In the case where an ASP is processing the management function. In the case where an ASP is processing the
traffic for more than one Application Server across a common SCTP traffic for more than one Application Server across a common SCTP
association, the ASP Inactive message contains one or more Routing association, the ASP Inactive message contains one or more Routing
Contexts to indicate for which Application Servers the ASP Inactive Contexts to indicate for which Application Servers the ASP Inactive
message applies. In the case where an ASP Inactive message does not message applies. In the case where an ASP Inactive message does not
skipping to change at page 80, line 4 skipping to change at page 77, line 38
provisionable, with a default of 2 seconds. Alternatively, provisionable, with a default of 2 seconds. Alternatively,
retransmission of ASP Inactive messages MAY be put under control of retransmission of ASP Inactive messages MAY be put under control of
Layer Management. In this method, expiry of T(ack) results in a M- Layer Management. In this method, expiry of T(ack) results in a M-
ASP_Inactive confirm primitive carrying a negative indication. ASP_Inactive confirm primitive carrying a negative indication.
If no other ASPs in the Application Server are in the state If no other ASPs in the Application Server are in the state
ASP-ACTIVE, the SGP MUST send a Notify message ("AS-Pending") to ASP-ACTIVE, the SGP MUST send a Notify message ("AS-Pending") to
all of the ASPs in the AS which are in the state ASP-INACTIVE. all of the ASPs in the AS which are in the state ASP-INACTIVE.
The SGP SHOULD start buffering the incoming messages for T(r) The SGP SHOULD start buffering the incoming messages for T(r)
seconds, after which messages MAY be discarded. T(r) is seconds, after which messages MAY be discarded. T(r) is
configurable by the network operator. If the SGP receives an ASP configurable by the network operator. If the SGP receives an ASP
Active message from an ASP in the AS before expiry of T(r), the Active message from an ASP in the AS before expiry of T(r), the
buffered traffic is directed to that ASP and the timer is cancelled. buffered traffic is directed to that ASP and the timer is cancelled.
If T(r) expires, the AS is moved to the AS-INACTIVE state. If T(r) expires, the AS is moved to the AS-INACTIVE state.
4.3.4.6 Notify Procedures 4.3.4.4.1 IPSP Considerations (ASP Inactive)
An IPSP may be considered in the ASP-INACTIVE state by a remote IPSP after an ASP Inactive or ASP Inactive Ack message has been received from it.
Alternatively, an interchange of ASP Inactive messages from each end can be performed. This option follows the ASP state transition diagram and gives the additional advantage of selecting a particular AS to be deactivated from each end. It is especially useful when an IPSP is serving more than one AS. It would need four messages for completion.
4.3.4.5 Notify Procedures
A Notify message reflecting a change in the AS state MUST be sent to A Notify message reflecting a change in the AS state MUST be sent to
all ASPs in the AS, except those in the ASP-DOWN state, with all ASPs in the AS, except those in the ASP-DOWN state, with
appropriate Status Information and any ASP Identifier of the failed appropriate Status Information and any ASP Identifier of the failed
ASP. At the ASP, Layer Management is informed with an M-NOTIFY ASP. At the ASP, Layer Management is informed with an M-NOTIFY
indication primitive. The Notify message must be sent whether the indication primitive. The Notify message must be sent whether the
AS state change was a result of an ASP failure or reception of an AS state change was a result of an ASP failure or reception of an
ASP State management (ASPSM) / ASP Traffic Management (ASPTM) ASP State management (ASPSM) / ASP Traffic Management (ASPTM)
message. In the second case, the Notify message MUST be sent after message. In the second case, the Notify message MUST be sent after
any related acknowledgement messages (e.g., ASP Up Ack, ASP Down any related acknowledgement messages (e.g., ASP Up Ack, ASP Down
skipping to change at page 80, line 36 skipping to change at page 78, line 31
sent in the Loadshare or Broadcast mode, the Notify message does not sent in the Loadshare or Broadcast mode, the Notify message does not
explicitly compel the ASP(s) receiving the message to become explicitly compel the ASP(s) receiving the message to become
active. The ASPs remain in control of what (and when) traffic action active. The ASPs remain in control of what (and when) traffic action
is taken. is taken.
In the case where a Notify message does not contain a Routing Context In the case where a Notify message does not contain a Routing Context
parameter, the receiver must know, via configuration data, of which parameter, the receiver must know, via configuration data, of which
Application Servers the ASP is a member and take the appropriate Application Servers the ASP is a member and take the appropriate
action in each AS. action in each AS.
4.3.4.7 Heartbeat Procedures 4.3.4.5.1 IPSP Considerations (NTFY)
Notify works in the same manner as in the SG-AS case. One of the IPSPs can send this message to any remote IPSP that is not in the ASP-DOWN state.
4.3.4.76 Heartbeat Procedures
The optional Heartbeat procedures MAY be used when operating over The optional Heartbeat procedures MAY be used when operating over
transport layers that do not have their own heartbeat mechanism for transport layers that do not have their own heartbeat mechanism for
detecting loss of the transport association (i.e., other than SCTP). detecting loss of the transport association (i.e., other than SCTP).
Either M3UA peer may optionally send Heartbeat messages periodically, Either M3UA peer may optionally send Heartbeat messages periodically,
subject to a provisionable timer T(beat). Upon receiving a Heartbeat subject to a provisionable timer T(beat). Upon receiving a Heartbeat
message, the M3UA peer MUST respond with a Heartbeat Ack message. message, the M3UA peer MUST respond with a Heartbeat Ack message.
If no Heartbeat Ack message (or any other M3UA message) is received If no Heartbeat Ack message (or any other M3UA message) is received
skipping to change at page 81, line 42 skipping to change at page 79, line 42
configuration MAY authorize the creation of a new Routing Key and configuration MAY authorize the creation of a new Routing Key and
related Application Server and add the ASP to the new AS. In either related Application Server and add the ASP to the new AS. In either
case, the SGP returns a Registration Response message to the ASP, case, the SGP returns a Registration Response message to the ASP,
containing the same Local-RK-Identifier as provided in the initial containing the same Local-RK-Identifier as provided in the initial
request, and a Registration Result "Successfully Registered". A unique request, and a Registration Result "Successfully Registered". A unique
Routing Context value assigned to the SGP Routing Key is included. The Routing Context value assigned to the SGP Routing Key is included. The
method of Routing Context value assignment at the SGP is method of Routing Context value assignment at the SGP is
implementation dependent but must be guaranteed to be unique for each implementation dependent but must be guaranteed to be unique for each
Application Server or Routing Key supported by the SGP. Application Server or Routing Key supported by the SGP.
If the SGP does not support the registration procedure, the SGP returns
an Error message to the ASP, with an error code of "Unsupported Message
Type".
If the SGP determines that the received Routing Key data is invalid, or If the SGP determines that the received Routing Key data is invalid, or
contains invalid parameter values, the SGP returns a Registration contains invalid parameter values, the SGP returns a Registration
Response message to the ASP, containing a Registration Result "Error - Response message to the ASP, containing a Registration Result "Error -
Invalid Routing Key", "Error - Invalid DPC", "Error - Invalid Network Invalid Routing Key", "Error - Invalid DPC", "Error - Invalid Network
Appearance" as appropriate. Appearance" as appropriate.
If the SGP determines that a unique Routing Key cannot be created, the If the SGP determines that a unique Routing Key cannot be created, the
SGP returns a Registration Response message to the ASP, with a SGP returns a Registration Response message to the ASP, with a
Registration Status of "Error - "Cannot Support Unique Routing" An Registration Status of "Error - "Cannot Support Unique Routing" An
incoming signalling message received at an SGP should not match against incoming signalling message received at an SGP should not match against
more than one Routing Key. more than one Routing Key.
If the SGP does not authorize the registration request, the SGP returns If the SGP does not authorize an otherwise valid registration
a REG RSP message to the ASP containing the Registration Result "Error request, the SGP returns a REG RSP message to the ASP containing the
- Permission Denied". Registration Result "Error - Permission Denied".
If an SGP determines that a received Routing Key does not currently If an SGP determines that a received Routing Key does not currently
exist and the SGP does not support dynamic configuration, the SGP exist and the SGP does not support dynamic configuration, the SGP
returns a Registration Response message to the ASP, containing a returns a Registration Response message to the ASP, containing a
Registration Result "Error - Routing Key not Currently Provisioned". Registration Result "Error - Routing Key not Currently Provisioned".
If an SGP determines that a received Routing Key does not currently If an SGP determines that a received Routing Key does not currently
exist and the SGP supports dynamic configuration but does not have the exist and the SGP supports dynamic configuration but does not have the
capacity to add new Routing Key and Application Server entries, the SGP capacity to add new Routing Key and Application Server entries, the SGP
returns a Registration Response message to the ASP, containing a returns a Registration Response message to the ASP, containing a
skipping to change at page 82, line 50 skipping to change at page 81, line 4
parameter to correlate the requests with the responses. parameter to correlate the requests with the responses.
Upon successful registration of an ASP in an AS, the SGP can now send Upon successful registration of an ASP in an AS, the SGP can now send
related SS7 Signalling Network Management messaging, if this did not related SS7 Signalling Network Management messaging, if this did not
previously start upon the ASP transitioning to state ASP-INACTIVE previously start upon the ASP transitioning to state ASP-INACTIVE
4.4.2 Deregistration 4.4.2 Deregistration
An ASP MAY dynamically deregister with an SGP as an ASP within an An ASP MAY dynamically deregister with an SGP as an ASP within an
Application Server using the DEREG REQ message. A Routing Context Application Server using the DEREG REQ message. A Routing Context
parameter in the DEREG REQ message specifies which Routing Keys to parameter in the DEREG REQ message specifies which Routing Keys to
deregister. An ASP SHOULD move to the ASP-INACTIVE state for an deregister. An ASP SHOULD move to the ASP-INACTIVE state for an
Application Server before attempting to deregister the Routing Key Application Server before attempting to deregister the Routing Key
(i.e., deregister after receiving an ASP Inactive Ack). Also, an ASP (i.e., deregister after receiving an ASP Inactive Ack). Also, an ASP
SHOULD deregister from all Application Servers that it is a member SHOULD deregister from all Application Servers that it is a member
before attempting to move to the ASP-Down state. before attempting to move to the ASP-Down state.
The SGP examines the contents of the received Routing Context parameter The SGP examines the contents of the received Routing Context parameter
and validates that the ASP is currently registered in the Application and validates that the ASP is currently registered in the Application
Server(s) related to the included Routing Context(s). If validated, Server(s) related to the included Routing Context(s). If validated,
the ASP is deregistered as an ASP in the related Application Server. the ASP is deregistered as an ASP in the related Application Server.
The deregistration procedure does not necessarily imply the deletion of The deregistration procedure does not necessarily imply the deletion of
Routing Key and Application Server configuration data at the SGP. Other Routing Key and Application Server configuration data at the SG. Other
ASPs may continue to be associated with the Application Server, in ASPs may continue to be associated with the Application Server, in
which case the Routing Key data MUST NOT be deleted. If a which case the Routing Key data MUST NOT be deleted. If a
Deregistration results in no more ASPs in an Application Server, an SGP Deregistration results in no more ASPs in an Application Server, an SG
MAY delete the Routing Key data. MAY delete the Routing Key data.
The SGP acknowledges the deregistration request by returning a DEREG The SGP acknowledges the deregistration request by returning a DEREG
RSP message to the requesting ASP. The result of the deregistration is RSP message to the requesting ASP. The result of the deregistration is
found in the Deregistration Result parameter, indicating success or found in the Deregistration Result parameter, indicating success or
failure with cause. failure with cause.
An ASP MAY deregister multiple Routing Contexts at once by including a An ASP MAY deregister multiple Routing Contexts at once by including a
number of Routing Contexts in a single DEREG REQ message. The SGP MAY number of Routing Contexts in a single DEREG REQ message. The SGP MAY
respond to each deregistration request in a single DEREG RSP message, respond to each deregistration request in a single DEREG RSP message,
indicating the success or failure result for each Routing Context in a indicating the success or failure result for each Routing Context in a
separate Deregistration Result parameter. separate Deregistration Result parameter.
4.4.3 IPSP Considerations (REG/DEREG)
The Registration/Deregistration procedures work in the IPSP cases in the same way as in AS-SG cases. An IPSP may register an RK in the remote IPSP. An IPSP is responsible for deregistering the RKs that it has registered.
4.5 Procedures to Support the Availability or Congestion Status of SS7 4.5 Procedures to Support the Availability or Congestion Status of SS7
Destination Destination
4.5.1 At an SGP 4.5.1 At an SGP
On receiving an MTP-PAUSE, MTP-RESUME or MTP-STATUS indication On receiving an MTP-PAUSE, MTP-RESUME or MTP-STATUS indication
primitive from the nodal interworking function at an SGP, the SGP M3UA primitive from the nodal interworking function at an SGP, the SGP M3UA
layer will send a corresponding SS7 Signalling Network Management layer will send a corresponding SS7 Signalling Network Management
(SSNM) DUNA, DAVA, SCON, or DUPU message (see Section 3.4) to the M3UA (SSNM) DUNA, DAVA, SCON, or DUPU message (see Section 3.4) to the M3UA
peers at concerned ASPs. The M3UA layer must fill in various fields of peers at concerned ASPs. The M3UA layer must fill in various fields of
skipping to change at page 85, line 39 skipping to change at page 83, line 50
The SGP SHOULD respond to a DAUD message with the MTP3 The SGP SHOULD respond to a DAUD message with the MTP3
availability/congested status of the routeset associated with each availability/congested status of the routeset associated with each
Destination Point Code(s) in the DAUD message. The status of each SS7 Destination Point Code(s) in the DAUD message. The status of each SS7
destination requested is indicated in a DUNA message (if unavailable), destination requested is indicated in a DUNA message (if unavailable),
a DAVA message (if available), or a DRST (if restricted and the SGP a DAVA message (if available), or a DRST (if restricted and the SGP
supports this feature). Where the SGP maintains the congestion status supports this feature). Where the SGP maintains the congestion status
of the SS7 destination, and the SS7 destination is congested, the SGP of the SS7 destination, and the SS7 destination is congested, the SGP
MUST additionally respond with an SCON message before the DAVA or DRST MUST additionally respond with an SCON message before the DAVA or DRST
message. If the SS7 destination is available and congested, the SGP message. If the SS7 destination is available and congested, the SGP
MUST respond with an SCON message DAVA message. If the SS7 MUST respond with an SCON message and then a DAVA message. If the SS7
destination is restricted and congested, the SGP MUST respond with destination is restricted and congested, the SGP MUST respond with
an SCON message immediately followed by a DRST message. If the SGP an SCON message immediately followed by a DRST message. If the SGP
has no information on the availability status of the SS7 destination, has no information on the availability status of the SS7 destination,
the SGP responds with a DUNA message, as it has no routing the SGP responds with a DUNA message, as it has no routing
information to allow it to route traffic to this destination. information to allow it to route traffic to this destination.
Any DUNA or DAVA message in response to a DAUD message MAY contain a Any DUNA or DAVA message in response to a DAUD message MAY contain a
list of up to sixteen Affected Point Codes. list of up to sixteen Affected Point Codes.
An SG MAY refuse to provide the availability or congestion status of An SG MAY refuse to provide the availability or congestion status of
a destination if, for example, the ASP is not authorized to know the a destination if, for example, the ASP is not authorized to know the
status of the destination. The SG MAY respond with an Error Message status of the destination. The SG MAY respond with an Error Message
(Error Code = "Destination Status Unknown") (Error Code = "Destination Status Unknown")
skipping to change at page 87, line 8 skipping to change at page 85, line 17
5.1 Establishment of Association and Traffic between SGPs and ASPs 5.1 Establishment of Association and Traffic between SGPs and ASPs
These scenarios show the example M3UA message flows for the These scenarios show the example M3UA message flows for the
establishment of traffic between an SGP and an ASP or between two establishment of traffic between an SGP and an ASP or between two
IPSPs. In all cases it is assumed that the SCTP association is IPSPs. In all cases it is assumed that the SCTP association is
already set up. already set up.
5.1.1 Single ASP in an Application Server ("1+0" sparing), 5.1.1 Single ASP in an Application Server ("1+0" sparing),
These scenarios show the example M3UA message flows for the These scenarios show the example M3UA message flows for the
establishment of traffic between an SGP and an ASP or between two establishment of traffic between an SGP and an ASP where only one ASP
IPSPs, where only one ASP/IPSP is configured within an AS/IPS is configured within an AS (no backup).
(no backup).
5.1.1.1 Single ASP/IPSP in an Application Server/IPS ("1+0" sparing), 5.1.1.1 Single ASP/IPSP in an Application Server ("1+0" sparing),
No Registration No Registration
The sending of any DUNA/SCON messages by The sending of any DUNA/SCON messages by the SGP is not shown but is similar to the case described in Section 5.1.2.
the SGP is not shown but is similar to the case described in Section
5.1.2.
SGP/IPSP ASP1/IPSP1 SGP ASP1
| | | |
|<-------------ASP Up------------| |<-------------ASP Up------------|
|-----------ASP Up Ack---------->| |-----------ASP Up Ack---------->|
| | | |
|<------- ASP Active(RCn)--------| RC: Routing Context |<------- ASP Active(RCn)--------| RC: Routing Context
|-----ASP Active Ack (RCn)------>| (optional) |-----ASP Active Ack (RCn)------>| (optional)
| | | |
Note: If the ASP Active message contains an optional Routing Context Note: If the ASP Active message contains an optional Routing Context
parameter, The ASP Active message only applies for the specified RC parameter, The ASP Active message only applies for the specified RC
value(s). For an unknown RC value, the SGP responds with an Error value(s). For an unknown RC value, the SGP responds with an Error
message. message.
5.1.1.2 Single ASP/IPSP in Application Server/IPS ("1+0" sparing), 5.1.1.2 Single ASP in Application Server ("1+0" sparing),
Dynamic Registration Dynamic Registration
This scenario is the same as for 5.1.1.1 but with the optional exchange This scenario is the same as for 5.1.1.1 but with the optional exchange
of registration information. In this case the Registration is accepted of registration information. In this case the Registration is accepted
by the SGP/IPSP. by the SGP.
SGP/IPSP ASP1/IPSP1 SGP ASP1
| | | |
|<------------ASP Up-------------| |<------------ASP Up-------------|
|----------ASP Up Ack----------->| |----------ASP Up Ack----------->|
| | | |
|<----REGISTER REQ(LRCn,RKn)-----| LRC: Local Routing |<----REGISTER REQ(LRCn,RKn)-----| LRC: Local Routing
| | Context | | Context
|----REGISTER RESP(LRCn,RCn)---->| RK: Routing Key |----REGISTER RESP(LRCn,RCn)---->| RK: Routing Key
| | RC: Routing Context | | RC: Routing Context
| | | |
|<------- ASP Active(RCn)--------| |<------- ASP Active(RCn)--------|
|-----ASP Active Ack (RCn)------>| |-----ASP Active Ack (RCn)------>|
| | | |
Note: In the case of an unsuccessful registration attempt (e.g., Note: In the case of an unsuccessful registration attempt (e.g.,
invalid RKn), the Register Response message will contain an invalid RKn), the Register Response message will contain an
unsuccessful indication and the ASP/IPSP will not subsequently send unsuccessful indication and the ASP will not subsequently send
an ASP Active message. an ASP Active message.
5.1.1.3 Single ASP/IPSP in Multiple Application Servers/IPSs (each 5.1.1.3 Single ASP in Multiple Application Servers (each
with "1+0" sparing), Dynamic Registration (Case 1 - Multiple with "1+0" sparing), Dynamic Registration (Case 1 - Multiple
Registration Requests) Registration Requests)
SGP/IPSP ASP1/IPSP1 SGP ASP1
| | | |
|<------------ASP Up-------------| |<------------ASP Up-------------|
|----------ASP Up Ack----------->| |----------ASP Up Ack----------->|
| | | |
|<----REGISTER REQ(LRC1,RK1)-----| LRC: Local Routing |<----REGISTER REQ(LRC1,RK1)-----| LRC: Local Routing
| | Context | | Context
|----REGISTER RESP(LRC1,RC1)---->| RK: Routing Key |----REGISTER RESP(LRC1,RC1)---->| RK: Routing Key
| | RC: Routing Context | | RC: Routing Context
| | | |
|<------- ASP Active(RC1)--------| |<------- ASP Active(RC1)--------|
skipping to change at page 88, line 39 skipping to change at page 86, line 53
| | | |
|----REGISTER RESP(LRCn,RCn)---->| |----REGISTER RESP(LRCn,RCn)---->|
| | | |
| | | |
|<------- ASP Active(RCn)--------| |<------- ASP Active(RCn)--------|
|-----ASP Active Ack (RCn)------>| |-----ASP Active Ack (RCn)------>|
| | | |
Note: In the case of an unsuccessful registration attempt (e.g., Note: In the case of an unsuccessful registration attempt (e.g.,
invalid RKn), the Register Response message will contain an invalid RKn), the Register Response message will contain an
unsuccessful indication and the ASP/IPSP will not subsequently send unsuccessful indication and the ASP will not subsequently send
an ASP Active message. Each LRC/RK pair registration is considered an ASP Active message. Each LRC/RK pair registration is considered
independently. independently.
It is not necessary to follow a Registration Request/Response message It is not necessary to follow a Registration Request/Response message
pair with an ASP Active message before sending the next Registration pair with an ASP Active message before sending the next Registration
Request. The ASP Active message can be sent at any time after the Request. The ASP Active message can be sent at any time after the
related successful registration. related successful registration.
5.1.1.4 Single ASP/IPSP in Multiple Application Servers/IPSs (each 5.1.1.4 Single ASP in Multiple Application Servers (each
with "1+0" sparing), Dynamic Registration (Case 2 - Single with "1+0" sparing), Dynamic Registration (Case 2 - Single
Registration Request) Registration Request)
SGP/IPSP ASP1/IPSP1
SGP ASP1
| | | |
|<------------ASP Up-------------| |<------------ASP Up-------------|
|----------ASP Up Ack----------->| |----------ASP Up Ack----------->|
| | | |
|<---REGISTER REQ({LRC1,RK1},----| |<---REGISTER REQ({LRC1,RK1},----|
| ..., | | ..., |
| {LRCn,RKn}),----| | {LRCn,RKn}),----|
| | | |
|---REGISTER RESP({LRC1,RC1},--->| |---REGISTER RESP({LRC1,RC1},--->|
| ..., | | ..., |
skipping to change at page 89, line 29 skipping to change at page 87, line 41
| | | |
: : : :
: : : :
| | | |
|<------- ASP Active(RCn)--------| |<------- ASP Active(RCn)--------|
|-----ASP Active Ack (RCn)------>| |-----ASP Active Ack (RCn)------>|
| | | |
Note: In the case of an unsuccessful registration attempt (e.g., Note: In the case of an unsuccessful registration attempt (e.g.,
Invalid RKn), the Register Response message will contain an Invalid RKn), the Register Response message will contain an
unsuccessful indication and the ASP/IPSP will not subsequently unsuccessful indication and the ASP will not subsequently
send an ASP Active message. Each LRC/RK pair registration is send an ASP Active message. Each LRC/RK pair registration is
considered independently. considered independently.
The ASP Active message can be sent at any time after the related The ASP Active message can be sent at any time after the related
successful registration, and may have more than one RC. successful registration, and may have more than one RC.
5.1.2 Two ASPs/IPSPs in Application Server/IPS ("1+1" sparing) 5.1.2 Two ASPs in Application Server ("1+1" sparing)
This scenario shows the example M3UA message flows for the This scenario shows the example M3UA message flows for the
establishment of traffic between an SGP and two ASPs in the same establishment of traffic between an SGP and two ASPs in the same
Application Server, or between an IPSP and two IPSPs in the same Application Server, where ASP1 is configured to be in the ASP-ACTIVE
IPS, where ASP1/IPSP1 is configured to be in the ASP-ACTIVE
state and ASP2/IPSP2 is to be a "backup" in the event of
communication failure or the withdrawal from service of
ASP1/IPSP1. ASP2/IPSP2 may act as a hot, warm, or cold backup
depending on the extent to which ASP1/IPSP1 and ASP2/IPSP2
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 indicate "Override",
"Loadshare" or "Broadcast" mode, although typically this example
would use an Override mode. The SGP MAY start sending any
relevant DUNA, DRST and SCON messages to ASPs as soon as they
enter the ASP-INACTIVE state.
SGP/IPSP ASP1/IPSP1 ASP2/IPSP2 state and ASP2 is to be a "backup" in the event of communication failure or the withdrawal from service of ASP1. ASP2 may act as a hot, warm, or cold backup 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 indicate "Override", "Loadshare" or "Broadcast" mode, although typically this example
would use an Override mode.
SGP ASP1 ASP2
| | | | | |
|<--------ASP Up----------| | |<--------ASP Up----------| |
|-------ASP Up Ack------->| | |-------ASP Up Ack------->| |
| | | | | |
|<-----------------------------ASP Up----------------| |<-----------------------------ASP Up----------------|
|-----------------------------ASP Up Ack------------>| |-----------------------------ASP Up Ack------------>|
| | | | | |
| | | | | |
|<-------ASP Active-------| | |<-------ASP Active-------| |
|------ASP Active Ack---->| | |------ASP Active Ack---->| |
| | | | | |
5.1.3 Two ASPs/IPSPs in an Application Server/IPS ("1+1" sparing, 5.1.3 Two ASPs in an Application Server ("1+1" sparing,
loadsharing case) loadsharing case)
This scenario shows a similar case to Section 5.1.2 but where the This scenario shows a similar case to Section 5.1.2 but where the
two ASPs/IPSPs are brought to the state ASP-ACTIVE and subsequently two ASPs are brought to the state ASP-ACTIVE and subsequently
loadshare the traffic. In this case, one ASP/IPSP is sufficient loadshare the traffic. In this case, one ASP is sufficient
to handle the total traffic load. The sending of DUNA, DRST and to handle the total traffic load. The sending of DUNA, DRST and
SCON messages by the SGP is not shown but is similar to the case SCON messages by the SGP is not shown but is similar to the case
described in Section 5.1.2. described in Section 5.1.2.
SGP/IPSP ASP1/IPSP1 ASP2/IPSP2 SGP ASP1 ASP2
| | | | | |
|<---------ASP Up---------| | |<---------ASP Up---------| |
|--------ASP Up Ack------>| | |--------ASP Up Ack------>| |
| | | | | |
|<------------------------------ASP Up---------------| |<------------------------------ASP Up---------------|
|-----------------------------ASP Up Ack------------>| |-----------------------------ASP Up Ack------------>|
| | | | | |
| | | | | |
|<--ASP Active (Ldshr)----| | |<--ASP Active (Ldshr)----| |
|-----ASP-Active Ack----->| | |-----ASP-Active Ack----->| |
| | | | | |
|----------------------------NOTIFY (AS-ACTIVE------>| |----------------------------NOTIFY (AS-ACTIVE------>|
| | | | | |
|<----------------------------ASP Active (Ldshr)-----| |<----------------------------ASP Active (Ldshr)-----|
|-------------------------------ASP Active Ack------>| |-------------------------------ASP Active Ack------>|
| | | | | |
5.1.4 Three ASPs/IPSPs in an Application Server/IPS ("n+k" sparing, 5.1.4 Three ASPs in an Application Server ("n+k" sparing,
loadsharing case) loadsharing case)
This scenario shows the example M3UA message flows for the This scenario shows the example M3UA message flows for the
establishment of traffic between an SGP and three ASPs in the same establishment of traffic between an SGP and three ASPs in the same
Application Server, or between an IPSP and three IPSPs in the same Application Server, where two of the ASPs are brought to the state
IPS, where two of the ASPs/IPSPs are brought to the state
ASP-ACTIVE and subsequently share the load. In this case, a minimum ASP-ACTIVE and subsequently share the load. In this case, a minimum
of two ASPs/IPSPs are required to handle the total traffic load of two ASPs are required to handle the total traffic load
(2+1 sparing). The sending of DUNA, DRST and SCON messages by the (2+1 sparing). The sending of DUNA, DRST and SCON messages by the
SGP is not shown but is similar to the case described in Section 5.1.2. SGP is not shown but is similar to the case described in Section 5.1.2.
SGP/IPSP ASP1/IPSP1 ASP2/IPSP2 ASP3/IPSP3 SGP ASP1 ASP2 ASP3
| | | | | | | |
|<------ASP Up-------| | | |<------ASP Up-------| | |
|-----ASP Up Ack---->| | | |-----ASP Up Ack---->| | |
| | | | | | | |
|<--------------------------ASP Up-------| | |<--------------------------ASP Up-------| |
|-------------------------ASP Up Ack---->| | |-------------------------ASP Up Ack---->| |
| | | | | | | |
|<---------------------------------------------ASP Up--------| |<---------------------------------------------ASP Up--------|
|---------------------------------------------ASP Up Ack---->| |---------------------------------------------ASP Up Ack---->|
| | | | | | | |
skipping to change at page 91, line 37 skipping to change at page 89, line 42
|-----------------------Notify (AS-ACTIVE)------------------>| |-----------------------Notify (AS-ACTIVE)------------------>|
| | | | | | | |
|<--------------------ASP Act. (Ldshr)---| | |<--------------------ASP Act. (Ldshr)---| |
|-----------------------ASP Act Ack----->| | |-----------------------ASP Act Ack----->| |
| | | | | | | |
5.2 ASP/IPSP Traffic Failover Examples 5.2 ASP/IPSP Traffic Failover Examples
5.2.1 (1+1 Sparing, Withdrawal of ASP/IPSP, Backup Override) 5.2.1 (1+1 Sparing, Withdrawal of ASP/IPSP, Backup Override)
Following on from the example in Section 5.1.2, and ASP1/IPSP1 Following on from the example in Section 5.1.2, and ASP1
withdraws from service: withdraws from service:
SGP/IPSP ASP1/IPSP1 ASP2/IPSP2 SGP ASP1 ASP2
| | | | | |
|<-----ASP Inactive-------| | |<-----ASP Inactive-------| |
|----ASP Inactive Ack---->| | |----ASP Inactive Ack---->| |
|------------------------NTFY(AS-Pending)----------->| |------------------------NTFY(AS-Pending)----------->|
| | | | | |
|<------------------------------ ASP Active----------| |<------------------------------ ASP Active----------|
|------------------------------ASP Active Ack------->| |------------------------------ASP Active Ack------->|
| | | |
Note: If the SGP/IPSP M3UA layer detects the loss of the M3UA peer Note: If the SGP M3UA layer detects the loss of the M3UA peer
(e.g., M3UA heartbeat loss or detection of SCTP failure), the (e.g., M3UA heartbeat loss or detection of SCTP failure), the
initial ASP Inactive message exchange (i.e., between ASP1/IPSP1 initial ASP Inactive message exchange (i.e., SGP to ASP1) would not occur.
and SGP/IPSP) would not occur.
5.2.2 (1+1 Sparing, Backup Override) 5.2.2 (1+1 Sparing, Backup Override)
Following on from the example in Section 5.1.2, ASP2/IPSP2 wishes to Following on from the example in Section 5.1.2, ASP2 wishes to
Override ASP1/IPSP1 and take over the traffic: Override ASP1 and take over the traffic:
SGP/IPSP ASP1/IPSP1 ASP2/IPSP2 SGP ASP1 ASP2
| | | | | |
|<------------------------------ ASP Active----------| |<------------------------------ ASP Active----------|
|-------------------------------ASP Active Ack------>| |-------------------------------ASP Active Ack------>|
|----NTFY(Alt ASP-Act)--->| |----NTFY(Alt ASP-Act)--->|
| | | | | |
5.2.3 (n+k Sparing, Loadsharing case, Withdrawal of ASP/IPSP) 5.2.3 (n+k Sparing, Loadsharing case, Withdrawal of ASP)
Following on from the example in Section 5.1.4, and ASP1/IPSP1 Following on from the example in Section 5.1.4, and ASP1
withdraws from service: withdraws from service:
SGP/IPSP ASP1/IPSP1 ASP2/IPSP2 ASP3/IPSP3 SGP ASP1 ASP2 ASP3
| | | | | | | |
|<----ASP Inact.-----| | | |<----ASP Inact.-----| | |
|---ASP Inact Ack--->| | | |---ASP Inact Ack--->| | |
| | | | | | | |
|---------------------------------NTFY(Ins. ASPs)----------->| |---------------------------------NTFY(Ins. ASPs)----------->|
| | | | | | | |
|<-----------------------------------------ASP Act (Ldshr)---| |<-----------------------------------------ASP Act (Ldshr)---|
|-------------------------------------------ASP Act (Ack)--->| |-------------------------------------------ASP Act (Ack)--->|
| | | | | | | |
For the Notify message to be sent, the SG/IPSP maintains knowledge of For the Notify message to be sent, the SG maintains knowledge of
the minimum ASP/IPSP resources required (e.g., if the SG/IPSP knows the minimum ASP resources required (e.g., if the SG knows
that "n+k" = "2+1" for a Loadshare AS/IPS and "n" currently equals that "n+k" = "2+1" for a Loadshare AS and "n" currently equals
"1"). "1").
Note: If the SGP/IPSP detects loss of the ASP1/IPSP1 M3UA peer (e.g., Note: If the SGP detects loss of the ASP1 M3UA peer (e.g.,
M3UA heartbeat loss or detection of SCTP failure), the initial ASP M3UA heartbeat loss or detection of SCTP failure), the initial ASP
Inactive message exchange (i.e., SGP/IPSP-ASP1/IPSP1) would not occur. Inactive message exchange (i.e., SGP-ASP1) would not occur.
5.3 Normal Withdrawal of an ASP/IPSP from an Application Server/IPS 5.3 Normal Withdrawal of an ASP from an Application Server
and Teardown of an Association and Teardown of an Association
An ASP/IPSP which is now confirmed in the state ASP-INACTIVE (i.e., An ASP which is now confirmed in the state ASP-INACTIVE (i.e.,
the ASP/IPSP has received an ASP Inactive Ack message) may now proceed the ASP has received an ASP Inactive Ack message) may now proceed
to the ASP-DOWN state, if it is to be removed from service. Following to the ASP-DOWN state, if it is to be removed from service. Following
on from Section 5.2.1 or 5.2.3, where ASP1/IPSP1 has moved to the on from Section 5.2.1 or 5.2.3, where ASP1 has moved to the
"Inactive" state: "Inactive" state:
SGP/IPSP ASP1/IPSP1 SGP ASP1
| | | |
|<-----ASP Inactive (RCn)-------| RC: Routing Context |<-----ASP Inactive (RCn)-------| RC: Routing Context
|----ASP Inactive Ack (RCn)---->| |----ASP Inactive Ack (RCn)---->|
| | | |
|<-----DEREGISTER REQ(RCn)------| See Notes |<-----DEREGISTER REQ(RCn)------| See Notes
| | | |
|---DEREGISTER RESP(LRCn,RCn)-->| |---DEREGISTER RESP(LRCn,RCn)-->|
| | | |
: : : :
| | | |
|<-----------ASP Down-----------| |<-----------ASP Down-----------|
|---------ASP Down Ack--------->| |---------ASP Down Ack--------->|
| | | |
Note: The Deregistration procedure MUST be used if the ASP/IPSP Note: The Deregistration procedure MUST be used if the ASP
previously used the Registration procedures for configuration previously used the Registration procedures for configuration
within the Application Server/IPS. ASP Inactive and Deregister within the Application Server. ASP Inactive and Deregister
messages exchanges may contain multiple Routing Contexts. messages exchanges may contain multiple Routing Contexts.
The ASP/IPSP SHOULD be in the ASP-INACTIVE state and SHOULD have The ASP should be in the ASP-INACTIVE state and should have
deregistered in all its Routing Contexts before attempting to move deregistered in all its Routing Contexts before attempting to move
to the ASP-DOWN state. to the ASP-DOWN state.
5.4 M3UA/MTP3-User Boundary Examples 5.4 M3UA/MTP3-User Boundary Examples
5.4.1 At an ASP/IPSP 5.4.1 At an ASP
This section describes the primitive mapping between the MTP3 User and This section describes the primitive mapping between the MTP3 User and
the M3UA layer at an ASP or IPSP. the M3UA layer at an ASP.
5.4.1.1 Support for MTP-TRANSFER Primitives at the ASP 5.4.1.1 Support for MTP-TRANSFER Primitives at the ASP
5.4.1.1.1 Support for MTP-TRANSFER Request Primitive 5.4.1.1.1 Support for MTP-TRANSFER Request Primitive
When the MTP3-User on the ASP/IPSP has data to send to a remote When the MTP3-User on the ASP has data to send to a remote
MTP3-User, it uses the MTP-TRANSFER request primitive. The M3UA MTP3-User, it uses the MTP-TRANSFER request primitive. The M3UA
layer at the ASP/IPSP will do the following when it receives an layer at the ASP will do the following when it receives an
MTP-TRANSFER request primitive from the M3UA user: MTP-TRANSFER request primitive from the M3UA user:
- Determine the correct SGP/IPSP; - Determine the correct SGP;
- Determine the correct association to the chosen SGP/IPSP; - Determine the correct association to the chosen SGP;
- Determine the correct stream in the association (e.g., based on - Determine the correct stream in the association (e.g., based on
SLS); SLS);
- Determine whether to complete the optional fields of the DATA - Determine whether to complete the optional fields of the DATA
message; message;
- Map the MTP-TRANSFER request primitive into the Protocol Data - Map the MTP-TRANSFER request primitive into the Protocol Data
field of a DATA message; field of a DATA message;
- Send the DATA message to the remote M3UA peer at the SGP/IPSP, over - Send the DATA message to the remote M3UA peer at the SGP, over
the SCTP association. the SCTP association.
SGP/IPSP ASP/IPSP SGP ASP
| | | |
|<-----DATA Message-------|<--MTP-TRANSFER req. |<-----DATA Message-------|<--MTP-TRANSFER req.
| | | |
5.4.1.1.2 Support for the MTP-TRANSFER Indication Primitive 5.4.1.1.2 Support for the MTP-TRANSFER Indication Primitive
When the M3UA layer on the ASP/IPSP receives a DATA message from the When the M3UA layer on the ASP receives a DATA message from the
M3UA peer at the remote SGP/IPSP, it will do the following: M3UA peer at the remote SGP, it will do the following:
- Evaluate the optional fields of the DATA message, if present; - Evaluate the optional fields of the DATA message, if present;
- Map the Protocol Data field of a DATA message into the MTP-TRANSFER - Map the Protocol Data field of a DATA message into the MTP-TRANSFER
indication primitive; indication primitive;
- Pass the MTP-TRANSFER indication primitive to the user part. In - Pass the MTP-TRANSFER indication primitive to the user part. In
case of multiple user parts, the optional fields of the Data case of multiple user parts, the optional fields of the Data
message are used to determine the concerned user part. message are used to determine the concerned user part.
SGP/IPSP ASP/IPSP SGP ASP
| | | |
|------Data Message------>|-->MTP-Transfer ind. |------Data Message------>|-->MTP-Transfer ind.
| | | |
5.4.1.1.3 Support for ASP Querying of SS7 Destination States 5.4.1.1.3 Support for ASP Querying of SS7 Destination States
There are situations such as temporary loss of connectivity to the SGP There are situations such as temporary loss of connectivity to the SGP
that may cause the M3UA layer at the ASP to audit SS7 destination that may cause the M3UA layer at the ASP to audit SS7 destination
availability/congestion states. Note: there is no primitive for the availability/congestion states. Note: there is no primitive for the
MTP3-User to request this audit from the M3UA layer as this is MTP3-User to request this audit from the M3UA layer as this is
skipping to change at page 95, line 36 skipping to change at page 93, line 44
<---MTP-TRANSFER req.|<---------DATA ----------| <---MTP-TRANSFER req.|<---------DATA ----------|
| | | |
5.4.2.2 Support for MTP-TRANSFER Indication Primitive at the SGP 5.4.2.2 Support for MTP-TRANSFER Indication Primitive at the SGP
When the MTP3 layer at the SGP has data to pass its user parts, it will When the MTP3 layer at the SGP has data to pass its user parts, it will
use the MTP-TRANSFER indication primitive. The M3UA layer at the SGP use the MTP-TRANSFER indication primitive. The M3UA layer at the SGP
will do the following when it receives an MTP-TRANSFER indication will do the following when it receives an MTP-TRANSFER indication
primitive: primitive:
- Determine the correct ASP using the distribution function; - Determine the correct AS using the distribution function;
- Select an ASP in the ASP-ACTIVE state - Select an ASP in the ASP-ACTIVE state
- Determine the correct association to the chosen ASP; - Determine the correct association to the chosen ASP;
- Determine the correct stream in the SCTP association (e.g., based - Determine the correct stream in the SCTP association (e.g., based
on SLS); on SLS);
- Determine whether to complete the optional fields of the DATA - Determine whether to complete the optional fields of the DATA
message; message;
- Map the MTP-TRANSFER indication primitive into the Protocol Data - Map the MTP-TRANSFER indication primitive into the Protocol Data
field of a DATA message; field of a DATA message;
- Send the DATA message to the remote M3UA peer in the ASP, over the - Send the DATA message to the remote M3UA peer in the ASP, over the
SCTP association SCTP association
SGP ASP SGP ASP
| | | |
--MTP-TRANSFER ind.->|----------DATA --------->| --MTP-TRANSFER ind.->|----------DATA --------->|
| | | |
5.4.2.3 Support for MTP-PAUSE, MTP-RESUME, MTP-STATUS Indication 5.4.2.3 Support for MTP-PAUSE, MTP-RESUME, MTP-STATUS Indication
Primitives Primitives
The MTP-PAUSE, MTP-RESUME and MTP-STATUS indication primitives from the The MTP-PAUSE, MTP-RESUME and MTP-STATUS indication primitives from the
MTP3 upper layer interface at the SGP need to be made available to the MTP3 upper layer interface at the SGP need to be made available to the
skipping to change at page 97, line 23 skipping to change at page 95, line 31
primitive when it receives an UPU message from the SS7 network. The primitive when it receives an UPU message from the SS7 network. The
M3UA layer will map this primitive to a DUPU message. It will M3UA layer will map this primitive to a DUPU message. It will
determine which ASP(s) to send the DUPU based on the intended determine which ASP(s) to send the DUPU based on the intended
Application Server. Application Server.
SGP ASP SGP ASP
| | | |
--MTP-STATUS ind.-->|----------DUPU---------->|--MTP-STATUS ind.--> --MTP-STATUS ind.-->|----------DUPU---------->|--MTP-STATUS ind.-->
| | | |
6. Security 5.5 Examples for IPSP communication.
These scenarios show a basic example for IPSP communication for the
three phases of the connection (establishment, data exchange,
disconnection). It is assumed that the SCTP association is already set
up. Both single exchange and double exchange behavior are included
for illustrative purposes.
5.5.1 Single exchange:
IPSP-A IPSP-B
| |
|-------------ASP Up------------>|
|<----------ASP Up Ack-----------|
| |
|<------- ASP Active(RCb)--------| RC: Routing Context
|-----ASP Active Ack (RCb)------>| (optional)
| |
| |
|<========= DATA (RCb) ========>|
| |
|<-----ASP Inactive (RCb)--------| RC: Routing Context
|----ASP Inactive Ack (RCb)----->| (optional)
| |
|<-----------ASP Down------------|
|---------ASP Down Ack---------->|
| |
Routing Context are previously agreed to be the same in both directions.
5.5.2 Double exchange:
IPSP-A IPSP-B
| |
|<-------------ASP Up------------|
|-----------ASP Up Ack---------->|
| |
|-------------ASP Up------------>| (optional)
|<----------ASP Up Ack-----------| (optional)
| |
|<------- ASP Active(RCb)--------| RC: Routing Context
|-----ASP Active Ack (RCb)------>| (optional)
| |
|------- ASP Active(RCa)-------->| RC: Routing Context
|<-----ASP Active Ack (RCa)------| (optional)
| |
|<========= DATA (RCa) =========|
|========== DATA (RCb) ========>|
| |
|<-----ASP Inactive (RCb)--------| RC: Routing Context
|----ASP Inactive Ack (RCb)----->|
| |
|------ASP Inactive (RCa)------->| RC: Routing Context
|<----ASP Inactive Ack (RCa)-----|
| |
|<-----------ASP Down------------|
|---------ASP Down Ack---------->|
| |
|------------ASP Down----------->| (optional)
|<--------ASP Down Ack-----------| (optional)
| |
In this approach, only one single exchange of ASP Up message can be
considered as enough since the response by the other peer can be
considered as a notice that it is in ASP_UP state.
For the same reason, only one ASP Down message is needed since once
that an IPSP receives ASP_Down ack message it is itself considered as
being in the ASP_Down state and not allowed to receive ASPSM messages.
6. Security Considerations
6.1 Introduction 6.1 Introduction
M3UA is designed to carry signalling messages for telephony services. M3UA is designed to carry signalling messages for telephony services.
As such, M3UA must involve the security needs of several parties: the As such, M3UA must involve the security needs of several parties: the
end users of the services; the network providers and the applications end users of the services; the network providers and the applications
involved. Additional requirements may come from local regulation. involved. Additional requirements may come from local regulation.
While having some overlapping security needs, any security solution While having some overlapping security needs, any security solution
should fulfill all of the different parties' needs. should fulfill all of the different parties' needs.
skipping to change at page 100, line 14 skipping to change at page 99, line 45
instances of this parameter type may be found within the same instances of this parameter type may be found within the same
message. message.
8. Acknowledgements 8. Acknowledgements
The authors would like to thank Antonio Roque Alvarez, Joyce Archibald, The authors would like to thank Antonio Roque Alvarez, Joyce Archibald,
Tolga Asveren, Maria-Cruz Bartolome-Rodrigo, Dan Brendes, Nikhil Jain, Tolga Asveren, Maria-Cruz Bartolome-Rodrigo, Dan Brendes, Nikhil Jain,
Roland Jesske, Joe Keller, Kurt Kite, Ming Lin, Steve Lorusso, Naoto Roland Jesske, Joe Keller, Kurt Kite, Ming Lin, Steve Lorusso, Naoto
Makinae, Howard May, Francois Mouillaud, Barry Nagelberg, Neil Olson, Makinae, Howard May, Francois Mouillaud, Barry Nagelberg, Neil Olson,
Heinz Prantner, Shyamal Prasad, Mukesh Punhani, Selvam Rengasami, Heinz Prantner, Shyamal Prasad, Mukesh Punhani, Selvam Rengasami,
John Shantz, Ray Singh, Michael Tuexen, Nitin Tomar, Gery Verwimp, John Schantz, Ray Singh, Michael Tuexen, Nitin Tomar, Gery Verwimp,
Tim Vetter, Kazuo Watanabe, Ben Wilson and many others for their Tim Vetter, Kazuo Watanabe, Ben Wilson and many others for their
valuable comments and suggestions. valuable comments and suggestions.
9. References 9. References
[1] RFC 2719, "Framework Architecture for Signaling Transport", L. Ong [1] RFC 2719, "Framework Architecture for Signaling Transport", L. Ong
et al, October 1999 et al, October 1999
[2] ITU-T Recommendations Q.761 to Q.767, "Signalling System No.7 (SS7) [2] ITU-T Recommendations Q.761 to Q.767, "Signalling System No.7 (SS7)
- ISDN User Part (ISUP)" - ISDN User Part (ISUP)"
[3] ANSI T1.113 - "Signaling System Number 7 - ISDN User Part" [3] ANSI T1.113 - "Signaling System Number 7 - ISDN User Part"
[4] ETSI ETS 300 356-1 "Integrated Services Digital Network (ISDN); [4] ETSI ETS 300 356-1 "Integrated Services Digital Network (ISDN);
Signalling System No.7; ISDN User Part (ISUP) version 2 for the Signalling System No.7; ISDN User Part (ISUP) version 2 for the
international interface; Part 1: Basic services" international interface; Part 1: Basic services"
[5] ITU-T Recommendations Q.711 to Q.715, "Signalling System No. 7 [5] ITU-T Recommendations Q.711 to Q.715, "Signalling System No. 7
skipping to change at page 102, line 18 skipping to change at page 101, line 45
[27] <draft-ietf-sigtran-m2pa-03.txt>, "SS7 MTP2-User Peer-to-Peer [27] <draft-ietf-sigtran-m2pa-03.txt>, "SS7 MTP2-User Peer-to-Peer
Adaptation Layer", Tom George et al, July 2001 (Work in Progress) Adaptation Layer", Tom George et al, July 2001 (Work in Progress)
10. Author's Addresses 10. Author's Addresses
Greg Sidebottom Greg Sidebottom
gregside consulting gregside consulting
Kanata, Ontario, Canada Kanata, Ontario, Canada
EMail: gregside@home.com EMail: gregside@home.com
Javier Pastor-Balb▀s Javier Pastor-Balb×s
Ericsson Espa▒a S.A. Ericsson Espaśa S.A.
C/ Ombö 3 C/ Omb" 3
28045 Madrid - Spain 28045 Madrid - Spain
EMail: j.javier.pastor@ericsson.com EMail: j.javier.pastor@ericsson.com
Guy Mousseau Guy Mousseau
Nortel Networks Nortel Networks
3685 Richmond Rd 3685 Richmond Rd
EMail: Nepean, Ontario, Canada K2H 5B7
Nepean, Ontario, Canada K2H 5B7
Lyndon Ong Lyndon Ong
Ciena Ciena
10480 Ridgeview Court 10480 Ridgeview Court
Cupertino, CA 95014 Cupertino, CA 95014
EMail: lyong@ciena.com EMail: lyong@ciena.com
Ian Rytina Ian Rytina
Ericsson Australia Ericsson Australia
37/360 Elizabeth Street 37/360 Elizabeth Street
skipping to change at page 103, line 37 skipping to change at page 103, line 12
Plano, TX, USA 75093 Plano, TX, USA 75093
EMail: bidulock@openss7.org EMail: bidulock@openss7.org
John Loughney John Loughney
Nokia Research Center Nokia Research Center
PO Box 407 PO Box 407
FIN-00045 Nokia Group FIN-00045 Nokia Group
Finland Finland
EMail: john.loughney@nokia.com EMail: john.loughney@nokia.com
This draft expires April 2002. This draft expires May 2002.
Appendix A
A.1 Signalling Network Architecture
A Signalling Gateway is used to support the transport of MTP3-User
signalling traffic received from the SS7 network to multiple
distributed ASPs (e.g., MGCs and IP Databases). Clearly, the M3UA
protocol is not designed to meet the performance and reliability
requirements for such transport by itself. However, the conjunction
of distributed architecture and redundant networks provides support
for reliable transport of signalling traffic over IP. The M3UA
protocol is flexible enough to allow its operation and management
in a variety of physical configurations, enabling Network Operators
to meet their performance and reliability requirements.
To meet the stringent SS7 signalling reliability and performance
requirements for carrier grade networks, Network Operators might require
that no single point of failure is present in the end-to-end
network architecture between an SS7 node and an IP-based application.
This can typically be achieved through the use of redundant SGPs or
SGs, redundant hosts, and the provision of redundant QOS-bounded IP
network paths for SCTP Associations between SCTP End Points. Obviously,
the reliability of the SG, the MGC and other IP-based functional
elements also needs to be taken into account. The distribution of ASPs
and SGPs within the available Hosts MAY also be considered. As an
example, for a particular Application Server, the related ASPs could
be distributed over at least two Hosts.
One example of a physical network architecture relevant to SS7 carrier-
grade operation in the IP network domain is shown in Figure 1 below:
SGs MGCs
Host#1 ************** ************** Host#3
* ********__*__________________________*__******** * =
* *SGP1.1*__*_____ _______________*__* ASP1 * * MGC1
* ******** * \ / * ******** *
* ********__*______\__/________________*__******** *
* *SGP2.1*__*_______\/______ _____*__* ASP2 * *
* ******** * /\ | | * ******** *
* : * / \ | | * : *
* ******** * / \ | | * ******** *
* * SGPn * * | | | | * * ASPn * *
* ******** * | | | | * ******** *
************** | | | | **************
| | \ /
Host#2 ************** | | \ / ************** Host#4
* ********__*_____| |______\/_______*__******** * =
* *SGP1.2*__*_________________/\_______*__* ASP1 * * MGC2
* ******** * / \ * ******** *
* ********__*_______________/ \_____*__******** *
* *SGP2.2*__*__________________________*__* ASP2 * *
* ******** * * ******** *
* : * SCTP Associations * : *
* ******** * * ******** *
* * SGPn * * * * ASPn * *
* ******** * * ******** *
************** **************
SGP1.1 and SGP1.2 are part of SG1
SGP2.1 and SGP2.2 are part of SG2
Figure 1 - Physical Model
In this model, each host MAY have many application processes. In the
case of the MGC, an ASP may provide service to one or more Application
Servers, and is identified as an SCTP end point. One or more
Signalling Gateway Processes make up a single Signalling Gateway.
This example model can also be applied to IPSP-IPSP signalling. In
this case, each IPSP MAY have its services distributed across 2 hosts
or more, and may have multiple server processes on each host.
In the example above, each signalling process (SGP, ASP or IPSP) is the
end point to more than one SCTP association, leading to more than one
other signalling processes. To support this, a signalling process must
be able to support distribution of M3UA messages to many simultaneous
active associations. This message distribution function is based on
the status of provisioned Routing Keys, the status of the signalling
routes to signalling points in the SS7 network , and the redundancy
model (active-standby, load sharing, broadcast, n+k) of the remote
signalling processes.
For carrier grade networks, the failure or isolation of a particular
signalling process should not cause stable calls or transactions to be
lost. This implies that signalling processes need, in some cases, to
share the call/transaction state or be able to pass the call state
information between each other. In the case of ASPs performing call
processing, coordination may also be required with the related Media
Gateway to transfer the MGC control for a particular trunk termination.
However, this sharing or communication of call/transaction state
information is outside the scope of this document.
This model serves as an example. M3UA imposes no restrictions as to
the exact layout of the network elements, the message distribution
algorithms and the distribution of the signalling processes. Instead,
it provides a framework and a set of messages that allow for a flexible
and scalable signalling network architecture, aiming to provide
reliability and performance.
A.2 Redundancy Models
A.2.1 Application Server Redundancy
At the SGP, an Application Server list contains active and inactive
ASPs to support ASP broadcast, loadsharing and failover procedures.
The list of ASPs within a logical Application Server is kept updated in
the SGP to reflect the active Application Server Process(es).
For example, in the network shown in Figure 1, all messages to DPC x
could be sent to ASP1 in Host3 or ASP1 in Host4. The AS list at SGP1
in Host 1 might look like the following:
Routing Key {DPC=x) - "Application Server #1"
ASP1/Host3 - State = Active
ASP1/Host4 - State = Inactive
In this "1+1" redundancy case, ASP1 in Host3 would be sent any incoming
message with DPC=x. ASP1 in Host4 would normally be brought to the
"active" state upon failure of, or loss of connectivity to, ASP1/Host1.
The AS List at SGP1 in Host1 might also be set up in loadshare mode:
Routing Key {DPC=x) - "Application Server #1"
ASP1/Host3 - State = Active
ASP1/Host4 - State = Active
In this case, both the ASPs would be sent a portion of the traffic.
For example the two ASPs could together form a database, where incoming
queries may be sent to any active ASP.
Care might need to be exercised by a Network Operator in the selection
of the routing information to be used as the Routing Key for a
particular AS.
For example, where Application Servers are defined using ranges of ISUP
CIC values, the Operator is implicitly splitting up control of the
related circuit groups. Some CIC value range assignments may interfere
with ISUP circuit group management procedures.
In the process of failover, 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. Any ASP-to-ASP
protocol to support this function is outside the scope of this
document.
A.2.2 Signalling Gateway Redundancy
Signalling Gateways MAY also be distributed over multiple hosts. Much
like the AS model, SGs may comprise one or more SG Processes (SGPs),
distributed over one or more hosts, using an active/backup or a
loadsharing model. Should an SGP lose all or partial SS7
connectivity and other SGPs exist, the SGP MUST terminate the SCTP
associations to the concerned ASPs.
It is therefore possible for an ASP to route signalling messages
destined to the SS7 network using more than one SGP. In this model, a
Signalling Gateway is deployed as a cluster of hosts acting as a single
SG. A primary/backup redundancy model is possible, where the
unavailability of the SCTP association to a primary SGP could be used
to reroute affected traffic to an alternate SGP. A loadsharing model
is possible, where the signalling messages are loadshared between
multiple SGPs. A broadcast model is also possible, where signalling
messages are sent to each active SGP in the SG. The distribution of the
MTP3-user messages over the SGPs should be done in such a way to
minimize message missequencing, as required by the SS7 User Parts.
It may also be possible for an ASP to use more than one SG to access a
specific SS7 end point, in a model that resembles an SS7 STP mated
pair. Typically, SS7 STPs are deployed in mated pairs, with traffic
loadshared between them. Other models are also possible, subject to
the limitations of the local SS7 network provisioning guidelines.
>From the perspective of the M3UA layer at an ASP, a particular SG is
capable of transferring traffic to a provisioned SS7 destination X if
an SCTP association with at least one SGP of the SG is established,
the SGP has returned an acknowledgement to the ASP to indicate that
the ASP is actively handling traffic for that destination X, the SGP
has not indicated that the destination X is inaccessible and the SGP
has not indicated MTP Restart. When an ASP is configured to use
multiple SGPs for transferring traffic to the SS7 network, the ASP
must maintain knowledge of the current capability of the SGPs to
handle traffic to destinations of interest. This information is
crucial to the overall reliability of the service, for active/backup,
loadsharing and broadcast models, in the event of failures, recovery
and maintenance activities. The ASP M3UA may also use this
information for congestion avoidance purposes. The distribution of
the MTP3-user messages over the SGPs should be done in such a way to
minimize message missequencing, as required by the SS7 User Parts.
This draft expires May 2002
 End of changes. 

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