draft-ietf-sigtran-m3ua-07.txt   draft-ietf-sigtran-m3ua-08.txt 
skipping to change at page 1, line 19 skipping to change at page 1, line 19
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
OpenSS7
Expires in six months Jul 2001 Expires in six months Jul 2001
SS7 MTP3-User Adaptation Layer (M3UA) SS7 MTP3-User Adaptation Layer (M3UA)
<draft-ietf-sigtran-m3ua-07.txt> <draft-ietf-sigtran-m3ua-08.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 4, line 40 skipping to change at page 4, line 40
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
is normally actively processing traffic. An AS is contained within a is normally actively processing traffic. Note that there is a 1:1
single Network Appearance. Note that there is a 1:1 relationship relationship between an AS and a Routing Key.
between an AS and a Routing Key.
Application Server Process (ASP) - A process instance of an Application Application Server Process (ASP) - A process instance of an Application
Server. An Application Server Process serves as an active or back-up Server. An Application Server Process serves as an active or back-up
process of an Application Server (e.g., part of a distributed virtual process of an Application Server (e.g., part of a distributed virtual
switch or database). Examples of ASPs are processes (or process switch or database). Examples of ASPs are processes (or process
instances) of MGCs, IP SCPs or IP HLRs. An ASP contains an SCTP end- instances) of MGCs, IP SCPs or IP HLRs. An ASP contains an SCTP end-
point and may be configured to process signalling traffic within more point and may be configured to process signalling traffic within more
than one Application Server. 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.
Signalling Gateway Process (SGP) - A process instance of a Signalling Signalling Gateway Process (SGP) - A process instance of a Signalling
Gateway. It serves as an active, back-up or load-sharing process of a Gateway. It serves as an active, back-up, load-sharing or broadcast
Signalling Gateway. process of a Signalling Gateway.
Signalling Gateway - An SG is a signaling agent that receives/sends SCN 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 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 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 or more unique Signalling Gateway Processes, of which one or more is
normally actively processing traffic. Where an SG contains more than normally actively processing traffic. Where an SG contains more than
one SGP, the SG is a logical entity and the contained SGPs must be one SGP, the SG is a logical entity and the contained SGPs might
coordinated into a single management view to the SS7 network and to the typically be coordinated into a single management view to the SS7
supported Application Servers. network and to the supported Application Servers.
Signalling Process - A process instance that uses M3UA to communicate Signalling Process - A process instance that uses M3UA to communicate
with other signalling process. An ASP, an SGP and an IPSP are all with other signalling processes. An ASP, an SGP and an IPSP are all
signalling processes. signalling processes.
Routing Key: A Routing Key describes a set of SS7 parameters and Routing Key: A Routing Key describes a set of SS7 parameters and
parameter values that uniquely define the range of signalling traffic parameter values that uniquely define the range of signalling traffic
to be handled by a particular Application Server. Parameters within the to be handled by a particular Application Server. Parameters within the
Routing Key cannot extend across more than a single SS7 Destination Routing Key cannot extend across more than a single Signalling Point
Point Code. Management Cluster.
Routing Context - A value that uniquely identifies a Routing Key. Routing Context - A value that uniquely identifies a Routing Key.
Routing Context values are either configured using a configuration Routing Context values are either configured using a configuration
management interface, or by using the routing key management procedures management interface, or by using the routing key management procedures
defined in this document. defined in this document.
Fail-over - The capability to re-route signalling traffic as required Fail-over - The capability to re-route 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. Fail-over also applies upon currently used Application Server Process. Fail-over 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 Signalling Point Management Cluster (SPMC) - The complete set of
Application Servers represented to the SS7 network under one specific Application Servers represented to the SS7 network under a single MTP
SS7 Point Code of one specific Network Appearance. SPMCs are used to entity (Signalling Point). SPMCs are used to aggregate the
sum the availability/congestion/User_Part status of an SS7 availability, congestion, and user part status of an MTP entity
destination point code that is distributed in the IP domain, for the (Signalling Point) that is distributed in the IP domain, for the purpose
purpose of supporting MTP3 management procedures at an SG. In some 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, cases, the SG itself may also be a member of the SPMC. In this case,
the SG availability/congestion/User_Part status must also be taken the SG availability/congestion/User_Part status should also be taken
into account when considering any supporting MTP3 management actions. into account when considering any supporting MTP3 management actions.
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 uniquely identifies an SS7 Network Appearance - The Network Appearance uniquely identifies an SS7
entity (Point Code) into an SS7 network, as presented by the SG. It is entity (Point Code) into an SS7 network, as presented by the SG. It is
used for the purposes of logically separating the signalling traffic used for the purposes of logically separating the signalling traffic
between the SG and the Application Server Processes over a common SCTP between the SG and the Application Server Processes over a common SCTP
association. This partitioning is necessary where an SG is logically association. This partitioning is necessary where an SG is logically
partitioned to appear as end node elements in multiple separate SS7 partitioned to appear as end node elements in multiple separate SS7
networks, in which case there is a separate network appearance for each networks, in which case there is a separate network appearance for each
point code in the SS7 networks. It is also necessary when an SG is point code in the SS7 networks. It is also necessary when an SG is
configured as an STP hosting multiple point codes, or when configured configured as an STP hosting multiple point codes, or when configured
as multiple end nodes within the same network, in which case each point as multiple end nodes within the same network, in which case each point
code is a separate network appearance.between the SG and the code is a separate network appearance.between the SG and the
Application Server Processes over a common SCTP Association. An Application Server Processes over a common SCTP Association. An
example is where an SG is logically partitioned to appear as an element example is where an SG is logically partitioned to appear as an element
in four separate national SS7 networks. A Network Appearance in four separate national SS7 networks. A Network Appearance
implicitly defines the SS7 Point Code(s), Network Indicator and MTP3 implicitly defines the SS7 Point Code(s), Network Indicator and MTP3
protocol type/variant/version used within a specific SS7 network protocol type/variant/version used within a separate SS7 network.
partition.
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 Layer Management - Layer Management is a nodal function that handles
the inputs and outputs between the M3UA layer and a local management the inputs and outputs between the M3UA layer and a local management
entity. entity.
Host - The computing platform that the ASP process is running on. Host - The computing platform that the process (SGP, ASP or IPSP) is
running on.
Stream - A stream refers to an SCTP stream; a uni-directional logical Stream - A stream refers to an SCTP stream; a uni-directional 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 un-ordered delivery service. except for those submitted to the un-ordered 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 layer, in SS7 any protocol layer that is identified to the MTP Level 3 as an MTP User.
terms, as a user part. The list of these protocol layers include, but The list of these protocol layers include, but is not limited to, ISDN
is not limited to, ISDN User Part (ISUP) [2,3,4], Signalling Connection User Part (ISUP) [2,3,4], Signalling Connection Control Part (SCCP)
Control Part (SCCP) [5,6,7] and Telephone User Part (TUP) [8]. TCAP [5,6,7] and Telephone User Part (TUP) [8]. TCAP [9,10,11] or RANAP [12]
[9,10,11] or RANAP [12] messages are transferred transparently by the messages are transferred transparently by the M3UA protocol as SCCP
M3UA protocol as SCCP payload, as they are SCCP-User protocols. 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:
- Explicit packet-oriented delivery (not stream-oriented), - Explicit packet-oriented delivery (not stream-oriented),
- Sequenced delivery of user messages within multiple streams, - Sequenced delivery of user messages within multiple streams,
with an option for order-of-arrival delivery of individual with an option for order-of-arrival delivery of individual
user messages, user messages,
skipping to change at page 7, line 49 skipping to change at page 7, line 49
The M3UA Layer at an ASP or IPSP provides the equivalent set of The M3UA Layer at an ASP or IPSP provides the equivalent set of
primitives at its upper layer to the MTP3-Users as provided by the MTP primitives at its upper layer to the MTP3-Users as provided by the MTP
Level 3 to its local MTP3-Users at an SS7 SEP. In this way, the ISUP Level 3 to its local MTP3-Users at an SS7 SEP. In this way, the ISUP
and/or SCCP layer at an ASP or IPSP is unaware that the expected MTP3 and/or SCCP layer at an ASP or IPSP is unaware that the expected MTP3
services are offered remotely from an MTP3 Layer at an SGP, and not by services are offered remotely from an MTP3 Layer at an SGP, and not by
a local MTP3 layer. The MTP3 layer at an SGP may also be unaware that a local MTP3 layer. The MTP3 layer at an SGP may also be unaware that
its local users are actually remote user parts over M3UA. In effect, its local users are actually remote user parts over M3UA. In effect,
the M3UA extends access to the MTP3 layer services to a remote IP-based the M3UA extends access to the MTP3 layer services to a remote IP-based
application. The M3UA layer does not itself provide the MTP3 services. application. The M3UA layer does not itself provide the MTP3 services.
However, in the case where an ASP is connected to more than one SGP, However, in the case where an ASP is connected to more than one SGP,
the the M3UA layer at an ASP should maintain the status of configured SS7
M3UA layer at an ASP must maintain the status of configured SS7
destinations and route messages according to the availability and destinations and route messages according to the availability and
congestion status of the routes to these destinations via each SGP. congestion status of the routes to these destinations via each SGP.
The M3UA layer may also be used for point-to-point signalling between The M3UA layer may also be used for point-to-point signalling between
two IP Server Processes (IPSPs). In this case, the M3UA layer provides two IP Server Processes (IPSPs). In this case, the M3UA layer provides
the same set of primitives and services at its upper layer as the MTP3. the same set of primitives and services at its upper layer as the MTP3.
However, in this case the expected MTP3 services are not offered However, in this case the expected MTP3 services are not offered
remotely from an SGP. The MTP3 services are provided but the remotely from an SGP. The MTP3 services are provided but the
procedures to support these services are a subset of the MTP3 procedures to support these services are a subset of the MTP3
procedures due to the simplified point-to-point nature of the IPSP to procedures due to the simplified point-to-point nature of the IPSP to
IPSP relationship. IPSP relationship.
1.3.2.1 Support for the Transport of MTP3-User Messages 1.3.2.1 Support for the Transport of MTP3-User Messages
The M3UA layer provides the transport of MTP-TRANSFER primitives across The M3UA layer provides the transport of MTP-TRANSFER primitives across
an established SCTP association between an SGP and an ASP or between an established SCTP association between an SGP and an ASP or between
IPSPs. IPSPs.
The MTP-TRANSFER primitive information is encoded as in MTP3-User The MTP-TRANSFER primitive information is encoded as in MTP3-User
messages. In this way, the SCCP and ISUP messages received from the messages. In this way, the User Part messages received from the
SS7 network by the SGP are not re-encoded into a different format for SS7 network by the SGP are not re-encoded into a different format for
transport between the M3UA peers. The MTP3 Service Information Octet transport between the M3UA peers. The MTP3 Service Information Octet
(SIO) and Routing Label (OPC, DPC, and SLS) are included, encoded as (SIO) and Routing Label (OPC, DPC, and SLS) are included, encoded as
expected by the MTP3 and MTP3-User protocol layer. expected by the MTP3 and MTP3-User protocol layer.
At an ASP, in the case where a destination is reachable via multiple At an ASP, in the case where a destination is reachable via multiple
SGPs, the M3UA layer must also choose via which SGP the message is to SGPs, the M3UA layer must also choose via which SGP the message is to
be routed or support load balancing across the SGPs, ensuring that no be routed or support load balancing across the SGPs, ensuring that no
missequencing occurs. missequencing occurs.
The M3UA layer does not impose a 272-octet signalling information field The M3UA layer does not impose a 272-octet signalling information field
(SIF) length limit as specified by the SS7 MTP Level 2 protocol [14] (SIF) length limit as specified by the SS7 MTP Level 2 protocol [14]
[15] [16]. Larger information blocks can be accommodated directly by [15] [16]. Larger information blocks can be accommodated directly by
M3UA/SCTP, without the need for an upper layer segmentation/re-assembly M3UA/SCTP, without the need for an upper layer segmentation/re-assembly
procedure as specified in recent SCCP or ISUP versions. However, in procedure as specified in recent SCCP or ISUP versions. However, in
the context of an SG, the maximum 272-octet block size must be followed the context of an SG, the maximum 272-octet block size must be followed
when inter-working to a SS7 network that does not support the transfer when inter-working to a SS7 network that does not support the transfer
of larger information blocks to the final destination. This avoids of larger information blocks to the final destination. This avoids
potential ISUP or SCCP fragmentation requirements at the SGPs. potential ISUP or SCCP fragmentation requirements at the SGPs.
However, if the SS7 network is provisioned to support the Broadband MTP However, if the SS7 network is provisioned to support the Broadband MTP
[20] to the final SS7 destination, the information block size limit may [20] to the final SS7 destination, the information block size limit MAY
be increased past 272 octets. be increased past 272 octets.
1.3.2.2 Native Management Functions 1.3.2.2 Native Management Functions
The M3UA layer provides management of the underlying SCTP transport
protocol to ensure that SGP-ASP and IPSP-IPSP transport is available to
the degree called for by the MTP3-User signalling applications.
The M3UA layer provides the capability to indicate errors associated The M3UA layer provides the capability to indicate errors associated
with received M3UA messages and to notify, as appropriate, local with received M3UA messages and to notify, as appropriate, local
management and/or the peer M3UA. management and/or the peer M3UA.
1.3.2.3 Inter-working with MTP3 Network Management Functions 1.3.2.3 Inter-working with MTP3 Network Management Functions
At the SGP, the M3UA layer must also provide inter-working with MTP3 At the SGP, the M3UA layer must also provide inter-working with MTP3
management functions to support seamless operation of the user SCN management functions to support seamless operation of the user SCN
signalling applications in the SS7 and IP domains. This includes: signalling applications in the SS7 and IP domains. This includes:
- Providing an indication to MTP3-Users at an ASP that a remote - Providing an indication to MTP3-Users at an ASP that a destination
destination in the SS7 network is not reachable. in the SS7 network is not reachable.
- Providing an indication to MTP3-Users at an ASP that a remote - Providing an indication to MTP3-Users at an ASP that a destination
destination in the SS7 network is now reachable. in the SS7 network is now reachable.
- Providing an indication to MTP3-Users at an ASP that messages to a - Providing an indication to MTP3-Users at an ASP that messages to a
remote destination in the SS7 network are experiencing SS7 destination in the SS7 network are experiencing SS7 congestion.
congestion.
- Providing an indication to the M3UA layer at an ASP that the routes - Providing an indication to the M3UA layer at an ASP that the routes
to a remote destination in the SS7 network are restricted. to a destination in the SS7 network are restricted.
- Providing an indication to MTP3-Users at an ASP that a remote MTP3- - Providing an indication to MTP3-Users at an ASP that a MTP3-User
User peer is unavailable. peer is unavailable.
The M3UA layer at an ASP may initiate an audit of the availability, the The M3UA layer at an ASP keeps the state of the routes to remote SS7
destinations and may initiate an audit of the availability, the
restricted or the congested state of remote SS7 destinations. This restricted or the congested state of remote SS7 destinations. This
information is requested from the M3UA layer at the SGP. information is requested from the M3UA layer at the SGP.
The M3UA layer at an ASP may also indicate to the SG that the M3UA The M3UA layer at an ASP may also indicate to the SG that the M3UA
layer itself or the ASP or the ASP's Host is congested. layer itself or the ASP or the ASP's Host is congested.
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, in order 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 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 knowledge 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
management of the reason for the release of an SCTP association, management of the reason for the release of an SCTP association,
determined either locally within the M3UA layer or by a primitive from determined either locally within the M3UA layer or by a primitive from
the SCTP. the SCTP.
Also the M3UA layer MAY inform the local management of the change in Also the M3UA layer MAY inform the local management of the change in
status of an ASP or AS. This may be achieved using the M-ASP_request status of an ASP or AS. This MAY be achieved using the M-ASP_STATUS
or M-AS_STATUS request primitives. request or M-AS_STATUS request primitives.
1.3.2.5 Support for the Management of Connections to Multiple SGPs 1.3.2.5 Support for the Management of Connections to Multiple SGPs
As shown in Figure 1 an ASP may be connected to multiple SGPs. In such As shown in Figure 1 an ASP may be connected to multiple SGPs. In such
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, i.e., via more than one route. As MTP3 users only maintain status SGP, i.e., via more than one route. As MTP3 users only maintain status
on a destination and not on a route basis, the M3UA layer must maintain on a destination and not on a route basis, the M3UA layer must maintain
the status (availability, restriction, and/or congestion of route to the status (availability, restriction, and/or congestion of route to
destination) of the individual routes, derive the overall availability destination) of the individual routes, derive the overall availability
or congestion status of the destination from the status of the or congestion status of the destination from the status of the
skipping to change at page 10, line 48 skipping to change at page 10, line 48
To meet the stringent SS7 signalling reliability and performance To meet the stringent SS7 signalling reliability and performance
requirements for carrier grade networks, Network Operators SHOULD requirements for carrier grade networks, Network Operators SHOULD
ensure that no single point of failure is present in the end-to-end 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. network architecture between an SS7 node and an IP-based application.
This can typically be achieved through the use of redundant SGPs or This can typically be achieved through the use of redundant SGPs or
SGs, redundant hosts, and the provision of redundant QOS-bounded IP SGs, redundant hosts, and the provision of redundant QOS-bounded IP
network paths for SCTP Associations between SCTP End Points. Obviously, network paths for SCTP Associations between SCTP End Points. Obviously,
the reliability of the SG, the MGC and other IP-based functional the reliability of the SG, the MGC and other IP-based functional
elements also needs to be taken into account. The distribution of ASPs elements also needs to be taken into account. The distribution of ASPs
and SGPs within the available Hosts SHOULD also be considered. As an and SGPs within the available Hosts MAY also be considered. As an
example, for a particular Application Server, the related ASPs SHOULD example, for a particular Application Server, the related ASPs SHOULD
be distributed over at least two Hosts. be distributed over at least two Hosts.
One example of a physical network architecture relevant to SS7 carrier- One example of a physical network architecture relevant to SS7 carrier-
grade operation in the IP network domain is shown in Figure 1 below: grade operation in the IP network domain is shown in Figure 1 below:
SG MGC SG MGC
Host#1 ************** ************** Host#3 Host#1 ************** ************** Host#3
= * ********__*__________________________*__******** * = = * ********__*__________________________*__******** * =
skipping to change at page 11, line 35 skipping to change at page 11, line 35
* * SGP2 *__*__________________________*__* ASP2 * * * * SGP2 *__*__________________________*__* ASP2 * *
* ******** * * ******** * * ******** * * ******** *
* : * SCTP Associations * : * * : * SCTP Associations * : *
* ******** * * ******** * * ******** * * ******** *
* * SGPn * * * * ASPn * * * * SGPn * * * * ASPn * *
* ******** * * ******** * * ******** * * ******** *
************** ************** ************** **************
Figure 1 - Physical Model Figure 1 - Physical Model
In this model, each host has many application processes. In the case In this model, each host MAY have many application processes. In the
of the MGC, an ASP may provide service to one or more Application case of the MGC, an ASP may provide service to one or more Application
Servers, and is identified as an SCTP end point. A pair of signalling Servers, and is identified as an SCTP end point. A pair of Signalling
gateway processes may represent, as an example, a single Signalling Gateway Processes MAY represent, as an example, a single Signalling
Gateway, serving a signalling point management cluster. Gateway, serving a signalling point management cluster.
This example model can also be applied to IPSP-IPSP signalling. In This example model can also be applied to IPSP-IPSP signalling. In
this case, each IPSP would have its services distributed across 2 hosts this case, each IPSP MAY have its services distributed across 2 hosts
or more, and may have multiple server processes on each host. or more, and may have multiple server processes on each host.
In the example above, each signalling process (SGP, ASP or IPSP) is the In the example above, each signalling process (SGP, ASP or IPSP) is the
end point to more than one SCTP association, leading to many other end point to more than one SCTP association, leading to more than one
signalling processes. To support this, a signalling process must be other signalling processes. To support this, a signalling process must
able to support distribution of M3UA messages to many simultaneous be able to support distribution of M3UA messages to many simultaneous
active associations. This message distribution function is based on active associations. This message distribution function is based on
the status of provisioned routing keys, the availability of signalling the status of provisioned Routing Keys, the status of the signalling
points in the SS7 network, and the redundancy model (active-standby, routes to signalling points in the SS7 network , and the redundancy
load-sharing, n+k) of the remote signalling processes. model (active-standby, load-sharing, broadcast, n+k) of the remote
signalling processes.
For carrier grade networks, the failure or isolation of a particular For carrier grade networks, the failure or isolation of a particular
signalling process SHOULD NOT cause stable calls or transactions to be signalling process should not cause stable calls or transactions to be
lost. This implies that signalling processes need, in some cases, to lost. This implies that signalling processes need, in some cases, to
share the call/transaction state or be able to pass the call state share the call/transaction state or be able to pass the call state
information between each other. In the case of ASPs performing call information between each other. In the case of ASPs performing call
processing, coordination may also be required with the related Media processing, coordination may also be required with the related Media
Gateway to transfer the MGC control for a particular trunk termination. Gateway to transfer the MGC control for a particular trunk termination.
However, this sharing or communication of call/transaction state However, this sharing or communication of call/transaction state
information is outside the scope of this document. information is outside the scope of this document.
This model serves as an example. M3UA imposes no restrictions as to This model serves as an example. M3UA imposes no restrictions as to
the exact layout of the network elements, the message distribution the exact layout of the network elements, the message distribution
skipping to change at page 12, line 30 skipping to change at page 12, line 30
reliability and performance. 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 used for MTP3 Management purposes. The SG Point Code might also be used for
addressing any local MTP3-Users at the SG such as an SG-resident SCCP addressing any local MTP3-Users at the SG such as an SG-resident SCCP
function. function.
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 must 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. Re-routing of traffic between the SGPs SHOULD also be supported SGPs. Re-routing of traffic between the SGPs SHOULD also be supported.
The M3UA places no restrictions on the SS7 Point Code representation of Application Servers can be represented under the same Point
an AS. 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) should 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 these SGs to be viewed from the SS7 network as "STPs", each This allows, for example, these SGs to be viewed from the SS7 network 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 re-routing through an alternate SG without network, allowing simple SS7 re-routing 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 an AS can be reached via more than one SGP it is equally Where an AS can be reached via more than one SGP the corresponding
important that the corresponding Routing Keys in the involved SGPs are Routing Keys in the involved SGPs should be identical. (Note: It is
identical. (Note: It is possible for the SGP Routing Key configuration possible for the SGP Routing Key configuration data to be temporarily
data to be temporarily out-of-synch during configuration updates). out-of-synch 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 +--------------+
| "STP" | | "STP" |
+--------+ +--------+
* Note:. SG-to SG communication is recommended for carrier grade * Note:. SG-to -SG communication is recommended for carrier grade
networks, using an MTP3 linkset or an equivalent, to allow re-routing networks, using an MTP3 linkset or an equivalent, to allow re-routing
between the SGs in the event of route failures. Where SGPs are used, between the SGs in the event of route failures. Where SGPs are used,
inter-SGP communication is recommended. Inter-SGP protocol is outside inter-SGP communication is recommended. Inter-SGP protocol is outside
of the scope of this document. of the scope of this document.
The following example shows a signalling gateway partitioned into two The following example shows a signalling gateway partitioned into two
network appearances. network appearances.
SG SG
+-------+ +---------------+ +-------+ +---------------+
skipping to change at page 14, line 13 skipping to change at page 14, line 13
Contexts. A Routing Key is essentially a set of SS7 parameters used to Contexts. A Routing Key is essentially a set of SS7 parameters used to
filter SS7 messages, whereas the Routing Context parameter is a 4-byte filter SS7 messages, whereas the Routing Context parameter is a 4-byte
value (integer) that is associated to that Routing Key in a 1:1 value (integer) that is associated to that Routing Key in a 1:1
relationship. The Routing Context therefore can be viewed as an index relationship. The Routing Context therefore can be viewed as an index
into a sending node's Message Distribution Table containing the Routing into a sending node's Message Distribution Table containing the Routing
Key entries. Key entries.
Possible SS7 address/routing information that comprise a Routing Key Possible SS7 address/routing information that comprise a Routing Key
entry includes, for example, the OPC, DPC, SIO found in the MTP3 entry includes, for example, the OPC, DPC, SIO found in the MTP3
routing label, or MTP3-User specific fields such as the ISUP CIC, SCCP routing label, or MTP3-User specific fields (such as the ISUP CIC, SCCP
subsystem number, or TCAP transaction ID. Some example Routing Keys subsystem number) or TCAP transaction ID. Some example Routing Keys
are: the DPC alone, the DPC/OPC combination, the DPC/OPC/CIC are: the DPC alone, the DPC/OPC combination, the DPC/OPC/CIC
combination, or the DPC/SSN combination. The particular information combination, or the DPC/SSN combination. The particular information
used to define an M3UA Routing Key is application and network used to define an M3UA Routing Key is application and network
dependent, and none of the above examples are mandated. dependent, and none of the above examples are mandated.
An Application Server Process may be configured to process signalling An Application Server Process may be configured to process signalling
traffic related to more than one Application Server, over a single SCTP traffic related to more than one Application Server, over a single SCTP
Association. In ASP Active and ASP Inactive management messages, the Association. In ASP Active and ASP Inactive management messages, the
signalling traffic to be started or stopped is discriminated by the signalling traffic to be started or stopped is discriminated by the
Routing Context parameter. At an ASP, the Routing Context parameter Routing Context parameter. At an ASP, the Routing Context parameter
uniquely identifies the range of signalling traffic associated with uniquely identifies the range of signalling traffic associated with
each Application Server that the ASP is each Application Server that the ASP is configured to receive.
configured to receive.
1.4.2.2 Routing Key Limitations 1.4.2.2 Routing Key Limitations
Routing Keys SHOULD be unique in the sense that each received SS7 Routing Keys SHOULD be unique in the sense that each received SS7
signalling message SHOULD have a single routing result to an signalling message SHOULD have a full or partial match to a single
Application Server. It is not necessary for the parameter range values routing result to an Application Server. It is not necessary for the
within a particular Routing Key to be contiguous. For example, an AS parameter range values within a particular Routing Key to be contiguous.
could be configured to support call processing for multiple ranges of For example, an AS could be configured to support call processing for
PSTN trunks that are not represented by contiguous CIC values. multiple ranges of PSTN trunks that are not represented by contiguous
CIC values.
1.4.2.3 Managing Routing Contexts and Routing Keys 1.4.2.3 Managing Routing Contexts and Routing Keys
There are two ways to provision a Routing Key at an SGP. A There are two ways to provision a Routing Key at an SGP. A
Routing Key may be configured statically using an implementation Routing Key may be configured statically using an implementation
dependent management interface, or dynamically using the M3UA Routing dependent management interface, or dynamically using the M3UA Routing
Key registration procedure. A Routing Key may also be configured using Key registration procedure.
the M3UA dynamic registration/deregistration procedures defined in this
document. An M3UA element must implement at least one method of
Routing Key provisioning.
When using a management interface to configure Routing Keys, the When using a management interface to configure Routing Keys, the
message distribution function within the SGP is not limited to the set message distribution function within the SGP is not limited to the set
of parameters defined in this document. Other implementation dependent of parameters defined in this document. Other implementation dependent
distribution algorithms may be used. distribution algorithms may be used.
1.4.2.4 Message Distribution at the SGP 1.4.2.4 Message Distribution at the SGP
In order to direct messages received from the SS7 MTP3 network to the To direct messages received from the SS7 MTP3 network to the
appropriate IP destination, the SGP must perform a message distribution appropriate IP destination, the SGP must perform a message distribution
function using information from the received MTP3-User message. function using information from the received MTP3-User message.
To support this message distribution, the SGP must maintain the To support this message distribution, the SGP might, for example,
equivalent of a network address translation table, mapping incoming SS7 maintain the equivalent of a network address translation table, mapping
message information to an Application Server for a particular incoming SS7 message information to an Application Server for a
application and range of traffic. This is accomplished by comparing particular application and range of traffic. This could be accomplished
elements of the incoming SS7 message to currently defined Routing Keys by comparing elements of the incoming SS7 message to currently defined
in the SGP. These Routing Keys in turn make reference to an Routing Keys in the SGP. These Routing Keys could in turn map directly
Application Server that is enabled by one or more ASPs. These ASPs to an Application Server that is enabled by one or more ASPs. These
provide dynamic status information on their availability, traffic ASPs provide dynamic status information regarding their availability,
handling capability and congestion to the SGP using various management traffic handling capability and congestion to the SGP using various
messages defined in the M3UA protocol. management messages defined in the M3UA protocol.
The list of ASPs in an AS is assumed to be dynamic, taking into account The list of ASPs in an AS is assumed to be dynamic, taking into account
the availability, traffic handling capability and congestion status of the availability, traffic handling capability and congestion status of
the individual ASPs in the list, as well as configuration changes and the individual ASPs in the list, as well as configuration changes and
possible fail-over mechanisms. possible fail-over mechanisms.
Normally, one or more ASPs are active in the AS (i.e., currently Normally, one or more ASPs are active (i.e., currently processing
processing traffic) but in certain failure and transition cases it is traffic) in the AS but in certain failure and transition cases it is
possible that there may be no active ASP available. Both load-sharing possible that there may be no active ASP available. Broadcast, load-
and backup scenarios are supported. sharing and backup scenarios are supported.
When there is no matching Routing Key entry for an incoming SS7 When there is no matching Routing Key entry for an incoming SS7
message, a default treatment SHOULD be specified. Possible solutions message, a default treatment MAY be specified. Possible solutions are
are to provide a default Application Server at the SGP that directs all to provide a default Application Server at the SGP that directs all
unallocated traffic to a (set of) default ASP(s), or to drop the unallocated traffic to a (set of) default ASP(s), or to drop the message
message and provide a notification to layer management. The treatment and provide a notification to layer management. The treatment of
of unallocated traffic is implementation dependent. unallocated traffic is implementation dependent.
1.4.2.5 Message Distribution at the ASP 1.4.2.5 Message Distribution at the ASP
In order to direct messages to the SS7 network, the ASP must also The ASP must choose an SGP to direct a message to the SS7 network. This
perform a message distribution function in order to choose the proper is accomplished by observing the Destination Point Code (and possibly
SGP for a given message. This is accomplished by observing the other elements of the outgoing message such as the SLS value).
Destination Point Code (and possibly other elements of the outgoing
message such as the SLS value).Where more than one route (or SGP) is Implementation Note: Where more than one route (or SGP) is
possible for routing to the SS7 network, the ASP SHOULD maintain a possible for routing to the SS7 network, the ASP could, for example,
dynamic table of available SGP routes for the SS7 destinations, taking maintain a dynamic table of available SGP routes for the SS7
into account the SS7 destination availability/restricted/congestion destinations, taking into account the SS7 destination
status received from the SGP(s), the availability status of the availability/restricted/congestion status received from the SGP(s), the
individual SGPs and configuration changes and fail-over mechanisms. availability status of the individual SGPs and configuration changes and
There is, however, no M3UA messaging to manage the status of an SGP fail-over mechanisms. There is, however, no M3UA messaging to manage the
(e.g., SGP-Up/Down/Active/Inactive messaging). Whenever an SCTP status of an SGP (e.g., SGP-Up/Down/Active/Inactive messaging).
Whenever an SCTP
association to an SGP exists, the SGP is assumed to be ready for the association to an SGP exists, the SGP is assumed to be ready for the
purposes of responding to M3UA ASPSM messages. purposes of responding to M3UA ASPSM messages (Refer to Section 3).
Every SGP of one SG ASP regarding one AS provides identical SS7 Every SGP of one SG ASP regarding one AS provides identical SS7
connectivity to this ASP. connectivity to this ASP.
1.4.3 SS7 and M3UA Interworking 1.4.3 SS7 and M3UA Interworking
In the case of SS7 and M3UA inter-working, the M3UA adaptation layer is In the case of SS7 and M3UA inter-working, the M3UA adaptation layer is
designed to provide an extension of the MTP3 defined user primitives. designed to provide an extension of the MTP3 defined user primitives.
1.4.3.1 Signalling Gateway SS7 Layers 1.4.3.1 Signalling Gateway SS7 Layers
skipping to change at page 16, line 33 skipping to change at page 16, line 33
from the PSTN over a standard SS7 network interface, using the SS7 from the PSTN over a standard SS7 network interface, using the SS7
Message Transfer Part (MTP) [14,15,16] to provide reliable transport of Message Transfer Part (MTP) [14,15,16] to provide reliable transport of
the messages. the messages.
As a standard SS7 network interface, the use of MTP Level 2 signalling As a standard SS7 network interface, the use of MTP Level 2 signalling
links is not the only possibility. ATM-based High Speed Links can also links is not the only possibility. ATM-based High Speed Links can also
be used with the services of the Signalling ATM Adaptation Layer (SAAL) be used with the services of the Signalling ATM Adaptation Layer (SAAL)
[17,18]. [17,18].
Note: It is also possible for IP-based interfaces to be present, using Note: It is also possible for IP-based interfaces to be present, using
the services of the MTP2-User Adaptation Layer (M2UA) [23] or M2PA []. the services of the MTP2-User Adaptation Layer (M2UA) [26] or M2PA [27].
These may be terminated at a Signalling Transfer Point (STP) or
Signalling End Point (SEP). Using the services of MTP3, the SG may be These could be terminated at a Signalling Transfer Point (STP) or
Signalling End Point (SEP). Using the services of MTP3, the SG could be
capable of communicating with remote SS7 SEPs in a quasi-associated capable of communicating with remote SS7 SEPs in a quasi-associated
fashion, where STPs may be present in the SS7 path between the SEP and fashion, where STPs may be present in the SS7 path between the SEP and
the SG. the SG.
1.4.3.2 SS7 and M3UA Inter-Working at the SG 1.4.3.2 SS7 and M3UA Inter-Working at the SG
The SGP provides a functional inter-working of transport functions The SGP provides a functional inter-working of transport functions
between the SS7 network and the IP network by also supporting the M3UA between the SS7 network and the IP network by also supporting the M3UA
adaptation layer. It allows the transfer of MTP3-User signalling adaptation layer. It allows the transfer of MTP3-User signalling
messages to and from an IP-based Application Server Process where the messages to and from an IP-based Application Server Process where the
peer MTP3-User protocol layer exists. peer MTP3-User protocol layer exists.
The Signalling Gateway must maintain knowledge of relevant SS7 node and
Signalling Point Management Cluster (SPMC) status in their respective
domains in order to perform a seamless inter-working of the IP-based
signalling and the SS7 domains. For example, SG knowledge of the
availability and/or congestion status of the SPMC and SS7 nodes must be
maintained and disseminated in the respective networks, in order to
ensure that end-to-end operation is transparent to the communicating
SCN protocol peers at the SS7 node and ASP. Where more than one SGP
constitutes an SG, the knowledge of the SGPs must be coordinated into
an overall SG view.
For SS7 user part management, it is required that the MTP3-User For SS7 user part management, it is required that the MTP3-User
protocols at ASPs receive indications of SS7 signalling point protocols at ASPs receive indications of SS7 signalling point
availability, SS7 network congestion, and remote User Part availability, SS7 network congestion, and remote User Part
unavailability as would be expected in an SS7 SEP node. To accomplish unavailability as would be expected in an SS7 SEP node. To accomplish
this, the MTP-PAUSE, MTP-RESUME and MTP-STATUS indication primitives this, the MTP-PAUSE, MTP-RESUME and MTP-STATUS indication primitives
received at the MTP3 upper layer interface at the SG need to be received at the MTP3 upper layer interface at the SG need to be
propagated to the remote MTP3-User lower layer interface at the ASP. propagated to the remote MTP3-User lower layer interface at the ASP.
(These indication primitives are also made available to any existing
local MTP3-Users at the SG, if present.)
MTP3 management messages (such as TFPs or TFAs received from the SS7 MTP3 management messages (such as TFPs or TFAs received from the SS7
network) MUST NOT be encapsulated as Data message Payload Data and sent network) MUST NOT be encapsulated as Data message Payload Data and sent
either from SG to ASP or from ASP to SG. The SG MUST terminate these either from SG to ASP or from ASP to SG. The SG MUST terminate these
messages and generate M3UA messages as appropriate. messages and generate M3UA messages as appropriate.
1.4.3.3 Application Server 1.4.3.3 Application Server
A cluster of application servers is responsible for providing the A cluster of application servers is responsible for providing the
overall support for one or more SS7 upper layers. From an SS7 overall support for one or more SS7 upper layers. From an SS7
standpoint, a Signalling Point Management Cluster (SPMC) provides standpoint, a Signalling Point Management Cluster (SPMC) provides
complete support for the upper layer service for a given point code. complete support for the upper layer service for a given point code.
As an example, an SPMC providing MGC capabilities must provide complete As an example, an SPMC providing MGC capabilities could provide complete
support for ISUP (and any other MTP3 user located at the point code of support for ISUP (and any other MTP3 user located at the point code of
the SPMC) for a given point code, according to the local SS7 network the SPMC) for a given point code.
specifications.
This measure is necessary to allow the SG to accurately represent the
signalling point on the local SS7 network.
In the case where an ASP is connected to more than one SGP, the M3UA In the case where an ASP is connected to more than one SGP, the M3UA
layer must maintain the status of configured SS7 destinations and route layer must maintain the status of configured SS7 destinations and route
messages according to availability/congestion/restricted status of the messages according to availability/congestion/restricted status of the
routes to these SS7 destinations. routes to these SS7 destinations.
1.4.3.4 IPSP Considerations 1.4.3.4 IPSP Considerations
Since IPSPs use M3UA in a point-to-point fashion, there is no concept Since IPSPs use M3UA in a point-to-point fashion, there is no concept
of routing of messages beyond the remote end. Therefore, SS7 and M3UA of routing of messages beyond the remote end. Therefore, SS7 and M3UA
inter-working is not necessary for this model. inter-working is not necessary for this model.
1.4.4 Redundancy Models 1.4.4 Redundancy Models
The network address translation and mapping function of the M3UA layer
supports signalling process fail-over functions in order to support a
high availability of call and transaction processing capability.
1.4.4.1 Application Server Redundancy 1.4.4.1 Application Server Redundancy
All MTP3-User messages (e.g., ISUP, SCCP) incoming to an SG from the All MTP3-User messages (e.g., ISUP, SCCP) which match a provisioned
SS7 network are assigned to a unique Application Server, based on the Routing Key at an SGP are mapped to an Application Server.
information in the message and the provisioned Routing Keys.
The Application Server is, in practical terms, a list of all ASPs The Application Server is the set of all ASPs associated with a specific
configured to process a range of MTP3-User traffic defined by one Routing Key. Each ASP in this set may be active inactive or unavailable.
Routing Key. One or more ASPs in the list are normally active (i.e., Active ASPs handle traffic; inactive ASPs might be used when active ASPs
handling traffic) while any others may be unavailable or inactive, to become unavailable.
be possibly used in the event of failure or unavailability of the
active ASP(s).
The fail-over model supports an "n+k" redundancy model, where "n" ASPs The fail-over model supports an "n+k" redundancy model, where "n" ASPs
is the minimum number of redundant ASPs required to handle traffic and 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/back-up redundancy is a subset of this model. A simplex "1+1" active/back-up 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 At the SGP, an Application Server list contains active and inactive
ASPs to support ASP load-sharing and fail-over procedures. The list of ASPs to support ASP broadcast, load-sharing and fail-over procedures.
ASPs within a logical Application Server is kept updated in the SGP to The list of ASPs within a logical Application Server is kept updated in
reflect the active Application Server Process(es). the SGP to reflect the active Application Server Process(es).
To avoid a single point of failure, it is recommended that a minimum of For example, in the network shown in Figure 1, all messages to DPC x
two ASPs be in the list, resident in separate hosts and therefore could be sent to ASP1 in Host3 or ASP1 in Host4. The AS list at SGP1 in
available over different SCTP Associations. For example, in the Host 1 might look like the following:
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" Routing Key {DPC=x) - "Application Server #1"
ASP1/Host3 - State = Active ASP1/Host3 - State = Active
ASP1/Host3 - State = Inactive ASP1/Host4 - State = Inactive
In this "1+1" redundancy case, ASP1 in Host3 would be sent any incoming 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 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. "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 load-share mode: The AS List at SGP1 in Host1 might also be set up in load-share mode:
Routing Key {DPC=x) - "Application Server #1" Routing Key {DPC=x) - "Application Server #1"
ASP1/Host3 - State = Active ASP1/Host3 - State = Active
ASP1/Host4 - State = Active ASP1/Host4 - State = Active
In this case, both the ASPs would be sent a portion of the traffic. 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 For example the two ASPs could together form a database, where incoming
queries may be sent to any active ASP. queries may be sent to any active ASP.
Care must be exercised by a Network Operator in the selection of the Care might need to be exercised by a Network Operator in the selection
routing information to be used as the Routing Key for a particular AS. 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 For example, where Application Servers are defined using ranges of ISUP
CIC values, the Operator is implicitly splitting up control of the CIC values, the Operator is implicitly splitting up control of the
related circuit groups. Some CIC value range assignments may interfere related circuit groups. Some CIC value range assignments may interfere
with ISUP circuit group management procedures. with ISUP circuit group management procedures.
In the process of fail-over, it is recommended that in the case of ASPs In the process of fail-over, it is recommended that in the case of ASPs
supporting call processing, stable calls do not fail. It is possible supporting call processing, stable calls do not fail. It is possible
that calls in "transition" MAY fail, although measures of communication that calls in "transition" MAY fail, although measures of communication
between the ASPs involved can be used to mitigate this. For example, between the ASPs involved can be used to mitigate this. For example,
skipping to change at page 19, line 26 skipping to change at page 19, line 26
protocol to support this function is outside the scope of this protocol to support this function is outside the scope of this
document. document.
1.4.4.2 Signalling Gateway Redundancy 1.4.4.2 Signalling Gateway Redundancy
Signalling Gateways MAY also be distributed over multiple hosts. Much Signalling Gateways MAY also be distributed over multiple hosts. Much
like the AS model, SGs may comprise one or more SG Processes (SGPs), like the AS model, SGs may comprise one or more SG Processes (SGPs),
distributed over one or more hosts, using an active/back-up or a load- distributed over one or more hosts, using an active/back-up or a load-
sharing model. Also, every SGP within an SG communicating with an ASP sharing model. Also, every SGP within an SG communicating with an ASP
provides identical SS7 connectivity to this ASP. Should an SGP lose all provides identical SS7 connectivity to this ASP. Should an SGP lose all
or partial SS7 connectivity and other SGPs exist, the SGP SHOULD or partial SS7 connectivity and other SGPs exist, the SGP MUST
terminate the SCTP associations to the concerned ASPs. terminate the SCTP associations to the concerned ASPs.
It is therefore possible for an ASP to route signalling messages 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 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 Signalling Gateway is deployed as a cluster of hosts acting as a single
SG. A primary/back-up redundancy model is possible, where the SG. A primary/back-up redundancy model is possible, where the
unavailability of the SCTP association to a primary SGP could be used unavailability of the SCTP association to a primary SGP could be used
to reroute affected traffic to an alternate SGP. A load-sharing model to reroute affected traffic to an alternate SGP. A load-sharing model
is possible, where the signalling messages are load-shared between is possible, where the signalling messages are load-shared between
multiple SGPs. The distribution of the MTP3-user messages over the multiple SGPs. A broadcast model is also possible, where signalling
SGPs should be done in such a way to minimize message mis-sequencing, messages are sent to each active SGP in the SG. The distribution of the
as required by the SS7 User Parts. MTP3-user messages over the SGPs should be done in such a way to
minimize message mis-sequencing, as required by the SS7 User Parts.
It may also be possible for an ASP to use more than one SG to access a 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 specific SS7 end point, in a model that resembles an SS7 STP mated
pair. Typically, SS7 STPs are deployed in mated pairs, with traffic pair. Typically, SS7 STPs are deployed in mated pairs, with traffic
load-shared between them. Other models are also possible, subject to load-shared between them. Other models are also possible, subject to
the limitations of the local SS7 network provisioning guidelines. the limitations of the local SS7 network provisioning guidelines.
>From the perspective of the M3UA layer at an ASP, a particular SG is >From the perspective of the M3UA layer at an ASP, a particular SG is
capable of transferring traffic to an SS7 destination if an SCTP capable of transferring traffic to an SS7 destination if an SCTP
association with at least one SGP of the SG is established, the SGP has 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 returned an acknowledgement to the ASP to indicate that the ASP is
actively handling traffic for that destination, and the SGP has not actively handling traffic for that destination, and the SGP has not
indicated that the destination is inaccessible. When an ASP is indicated that the destination is inaccessible. When an ASP is
configured to use multiple SGPs for transferring traffic to the SS7 configured to use multiple SGPs for transferring traffic to the SS7
network, the ASP must maintain knowledge of the current capability of network, the ASP must maintain knowledge of the current capability of
the SGPs to handle traffic to destinations of interest. This the SGPs to handle traffic to destinations of interest. This
information is crucial to the overall reliability of the service, for information is crucial to the overall reliability of the service, for
both active/back-up and load-sharing model, in the event of failures, active/back-up, load-sharing and broadcast models, in the event of
recovery and maintenance activities. The ASP M3UA may also use this failures, recovery and maintenance activities. The ASP M3UA may also
information for congestion avoidance purposes. The distribution of the use this information for congestion avoidance purposes. The
MTP3-user messages over the SGPs should be done in such a way to distribution of the MTP3-user messages over the SGPs should be done in
minimize message mis-sequencing, as required by the SS7 User Parts. such a way to minimize message mis-sequencing, 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 in order 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
The M3UA layer is informed of local and IP network congestion by means The M3UA layer is informed of local and IP network congestion by means
of an implementation-dependent function (e.g., an implementation- of an implementation-dependent function (e.g., an implementation-
dependent indication from the SCTP of IP network congestion). dependent indication from the SCTP of IP network congestion).
skipping to change at page 20, line 35 skipping to change at page 20, line 37
Users by means of an MTP-STATUS primitive, as per current MTP3 Users by means of an MTP-STATUS primitive, as per current MTP3
procedures, to invoke appropriate upper layer responses. procedures, to invoke appropriate upper layer responses.
When an SG determines that the transport of SS7 messages to a When an SG determines that the transport of SS7 messages to a
Signalling Point Management Cluster (SPMC) is encountering congestion, Signalling Point Management Cluster (SPMC) is encountering congestion,
the SG MAY trigger SS7 MTP3 Transfer Controlled management messages the SG MAY trigger SS7 MTP3 Transfer Controlled management messages
to originating SS7 nodes, per the congestion procedures of the relevant to originating SS7 nodes, per the congestion procedures of the relevant
MTP3 standard. The triggering of SS7 MTP3 Management messages from an MTP3 standard. The triggering of SS7 MTP3 Management messages from an
SG is an implementation-dependent function. SG is an implementation-dependent function.
The M3UA layer at an ASP or IPSP should indicate local congestion to an The M3UA layer at an ASP or IPSP MAY indicate local congestion to an
M3UA peer with an SCON message. When an SG receives a congestion M3UA peer with an SCON message. When an SG receives a congestion
message (SCON) from an ASP, and the SG determines that an SPMC is now message (SCON) from an ASP, and the SG determines that an SPMC is now
encountering congestion, it MAY trigger SS7 MTP3 Transfer Controlled encountering congestion, it MAY trigger SS7 MTP3 Transfer Controlled
management messages to concerned SS7 destinations according to management messages to concerned SS7 destinations according to
congestion procedures of the relevant MTP3 standard. congestion procedures of the relevant MTP3 standard.
1.4.7 SCTP Stream Mapping. 1.4.7 SCTP Stream Mapping.
The M3UA layer at both the SGP and ASP also supports the assignment of The M3UA layer at both the SGP and ASP also supports the assignment of
signalling traffic into streams within an SCTP association. Traffic signalling traffic into streams within an SCTP association. Traffic
that requires sequencing must be assigned to the same stream. To that requires sequencing SHOULD be assigned to the same stream. To
accomplish this, MTP3-User traffic may be assigned to individual accomplish this, MTP3-User traffic may be assigned to individual
streams based on, for example, the SLS value in the MTP3 Routing Label streams based on, for example, the SLS value in the MTP3 Routing Label
or the ISUP CIC assignment, subject of course to the maximum number of or the ISUP CIC assignment, subject of course to the maximum number of
streams supported by the underlying SCTP association. streams supported by the underlying SCTP association.
The use of SCTP streams within M3UA is recommended in order to minimize
transmission and buffering delays, therefore improving the overall
performance and reliability of the signalling elements. The
distribution of the MTP3 user messages over the various streams should
be done in such a way to minimize message mis-sequencing, as required
by the SS7 User Parts.
1.4.8 Client/Server Model 1.4.8 Client/Server Model
It is recommended that the SGP and ASP be able to support both client and server It is recommended that the SGP and ASP be able to support both client
operation. The peer endpoints using M3UA SHOULD be configured so that one always and server
takes on the role of client and the other the role of server for initiating SCTP operation. The peer endpoints using M3UA SHOULD be configured so that
associations. The default orientation would be for the SGP to take on the role one always
of server while the ASP is the client. In this case, ASPs SHOULD initiate the takes on the role of client and the 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 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 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 *
******** ***************** ******** ******** ***************** ********
+------+ +------+ +------+ +---------------+ +------+
| ISUP | (NIF) | ISUP | | ISUP | | (NIF) | | ISUP |
+------+ +------+-+------+ +------+ +------+ +------+ +------+ +------+
| MTP3 | | MTP3 | | M3UA | | M3UA | | MTP3 | | MTP3 | | M3UA | | M3UA |
+------| +------+ +------+ +------+ +------| +------+-+------+ +------+
| MTP2 | | MTP2 | | SCTP | | SCTP | | MTP2 | | MTP2 | | SCTP | | SCTP |
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
| L1 | | L1 | | IP | | IP | | L1 | | L1 | | IP | | IP |
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
|_______________| |______________| |_______________| |______________|
SEP - SS7 Signalling End Point SEP - SS7 Signalling End Point
SCTP - Stream Control Transmission Protocol SCTP - Stream Control Transmission Protocol
NIF - Nodal Inter-working Function NIF - Nodal Inter-working Function
skipping to change at page 25, line 15 skipping to change at page 25, line 15
M-SCTP_RELEASE confirm M-SCTP_RELEASE confirm
Direction: M3UA -> LM Direction: M3UA -> LM
Purpose: ASP confirms to LM that it has released SCTP association Purpose: ASP confirms to LM that it has released SCTP association
with its peer. with its peer.
M-SCTP_RELEASE indication M-SCTP_RELEASE indication
Direction: M3UA -> LM Direction: M3UA -> LM
Purpose: M3UA informs LM that a remote ASP has released an SCTP Purpose: M3UA informs LM that a remote ASP has released an SCTP
Association or the SCTP association has failed. Association or the SCTP association has failed.
M-SCTP RESTART indication
Direction: M3UA -> LM
Purpose: M3UA informs LM that an SCTP restart indication has been
received.
M-SCTP_STATUS request M-SCTP_STATUS request
Direction: LM -> M3UA Direction: LM -> M3UA
Purpose: LM requests M3UA to report the status of an SCTP Purpose: LM requests M3UA to report the status of an SCTP
association. association.
M-SCTP_STATUS confirm M-SCTP_STATUS confirm
Direction: M3UA -> LM Direction: M3UA -> LM
Purpose: M3UA responds with the status of an SCTP association. Purpose: M3UA responds with the status of an SCTP association.
M-SCTP STATUS indication M-SCTP STATUS indication
skipping to change at page 31, line 30 skipping to change at page 31, line 30
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where more than one parameter is included in a message, the parameters Where more than one parameter is included in a message, the parameters
may be in any order, except where explicitly mandated. A receiver may be in any order, except where explicitly mandated. A receiver
SHOULD accept the parameters in any order. SHOULD accept the parameters in any order.
Parameter Tag: 16 bits (unsigned integer) Parameter Tag: 16 bits (unsigned integer)
The Tag field is a 16-bit identifier of the type of parameter. It The Tag field is a 16-bit identifier of the type of parameter. It
takes a value of 0 to 65534. Common parameters used by adaptation takes a value of 0 to 65534. Common parameters used by adaptation
layers are in the range of 0x00 to 0xff. M3UA-specific parameters layers are in the range of 0x00 to 0x3f. M3UA-specific parameters
have Tags in the range 0x80 to 0xbf. The parameter Tags defined are have Tags in the range 0x0200 to 0x02ff. The parameter Tags defined
as follows: are as follows:
0x00 Reserved 0x0000 Reserved
0x80 Network Appearance 0x0200 Network Appearance
0x81 Protocol Data 1 0x0201 Protocol Data 1
0x82 Protocol Data 2 0x0202 Protocol Data 2
0x04 INFO String 0x0004 INFO String
0x83 Affected Destinations 0x0203 Affected Destinations
0x06 Routing Context 0x0006 Routing Context
0x07 Diagnostic Information 0x0007 Diagnostic Information
0x09 Heartbeat Data 0x0009 Heartbeat Data
0x84 User/Cause 0x0204 User/Cause
0x0a Reason 0x000a Reason
0x0b Traffic Mode Type 0x000b Traffic Mode Type
0x0c Error Code 0x000c Error Code
0x0d Status 0x000d Status
0x85 Congestion Indications 0x000e ASP Identifier
0x86 Concerned Destination 0x0205 Congestion Indications
0x87 Routing Key 0x0206 Concerned Destination
0x88 Registration Result 0x0207 Routing Key
0x89 De-registration Result 0x0208 Registration Result
0x8a Local_Routing Key Identifier 0x0209 De-registration Result
0x8b Destination Point Code 0x020a Local_Routing Key Identifier
0x8c Service Indicators 0x020b Destination Point Code
0x8d Subsystem Numbers 0x020c Service Indicators
0x8e Originating Point Code List 0x02 Subsystem Numbers
0x8f Circuit Range 0x020e Originating Point Code List
0x90 Registration Results 0x020f Circuit Range
0x91 De-Registration Results
0x92 to ffff...Reserved by the IETF 0x0210 to 0xffff...Reserved by the IETF
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. The Parameter Length does not include any padding
skipping to change at page 33, line 10 skipping to change at page 33, line 10
DATA message contains the following variable length parameters: DATA message contains the following variable length parameters:
Network Appearance Optional Network Appearance Optional
Protocol Data 1 or 2 Mandatory Protocol Data 1 or 2 Mandatory
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 = 0x80 | Length = 8 | | Tag = 0x0200 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance | | Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x81 or 0x82 | Length | | Tag = 0x0201 or 0x0202 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ Protocol Data / / Protocol Data /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Network Appearance: 32-bits (unsigned integer) Network Appearance: 32-bits (unsigned integer)
The optional Network Appearance parameter identifies the SS7 network The optional Network Appearance parameter identifies the SS7 network
context for the message, for the purposes of logically separating context for the message, for the purposes of logically separating
the signalling traffic between the SGP and the ASP over a common the signalling traffic between the SGP and the ASP over a common
SCTP association. An example is where an SG is logically SCTP association. An example is where an SG is logically
partitioned to appear as an element in four different national SS7 partitioned to appear as an element in four different national SS7
networks. networks.
In a DATA message, the Network Appearance implicitly defines the SS7 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 SS7 network partition. 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 are context of a single SS7 network, or individual SCTP associations
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 MUST be
included. included.
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
skipping to change at page 35, line 47 skipping to change at page 35, line 47
3.4 SS7 Signalling Network Management (SSNM) Messages 3.4 SS7 Signalling Network Management (SSNM) Messages
3.4.1 Destination Unavailable (DUNA) 3.4.1 Destination Unavailable (DUNA)
The DUNA message is sent from all SGPs in an SG to all concerned ASPs The DUNA message is sent from all SGPs in an SG to all concerned ASPs
to indicate that the SG has determined that one or more SS7 to indicate that the SG has determined that one or more SS7
destinations are unreachable. It is also sent by an SGP in response to destinations are unreachable. It is also sent by an SGP in response to
a message from the ASP to an unreachable SS7 destination. As an a message from the ASP to an unreachable SS7 destination. As an
implementation option the SG may suppress the sending of subsequent implementation option the SG may suppress the sending of subsequent
"response" DUNA messages regarding a certain unreachable SS7 "response" DUNA messages regarding a certain unreachable SS7
destination for a certain period in order to give the remote side time destination for a certain period to give the remote side time
to react. The MTP3-User at the ASP is expected to stop traffic to the to react. The MTP3-User at the ASP is expected to stop traffic to the
affected destination through the SGPs initiating the DUNA message as affected destination through the SGPs initiating the DUNA message as
per the defined MTP3-User procedures. per the defined MTP3-User procedures.
The DUNA message contains the following parameters: The DUNA message contains the following parameters:
Network Appearance Optional Network Appearance Optional
Affected Destinations Mandatory Affected Destinations Mandatory
INFO String Optional INFO String Optional
The format for DUNA Message parameters is as follows: The format for DUNA Message parameters 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 = 0x80 | Length =8 | | Tag = 0x0200 | Length =8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance | | Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x83 | Length | | Tag = 0x0203 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Affected DPC 1 | | Mask | Affected DPC 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ ... / / ... /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Affected DPC n | | Mask | Affected DPC n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x04 | Length | | Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ INFO String / / INFO String /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Network Appearance: 32-bit unsigned integer Network Appearance: 32-bit unsigned integer
See Section 3.3.1 See Section 3.3.1
skipping to change at page 38, line 5 skipping to change at page 38, line 5
The Mask parameter represents a bit mask that can be applied to the The Mask parameter represents a bit mask that can be applied to the
related Affected DPC field. The bit mask identifies how many bits related Affected DPC field. The bit mask identifies how many bits
of the Affected DPC field are significant and which are effectively of the Affected DPC field are significant and which are effectively
"wildcarded". For example, a mask of "8" indicates that the least "wildcarded". For example, a mask of "8" indicates that the least
significant eight bits of the DPC is "wildcarded". For an ANSI 24- significant eight bits of the DPC is "wildcarded". For an ANSI 24-
bit Affected DPC, this is equivalent to signalling that all DPCs in bit Affected DPC, this is equivalent to signalling that all DPCs in
an ANSI Cluster are unavailable. A mask of "3" indicates that the an ANSI Cluster are unavailable. A mask of "3" indicates that the
least significant three bits of the DPC is "wildcarded". For a 14- least significant three bits of the DPC is "wildcarded". For a 14-
bit ITU Affected DPC, this is equivalent to signaling that an ITU bit ITU Affected DPC, this is equivalent to signaling that an ITU
Region is unavailable. A mask value equal to the number of bits in Region is unavailable. A mask value equal to the number of bits in
the DPC indicates that the entire network appearance is affected the DPC indicates that the entire network appearance is affected -
this is used to indicate network isolation to the ASP. this is used to indicate network isolation to the ASP.
INFO String: variable length INFO String: variable length
The optional INFO String parameter can carry any 8-bit ASCII The optional INFO String parameter can carry any 8-bit ASCII
character string along with the message. Length of the INFO character string along with the message. Length of the INFO
String parameter is from 0 to 255 characters. No procedures are String parameter is from 0 to 255 characters. No procedures are
presently identified for its use but the INFO String MAY be used by presently identified for its use but the INFO String MAY be used by
Operators to identify in text form the location reflected by the Operators to identify in text form the location reflected by the
Affected DPC for debugging purposes. Affected DPC for debugging purposes.
skipping to change at page 39, line 24 skipping to change at page 39, line 24
Affected Destinations Mandatory Affected Destinations Mandatory
Concerned Destination Optional Concerned Destination Optional
Congestion Indications Optional Congestion Indications Optional
INFO String Optional INFO String Optional
The format for SCON Message parameters is as follows: The format for SCON Message parameters 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 = 0x80 | Length =8 | | Tag = 0x0200 | Length =8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance | | Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x83 | Length | | Tag = 0x0203 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Affected DPC 1 | | Mask | Affected DPC 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ ... / / ... /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Affected DPC n | | Mask | Affected DPC n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x86 | Length | | Tag = 0x0206 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | Concerned DPC | | reserved | Concerned DPC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x85 | Length | | Tag = 0x0205 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Cong. Level | | Reserved | Cong. Level |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x04 | Length | | Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ INFO String / / INFO String /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the Network Appearance, Affected The format and description of the Network Appearance, Affected
Destinations, and INFO String parameters is the same as for the DUNA Destinations, and INFO String parameters is the same as for the DUNA
message (See Section 3.4.1). message (See Section 3.4.1).
The Affected Destinations parameter can be used to indicate congestion The Affected Destinations parameter can be used to indicate congestion
of multiple destinations or ranges of destinations. However, an SCON of multiple destinations or ranges of destinations. However, an SCON
message MUST not be delayed in order to "collect" individual congested message MUST not be delayed to "collect" individual congested
destinations into a single SCON message as any delay might affect the destinations into a single SCON message as any delay might affect the
timing of congestion indications to the M3UA Users. One use for timing of congestion indications to the M3UA Users. One use for
including a range of Congested DPCs is when the SG supports an ANSI 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 cluster route set to the SS7 network that becomes congested due to
outgoing link set congestion. 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
skipping to change at page 41, line 17 skipping to change at page 41, line 17
Network Appearance Optional Network Appearance Optional
Affected Destinations Mandatory Affected Destinations Mandatory
User/Cause Mandatory User/Cause Mandatory
INFO String Optional INFO String Optional
The format for DUPU message parameters is as follows: The format for DUPU message parameters 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 = 0x80 | Length | | Tag = 0x0200 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance | | Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x83 | Length = 8 | | Tag = 0x0203 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Affected DPC | | Mask = 0 | Affected DPC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x84 | Length = 8 | | Tag = 0x0204 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause | User | | Cause | User |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x04 | Length | | Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ INFO String / / INFO String /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
User/Cause: 32-bits User/Cause: 32-bits
The Unavailability Cause and MTP3-User Identity fields, associated The Unavailability Cause and MTP3-User Identity fields, associated
with the Affected DPC in the Affected Destinations parameter, are with the Affected DPC in the Affected Destinations parameter, are
skipping to change at page 43, line 29 skipping to change at page 43, line 29
3.5 ASP State Maintenance (ASPSM) Messages 3.5 ASP State Maintenance (ASPSM) Messages
3.5.1 ASP Up 3.5.1 ASP Up
The ASP Up message is used to indicate to a remote M3UA peer that the The ASP Up message is used to indicate to a remote M3UA peer that the
adaptation layer is ready to receive any SSNM or ASPSM/ASPTM messages adaptation layer is ready to receive any SSNM or ASPSM/ASPTM messages
for all Routing Keys that the ASP is configured to serve. for all Routing Keys that the ASP is configured to serve.
The ASP Up message contains the following parameters: The ASP Up message contains the following parameters:
ASP Identifier Optional
INFO String Optional INFO String Optional
The format for ASP Up message parameters is as follows: The format for ASP Up message parameters 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 = 0x04 | Length | | Tag = 0x000e | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ INFO String / / INFO String /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The optional ASP Identifier parameter contains a unique value that is
locally significant among the ASPs that support an AS. The SGP should
save the ASP Identifier to be used, if necessary, with the Notify
message (see Section 3.8.2).
The format and description of the optional INFO String parameter is the The format and description of the optional INFO String parameter is the
same as for the DUNA message (See Section 3.4.1). same as for the DUNA message (See Section 3.4.1).
3.5.2 ASP Up Acknowledgement (ASP Up Ack) 3.5.2 ASP Up Acknowledgement (ASP Up Ack)
The ASP UP Ack message is used to acknowledge an ASP Up message The ASP UP Ack message is used to acknowledge an ASP Up message
received from a remote M3UA peer. received from a remote M3UA peer.
The ASP Up Ack message contains the following parameters: The ASP Up Ack message contains the following parameters:
INFO String (optional) INFO String (optional)
The format for ASP Up Ack message parameters is as follows: The format for ASP Up Ack message parameters 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 =0x04 | Length | | Tag =0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ INFO String / / INFO String /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional INFO String parameter is the The format and description of the optional INFO String parameter is the
same as for the DUNA message (See Section 3.4.1). The INFO String in same as for the DUNA message (See Section 3.4.1). The INFO String in
an ASP Up Ack message is independent from the INFO String in the ASP Up an ASP Up Ack message is independent from the INFO String in the ASP Up
message (i.e., it does not have to echo back the INFO String received). message (i.e., it does not have to echo back the INFO String received).
3.5.3 ASP Down 3.5.3 ASP Down
The ASP Down message is used to indicate to a remote M3UA peer that the The ASP Down message is used to indicate to a remote M3UA peer that the
adaptation layer is NOT ready to receive DATA, SSNM or ASPTM messages. adaptation layer is NOT ready to receive DATA, SSNM, RKM or ASPTM
messages.
The ASP Down message contains the following parameters: The ASP Down message contains the following parameters:
Reason Mandatory
INFO String Optional INFO String Optional
The format for the ASP Down message parameters is as follows: The format for the ASP Down message parameters 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 = 0x0a | Length | | Tag =0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag =0x04 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ INFO String / / INFO String /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional INFO String parameter is the The format and description of the optional INFO String parameter is the
same as for the DUNA message (See Section 3.4.1). same as for the DUNA message (See Section 3.4.1).
Reason: 32-bit (unsigned integer)
The Reason parameter indicates the reason that the remote M3UA
adaptation layer is unavailable. The valid values for Reason are
shown in the following table.
0 Unspecified
1 User Unavailable
2 Management Blocking
3.5.4 ASP Down Acknowledgement (ASP Down Ack) 3.5.4 ASP Down Acknowledgement (ASP Down Ack)
The ASP Down Ack message is used to acknowledge an ASP Down message The ASP Down Ack message is used to acknowledge an ASP Down message
received from a remote M3UA peer. received from a remote M3UA peer.
The ASP Down Ack message contains the following parameters: The ASP Down Ack message contains the following parameters:
Reason Mandatory Reason Mandatory
INFO String Optional INFO String Optional
The format for the ASP Down Ack message parameters is as follows: The format for the ASP Down Ack message parameters 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 = 0x0a | Length | | Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x04 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ INFO String / / INFO String /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional INFO String parameter is the The format and description of the optional INFO String parameter is the
same as for the DUNA message (See Section 3.4.1). same as for the DUNA message (See Section 3.4.1).
The INFO String in an ASP Down Ack message is independent from the INFO The INFO String in an ASP Down Ack message is independent from the INFO
String in the ASP Down message (i.e., it does not have to echo back the String in the ASP Down message (i.e., it does not have to echo back the
INFO String received). INFO String received).
The format of the Reason parameter is the same as for the ASP-Down
message. (See Section 3.5.3).
3.5.5 Heartbeat (BEAT) 3.5.5 Heartbeat (BEAT)
The BEAT message is optionally used to ensure that the M3UA peers The BEAT message is optionally used to ensure that the M3UA peers
are still available to each other. It is recommended for use when the are still available to each other. It is recommended for use when the
M3UA runs over a transport layer other than the SCTP, which has its own M3UA runs over a transport layer other than the SCTP, which has its own
heartbeat. heartbeat.
The BEAT message contains the following parameters: The BEAT message contains the following parameters:
Heatbeat Data Optional Heatbeat Data Optional
The format for the BEAT message is as follows: The format for the BEAT 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 = 0x09 | Length | | Tag = 0x0009 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ Heartbeat Data / / Heartbeat Data /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Heartbeat Data parameter contents are defined by the sending node. The Heartbeat Data parameter contents are defined by the sending node.
The Heartbeat Data could include, for example, a Heartbeat Sequence The Heartbeat Data could include, for example, a Heartbeat Sequence
Number and/or Timestamp. The receiver of a BEAT message does not Number and/or Timestamp. The receiver of a BEAT message does not
process this field as it is only of significance to the sender. The process this field as it is only of significance to the sender. The
skipping to change at page 47, line 5 skipping to change at page 47, line 5
The REG REQ message is sent by an ASP to indicate to a remote M3UA peer The REG REQ message is sent by an ASP to indicate to a remote M3UA peer
that it wishes to register one or more given Routing Keys with the that it wishes to register one or more given Routing Keys with the
remote peer. Typically, an ASP would send this message to an SGP, and remote peer. Typically, an ASP would send this message to an SGP, and
expects to receive a REG RSP message in return with an associated expects to receive a REG RSP message in return with an associated
Routing Context value. Routing Context value.
The REG REQ message contains the following parameters: The REG REQ message contains the following parameters:
Routing Key Mandatory Routing Key Mandatory
The format for the REG REQ message is as follows: One or more Routing Key parameters MAY be included. The format for the
REG REQ 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 = 0x87 | Length | | Tag = 0x0207 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ Routing Key 1 / / Routing Key 1 /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ ... / / ... /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x87 | Length | | Tag = 0x0207 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ Routing Key n / / Routing Key n /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Routing Key: variable length Routing Key: variable length
The Routing Key parameter is mandatory. The sender of this message The Routing Key parameter is mandatory. The sender of this message
expects that the receiver of this message will create a Routing expects that the receiver of this message will create a Routing
skipping to change at page 48, line 40 skipping to change at page 48, line 40
the registration request. The Identifier value is assigned by the the registration request. The Identifier value is assigned by the
ASP, and is used to correlate the response in an REG RSP message ASP, and is used to correlate the response in an REG RSP message
with the original registration request. The Identifier value must with the original registration request. The Identifier value must
remain unique until the REG RSP message is received. remain unique until the REG RSP message is received.
The format of the Local-RK-Identifier field is as follows: The format of the Local-RK-Identifier field 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ag = 0x8a | Length = 8 | | Tag = 0x020a | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local-RK-Identifier value | | Local-RK-Identifier value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Traffic Mode Type: 32-bit (unsigned integer) Traffic Mode Type: 32-bit (unsigned integer)
The Traffic Mode Type parameter is mandatory and identifies the The Traffic Mode Type parameter is mandatory and identifies the
traffic mode of operation of the ASP(s) within an Application traffic mode of operation of the ASP(s) within an Application
Server. The valid values for Traffic Mode Type are shown in the Server. The valid values for Traffic Mode Type are shown in the
following table: following table:
1 Over-ride 1 Over-ride
2 Load-share 2 Load-share
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, 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:
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 = 0x8b | Length = 8 | | Tag = 0x020b | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Destination Point Code | | Mask = 0 | Destination Point Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Network Appearance: Network Appearance:
The optional Network Appearance parameter field identifies the SS7 The optional Network Appearance parameter field identifies the SS7
network context for the Routing Key, and has the same format as in network context for the Routing Key, and has the same format as in
the DATA message (See Section 3.3.1). The absence of the Network the DATA message (See Section 3.3.1). The absence of the Network
Appearance parameter in the Routing Key indicates the use Appearance parameter in the Routing Key indicates the use
of any Network Appearance value, Its format is: of any Network Appearance value, Its 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 = 0x80 | Length = 8 | | Tag = 0x0200 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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. An
SI value of zero is not valid in M3UA. The SI format is: SI value of zero is not valid in M3UA. 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 = 0x8c | Length | | Tag = 0x020c | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SI #1 | SI #2 | SI #3 | SI #4 | | SI #1 | SI #2 | SI #3 | SI #4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ... / / ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SI #n | 0 Padding, if necessary | | SI #n | 0 Padding, if necessary |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Subsystem Numbers (SSN): n X 8-bit integers Subsystem Numbers (SSN): n X 8-bit integers
skipping to change at page 50, line 32 skipping to change at page 50, line 32
use of any SSN value, in the case of SCCP traffic. Where an SSN use of any SSN value, in the case of SCCP traffic. Where an SSN
parameter does not contain a multiple of four SSNs, the parameter is parameter does not contain a multiple of four SSNs, the parameter is
padded out to 32-byte alignment. The subsystem number values padded out to 32-byte alignment. The subsystem number values
associated are defined by the local network operator, and typically associated are defined by the local network operator, and typically
follow ITU-T Recommendation Q.713 [5]. An SSN value of zero is not follow ITU-T Recommendation Q.713 [5]. An SSN value of zero is not
valid in M3UA. The format of this field is as follows: valid in M3UA. The format of this field 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 = 0x8d | Length | | Tag = 0x020d | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSN #1 | SSN #2 | SSN #3 | SSN #4 | | SSN #1 | SSN #2 | SSN #3 | SSN #4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ... / / ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSN #n | 0 Padding, if necessary | | SSN #n | 0 Padding, if necessary |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OPC List: OPC List:
The Originating Point Code List parameter contains one or more SS7 The Originating Point Code List parameter contains one or more SS7
OPC entries, and its format is the same as the Destination Point OPC entries, and its format is the same as the Destination Point
Code parameter. The absence of the OPC List parameter in the Code parameter. The absence of the OPC List parameter in the
Routing Key indicates the use of any OPC value, Routing Key indicates the use of any OPC value,
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 = 0x8e | Length | | Tag = 0x020e | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Origination Point Code #1 | | Mask = 0 | Origination Point Code #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Origination Point Code #2 | | Mask = 0 | Origination Point Code #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ... / / ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Origination Point Code #n | | Mask = 0 | Origination Point Code #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 51, line 37 skipping to change at page 51, line 37
the use of any Circuit Range values, in the case of ISUP/TUP the use of any Circuit Range values, in the case of ISUP/TUP
traffic. The Origination Point Code is encoded the same as the traffic. The Origination Point Code is encoded the same as the
Destination Point Code parameter, while the CIC values are 16-bit Destination Point Code parameter, while the CIC values are 16-bit
integers. integers.
The Circuit Range format is as follows: The Circuit Range format 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 = 0x8f | Length | | Tag = 0x020f | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Origination Point Code #1 | | Mask = 0 | Origination Point Code #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lower CIC Value #1 | Upper CIC Value #1 | | Lower CIC Value #1 | Upper CIC Value #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Origination Point Code #2 | | Mask = 0 | Origination Point Code #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lower CIC Value #2 | Upper CIC Value #2 | | Lower CIC Value #2 | Upper CIC Value #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ... / / ... /
skipping to change at page 52, line 15 skipping to change at page 52, line 15
3.6 2 Registration Response (REG RSP) 3.6 2 Registration Response (REG RSP)
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 Results Mandatory Registration Result Mandatory
The format for the REG RSP message is as follows: One or more Registration Result parameters MAY be included. The format
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 = 0x90 | Length | | Tag = 0x0208 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Result 1 | | Registration Result 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ ... / / ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0208 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Result n | | Registration Result n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Registration Results: Registration Results:
The Registration Results parameter contains one or more results, The Registration Result parameter contains the registration status
each containing the registration status for a single Routing Key in for a single Routing Key in an REG REQ message. The number of
an REG REQ message. The number of results in a single REG RSP results in a single REG RSP message MAY be anywhere from one to the
message MAY match the number of Routing Key parameters found in the total number of number of Routing Key parameters found in the
corresponding REG REQ message. The format of each result is as corresponding REG REQ message. Where multiple REG RSP messages are
follows: 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:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local-RK-Identifier value | | Local-RK-Identifier value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Status | | Registration Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Routing Context | | Routing Context |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 53, line 22 skipping to change at page 53, line 22
0 Successfully Registered 0 Successfully Registered
1 Error - Unknown 1 Error - Unknown
2 Error - Invalid DPC 2 Error - Invalid DPC
3 Error - Invalid Network Appearance 3 Error - Invalid Network Appearance
4 Error - Invalid Routing Key 4 Error - Invalid Routing Key
5 Error - Permission Denied 5 Error - Permission Denied
6 Error - Cannot Support Unique Routing 6 Error - Cannot Support Unique Routing
7 Error - Routing Key not Currently Provisioned 7 Error - Routing Key not Currently Provisioned
8 Error - Insufficient Resources 8 Error - Insufficient Resources
9 Error - Unsupported RK parameter Field 9 Error - Unsupported RK parameter Field
10 Error Unsupported/Invalid Traffic Handling Mode 10 Error - Unsupported/Invalid Traffic Handling Mode
Routing Context: 32-bit integer Routing Context: 32-bit integer
The Routing Context field contains the Routing Context value for the The Routing Context field contains the Routing Context value for the
associated Routing Key if the registration was successful. It is set associated Routing Key if the registration was successful. It is set
to "0" if the registration was not successful. to "0" if the registration was not successful.
3.6.3 De-Registration Request (DEREG REQ) 3.6.3 De-Registration Request (DEREG REQ)
The DEREG REQ message is sent by an ASP to indicate to a remote M3UA The DEREG REQ message is sent by an ASP to indicate to a remote M3UA
skipping to change at page 53, line 46 skipping to change at page 53, line 46
The DEREG REQ message contains the following parameters: The DEREG REQ message contains the following parameters:
Routing Context Mandatory Routing Context Mandatory
The format for the DEREG REQ message is as follows: The format for the DEREG REQ 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 = 0x06 | Length | | Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ Routing Context / / Routing Context /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Routing Context: n X 32-bit integers Routing Context: n X 32-bit integers
The Routing Context parameter contains (a list of) integers indexing The Routing Context parameter contains (a list of) integers indexing
the Application Server traffic that the sending ASP is currently the Application Server traffic that the sending ASP is currently
registered to receive from the SGP but now wishes to deregister. registered to receive from the SGP but now wishes to deregister.
3.6.4 De-Registration Response (DEREG RSP) 3.6.4 De-Registration 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:
De-registration Results Mandatory De-registration Result Mandatory
The format for the DEREG RSP message is as follows: One or more De-registration Result parameters MAY be included. The
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 = 0x89 | Length | | Tag = 0x0209 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| De-Registration Result 1 | | De-Registration Result 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ ... / / ... /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0209 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| De-Registration Result n | | De-Registration Result n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
De-Registration Results: De-Registration Results:
The De-Registration Results parameter contains one or more results, The De-Registration Result parameter contains the de-registration
each containing the de-registration status for a single Routing status for a single Routing Context in a DEREG REQ message. The
Context in a DEREG REQ message. The number of results in a single number of results in a single DEREG RSP message MAY be anywhere from
DEREG RSP message MAY match the number of Routing Contexts found in one to the total number of number of Routing Context values found in
the corresponding DEREG REQ message. The format of each result is the corresponding REG REQ message. Where multiple DEREG RSP messages
as follows: are used in reply to DEREG REQ message, a specific result SHOULD be
in only one DEREG 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Routing Context | | Routing Context |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| De-Registration Status | | De-Registration Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Routing Context: 32-bit integer Routing Context: 32-bit integer
skipping to change at page 55, line 22 skipping to change at page 55, line 22
The De-Registration Result Status field indicates the success or the The De-Registration Result Status field indicates the success or the
reason for failure of the de-registration. reason for failure of the de-registration.
Its values may be: Its values may be:
0 Successfully De-registered 0 Successfully De-registered
1 Error - Unknown 1 Error - Unknown
2 Error - Invalid Routing Context 2 Error - Invalid Routing Context
3 Error - Permission Denied 3 Error - Permission Denied
4 Error - Not Registered 4 Error - Not Registered
5 Error ASP Currently Active for Routing Context 5 Error - ASP Currently Active for Routing Context
3.7 ASP Traffic Maintenance (ASPTM) Messages 3.7 ASP Traffic Maintenance (ASPTM) Messages
3.7.1 ASP Active 3.7.1 ASP Active
The ASP Active message is sent by an ASP to indicate to a remote M3UA The ASP Active message is sent by an ASP to indicate to a remote M3UA
peer that it is ready to process signalling traffic for a particular peer that it is ready to process signalling traffic for a particular
Application Server. The ASP Active message affects only the ASP state Application Server. The ASP Active message affects only the ASP state
for the Routing Keys identified by the Routing Contexts, if present. for the Routing Keys identified by the Routing Contexts, if present.
skipping to change at page 56, line 10 skipping to change at page 56, line 10
Traffic Mode Type Mandatory Traffic Mode Type Mandatory
Routing Context Optional Routing Context Optional
INFO String Optional INFO String Optional
The format for the ASP Active message is as follows: The format for the ASP Active 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 = 0x0b | Length | | Tag = 0x000b | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type | | Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x06 | Length | | Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ Routing Context / / Routing Context /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x04 | Length | | Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ INFO String / / INFO String /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Traffic Mode Type: 32-bit (unsigned integer) Traffic Mode Type: 32-bit (unsigned integer)
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 Over-ride 1 Over-ride
2 Load-share 2 Load-share
3 Over-ride (Standby) 3 Broadcast
4 Load-share (Standby) 5 Over-ride (Standby)
6 Load-share (Standby)
7 Broadcst (Standby)
Within a particular Routing Context, Over-ride and Load-share, Within a particular Routing Context, Over-ride,Load-share and
either active or standby, MUST NOT be mixed. The Over-ride value Broadcast, either active or standby, MUST NOT be mixed. The Over-
indicates that the ASP is operating in Over-ride mode, and the ASP ride value indicates that the ASP is operating in Over-ride mode,
takes over all traffic in an Application Server (i.e., primary/back- and the ASP takes over all traffic in an Application Server (i.e.,
up operation), over-riding any currently active ASPs in the AS. In primary/back-up operation), over-riding any currently active ASPs in
Load-share mode, the ASP will share in the traffic distribution with the AS. In Load-share mode, the ASP will share in the traffic
any other currently active ASPs. The Standby versions of the Over- distribution with any other currently active ASPs. In Broadcast
ride and Load-share Types indicate that the ASP is declaring itself mode, the ASP will receive the same messages as any other currently
ready to accept traffic but leaves it up to the sender as to when active ASP. The Standby versions of the Over-ride, Load-share and
the traffic is started. Over-ride (Standby) indicates that the Broadcast Types indicate that the ASP is declaring itself ready to
traffic sender continues to use the currently active ASP until it accept traffic but leaves it up to the sender as to when the traffic
can no longer send/receive traffic (i.e., the currently active ASP is started. Over-ride (Standby) indicates that the traffic sender
transitions to state ASP-DOWN or ASP-ACTIVE). At this point the continues to use the currently active ASP until it can no longer
sender MUST move the standby ASP to the ASP-ACTIVE state and send/receive traffic (i.e., the currently active ASP transitions to
commence traffic. Load-share (Standby) is similar - the sender state ASP-DOWN or ASP-INACTIVE). At this point the sender MUST move
continues to load-share to the current ASPs until it is determined the standby ASP to the ASP-ACTIVE state and commence traffic. Load-
that there is insufficient resources in the Load-share group. When share (Standby) and Broadcast (Standby) are similar - the sender
there are insufficient ASPs, the sender MUST move the ASP to state continues to load-share or broadcast to the current ASPs until it is
ASP-ACTIVE. determined
that there is insufficient resources in the Load-share or Broadcast
group. When there are insufficient ASPs, the sender MUST move the
ASP to state ASP-ACTIVE.
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
indexing the Application Server traffic that the sending ASP is indexing the Application Server traffic that the sending ASP is
configured/registered to receive. configured/registered to receive.
There is one-to-one relationship between an index entry and an SGP There is one-to-one relationship between an index entry and an SGP
Routing Key or AS Name. Because an AS can only appear in one Routing Key or AS Name. Because an AS can only appear in one
Network Appearance, the Network Appearance parameter is not required Network Appearance, the Network Appearance parameter is not required
skipping to change at page 57, line 34 skipping to change at page 57, line 34
multiple ranges of PSTN trunks and therefore receive related multiple ranges of PSTN trunks and therefore receive related
signalling traffic, identified by separate SS7 DPC/OPC/CIC ranges. signalling traffic, identified by separate SS7 DPC/OPC/CIC ranges.
The format and description of the optional INFO String parameter is the The format and description of the optional INFO String parameter is the
same as for the DUNA message (See Section 3.4.1). same as for the DUNA message (See Section 3.4.1).
3.7.2 ASP Active Acknowledgement (ASP Active Ack) 3.7.2 ASP Active Acknowledgement (ASP Active Ack)
The ASP Active Ack message is used to acknowledge an ASP Active message The ASP Active Ack message is used to acknowledge an ASP Active message
received from a remote M3UA peer. In the case where an ASP Active received from a remote M3UA peer. In the case where an ASP Active
(Over-ride (standby)) or ASP Active (Load-share (standby)) message is (Over-ride (standby)), ASP Active (Load-share (standby)) or ASP Active
(Broadcast (standby)) message is
received, a second ASP Active Ack message is sent when the ASP is moved received, a second ASP Active Ack message is sent when the ASP is moved
from the ASP-STANDBY to the ASP-ACTIVE state. from the ASP-STANDBY to the ASP-ACTIVE state.
The ASP Active Ack message contains the following parameters: The ASP Active Ack message contains the following parameters:
Traffic Mode Type Mandatory Traffic Mode Type Mandatory
Routing Context Optional Routing Context Optional
INFO String Optional INFO String Optional
The format for the ASP Active Ack message is as follows: The format for the ASP Active Ack 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 = 0x0b | Length | | Tag = 0x000b | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type | | Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x06 | Length | | Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ Routing Context / / Routing Context /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x04 | Length | | Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ INFO String / / INFO String /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional INFO String parameter is the The format and description of the optional INFO String parameter is the
same as for the DUNA message (See Section 3.4.1). same as for the DUNA message (See Section 3.4.1).
The INFO String in an ASP Active Ack message is independent from the The INFO String in an ASP Active Ack message is independent from the
INFO String in the ASP Active message (i.e., it does not have to echo INFO String in the ASP Active message (i.e., it does not have to echo
back the INFO String received). back the INFO String received).
The format of the Traffic Mode Type and Routing Context parameters is The format of the Traffic Mode Type and Routing Context parameters is
the same as for the ASP Active message. (See Section 3.5.5). the same as for the ASP Active message. (See Section 3.5.5).
3.7.3 ASP Inactive 3.7.3 ASP Inactive
The ASP Inactive message is sent by an ASP to indicate to a remote M3UA The ASP Inactive message is sent by an ASP to indicate to a remote M3UA
peer peer that it is no longer an active ASP to be used from within a list of
that it is no longer an active ASP to be used from within a list of
ASPs. The ASP Inactive message affects only the ASP state in the ASPs. The ASP Inactive message affects only the ASP state in the
Routing Keys identified by the Routing Contexts, if present. Routing Keys identified by the Routing Contexts, if present.
The ASP Inactive message contains the following parameters: The ASP Inactive message contains the following parameters:
Routing Context Optional Routing Context Optional
INFO String Optional INFO String Optional
The format for the ASP Inactive message parameters is as follows: The format for the ASP Inactive message parameters 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 = 0x06 | Length | | Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ Routing Context / / Routing Context /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x04 | Length | | Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ INFO String / / INFO String /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional Routing Context and INFO The format and description of the optional Routing Context and INFO
String parameters is the same as for the ASP Active message (See String parameters is the same as for the ASP Active message (See
Section 3.5.5.) Section 3.5.5.)
3.7.4 ASP Inactive Acknowledgement (ASP Inactive Ack) 3.7.4 ASP Inactive Acknowledgement (ASP Inactive Ack)
The ASP Inactive Ack message is used to acknowledge an ASP Inactive The ASP Inactive Ack message is used to acknowledge an ASP Inactive
message message received from a remote M3UA peer.
received from a remote M3UA peer.
The ASP Inactive Ack message contains the following parameters: The ASP Inactive Ack message contains the following parameters:
Routing Context Optional Routing Context Optional
INFO String Optional INFO String Optional
The format for the ASP Inactive Ack message is as follows: The format for the ASP Inactive Ack 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 = 0x06 | Length | | Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ Routing Context* / / Routing Context /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x04 | Length | | Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ INFO String / / INFO String /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional INFO String parameter is the The format and description of the optional INFO String parameter is the
same as for the DUNA message (See Section 3.4.1.) same as for the DUNA message (See Section 3.4.1.)
The INFO String in an ASP Inactive Ack message is independent from the The INFO String in an ASP Inactive Ack message is independent from the
skipping to change at page 60, line 34 skipping to change at page 60, line 34
The Error message contains the following parameters: The Error message contains the following parameters:
Error Code Mandatory Error Code Mandatory
Diagnostic Information Optional Diagnostic Information Optional
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 = 0x0c | Length | | Tag = 0x000c | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | | Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x07 | 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.
The Error parameter value can be one of the following values: The Error parameter value can be one of the following values:
skipping to change at page 61, line 13 skipping to change at page 61, line 13
3 Unsupported Message Class 3 Unsupported Message Class
4 Unsupported Message Type 4 Unsupported Message Type
5 Unsupported/Invalid Traffic Handling Mode 5 Unsupported/Invalid Traffic Handling Mode
6 Unexpected Message 6 Unexpected Message
7 Protocol Error 7 Protocol Error
8 Invalid Routing Context 8 Invalid Routing Context
9 Invalid Stream Identifier 9 Invalid Stream Identifier
10 Invalid Parameter Value 10 Invalid Parameter Value
11 Refused - Management Blocking 11 Refused - Management Blocking
12 Unknown Routing Context 12 Unknown Routing Context
13 Missing, Duplicated or Invalid ASP Identifier
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.
skipping to change at page 62, line 17 skipping to change at page 62, line 17
a Mask value other than "0"). a Mask value other than "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 lock-out"). management reasons (e.g., management lock-out").
The "Unknown Routing Context" Error is sent if a message is received The "Unknown Routing Context" Error is sent if a message is received
from a peer without a Routing Context parameter and it is not known by from a peer without a Routing Context parameter and it is not known by
configuration data which Application Servers are referenced. configuration data which Application Servers are referenced.
The "Refused - Missing, Duplicated or Invalid ASP Identifier" error is
sent when an ASP-Up message is received and the request is refused
because an ASP ID is required, or the value is invalid/duplicated.
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. In the case of an Invalid
Network Appearance, Traffic Handling Mode, Routing Context or Network Appearance, Traffic Handling Mode, Routing Context or
Parameter Value, the Diagnostic information parameter MUST be added Parameter Value, the Diagnostic information parameter MUST be added
and include the offending parameter. In the other cases, the and include the offending parameter. In the other cases, the
Diagnostic information MAY be the first 40 bytes of the offending Diagnostic information MAY be the first 40 bytes of the offending
message. message.
skipping to change at page 62, line 39 skipping to change at page 62, line 43
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:
Status Mandatory Status Mandatory
ASP Identifier Optional
Routing Context Optional Routing Context Optional
INFO String Optional INFO String Optional
The format for the Notify message is as follows: The format for the Notify 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 = 0x0d | Length | | Tag = 0x000d | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Type | Status Information | | Status Type | Status Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x06 | Length | | Tag = 0x000e | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ Routing Context / / Routing Context /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x04 | Length | | Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ INFO String / / INFO String /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Status Type: 16-bits (unsigned integer) Status Type: 16-bits (unsigned integer)
The Status Type parameter identifies the type of the Notify message. The Status Type parameter identifies the type of the Notify message.
The following are the valid Status Type values: The following are the valid Status Type values:
skipping to change at page 64, line 14 skipping to change at page 64, line 14
If the Status Type is Other, then the following Status Information If the Status Type is Other, then the following Status Information
values are defined: values are defined:
1 Insufficient ASP Resources Active in AS 1 Insufficient ASP Resources Active in AS
2 Alternate ASP Active 2 Alternate ASP Active
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 in order to handle the load of the AS (Load-sharing mode). required to handle the load of the AS (Load-sharing 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 Over-ride mode. ASP transitions to the ASP-ACTIVE state in Over-ride mode.
The format and description of the optional Routing Context and Info The format and description of the optional ASP Identifier, Routing
String parameters is the same as for the ASP Active message (See Context and Info String parameters is the same as for the ASP Active
Section message (See Section 3.5.5.)
3.5.5.)
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 and Layer Management Layers 4.1 Procedures to Support the M3UA-User and Layer Management Layers
skipping to change at page 64, line 49 skipping to change at page 64, line 48
The M3UA message distribution function (see Section 1.4.2.1) determines The M3UA message distribution function (see Section 1.4.2.1) determines
the Application Server (AS) based on comparing the information in the the Application Server (AS) based on comparing the information in the
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 load-shared across more than one ACTIVE state (i.e., traffic is to be load-shared 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. The selection algorithm is implementation dependent but could, 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 selection
algorithm is implementation dependent but could,
for example, be round-robin or based on, for example, the SLS or ISUP for example, be round-robin or based on, for example, the SLS or ISUP
CIC. The appropriate selection algorithm must be chosen carefully as CIC. The appropriate selection algorithm must be chosen carefully as
it is dependent on application assumptions and understanding of the it is 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. signalling application.
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
skipping to change at page 68, line 22 skipping to change at page 68, line 22
| Overrides | ^ | | Overrides | ^ |
| | ASP | | ASP | | ASP | | ASP
| | Active | | Inactive | | Active | | Inactive
| | | v | | | v
| | +--------------+ | | +--------------+
| | | | | | | |
| +------>| ASP-INACTIVE | | +------>| ASP-INACTIVE |
| +--------------+ | +--------------+
| ^ | | ^ |
ASP Down/ | ASP | | ASP Down / ASP Down/ | ASP | | ASP Down /
SCTP CDI | Up | | SCTP CDI SCTP CDI/ | Up | | SCTP CDI/
| | v SCTP RI | | v SCTP RI
| +--------------+ | +--------------+
| | | | | |
+--------------------->| ASP-DOWN | +--------------------->| ASP-DOWN |
| | | |
+--------------+ +--------------+
*Note: ASP-ACTIVE and ASP-STANDBY differ only in whether the ASP is *Note: ASP-ACTIVE and ASP-STANDBY differ only in whether the ASP is
currently receiving Data traffic within the AS. currently receiving Data traffic within the AS.
SCTP CDI: The SCTP CDI denotes the local SCTP layer's Communication 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 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 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 connectivity to the ASP's peer SCTP layer. SCTP CDI is understood as
either a SHUTDOWN_COMPLETE notification or COMMUNICATION_LOST either a SHUTDOWN_COMPLETE notification or COMMUNICATION_LOST
notification from the SCTP layer. 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.2.1.2 AS States 4.2.1.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 SGP. 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:
skipping to change at page 71, line 43 skipping to change at page 71, line 43
When an ASP Up message is received at an SGP and internally the remote When an ASP Up message is received at an SGP and internally the remote
ASP is in the ASP-DOWN state and not considered locked-out for local ASP is in the ASP-DOWN state and not considered locked-out for local
management reasons, the SGP marks the remote ASP in the state ASP- management reasons, the SGP marks the remote ASP in the state ASP-
INACTIVE and informs Layer Management with an M-ASP_Up indication INACTIVE and informs Layer Management with an M-ASP_Up indication
primitive. If the SGP is aware, via current configuration data, which primitive. If the SGP is aware, via current configuration data, which
Application Servers the ASP is configured to operate in, the SGP Application Servers the ASP is configured to operate in, the SGP
updates the ASP state to ASP-INACTIVE in each AS that it is a member. updates the ASP state to ASP-INACTIVE in each AS that it is a member.
Alternatively, the SGP may move the ASP into a pool of Inactive ASPs Alternatively, the SGP may move the ASP into a pool of Inactive ASPs
available for future configuration within Application Server(s), available for future configuration within Application Server(s),
determined in a subsequent Registration Request or ASP Active determined in a subsequent Registration Request or ASP Active
procedure. The SGP responds with an ASP Up Ack message in procedure. If the ASP Up message contains an ASP Identifier, the SGP
should save the ASP Identifier for that ASP.
The SGP responds with an ASP Up Ack message in
acknowledgement. The SGP sends an ASP Up Ack message in response to a acknowledgement. The SGP sends an ASP Up Ack message in response to a
received ASP Up message even if the ASP is already marked as ASP- received ASP Up message even if the ASP is already marked as ASP-
INACTIVE at the SGP. INACTIVE at the SGP.
If for any local reason (e.g., management lock-out) the SGP cannot If for any local reason (e.g., management lock-out) 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
skipping to change at page 73, line 29 skipping to change at page 73, line 29
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 3.5.5) to register within the Registration procedures (see Section 3.5.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 SHOULD 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. has locked out the ASP for management reasons. the ASP.
The SGP sends an ASP Down Ack message in response to a received ASP- The SGP sends 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 Down message from the ASP even if the ASP is already marked as ASP-DOWN
at the SGP. The SGP sends an ASP Down Ack message even if the reason at the SGP. The SGP sends an ASP Down Ack message even if the reason
in the received ASP Down message is considered invalid. in the received ASP Down message is considered invalid.
At the ASP, the ASP Down Ack message received is not acknowledged. At the ASP, the ASP Down Ack message received is not acknowledged.
Layer Management is informed with an M-ASP_DOWN confirm primitive. If Layer Management is informed with an M-ASP_DOWN confirm primitive. If
the ASP receives an ASP Down Ack without having sent an ASP Down the ASP receives an ASP Down Ack without having sent an ASP Down
message, the ASP should now consider itself as in the ASP-DOWN state. message, the ASP should now consider itself as in the ASP-DOWN state.
skipping to change at page 74, line 26 skipping to change at page 74, line 26
message applies. It is not necessary for the ASP to include all Routing message applies. It is not necessary for the ASP to include all Routing
Contexts of interest in a single ASP Active message, thus requesting to Contexts of interest in a single ASP Active message, thus requesting to
become active in all Routing Contexts at the same time. Multiple ASP become active in all Routing Contexts at the same time. Multiple ASP
Active messages MAY be used to activate within the Application Servers Active messages MAY be used to activate within the Application Servers
independently, or in sets. In the case where an ASP Active message independently, or in sets. In the case where an ASP Active message
does not contain a Routing Context parameter, the receiver must know, does not contain a Routing Context parameter, the receiver must know,
via configuration data, which Application Server(s) the ASP is a via configuration data, which Application Server(s) the ASP is a
member. member.
For the Application Servers that the ASP can be successfully activated, For the Application Servers that the ASP can be successfully activated,
he SGP or IPSP responds the SGP or IPSP responds with one or more ASP Active Ack messages,
with one or more ASP Active Ack messages, including the associated including the associated Routing Context and Traffic Mode Type values.
Routing Context and Traffic Mode Type values. The Routing Context The Routing Context parameter MUST be included in the Asp Active Ack
parameter MUST be included in the Asp Active Ack message if the message if the received ASP Active message contained any Routing
received ASP Active message contained any Routing Contexts. Depending Contexts. Depending on the ASP Active Message Traffic Mode Type
on the ASP Active Message Traffic Mode Type request, the SGP moves the request, the SGP moves the ASP to the correct ASP traffic state within
ASP to the correct ASP traffic state within the associated Application the associated Application Server(s). Layer Management is informed with
Server(s). Layer Management is informed with an M-ASP_Active an M-ASP_Active indication. If the SGP or IPSP receives any Data
indication. If the SGP or IPSP receives any Data messages before an ASP messages before an ASP Active message is received, the SGP or IPSP MAY
Active message is received, the SGP or IPSP MAY discard them. By discard them. By sending an ASP Active Ack message, the SGP or IPSP is
sending an ASP Active Ack message, the SGP or IPSP is now ready to now ready to receive and send traffic for the related Routing
receive and send traffic for the related Routing Context(s). The ASP Context(s). The ASP SHOULD NOT send Data messages for the related
SHOULD NOT send Data messages for the related Routing Context(s) before Routing Context(s) before receiving an ASP Active Ack message, or it
receiving an ASP Active Ack message, or it will risk message loss. 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 sends an Error different (sets of) Routing Contexts. The SGP or IPSP sends an Error
message ("Invalid Routing Context") for each Routing Context value that message ("Invalid Routing Context") for each Routing Context value that
the ASP cannot be successfully activated . 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
(i.e., the ASP has not registered with the SG or the SG has no static (i.e., the ASP has not registered with the SG or the SG has no static
skipping to change at page 75, line 22 skipping to change at page 75, line 22
When the ASP sends an ASP Active message it starts timer T(ack). If When the ASP sends an ASP Active message it starts timer T(ack). If
the ASP does not receive a response to an ASP Active message within the ASP does not receive a response to an ASP Active message within
T(ack), the ASP MAY restart T(ack) and resend ASP Active messages until T(ack), the ASP MAY restart T(ack) and resend ASP Active messages until
it receives an ASP Active Ack message. T(ack) is provisionable, with a it receives an ASP Active Ack message. T(ack) is provisionable, with a
default of 2 seconds. Alternatively, retransmission of ASP Active default of 2 seconds. Alternatively, retransmission of ASP Active
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_ACTIVE confirm primitive carrying expiry of T(ack) results in an M-ASP_ACTIVE confirm primitive carrying
a negative indication. a negative indication.
There are four modes of Application Server traffic handling in the SGP There are six modes of Application Server traffic handling in the SGP
M3UA layer - Over-ride, Over-ride (Standby), Load-share and Load-share M3UA layer - Over-ride, Over-ride (Standby), Load-share, Load-share
(Standby). The Traffic Mode Type parameter in the ASP Active message (Standby), Broadcast and Broadcast Standby. The Traffic Mode Type
indicates the traffic handling mode used in a particular Application parameter in the ASP Active message indicates the traffic handling mode
Server. If the SGP determines that the mode indicated in an ASP Active used in a particular Application Server. If the SGP determines that the
message is unsupported or incompatible with the mode currently mode indicated in an ASP Active message is unsupported or incompatible
configured for the AS, the SGP responds with an Error message with the mode currently configured for the AS, the SGP responds with an
("Unsupported / Invalid Traffic Handling Mode"). If the Traffic Error message ("Unsupported / Invalid Traffic Handling Mode"). If the
Handling mode of the Application Server is not already known via Traffic Handling mode of the Application Server is not already known via
configuration data, then the Traffic Handling mode indicated in the configuration data, then the Traffic Handling mode indicated in the
first ASP Active message causing the transition of the Application first ASP Active message causing the transition of the Application
Server state to AS-ACTIVE MAY be used to set the mode. Server state to AS-ACTIVE MAY be used to set the mode.
In the case of an Over-ride mode AS, reception of an ASP Active message In the case of an Over-ride mode AS, reception of an ASP Active message
at an SGP causes the (re)direction of all traffic for the AS to the ASP at an SGP causes the (re)direction of all traffic for the AS to the ASP
that sent the ASP Active message. Any previously active ASP in the AS that sent the ASP Active message. Any previously active ASP in the AS
is now considered to be in state ASP-INACTIVE and SHOULD no longer is now considered to be in state ASP-INACTIVE and SHOULD no longer
receive traffic from the SGP within the AS. The SGP or IPSP then MUST receive traffic from the SGP within the AS. The SGP or IPSP then MUST
send a Notify message ("Alternate ASP-Active") to the previously active send a Notify message ("Alternate ASP-Active") to the previously active
skipping to change at page 76, line 39 skipping to change at page 76, line 39
is started. A second ASP Active Ack message with a new Traffic Mode is started. A second ASP Active Ack message with a new Traffic Mode
Type ("Load-share" - previously "Loadshare(Standby)") is sent to the Type ("Load-share" - previously "Loadshare(Standby)") is sent to the
ASP. A Notify message ("Insufficient ASP resources active in AS ") is ASP. A Notify message ("Insufficient ASP resources active in AS ") is
not sent in this case. not sent in this case.
If there is no currently active ASP, an ASP Active Ack message If there is no currently active ASP, an ASP Active Ack message
("Loadshare") is returned right away and the traffic is directed to the ("Loadshare") is returned right away and the traffic is directed to the
ASP. ASP.
All ASPs within a load-sharing mode AS must be able to process any All ASPs within a load-sharing mode AS must be able to process any
Data message received for the AS, in order to accommodate any potential Data message received for the AS, to accommodate any potential
fail-over or rebalancing of the offered load. fail-over or rebalancing of the offered load.
In the case of a Broadcast mode AS, reception of an ASP Active message
at an SGP or IPSP cuases the direction of traffic to the ASP sending the
ASP Active message, in addition to all the other ASPs that are
currently active in the AS. The algorithm at the SGP for broadcasting
traffic within an AS to all the active ASPs is a simple braoadcast
algorithm, where every message is sent to each of the active ASPs.
An SGP or IPSP, upon reception of an ASP Active message for the first
ASP in a Broadcast AS, MAY choose not to direct traffic to a newly
active ASP until it determines that there are sufficient resources to
handle the expected load (e.g., until there are "n" ASPs in state
ASP-ACTIVE in the AS).
In the case of Broadcast (Standby) mode AS, the traffic is not started
to the ASP until the SGP or IPSP determines that there are sufficient
resuorces available in the AS. This is likely when one of the active
broadcast ASPs transitions to either the ASP-INACTIVE or ASP-DOWN
state. At this point the ASP that sent the ASP Active message
("Broadcast (Standby)") is moved to the ASP_ACTIVE state and traffic
is started. A second ASP Active Ack message with a new Traffic Mode
Type ("Broadcast" - previously "Broadcast (Standby)") is sent to the
ASP. A Notify message ("Insufficient ASP resources active in AS") is
not sent in this case.
If there is no currently active ASP, an ASP Active Ack message
("Broadcast") is returned right away and the traffic is directed to
the ASP.
4.2.3.5 ASP Inactive Procedures 4.2.3.5 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
skipping to change at page 77, line 25 skipping to change at page 77, line 25
INACTIVE state and the AS traffic is re-allocated across the remaining INACTIVE state and the AS traffic is re-allocated across the remaining
ASPs in the state ASP-ACTIVE, as per the load-sharing algorithm ASPs in the state ASP-ACTIVE, as per the load-sharing algorithm
currently used within the AS. A Notify message("Insufficient ASP currently used within the AS. A Notify message("Insufficient ASP
resources active in AS") MAY be sent to all inactive ASPs, if required. resources active in AS") MAY be sent to all inactive ASPs, if required.
However, if a Loadshare ("Standby") ASP is available, it may be now However, if a Loadshare ("Standby") ASP is available, it may be now
immediately included in the loadshare group and a Notify message is not immediately included in the loadshare group and a Notify message is not
sent. An ASP Inactive Ack message is sent to the ASP after all traffic sent. An ASP Inactive Ack message is sent to the ASP after all traffic
is halted and Layer Management is informed with an M-ASP_INACTIVE is halted and Layer Management is informed with an M-ASP_INACTIVE
indication primitive. indication primitive.
In the case of a Broadcast mode AS, the SGP moves the ASP to the
ASP-INACTIVE state and the AS traffic is broadcast only to the
remaining ASPs in the state ASP-ACTIVE. A Notify message
("Insufficient ASP resources active in AS") MAY be sent to all
inactive ASPs, if required. However, if a Broadcast ("Standby") ASP
is available, it may be now immediately included in the broadcast
group and a Notify message is not sent. An ASP Inactive Ack message
is sent to the ASP after all traffic is halted and Layer Management is
informed with an M-ASP_INACTIVE indication primitive.
Multiple ASP Inactive Ack messages MAY be used in response to an ASP Multiple ASP Inactive Ack messages MAY be used in response to an ASP
Inactive message containing multiple Routing Contexts, allowing the SGP Inactive message containing multiple Routing Contexts, allowing the SGP
or IPSP to independently acknowledge for different (sets of) Routing or IPSP to independently acknowledge for different (sets of) Routing
Contexts. The SGP or IPSP sends an Error message ("Invalid Routing Contexts. The SGP or IPSP sends an Error message ("Invalid Routing
Context") message for each invalid or un-configured Routing Context Context") message for each invalid or un-configured Routing Context
value in a received ASP Inactive message message. value in a received ASP Inactive message message.
The SGP MUST send an ASP Inactive Ack message in response to a received The SGP MUST send an ASP Inactive Ack message in response to a received
ASP Inactive message from the ASP and the ASP is already marked as ASP- ASP Inactive message from the ASP and the ASP is already marked as ASP-
INACTIVE at the SGP. INACTIVE at the SGP.
skipping to change at page 78, line 7 skipping to change at page 78, line 7
all of the ASPs in the AS which are in the state ASP-INACTIVE. The SGP 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)seconds, after SHOULD start buffering the incoming messages for T(r)seconds, after
which messages MAY be discarded. T(r) is configurable by the network which messages MAY be discarded. T(r) is configurable by the network
operator. If the SGP receives an ASP Active message from an ASP in the operator. If the SGP receives an ASP Active message from an ASP in the
AS before expiry of T(r), the buffered traffic is directed to that ASP AS before expiry of T(r), the buffered traffic is directed to that ASP
and the timer is cancelled. If T(r) expires, the AS is moved to the and the timer is cancelled. If T(r) expires, the AS is moved to the
AS-INACTIVE state. AS-INACTIVE state.
4.2.3.6 Notify Procedures 4.2.3.6 Notify Procedures
A Notify message reflecting a change in the AS state SHOULD 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. The Notify message MUST be sent after appropriate Status Information and any ASP Identifier of the failed
any ASP State or Traffic Management acknowledgement messages (e.g., ASP ASP. The Notify message MUST be sent after any ASP State or Traffic
Up Ack, ASP Down Ack, ASP Active Ack, or ASP Inactive Ack). At the Management acknowledgement messages (e.g., ASP Up Ack, ASP Down Ack, ASP
ASP, Layer Management is informed with an M-NOTIFY indication Active Ack, or ASP Inactive Ack). At the ASP, Layer Management is
primitive. informed with an M-NOTIFY indication primitive.
In the case where a Notify message("AS-Pending") message is sent by an In the case where a Notify message("AS-PENDING") message is sent by an
SGP that now has no ASPs active to service the traffic, or where a SGP that now has no ASPs active to service the traffic, or where a
Notify message("Insufficient ASP resources active in AS") is sent in Notify message("Insufficient ASP resources active in AS") MUST be sent
the Loadshare mode, the Notify message does not explicitly compel the in the Loadshare or Broadcast mode, the Notify message does not
ASP(s) receiving the message to become active. The ASPs remain in explicitly compel the ASP(s) receiving the message to become active. The
control of what (and when) traffic action is taken. ASPs remain in control of what (and when) traffic action 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 action for Application Servers the ASP is a member and take the appropriate action
the ASP in each AS. in each AS.
4.2.3.7 Heartbeat Procedures 4.2.3.7 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).
After receiving an ASP Up Ack message from an M3UA peer in response to After an ASP or IPSP has received an ASP Up Ack message from an M3UA
an ASP Up message, an ASP may optionally send Heartbeat messages peer in response to an ASP Up message, either M3UA peer may optionally
periodically, subject to a provisionable timer T(beat). Upon receiving send Heartbeat messages periodically, subject to a provisionable timer
a Heartbeat message, the M3UA peer MUST respond with a Heartbeat ACK T(beat). Upon receiving a Heartbeat message, the M3UA peer MUST respond
message. with a Heartbeat Ack message.
At the ASP, if no Heartbeat Ack message (or any other M3UA message) is If no Heartbeat Ack message (or any other M3UA message) is received from
received from the M3UA peer within 2*T(beat), the remote M3UA peer is the M3UA peer within 2*T(beat), the remote M3UA peer is considered
considered unavailable. Transmission of Heartbeat messages is stopped unavailable. Transmission of Heartbeat messages is stopped and the
and the ASP SHOULD attempt to re-establish communication with the SGP signalling process SHOULD attempt to re-establish communication if it is
M3UA peer. configured as the client for the disconnectd M3UA peer.
The Heartbeat message may optionally contain an opaque Heartbeat Data The Heartbeat message may optionally contain an opaque Heartbeat Data
parameter that MUST be echoed back unchanged in the related Heartbeat parameter that MUST be echoed back unchanged in the related Heartbeat
Ack message. The ASP, upon examining the contents of the returned Ack message. The sender, upon examining the contents of the returned
Heartbeat Ack message, MAY choose to consider the remote M3UA peer as Heartbeat Ack message, MAY choose to consider the remote M3UA peer as
unavailable. The contents/format of the Heartbeat Data parameter is unavailable. The contents/format of the Heartbeat Data parameter is
implementation-dependent and only of local interest to the original implementation-dependent and only of local interest to the original
sender. The contents may be used, for example, to support a Heartbeat sender. The contents may be used, for example, to support a Heartbeat
sequence algorithm (to detect missing Heartbeats), and/or a timestamp sequence algorithm (to detect missing Heartbeats), and/or a timestamp
mechanism (to evaluate delays). mechanism (to evaluate delays).
Note: Heartbeat related events are not shown in Figure 4 "ASP state Note: Heartbeat related events are not shown in Figure 4 "ASP state
transition diagram". transition diagram".
skipping to change at page 79, line 30 skipping to change at page 79, line 30
ASP is not currently included in the list of ASPs for the related ASP is not currently included in the list of ASPs for the related
Application Server, the SGP MAY authorize the ASP to be added to the Application Server, the SGP MAY authorize the ASP to be added to the
AS. Or, if the Routing Key does not currently exist and the received AS. Or, if the Routing Key does not currently exist and the received
Routing Key data is valid and unique, an SGP supporting dynamic Routing Key data is valid and unique, an SGP supporting dynamic
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 SG/SGP is method of Routing Context value assignment at the SGP is
implementation dependent but must be guaranteed to be unique across all implementation dependent but must be guaranteed to be unique for each
SGPs in an SG. Application Server or Routing Key supported by the SGP.
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 the registration request, the SGP returns
a REG RSP message to the ASP containing the Registration Result "Error a REG RSP message to the ASP containing the Registration Result "Error
Permission Denied". - 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
Registration Result "Error - Insufficient Resources". Registration Result "Error - Insufficient Resources".
If an SGP determines that one or more of the Routing Key parameters are If an SGP determines that one or more of the Routing Key parameters are
not supported for the purpose of creating new Routing Key entries, the not supported for the purpose of creating new Routing Key entries, the
SGP returns a Registration Response message to the ASP, containing a SGP returns a Registration Response message to the ASP, containing a
Registration Result "Error Unsupported RK parameter field". This Registration Result "Error - Unsupported RK parameter field". This
result MAY be used if, for example, the SGP does not support RK Circuit result MAY be used if, for example, the SGP does not support RK Circuit
Range Lists in a Routing Key because the SGP does not support ISUP Range Lists in a Routing Key because the SGP does not support ISUP
traffic, or does not provide CIC range granularity. traffic, or does not provide CIC range granularity.
A Registration Response "Error Unsupported Traffic Handling Mode" is A Registration Response "Error - Unsupported Traffic Handling Mode" is
returned if the Routing Key in the REG REQ contains an Traffic Handling returned if the Routing Key in the REG REQ contains an Traffic Handling
Mode that is inconsistent with the presently configured mode for the Mode that is inconsistent with the presently configured mode for the
matching Application Server. matching Application Server.
An ASP MAY register multiple Routing Keys at once by including a number An ASP MAY register multiple Routing Keys at once by including a number
of Routing Key parameters in a single REG REQ message. The SGP MAY of Routing Key parameters in a single REG REQ message. The SGP MAY
respond to each registration request in a single REG RSP message, respond to each registration request in a single REG RSP message,
indicating the success or failure result for each Routing Key in a indicating the success or failure result for each Routing Key in a
separate Registration Result parameter. Alternatively the SGP MAY separate Registration Result parameter. Alternatively the SGP MAY
respond with multiple REG RSP messages, each with one or more respond with multiple REG RSP messages, each with one or more
Registration Result parameters. The ASP uses the Local-RK-Identifier Registration Result parameters. The ASP uses the Local-RK-Identifier
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
skipping to change at page 81, line 37 skipping to change at page 81, line 37
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 inter-working function at an SGP, the SGP M3UA primitive from the nodal inter-working 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
the SSNM messages consistently with the information received in the the SSNM messages consistently with the information received in the
primitives. primitives.
The SGP M3UA layer determines the set of concerned ASPs to be informed The SGP M3UA layer determines the set of concerned ASPs to be informed
based on the SS7 network partition for which the primitive indication based on the specific SS7 network for which the primitive indication
is relevant. In this way, all ASPs configured to send/receive traffic is relevant. In this way, all ASPs configured to send/receive traffic
within a particular network appearance are informed. If the SGP within a particular network appearance are informed. If the SGP
operates within a single SS7 network appearance, then all ASPs are operates within a single SS7 network appearance, then all ASPs are
informed. informed.
The SG M3UA MAY filter further based on the Affected Point Code in the DUNA, DAVA, SCON, and DRST messages MUST be sent sequentially and
MTP-PAUSE, MTP-RESUME or MTP-STATUS indication primitives. In this way processed at the receiver in the order sent. SCTP stream "0" is used to
ASPs can be informed only of affected destinations to which they provide the sequencing. The only exception to this is if the
actually communicate. The SGP M3UA layer MAY also suppress DUPU international congestion method (see Q.704) is used. If so, the
messages to ASPs that do not implement an MTP3-User protocol peer for Unordered bit in the SCTP DATA chunk MAY be used for the SCON message.
the affected MTP3-User.
DUNA, DAVA, SCON, and DRST messages MUST be sent sequentially and processed at
the receiver in the order sent. SCTP stream "0" is used to provide the
sequencing. . The only exception to this is if the international congestion
method (see Q.704) is used. If so, the Unordered bit in the SCTP DATA chunk MAY
be used for the SCON message.
Sequencing is not required for the DUPU or DAUD messages, which MAY Sequencing is not required for the DUPU or DAUD messages, which MAY
be sent un-sequenced. Again, SCTP stream 0 is used, with optional use be sent un-sequenced. Again, SCTP stream 0 is used, with optional use
of the Unordered bit in the SCTP DATA chunk. of the Unordered bit in the SCTP DATA chunk.
4.3.2 At an ASP 4.3.2 At an ASP
4.3.2.1 Single SGP Configurations 4.3.2.1 Single SGP Configurations
At an ASP, upon receiving an SS7 Signalling Network Management (SSNM) At an ASP, upon receiving an SS7 Signalling Network Management (SSNM)
message from the remote M3UA Peer, the M3UA layer invokes the message from the remote M3UA Peer, the M3UA layer invokes the
appropriate primitive indications to the resident M3UA-Users. Local appropriate primitive indications to the resident M3UA-Users. Local
management is informed. management is informed.
In the case where a local event has caused the unavailability or In the case where a local event has caused the unavailability or
congestion status of SS7 destinations, the M3UA layer at the ASP MUST congestion status of SS7 destinations, the M3UA layer at the ASP SHOULD
pass up appropriate indications in the primitives to the M3UA User, as pass up appropriate indications in the primitives to the M3UA User, as
though equivalent SSNM messages were received. For example, the loss though equivalent SSNM messages were received. For example, the loss
of an SCTP association to an SGP may cause the unavailability of a set of an SCTP association to an SGP may cause the unavailability of a set
of SS7 destinations. MTP-PAUSE indication primitives to the M3UA User of SS7 destinations. MTP-PAUSE indication primitives to the M3UA User
are appropriate. To accomplish this, the M3UA layer at an ASP are appropriate.
Implementation Note: To accomplish this, the M3UA layer at an ASP
maintains the status of routes via the SG(P), much like an MTP3 layer maintains the status of routes via the SG(P), much like an MTP3 layer
maintains route-set status. maintains route-set status.
4.3.2.2 Multiple SGP Configurations 4.3.2.2 Multiple SGP Configurations
At an ASP, upon receiving a Signalling Network Management message from At an ASP, upon receiving a Signalling Network Management message from
the remote M3UA Peer, the M3UA layer updates the status of the affected the remote M3UA Peer, the M3UA layer updates the status of the affected
route(s) via the originating SGP and determines, whether or not the route(s) via the originating SGP and determines, whether or not the
overall availability or congestion status of the effected overall availability or congestion status of the effected
destination(s) has changed. If so, the M3UA layer invokes the destination(s) has changed. If so, the M3UA layer invokes the
appropriate primitive indications to the resident M3UA-Users. Local appropriate primitive indications to the resident M3UA-Users. Local
management is informed. management is informed.
An M3UA layer at the ASP MAY choose to maintain knowledge of which SGPs
are included in Signalling Gateways for the purpose of interpreting
SSNM messaging from one SGP so as to apply to all the SGPs in the SG.
4.3.3 ASP Auditing 4.3.3 ASP Auditing
An ASP may optionally initiate an audit procedure in order to enquire An ASP may optionally initiate an audit procedure to enquire
of an SGP the availability and, if the national congestion method with of an SGP the availability and, if the national congestion method with
multiple congestion levels and message priorities is used, congestion multiple congestion levels and message priorities is used, congestion
status of an SS7 destination or set of destinations. A Destination status of an SS7 destination or set of destinations. A Destination
Audit (DAUD) message is sent from the ASP to the SGP requesting the Audit (DAUD) message is sent from the ASP to the SGP requesting the
current availability and congestion status of one or more SS7 current availability and congestion status of one or more SS7
Destination Point Codes. Destination Point Codes.
The DAUD message MAY be sent un-sequenced. The DAUD MAY be sent by the The DAUD message MAY be sent un-sequenced. The DAUD MAY be sent by the
ASP in the following cases: ASP in the following cases:
skipping to change at page 83, line 51 skipping to change at page 83, line 51
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.
4.4 MTP3 Restart 4.4 MTP3 Restart
In the case where the MTP3 in the SG undergoes an MTP restart, event In the case where the MTP3 in the SG undergoes an MTP restart, event
communication SHOULD be handled as follows: communication SHOULD be handled as follows:
When the SG discovers SS7 network isolation, the SGPs send an indication When the SG discovers SS7 network isolation, the SGPs send an
to all concerned available ASPs (i.e., ASPs in the ASP-ACTIVE, ASP- indication to all concerned available ASPs (i.e., ASPs in the ASP-
STANDBY or ASP-INACTIVE state) using a DUNA message. For the purpose of ACTIVE, ASP-STANDBY or ASP-INACTIVE state) using a DUNA message. For
MTP restart, all Signalling Point Management Clusters with point codes the purpose of MTP restart, all Signalling Point Management Clusters
with point codes
different from that of the SG with at least one ASP in the ASP-ACTIVE different from that of the SG with at least one ASP in the ASP-ACTIVE
state or that has sent an ASP ACTIVE message to the SG during the first state or that has sent an ASP ACTIVE message to the SG during the first
part of the restart procedure should be considered as available. If the part of the restart procedure should be considered as available. If the
M3UA layer at the SGP receives any ASP ACTIVE messages during the M3UA layer at the SGP receives any ASP ACTIVE messages during the
restart procedure, it delays the ASP ACTIVE ACK messages until the end restart procedure, it delays the ASP ACTIVE ACK messages until the end
of the restart procedure. During the second part of the restart of the restart procedure. During the second part of the restart
procedure the SGP M3UA layers at the SGPs inform all concerned ASPs in procedure the SGP M3UA layers at the SGPs inform all concerned ASPs in
the ASP-ACTIVE, ASP-STANDBY or ASP-INACTIVE states of any unavailable the ASP-ACTIVE, ASP-STANDBY or ASP-INACTIVE states of any
SS7 destinations using the DUNA message. At the end of the restart unavailable/restricted SS7 destinations using the DUNA/DRST message. At
procedure the SGP M3UA layers send an ASP ACTIVE ACK message to all ASPs the end of the restart procedure the SGP M3UA layers send an ASP ACTIVE
in the ASP-ACTIVE state. ACK message to all ASPs in the ASP-ACTIVE state.
When the M3UA layer at an ASP receives a DUNA message indicating SS7 When the M3UA layer at an ASP receives a DUNA message indicating SS7
network isolation at an SG, it will stop any affected traffic via this network isolation at an SG, it will stop any affected traffic via this
route. When the M3UA subsequently receives any DUNA messages from an SGP route. When the M3UA subsequently receives any DUNA messages from an SGP
it will mark the affected SS7 destinations as unavailable via that SG. it will mark the affected SS7 destinations as unavailable via that SG.
When the M3UA receives an ASP ACTIVE ACK message it can resume traffic When the M3UA receives an ASP ACTIVE ACK message it can resume traffic
to available SS7 destinations via this SGP, provided the ASP is in the to available SS7 destinations via this SGP, provided the ASP is in the
ASP-ACTIVE state towards this SGP. The ASP MAY choose to audit the ASP-ACTIVE state towards this SGP. The ASP MAY choose to audit the
availability of any unavailable destinations availability of any unavailable destinations
skipping to change at page 85, line 32 skipping to change at page 85, line 32
|<------- 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 will not subsequently send an ASP unsuccessful indication and the ASP will not subsequently send an ASP
Active message. Active message.
5.1.1.3 Single ASP in Multiple Application Servers (each with "1+0" 5.1.1.3 Single ASP in Multiple Application Servers (each with "1+0"
sparing), Dynamic Registration (Case 1 Multiple Registration sparing), Dynamic Registration (Case 1 - Multiple Registration
Requests) Requests)
SGP ASP1 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
skipping to change at page 86, line 17 skipping to change at page 86, line 17
unsuccessful indication and the ASP will not subsequently send an ASP unsuccessful indication and the ASP will not subsequently send an ASP
Active message. Each LRC/RK pair registration is considered 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 in Multiple Application Servers (each with "1+0" 5.1.1.4 Single ASP in Multiple Application Servers (each with "1+0"
sparing), Dynamic Registration (Case 2 Single Registration Request) sparing), Dynamic Registration (Case 2 - Single Registration Request)
SGP ASP1 SGP ASP1
| | | |
|<------------ASP Up-------------| |<------------ASP Up-------------|
|----------ASP Up Ack----------->| |----------ASP Up Ack----------->|
| | | |
|<---REGISTER REQ({LRC1,RK1},----| |<---REGISTER REQ({LRC1,RK1},----|
| ..., | | ..., |
| {LRCn,RKn}),----| | {LRCn,RKn}),----|
| | | |
skipping to change at page 87, line 15 skipping to change at page 87, line 15
5.1.2 Two ASPs in Application Server ("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, where ASP1 is configured to be in the ASP-ACTIVE Application Server, where ASP1 is configured to be in the ASP-ACTIVE
state and ASP2 is to be a "back-up" in the event of communication state and ASP2 is to be a "back-up" in the event of communication
failure or the withdrawal from service of ASP1. ASP2 may act as a hot, failure or the withdrawal from service of ASP1. ASP2 may act as a hot,
warm, or cold back-up depending on the extent to which ASP1 and ASP2 warm, or cold back-up depending on the extent to which ASP1 and ASP2
share call/transaction state or can communicate call state under share call/transaction state or can communicate call state under
failure/withdrawal events. The example message flow is the same failure/withdrawal events. The example message flow is the same
whether the ASP Active messages indicate "Over-ride" or "Load-share" whether the ASP Active messages indicate "Over-ride", "Load-share" or
mode, although typically this example would use an Over-ride mode. The "Broadcast" mode, although typically this example would use an Over-ride
mode. The
SGP MAY start sending any relevant DUNA, DRST and SCON messages to ASPs SGP MAY start sending any relevant DUNA, DRST and SCON messages to ASPs
as soon as they enter the ASP-INACTIVE state. In the case of MTP as soon as they enter the ASP-INACTIVE state. In the case of MTP
Restart, the ASP-Active Ack message is only sent after all relevant Restart, the ASP-Active Ack message is only sent after all relevant
DUNA/DRST/SCON messages have been transmitted to the concerned ASP. DUNA/DRST/SCON messages have been transmitted to the concerned ASP.
SGP ASP1 ASP2 SGP ASP1 ASP2
| | | | | |
|<--------ASP Up----------| | |<--------ASP Up----------| |
|-------ASP Up Ack------->| | |-------ASP Up Ack------->| |
| | | | | |
skipping to change at page 88, line 17 skipping to change at page 88, line 17
|<---------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------>|
| | |
|<----------------------------ASP Active (Ldshr)-----| |<----------------------------ASP Active (Ldshr)-----|
|-------------------------------ASP Active Ack------>| |-------------------------------ASP Active Ack------>|
| | | | | |
5.1.4 Three ASPs in an Application Server ("n+k" sparing, load-sharing 5.1.4 Three ASPs in an Application Server ("n+k" sparing, load-sharing
case) 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, where two of the ASPs are brought to the state ASP- Application Server, where two of the ASPs are brought to the state ASP-
skipping to change at page 88, line 47 skipping to change at page 88, line 49
|<--------------------------ASP Up-------| | |<--------------------------ASP Up-------| |
|-------------------------ASP Up Ack---->| | |-------------------------ASP Up Ack---->| |
| | | | | | | |
|<---------------------------------------------ASP Up--------| |<---------------------------------------------ASP Up--------|
|---------------------------------------------ASP Up Ack---->| |---------------------------------------------ASP Up Ack---->|
| | | | | | | |
| | | | | | | |
|<--ASP Act (Ldshr)--| | | |<--ASP Act (Ldshr)--| | |
|----ASP Act Ack---->| | | |----ASP Act Ack---->| | |
| | | | | | | |
-----------Notify (AS-ACTIVE)----------->| |
|-----------------------Notify (AS-ACTIVE)------------------>|
| | | |
|<--------------------ASP Act. (Ldshr)---| | |<--------------------ASP Act. (Ldshr)---| |
|-----------------------ASP Act Ack----->| | |-----------------------ASP Act Ack----->| |
| | | | | | | |
Note: It is also possible for ASP3 to send an ASP Active message Note: It is also possible for ASP3 to send an ASP Active message
("Loadshare-Standby") after ASP1 and ASP2 go to the ASP-ACTIVE state A ("Loadshare-Standby") after ASP1 and ASP2 go to the ASP-ACTIVE state A
similar sparing arrangement is created, except that the SGP may similar sparing arrangement is created, except that the SGP may
redirect traffic to ASP3 more quickly in certain fail-over cases. redirect traffic to ASP3 more quickly in certain fail-over cases.
5.2 ASP Traffic Fail-over Examples 5.2 ASP Traffic Fail-over Examples
skipping to change at page 89, line 33 skipping to change at page 89, line 33
|<------------------------------ ASP Active----------| |<------------------------------ ASP Active----------|
|------------------------------ASP Active Ack------->| |------------------------------ASP Active Ack------->|
| | | |
Note: If the SGP M3UA layer detects the loss of the M3UA peer (M3UA Note: If the SGP M3UA layer detects the loss of the M3UA peer (M3UA
heartbeat loss or detection of SCTP failure), the initial ASP Inactive heartbeat loss or detection of SCTP failure), the initial ASP Inactive
message exchange (i.e., SGP to ASP1) would not occur. message exchange (i.e., SGP to ASP1) would not occur.
5.2.2 (1+1 Sparing, Back-up Over-ride) 5.2.2 (1+1 Sparing, Back-up Over-ride)
Following on from the example in Section 5.1.2, and ASP2 wishes to Following on from the example in Section 5.1.2, ASP2 wishes to
over-ride ASP1 and take over the traffic: over-ride ASP1 and take over the traffic:
SGP ASP1 ASP2 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, Load-sharing case, Withdrawal of ASP) 5.2.3 (n+k Sparing, Load-sharing case, Withdrawal of ASP)
skipping to change at page 91, line 5 skipping to change at page 91, line 5
| | | |
|<-----------ASP Down-----------| |<-----------ASP Down-----------|
|---------ASP Down Ack--------->| |---------ASP Down Ack--------->|
| | | |
Note: The Deregistration procedure MUST be used if the ASP previously Note: The Deregistration procedure MUST be used if the ASP previously
used the Registration procedures for configuration within the used the Registration procedures for configuration within the
Application Server. ASP Inactive and Deregister messages exchanges may Application Server. ASP Inactive and Deregister messages exchanges may
contain multiple Routing Contexts. contain multiple Routing Contexts.
The ASP SHOULD be ASP-INACTIVE and de-registered in all its Routing The ASP SHOULD be in the ASP-INACTIVE state and SHOULD have deregistered
Contexts before attempting to move to the ASP-DOWN state. in all its Routing Contexts before attempting to move 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 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. 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
skipping to change at page 91, line 45 skipping to change at page 91, line 46
field of a DATA message; field of a DATA message;
- Send the DATA message to the remote M3UA peer at the SGP, over the - Send the DATA message to the remote M3UA peer at the SGP, over the
SCTP association. SCTP association.
SGP ASP SGP ASP
| | | |
|<-----DATA Message-------|<--MTP-TRANSFER req. |<-----DATA Message-------|<--MTP-TRANSFER req.
| | | |
5.4.1.1.2 Support for the MTPTRANSFER Indication Primitive 5.4.1.1.2 Support for the MTP-TRANSFER Indication Primitive
When the M3UA layer on the ASP receives a DATA message from the remote When the M3UA layer on the ASP receives a DATA message from the remote
M3UA peer at the SGP, it will do the following: M3UA peer at the 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
skipping to change at page 93, line 17 skipping to change at page 93, line 17
<---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; - Determine the correct ASP using the distribution function;
- 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 association (e.g., based on - Determine the correct stream in the SCTP association (e.g., based
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
skipping to change at page 97, line 36 skipping to change at page 97, line 36
described in Section 3.2; described in Section 3.2;
(c) Detailed definition of each component of the parameter value; (c) Detailed definition of each component of the parameter value;
(d) Detailed description of the intended use of this parameter type, (d) Detailed description of the intended use of this parameter type,
and an indication of whether and under what circumstances multiple and an indication of whether and under what circumstances multiple
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, Brian Bidulock, Dan Brendes, Nikhil Jain, Joe Keller, Tolga Asveren, Maria-Cruz Bartolome-Rodrigo, Dan Brendes, Nikhil Jain,
Kurt Kite, Ming Lin, Steve Lorusso, John Loughney, Naoto Makinae, Joe Keller, Kurt Kite, Ming Lin, Steve Lorusso, John Loughney, Naoto
Howard May, Barry Nagelberg, Neil Olson, Heinz Prantner, Shyamal Makinae, Howard May, Barry Nagelberg, Neil Olson, Heinz Prantner,
Prasad, Mukesh Punhani, Selvam Rengasami, Ray Singh, Michael Tuexen, Shyamal Prasad, Mukesh Punhani, Selvam Rengasami, Ray Singh, Michael
Nitin Tomar, Gery Verwimp, Kazuo Watanabe, Ben Wilson and many others Tuexen, Nitin Tomar, Gery Verwimp, Kazuo Watanabe, Ben Wilson and many
for their valuable comments and suggestions. others for their 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
(SS7) - Signalling Connection Control Part (SCCP)" (SS7) - Signalling Connection Control Part (SCCP)"
[6] ANSI T1.112 "Signaling System Number 7 - Signaling Connection [6] ANSI T1.112 "Signaling System Number 7 - Signaling Connection
Control Part" Control Part"
[7] ETSI ETS 300 009-1, "Integrated Services Digital Network (ISDN); [7] ETSI ETS 300 009-1, "Integrated Services Digital Network (ISDN);
Signalling System No.7; Signalling Connection Control Part (SCCP) Signalling System No.7; Signalling Connection Control Part (SCCP)
(connectionless and connection-oriented class 2) to support (connectionless and connection-oriented class 2) to support
international interconnection; Part 1: Protocol specification" international interconnection; Part 1: Protocol specification"
[8] ITU-T Recommendation Q.720, "Telephone User Part" [8] ITU-T Recommendation Q.720, "Telephone User Part"
[9] ITU-T Recommendations Q.771 to Q.775 "Signalling System No. 7 (SS7) - [9] ITU-T Recommendations Q.771 to Q.775 "Signalling System No. 7 (SS7)
-
Transaction Capabilities (TCAP)" Transaction Capabilities (TCAP)"
[10] ANSI T1.114 "Signaling System Number 7 - Transaction Capabilities [10] ANSI T1.114 "Signaling System Number 7 - Transaction Capabilities
Application Part" Application Part"
[11] ETSI ETS 300 287-1, "Integrated Services Digital Network (ISDN); [11] ETSI ETS 300 287-1, "Integrated Services Digital Network (ISDN);
Signalling System No.7; Transaction Capabilities (TC) version 2; Signalling System No.7; Transaction Capabilities (TC) version 2;
Part 1: Protocol specification" Part 1: Protocol specification"
[12] 3G TS 25.410 V4.0.0 (2001-04) "Technical Specification - 3rd [12] 3G TS 25.410 V4.0.0 (2001-04) "Technical Specification - 3rd
skipping to change at page 99, line 29 skipping to change at page 99, line 29
[24] RFC 2408, "Internet Security Association and Key Management [24] RFC 2408, "Internet Security Association and Key Management
Protocol", D. Maughan, M. Schertler, M. Schneider and J. Turner, Protocol", D. Maughan, M. Schertler, M. Schneider and J. Turner,
November 1998. November 1998.
[25] RFC 2434, "Guidelines for Writing an IANA Considerations Section [25] RFC 2434, "Guidelines for Writing an IANA Considerations Section
in RFCs", T. Narten and H. Alvestrand, October 1998 in RFCs", T. Narten and H. Alvestrand, October 1998
10. Bibliography 10. Bibliography
[26] <draft-ietf-sigtran-m2ua-07.txt>, "MTP2-User Adaptation Layer", [26] <draft-ietf-sigtran-m2ua-09.txt>, "MTP2-User Adaptation Layer",
K. Morneault et al, February 2001 (Work in Progress) K. Morneault et al, July 2001 (Work in Progress)
[27]<draft-ietf-sigtran-m2pa-02.txt>, "SS7 MTP2-User Peer-to-Peer
Adaptation Layer", Tom George et al (Work in Progress)
11. Author's Addresses 11. Author's Addresses
Greg Sidebottom Greg Sidebottom
Kanata, Ontario, Canada Kanata, Ontario, Canada
gregside@home.com gregside@home.com
Guy Mousseau Guy Mousseau
Nortel Networks Nortel Networks
3685 Richmond Rd 3685 Richmond Rd
skipping to change at page 100, line 21 skipping to change at page 100, line 21
Klaus D. Gradischnig Klaus D. Gradischnig
NeuStar, Inc NeuStar, Inc
1120 Vermont Ave. N.W.Suite 400 1120 Vermont Ave. N.W.Suite 400
Washington D.C 20005 Washington D.C 20005
klaus.gradischnig@neustar.com klaus.gradischnig@neustar.com
Ken Morneault Ken Morneault
Cisco Systems Inc. Cisco Systems Inc.
13615 Dulles Technology Drive 13615 Dulles Technology Drive
Herndon, VA, USA 20171 Herndon, VA, USA 20171
EMail: kmorneau@cisco.com EMail:
Malleswar Kalla Malleswar Kalla
Telcordia Technologies Telcordia Technologies
MCC 1J211R MCC 1J211R
445 South Street 445 South Street
Morristown, NJ, USA 07960 Morristown, NJ, USA 07960
Email: kalla@research.telcordia.com Email: kalla@research.telcordia.com
Normand Glaude Normand Glaude
Performance Technologies Performance Technologies
150 Metcalf Sreet, Suite 1300 150 Metcalf Sreet, Suite 1300
Ottawa, Ontario, Canada K2P 1P1 Ottawa, Ontario, Canada K2P 1P1
EMail: nglaude@microlegend.com EMail: nglaude@microlegend.com
Brian Bidulock
OpenSS7 Corporation
c/o #424, 4701 Preston Park Blvd.
Plano, TX, USA 75093
EMail: bidulock@openss7.org
This draft expires December 2001. This draft expires December 2001.
 End of changes. 

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