draft-ietf-sigtran-m3ua-10.txt   draft-ietf-sigtran-m3ua-11.txt 
Network Working Group Greg Sidebottom Network Working Group Greg Sidebottom
INTERNET-DRAFT gregside consulting INTERNET-DRAFT gregside consulting
Javier Pastor-Balbs, Ian Rytina Javier Pastor-Balbas, Ian Rytina
Ericsson Ericsson
Guy Mousseau Guy Mousseau
Nortel Networks Nortel Networks
Lyndon Ong Lyndon Ong
Ciena Ciena
Hanns Juergen Schwarzbauer Hanns Juergen Schwarzbauer
Siemens Siemens
Klaus Gradischnig Klaus Gradischnig
NeuStar NeuStar
Ken Morneault Ken Morneault
Cisco Cisco
Mallesh Kalla Mallesh Kalla
Telcordia Telcordia
Normand Glaude Normand Glaude
Performance Technologies Performance Technologies
Brian Bidulock Brian Bidulock
OpenSS7 OpenSS7
John Loughney John Loughney
Nokia Nokia
Expires in six months Nov 2001 Expires in six months Jan 2002
SS7 MTP3-User Adaptation Layer (M3UA) SS7 MTP3-User Adaptation Layer (M3UA)
<draft-ietf-sigtran-m3ua-10.txt> <draft-ietf-sigtran-m3ua-11.txt>
Status of This Memo Status of This Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026. Internet-Drafts are working provisions of Section 10 of RFC 2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working its working groups. Note that other groups may also distribute working
documents as Internet-Drafts. documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 3, line 22 skipping to change at page 3, line 22
1.5 Sample Configurations........................................16 1.5 Sample Configurations........................................16
1.6 Definition of M3UA Boundaries................................19 1.6 Definition of M3UA Boundaries................................19
2. Conventions.......................................................24 2. Conventions.......................................................24
3. M3UA Protocol Elements............................................24 3. M3UA Protocol Elements............................................24
3.1 Common Message Header........................................24 3.1 Common Message Header........................................24
3.2 Variable Length Parameter....................................26 3.2 Variable Length Parameter....................................26
3.3 Transfer Messages............................................29 3.3 Transfer Messages............................................29
3.4 SS7 Signalling Network management (SSNM) Messages............32 3.4 SS7 Signalling Network management (SSNM) Messages............32
3.5 ASP State Maintenance (ASPM) Messages........................41 3.5 ASP State Maintenance (ASPM) Messages........................41
3.6 Routing Key Management (RKM) Messages........................44 3.6 Routing Key Management (RKM) Messages........................44
3.7 ASP Traffic Maintenance (ASPTM) Messages.....................54 3.7 ASP Traffic Maintenance (ASPTM) Messages.....................57
3.8 Management(MGMT) Messages....................................58 3.8 Management (MGMT) Messages...................................61
4. Procedures........................................................63 4. Procedures........................................................66
4.1 Procedures to Support the M3UA-User .........................63 4.1 Procedures to Support the M3UA-User .........................66
4.2 Procedures to Support the Management of SCTP Associations ...66 4.2 Procedures to Support the Management of SCTP Associations ...69
4.3 AS and ASP State Maintenance.................................66 4.3 AS and ASP State Maintenance.................................69
4.4 Routing Key Management Procedures............................79 4.4 Routing Key Management Procedures............................81
4.5 Procedures to Support the Availability or Congestion Status 4.5 Procedures to Support the Availability or Congestion Status
of SS7 Destination...........................................81 of SS7 Destination...........................................83
4.6 MTP3 Restart.................................................84 4.6 MTP3 Restart.................................................86
5. Examples of M3UA Procedures.......................................85 5. Examples of M3UA Procedures.......................................86
5.1 Establishment of Association and Traffic 5.1 Establishment of Association and Traffic
Between SGs and ASPs.........................................85 Between SGs and ASPs.........................................86
5.2 ASP traffic Failover Examples................................89 5.2 ASP traffic Failover Examples................................91
5.3 Normal Withdrawal of an ASP from an Application Server 5.3 Normal Withdrawal of an ASP from an Application Server
and Teardown of an Association...............................91 and Teardown of an Association...............................92
5.4.M3UA/MTP3-User Boundary Examples.............................91 5.4 M3UA/MTP3-User Boundary Examples.............................93
5.5.Examples for IPSP Communication..............................95 6. Security Considerations...........................................97
6. Security..........................................................97
6.1 Introduction.................................................97 6.1 Introduction.................................................97
6.2 Threats......................................................97 6.2 Threats......................................................97
6.3 Protecting Confidentiality...................................97 6.3 Protecting Confidentiality...................................98
7. IANA Considerations...............................................98 7. IANA Considerations...............................................98
7.1 SCTP Payload Protocol Identifier.............................98 7.1 SCTP Payload Protocol Identifier.............................98
7.2 M3UA Port Number.............................................98 7.2 M3UA Port Number.............................................98
7.3 M3UA Protocol Extensions.....................................99 7.3 M3UA Protocol Extensions.....................................99
8. Acknowledgements..................................................99 8. Acknowledgements.................................................100
9. References........................................................99 9. References.......................................................100
11. Author's Addresses.............................................101 9.1 Normative References........................................100
Appendix A..........................................................104 9.2 Informative References......................................100
11. Author's Addresses..............................................102
Appendix A..........................................................103
1. Introduction 1. Introduction
This draft defines a protocol for supporting the transport of This draft defines a protocol for supporting the transport of
any SS7 MTP3-User signalling (e.g., ISUP and SCCP messages) over IP any SS7 MTP3-User signalling (e.g., ISUP and SCCP messages) over IP
using the services of the Stream Control Transmission Protocol [13]. Also, provision is made for protocol elements that enable a seamless using the services of the Stream Control Transmission Protocol [16]. Also, provision is made for protocol elements that enable a seamless
operation of the MTP3-User peers in the SS7 and IP domains. This operation of the MTP3-User peers in the SS7 and IP domains. This
protocol would be used between a Signalling Gateway (SG) and a Media protocol would be used between a Signalling Gateway (SG) and a Media
Gateway Controller (MGC) or IP-resident Database [1]. Gateway Controller (MGC) or IP-resident Database [10].
1.1 Scope 1.1 Scope
There is a need for Switched Circuit Network (SCN) signalling protocol There is a need for Switched Circuit Network (SCN) signalling protocol
delivery from an SS7 Signalling Gateway (SG) to a Media Gateway delivery from an SS7 Signalling Gateway (SG) to a Media Gateway
Controller (MGC) or IP-resident Database as described in the Framework Controller (MGC) or IP-resident Database as described in the Framework
Architecture for Signalling Transport [1]. The delivery mechanism Architecture for Signalling Transport [10]. The delivery mechanism
should meet the following criteria: should meet the following criteria:
* Support for the transfer of all SS7 MTP3-User Part messages (e.g., * Support for the transfer of all SS7 MTP3-User Part messages (e.g.,
ISUP [2,3,4], SCCP [5,6,7], TUP [8] , etc.) ISUP [1,2,3], SCCP [4,5,6], TUP [11], etc.)
* Support for the seamless operation of MTP3-User protocol peers * Support for the seamless operation of MTP3-User protocol peers
* Support for the management of SCTP transport associations and * Support for the management of SCTP transport associations and
traffic between an SG and one or more MGCs or IP-resident Databases traffic between an SG and one or more MGCs or IP-resident Databases
* Support for MGC or IP-resident Database process failover and load * Support for MGC or IP-resident Database process failover and load
sharing sharing
* Support for the asynchronous reporting of status changes to * Support for the asynchronous reporting of status changes to
management management
In simplistic transport terms, the SG will terminate SS7 MTP2 and MTP3 In simplistic transport terms, the SG will terminate SS7 MTP2 and MTP3
protocol layers [14,15,16] and deliver ISUP, SCCP and/or any other protocol layers [7,8,9] and deliver ISUP, SCCP and/or any other
MTP3-User protocol messages, as well as certain MTP network management MTP3-User protocol messages, as well as certain MTP network management
events, over SCTP transport associations to MTP3-User peers in MGCs or events, over SCTP transport associations to MTP3-User peers in MGCs or
IP-resident Databases. IP-resident Databases.
1.2 Terminology 1.2 Terminology
Application Server (AS) - A logical entity serving a specific Routing Application Server (AS) - A logical entity serving a specific Routing
Key. An example of an Application Server is a virtual switch element Key. An example of an Application Server is a virtual switch element
handling all call processing for a unique range of PSTN trunks, handling all call processing for a unique range of PSTN trunks,
identified by an SS7 SIO/DPC/OPC/CIC_range. Another example is a identified by an SS7 SIO/DPC/OPC/CIC_range. Another example is a
skipping to change at page 6, line 21 skipping to change at page 6, line 21
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.
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, backup, loadsharing or broadcast Gateway. It serves as an active, backup, loadsharing or broadcast
process of a 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 [10]. An SG appears to
the SS7 network as an SS7 Signalling Point. An SG contains a set of 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 one or more unique Signalling Gateway Processes, of which one or more
is normally actively processing traffic. Where an SG contains more is normally actively processing traffic. Where an SG contains more
than one SGP, the SG is a logical entity and the contained SGPs are than one SGP, the SG is a logical entity and the contained SGPs are
assumed to be coordinated into a single management view to the SS7 assumed to be coordinated into a single management view to the SS7
network and to the 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 processes. 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.
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 a single MTP Application Servers represented to the SS7 network under a single MTP
entity (Signalling Point) in one specific Network Appearance. SPMCs entity (Signalling Point) in one specific Network Appearance. SPMCs
are used to aggregate the availability, congestion, and user part status are used to aggregate the availability, congestion, and user part status of an MTP entity (Signalling Point) that is distributed in the IP domain, for the purpose of supporting MTP3 management procedures
of an MTP entity (Signalling Point) that is distributed in the IP domain,
for the purpose of supporting MTP3 management procedures
towards the SS7 network. In some cases, the SG itself may also be a towards the SS7 network. In some cases, the SG itself may also be a
member of the SPMC. In this case, the SG availability /congestion member of the SPMC. In this case, the SG availability /congestion
/User_Part status should also be taken into account when considering any /User_Part status should also be taken into account when considering any supporting MTP3 management actions.
supporting MTP3 management actions.
Stream - A stream refers to an SCTP stream; a unidirectional logical Stream - A stream refers to an SCTP stream; a unidirectional logical
channel established from one SCTP endpoint to another associated SCTP channel established from one SCTP endpoint to another associated SCTP
endpoint, within which all user messages are delivered in-sequence endpoint, within which all user messages are delivered in-sequence
except for those submitted to the unordered delivery service. except for those submitted to the unordered delivery service.
1.3 M3UA Overview 1.3 M3UA Overview
1.3.1 Protocol Architecture. 1.3.1 Protocol Architecture.
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 [10] uses multiple components, including a common
signalling transport protocol and an adaptation module to support the signalling transport protocol and an adaptation module to support the
services expected by a particular SCN signalling protocol from its services expected by a particular SCN signalling protocol from its
underlying protocol layer. underlying protocol layer.
Within the framework architecture, this document defines an MTP3-User Within the framework architecture, this document defines an MTP3-User
adaptation module suitable for supporting the transfer of messages of adaptation module suitable for supporting the transfer of messages of
any protocol layer that is identified to the MTP Level 3 as an MTP any protocol layer that is identified to the MTP Level 3 as an MTP
User. The list of these protocol layers includes, but is not limited User. The list of these protocol layers includes, but is not limited
to, ISDN User Part (ISUP) [1,2,3], Signalling Connection Control Part
to, ISDN User Part (ISUP) [2,3,4], Signalling Connection Control Part (SCCP) [4,5,6] and Telephone User Part (TUP) [11]. TCAP [12,13,14] or
(SCCP) [5,6,7] and Telephone User Part (TUP) [8]. TCAP [9,10,11] or RANAP [15] messages are transferred transparently by the M3UA protocol
RANAP [12] messages are transferred transparently by the M3UA protocol
as SCCP payload, as they are SCCP-User protocols. as SCCP payload, as they are SCCP-User protocols.
It is recommended that M3UA use the services of the Stream Control It is recommended that M3UA use the services of the Stream Control
Transmission Protocol (SCTP) [13] as the underlying reliable common Transmission Protocol (SCTP) [16] 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,
- Optional multiplexing of user messages into SCTP datagrams, - Optional multiplexing of user messages into SCTP datagrams,
- Network-level fault tolerance through support of multi-homing - Network-level fault tolerance through support of multi-homing
at either or both ends of an association, at either or both ends of an association,
skipping to change at page 8, line 26 skipping to change at page 8, line 26
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.
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, minimizing be routed or support load balancing across the SGPs, minimizing
missequencing. missequencing.
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 [7,8,9]. 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/reassembly M3UA/SCTP, without the need for an upper layer segmentation/reassembly
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 interworking to a SS7 network that does not support the transfer when interworking 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. The potential ISUP or SCCP fragmentation requirements at the SGPs. The
provisioning and configuration of the SS7 network determines the provisioning and configuration of the SS7 network determines the
restriction placed on the maximum block size. Some configurations restriction placed on the maximum block size. Some configurations
(e.g., Broadband MTP [20]) may permit larger block sizes. (e.g., Broadband MTP [20]) may permit larger block sizes.
skipping to change at page 10, line 32 skipping to change at page 10, line 31
For example, within an SS7 network, a Signalling Gateway might be For example, within an SS7 network, a Signalling Gateway might be
charged with representing a set of nodes in the IP domain into the SS7 charged with representing a set of nodes in the IP domain into the SS7
network for routing purposes. The SG itself, as a signalling point in network for routing purposes. The SG itself, as a signalling point in
the SS7 network, might also be addressable with an SS7 Point Code for the SS7 network, might also be addressable with an SS7 Point Code for
MTP3 Management purposes. The SG Point Code might also be used for MTP3 Management purposes. The SG Point Code might also be used for
addressing any local MTP3-Users at the SG such as a local SCCP layer. addressing any local MTP3-Users at the SG such as a local SCCP layer.
An SG may be logically partitioned to operate in multiple SS7 network An SG may be logically partitioned to operate in multiple SS7 network
appearances. In such a case, the SG could be addressable with a Point appearances. In such a case, the SG could be addressable with a Point
Code in each network appearance, and represents a set of nodes in the Code in each network appearance, and represents a set of nodes in the
IP domain into each SS7 network. Alias Point Codes [15] may also be IP domain into each SS7 network. Alias Point Codes [8] may also be
used within an SG network appearance. used within an SG network appearance.
Where an SG contains more than one SGP, the MTP3 routeset, SPMC and Where an SG contains more than one SGP, the MTP3 routeset, SPMC and
remote AS/ASP states of each SGP SHOULD be coordinated across all the remote AS/ASP states of each SGP SHOULD be coordinated across all the
SGPs. Rerouting of traffic between the SGPs MAY also be supported. SGPs. Rerouting of traffic between the SGPs MAY also be supported.
Application Servers can be represented under the same Point Application Servers can be represented under the same Point
Code of the SG, their own individual Point Codes or grouped with other Code of the SG, their own individual Point Codes or grouped with other
Application Servers for Point Code preservation purposes. A single Application Servers for Point Code preservation purposes. A single
Point Code may be used to represent the SG and all the Application Point Code may be used to represent the SG and all the Application
Servers together, if desired. Servers together, if desired.
If an ASP or group of ASPs is available to the SS7 network via more If an ASP or group of ASPs is available to the SS7 network via more
than one SG, each with its own Point Code, the ASP(s) will typically be than one SG, each with its own Point Code, the ASP(s) will typically be
represented by a Point Code that is separate from any SG Point Code. represented by a Point Code that is separate from any SG Point Code.
This allows, for example, these SGs to be viewed from the SS7 network This allows, for example, these SGs to be viewed from the SS7 network
as "STPs", each as "STPs", each having an ongoing "route" to the same ASP(s). Under failure conditions where the ASP(s) become(s) unavailable from one of the SGs, this approach enables MTP3 route management messaging between the SG and SS7 network, allowing simple SS7 rerouting through an alternate SG without changing the Destination Point Code Address of SS7 traffic to the ASP(s).
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
approach enables MTP3 route management messaging between the SG and SS7
network, allowing simple SS7 rerouting through an alternate SG without
changing the Destination Point Code Address of SS7 traffic to the
ASP(s).
Where a particular AS can be reached via more than one SGP, the Where a particular AS can be reached via more than one SGP, the
corresponding Routing Keys in the SGPs should be identical. (Note: corresponding Routing Keys in the SGPs should be identical. (Note:
It is possible for the SGP Routing Key configuration data to be It is possible for the SGP Routing Key configuration data to be
temporarily out-of-sync during configuration updates). temporarily out-of-sync during configuration updates).
+--------+ +--------+
| | | |
+------------+ SG 1 +--------------+ +------------+ SG 1 +--------------+
+-------+ | SS7 links | "STP" | IP network | ---- +-------+ | SS7 links | "STP" | IP network | ----
skipping to change at page 12, line 55 skipping to change at page 12, line 52
1.4.2.4 Message Distribution at the SGP 1.4.2.4 Message Distribution at the SGP
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 might, for example, To support this message distribution, the SGP might, for example,
maintain the equivalent of a network address translation table, mapping maintain the equivalent of a network address translation table, mapping
incoming SS7 message information to an Application Server for a incoming SS7 message information to an Application Server for a
particular application and range of traffic. This could be accomplished particular application and range of traffic. This could be accomplished by comparing elements of the incoming SS7 message to
currently defined Routing Keys in the SGP.
by comparing elements of the incoming SS7 message to currently defined These Routing Keys could in turn map directly to an Application Server that is enabled by one or more ASPs. These ASPs provide dynamic status information regarding their availability, traffic handling capability and congestion to the SGP using various management messages defined in the M3UA protocol.
Routing Keys in the SGP. These Routing Keys could in turn map directly
to an Application Server that is enabled by one or more ASPs. These
ASPs provide dynamic status information regarding their availability,
traffic handling capability and congestion to the SGP using various
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 failover mechanisms. possible failover mechanisms.
Normally, one or more ASPs are active (i.e., currently processing Normally, one or more ASPs are active (i.e., currently processing
traffic) in the AS 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. Broadcast, possible that there may be no active ASP available. Broadcast,
loadsharing and backup scenarios are supported. loadsharing and backup scenarios are supported.
skipping to change at page 13, line 34 skipping to change at page 13, line 29
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 and provide a notification to layer management. The treatment message and provide a notification to layer management. The treatment
of unallocated traffic is implementation dependent. of unallocated traffic is implementation dependent.
1.4.2.5 Message Distribution at the ASP 1.4.2.5 Message Distribution at the ASP
The ASP must choose an SGP to direct a message to the SS7 network. The ASP must choose an SGP to direct a message to the SS7 network.
This is accomplished by observing the Destination Point Code (and This is accomplished by observing the Destination Point Code (and
possibly other elements of the outgoing message such as the SLS value). possibly other elements of the outgoing message such as the SLS value).
The ASP must also take into account whether the related Routing Context is active or not (See Section 4.3.4.3).
Implementation Note: 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 could, for example, possible for routing to the SS7 network, the ASP could, for example,
maintain a dynamic table of available SGP routes for the SS7 maintain a dynamic table of available SGP routes for the SS7
destinations, taking into account the SS7 destination destinations, taking into account the SS7 destination
availability/restricted/congestion status received from the SGP(s), the availability/restricted/congestion status received from the SGP(s), the
availability status of the individual SGPs and configuration changes availability status of the individual SGPs and configuration changes
and failover mechanisms. There is, however, no M3UA messaging to manage and failover mechanisms. There is, however, no M3UA messaging to manage
the status of an SGP (e.g., SGP-Up/Down/Active/Inactive messaging). the status of an SGP (e.g., SGP-Up/Down/Active/Inactive messaging).
skipping to change at page 14, line 13 skipping to change at page 14, line 13
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
The SG is responsible for terminating MTP Level 3 of the SS7 protocol, The SG is responsible for terminating MTP Level 3 of the SS7 protocol,
and offering an IP-based extension to its users. and offering an IP-based extension to its users.
>From an SS7 perspective, it is expected that the Signalling Gateway >From an SS7 perspective, it is expected that the Signalling Gateway
transmits and receives SS7 Message Signalling Units (MSUs) to and transmits and receives SS7 Message Signalling Units (MSUs) to and
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) [7,8,9] 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) [26] or M2PA [27]. the services of the MTP2-User Adaptation Layer (M2UA) [26] or M2PA [27].
skipping to change at page 19, line 45 skipping to change at page 19, line 45
Note that the services and interface provided by the M3UA layer are the Note that the services and interface provided by the M3UA layer are the
same as in Example 1 and the functions taking place in the SCCP entity same as in Example 1 and the functions taking place in the SCCP entity
are transparent to the M3UA layer. The SCCP protocol functions are not are transparent to the M3UA layer. The SCCP protocol functions are not
reproduced in the M3UA protocol. reproduced in the M3UA protocol.
1.6 Definition of M3UA Boundaries 1.6 Definition of M3UA Boundaries
1.6.1 Definition of the Boundary between M3UA and an MTP3-User. 1.6.1 Definition of the Boundary between M3UA and an MTP3-User.
>From ITU Q.701 [14]: >From ITU Q.701 [7]:
MTP-TRANSFER request MTP-TRANSFER request
MTP-TRANSFER indication MTP-TRANSFER indication
MTP-PAUSE indication MTP-PAUSE indication
MTP-RESUME indication MTP-RESUME indication
MTP-STATUS indication MTP-STATUS indication
1.6.2 Definition of the Boundary between M3UA and SCTP 1.6.2 Definition of the Boundary between M3UA and SCTP
An example of the upper layer primitives provided by the SCTP are An example of the upper layer primitives provided by the SCTP are
provided in Reference [13] Section 10. provided in Reference [16] Section 10.
1.6.3 Definition of the Boundary between M3UA and Layer Management 1.6.3 Definition of the Boundary between M3UA and Layer Management
M-SCTP_ESTABLISH request M-SCTP_ESTABLISH request
Direction: LM -> M3UA Direction: LM -> M3UA
Purpose: LM requests ASP to establish an SCTP association with its Purpose: LM requests ASP to establish an SCTP association with its
peer. peer.
M-STCP_ESTABLISH confirm M-STCP_ESTABLISH confirm
Direction: M3UA -> LM Direction: M3UA -> LM
skipping to change at page 24, line 9 skipping to change at page 24, line 9
M-RK_DEREG indication M-RK_DEREG indication
Direction: M3UA -> LM Direction: M3UA -> LM
Purpose: M3UA informs LM that it has successfully processed an Purpose: M3UA informs LM that it has successfully processed an
incoming DEREG REQ from its peer. incoming DEREG REQ from its peer.
2. Conventions 2. Conventions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD
NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear
in this document, are to be interpreted as described in [RFC2119]. in this document, are to be interpreted as described in [19].
3. M3UA Protocol Elements 3. M3UA Protocol Elements
The general M3UA message format includes a Common Message Header The general M3UA message format includes a Common Message Header
followed by zero or more parameters as defined by the Message Type. followed by zero or more parameters as defined by the Message Type.
For forward compatibility, all Message Types may have attached For forward compatibility, all Message Types may have attached
parameters even if none are specified in this version. parameters even if none are specified in this version.
3.1 Common Message Header 3.1 Common Message Header
skipping to change at page 28, line 4 skipping to change at page 27, line 54
Heartbeat Data 0x0009 Heartbeat Data 0x0009
Not Used in M3UA 0x000a Not Used in M3UA 0x000a
Traffic Mode Type 0x000b Traffic Mode Type 0x000b
Error Code 0x000c Error Code 0x000c
Status 0x000d Status 0x000d
Not Used in M3UA 0x000e Not Used in M3UA 0x000e
Not Used in M3UA 0x000f Not Used in M3UA 0x000f
Not Used in M3UA 0x0010 Not Used in M3UA 0x0010
ASP Identifier 0x0011 ASP Identifier 0x0011
Affected Point Code 0x0012 Affected Point Code 0x0012
Correlation ID 0x0013
M3UA-Specific parameters. These TLV parameters are specific to the M3UA-Specific parameters. These TLV parameters are specific to the
M3UA protocol: M3UA protocol:
Network Appearance 0x0200 Network Appearance 0x0200
Reserved 0x0201 Reserved 0x0201
Reserved 0x0202 Reserved 0x0202
Reserved 0x0203 Reserved 0x0203
User/Cause 0x0204 User/Cause 0x0204
Congestion Indications 0x0205 Congestion Indications 0x0205
Concerned Destination 0x0206 Concerned Destination 0x0206
Routing Key 0x0207 Routing Key 0x0207
Registration Result 0x0208 Registration Result 0x0208
Deregistration Result 0x0209 Deregistration Result 0x0209
Local_Routing Key Identifier 0x020a Local_Routing Key Identifier 0x020a
Destination Point Code 0x020b Destination Point Code 0x020b
Service Indicators 0x020c Service Indicators 0x020c
Subsystem Numbers 0x020d Subsystem Numbers 0x020d
Originating Point Code List 0x020e Originating Point Code List 0x020e
Circuit Range 0x020f Circuit Range 0x020f
Protocol Data 0x0210 Protocol Data 0x0210
Correlation Id 0x0211 Reserved 0x0211
Registration Status 0x0212 Registration Status 0x0212
Deregistration Status 0x0213 Deregistration Status 0x0213
Reserved by the IETF 0x0214 to 0xffff Reserved by the IETF 0x0214 to 0xffff
The value of 65535 is reserved for IETF-defined extensions. Values The value of 65535 is reserved for IETF-defined extensions. Values
other than those defined in specific parameter description are other than those defined in specific parameter description are
reserved for use by the IETF. reserved for use by the IETF.
Parameter Length: 16 bits (unsigned integer) Parameter Length: 16 bits (unsigned integer)
skipping to change at page 29, line 40 skipping to change at page 29, line 40
| Tag = 0x0006 | Length = 8 | | Tag = 0x0006 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Routing Context | | Routing Context |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0210 | Length | | Tag = 0x0210 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ Protocol Data / / Protocol Data /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0211 | Length = 8 | | Tag = 0x0013 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Correlation Id | | Correlation Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Network Appearance: 32-bits (unsigned integer) Network Appearance: 32-bits (unsigned integer)
The Network Appearance parameter identifies the SS7 network The Network Appearance parameter identifies the SS7 network
context for the message and implicitly identifies the SS7 context for the message and implicitly identifies 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
skipping to change at page 30, line 41 skipping to change at page 30, line 41
Routing Context: 32-bits (unsigned integer) Routing Context: 32-bits (unsigned integer)
The Routing Context parameter contains the Routing Context The Routing Context parameter contains the Routing Context
value associated with the DATA message. Where a Routing Key has value associated with the DATA message. Where a Routing Key has
not been coordinated between the SGP and ASP, sending of Routing not been coordinated between the SGP and ASP, sending of Routing
Context is not required. Where multiple Routing Context is not required. Where multiple Routing
Keys and Routing Contexts are used across a common association, the Keys and Routing Contexts are used across a common association, the
Routing Context MUST be sent to identify the traffic flow, Routing Context MUST be sent to identify the traffic flow,
assisting in the internal distribution of Data messages. assisting in the internal distribution of Data messages.
Protocol Data 1 or 2: variable length Protocol Data: variable length
The Protocol Data parameter contains the original SS7 MTP3 The Protocol Data parameter contains the original SS7 MTP3
message, including the Service Information Octet and Routing Label. message, including the Service Information Octet and Routing Label.
The Protocol Data parameter contains the following fields: The Protocol Data parameter contains the following fields:
Service Indicator, Service Indicator,
Network Indicator, Network Indicator,
Message Priority. Message Priority.
skipping to change at page 34, line 7 skipping to change at page 34, line 7
not been coordinated between the SGP and ASP, sending of Routing not been coordinated between the SGP and ASP, sending of Routing
Context is not required. Where multiple Routing Keys and Routing Context is not required. Where multiple Routing Keys and Routing
Contexts are used across a common association, the Routing Contexts are used across a common association, the Routing
Context(s) MUST be sent to identify the concerned traffic flows Context(s) MUST be sent to identify the concerned traffic flows
for which the DUNA message applies, assisting in outgoing traffic for which the DUNA message applies, assisting in outgoing traffic
management and internal distribution of MTP-PAUSE indications to management and internal distribution of MTP-PAUSE indications to
MTP3-Users at the receiver. MTP3-Users at the receiver.
Affected Point Code: n x 32-bits Affected Point Code: n x 32-bits
The Affected Point Code parameter contains up to sixteen Affected The Affected Point Code parameter contains a list of Affected
Destination Point Code fields, each a three-octet parameter to allow Destination Point Code fields, each a three-octet parameter to allow
for 14-, 16- and 24-bit binary formatted SS7 Point Codes. Affected for 14-, 16- and 24-bit binary formatted SS7 Point Codes. Affected
Point Codes that are less than 24-bits, are padded on the left to Point Codes that are less than 24-bits, are padded on the left to
the 24-bit boundary. The encoding is shown below for ANSI and ITU the 24-bit boundary. The encoding is shown below for ANSI and ITU
Point Code examples. Point Code examples.
ANSI 24-bit Point Code: ANSI 24-bit Point Code:
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
skipping to change at page 34, line 35 skipping to change at page 34, line 35
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask |0 0 0 0 0 0 0 0 0 0|Zone | Region | SP | | Mask |0 0 0 0 0 0 0 0 0 0|Zone | Region | SP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MSB--------------------LSB| |MSB--------------------LSB|
It is optional to send an Affected Point Code parameter with more It is optional to send an Affected Point Code parameter with more
than one Affected PC but it is mandatory to receive it. All the than one Affected PC but it is mandatory to receive it. Including
Affected PCs included must be within the same Network Appearance multiple Affected PCs may be useful when reception of an MTP3
and/or (set of) Routing Context values included in a Routing Context management message or a linkset event simultaneously affects the
parameter. Including multiple Affected PCs may be useful when availability status of a list of destinations at an SG.
reception of an MTP3 management message or a linkset event
simultaneously affects the availability status of a list of
destinations at an SG.
Mask: 8-bits (unsigned integer) Mask: 8-bits (unsigned integer)
The Mask field can be used to identify a contiguous range of The Mask field can be used to identify a contiguous range of
Affected Destination Point Codes, independent of the point code Affected Destination Point Codes. Identifying a contiguous range of
format. Identifying a contiguous range of Affected DPCs may be Affected DPCs may be useful when reception of an MTP3 management
useful when reception of an MTP3 management message or a linkset message or a linkset event simultaneously affects the availability
event simultaneously affects the availability status of a series of status of a series of destinations at an SG.
destinations at an SG.
The Mask parameter is an integer representing a bit mask that can be The Mask parameter is an integer representing a bit mask that can be
applied to the related Affected PC field. The bit mask identifies applied to the related Affected PC field. The bit mask identifies
how many bits of the Affected PC field are significant and which are how many bits of the Affected PC field are significant and which are
effectively "wildcarded". For example, a mask of "8" indicates that effectively "wildcarded". For example, a mask of "8" indicates that
the last eight bits of the PC is "wildcarded". For an ANSI 24- the last eight bits of the PC is "wildcarded". For an ANSI 24-
bit Affected PC, this is equivalent to signalling that all PCs in bit Affected PC, this is equivalent to signalling that all PCs 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
last three bits of the PC is "wildcarded". For a 14-bit ITU last three bits of the PC is "wildcarded". For a 14-bit ITU
Affected PC, this is equivalent to signaling that an ITU Affected PC, this is equivalent to signaling that an ITU
skipping to change at page 38, line 35 skipping to change at page 38, line 35
The Congestion Level field, associated with all of the Affected The Congestion Level field, associated with all of the Affected
DPC(s) in the Affected Destinations parameter, contains one of the DPC(s) in the Affected Destinations parameter, contains one of the
Following values: Following values:
0 No Congestion or Undefined 0 No Congestion or Undefined
1 Congestion Level 1 1 Congestion Level 1
2 Congestion Level 2 2 Congestion Level 2
3 Congestion Level 3 3 Congestion Level 3
The congestion levels are defined in the congestion method in the The congestion levels are defined in the congestion method in the
appropriate national MTP recommendations [14,15]. appropriate national MTP recommendations [7,8].
3.4.5 Destination User Part Unavailable (DUPU) 3.4.5 Destination User Part Unavailable (DUPU)
The DUPU message is used by an SGP to inform concerned ASPs that a The DUPU message is used by an SGP to inform concerned ASPs that a
remote peer MTP3-User Part (e.g., ISUP or SCCP) at an SS7 node is remote peer MTP3-User Part (e.g., ISUP or SCCP) at an SS7 node is
unavailable. unavailable.
The DUPU message contains the following parameters: The DUPU message contains the following parameters:
Network Appearance Optional Network Appearance Optional
skipping to change at page 40, line 5 skipping to change at page 39, line 54
The values agree with those provided in the SS7 MTP3 User Part The values agree with those provided in the SS7 MTP3 User Part
Unavailable message. Depending on the MTP3 protocol used in the Unavailable message. Depending on the MTP3 protocol used in the
Network Appearance, additional values may be used - the Network Appearance, additional values may be used - the
specification of the relevant MTP3 protocol variant/version specification of the relevant MTP3 protocol variant/version
recommendation is definitive. recommendation is definitive.
0 Unknown 0 Unknown
1 Unequipped Remote User 1 Unequipped Remote User
2 Inaccessible Remote User 2 Inaccessible Remote User
Sidebottom et al
MTP3-User Identity field: 16-bits (unsigned integer) MTP3-User Identity field: 16-bits (unsigned integer)
The MTP3-User Identity describes the specific MTP3-User that is The MTP3-User Identity describes the specific MTP3-User that is
unavailable (e.g., ISUP, SCCP, ...). Some of the valid values for unavailable (e.g., ISUP, SCCP, ...). Some of the valid values for
the MTP3-User Identity are shown below. The values align with those the MTP3-User Identity are shown below. The values align with those
provided in the SS7 MTP3 User Part Unavailable message and Service provided in the SS7 MTP3 User Part Unavailable message and Service
Indicator. Depending on the MTP3 protocol variant/version used in Indicator. Depending on the MTP3 protocol variant/version used in
the network appearance, additional values may be used. The relevant the network appearance, additional values may be used. The relevant
MTP3 protocol variant/version recommendation is definitive. MTP3 protocol variant/version recommendation is definitive.
skipping to change at page 41, line 25 skipping to change at page 41, line 25
The format and description of the Network Appearance, Routing Context, The format and description of the Network Appearance, Routing Context,
Affected Point Code and INFO String parameters is the same as for the Affected Point Code and INFO String parameters is the same as for the
DUNA message (See Section 3.4.1). DUNA message (See Section 3.4.1).
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 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 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
skipping to change at page 47, line 34 skipping to change at page 47, line 34
| Traffic Mode Type | | Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for Traffic Mode Type are shown in the The valid values for Traffic Mode Type are shown in the
following table: following table:
1 Override 1 Override
2 Loadshare 2 Loadshare
3 Broadcast 3 Broadcast
If the receiver of the REG REQ creates a new Routing Key entry, then
the Traffic Mode Type sets the traffic mode for the new Application
Server. If the receiver of the REG REQ determines that a matching
Routing Key already exists, and the traffic mode was specified in the Routing Key, the Traffic Mode Type MUST match the
existing traffic mode for the AS.
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
skipping to change at page 50, line 40 skipping to change at page 50, line 40
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0208 | Length | | Tag = 0x0208 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Result n | | Registration Result n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Registration Results: Registration Results:
The Registration Result parameter contains the registration result The Registration Result parameter contains the registration result
for a single Routing Key in an REG REQ message. The number of for a single Routing Key in an REG REQ message. The number of
results in a single REG RSP message MAY MUST be anywhere from one to the results in a single REG RSP message MAY MUST be anywhere from one to
total number of number of Routing Key parameters found in the the total number of number of Routing Key parameters found in the
corresponding REG REQ message. Where multiple REG RSP messages are corresponding REG REQ message. Where multiple REG RSP messages are
used in reply to REG REQ message, a specific result SHOULD be in used in reply to REG REQ message, a specific result SHOULD be in
only one REG RSP message. The format of each result is as follows: only one REG RSP message. The format of each result is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x020a | Length = 8 | | Tag = 0x020a | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local-RK-Identifier value | | Local-RK-Identifier value |
skipping to change at page 55, line 10 skipping to change at page 58, line 10
The Traffic Mode Type parameter identifies the traffic mode of The Traffic Mode Type parameter identifies the traffic mode of
operation of the ASP within an AS. The valid values for Traffic Mode operation of the ASP within an AS. The valid values for Traffic Mode
Type are shown in the following table: Type are shown in the following table:
1 Override 1 Override
2 Loadshare 2 Loadshare
3 Broadcast 3 Broadcast
Within a particular Routing Context, Override, Loadshare and Within a particular Routing Context, Override, Loadshare and
Broadcast SHOULD NOT be mixed. The Override value indicates that the Broadcast SHOULD NOT be mixed. The Override value indicates that
ASP is operating in Override mode, and the ASP takes over all the ASP is operating in Override mode, and the ASP takes over all
traffic in an Application Server (i.e., primary/backup operation), traffic in an Application Server (i.e., primary/backup operation),
overriding any currently active ASPs in the AS. In Loadshare mode, overriding any currently active ASPs in the AS. In Loadshare mode,
the ASP will share in the traffic distribution with any other the ASP will share in the traffic distribution with any other
currently active ASPs. In Broadcast mode, the ASP will receive the currently active ASPs. In Broadcast mode, the ASP will receive the
same messages as any other currently active ASP. same messages as any other currently active ASP.
Routing Context: n X 32-bit integers Routing Context: n X 32-bit integers
The optional Routing Context parameter contains (a list of) integers The optional Routing Context parameter contains (a list of) integers
indexing the Application Server traffic that the sending ASP is indexing the Application Server traffic that the sending ASP is
skipping to change at page 56, line 40 skipping to change at page 59, line 41
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 that it is no longer an active ASP to be used from within a list of peer 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
skipping to change at page 60, line 11 skipping to change at page 63, line 11
0x06 Unexpected Message 0x06 Unexpected Message
0x07 Protocol Error 0x07 Protocol Error
0x08 Not used in M3UA 0x08 Not used in M3UA
0x09 Invalid Stream Identifier 0x09 Invalid Stream Identifier
0x0a Not used in M3UA 0x0a Not used in M3UA
0x0b Not used in M3UA 0x0b Not used in M3UA
0x0c Not used in M3UA 0x0c Not used in M3UA
0x0d Refused - Management Blocking 0x0d Refused - Management Blocking
0x0e ASP Identifier Required 0x0e ASP Identifier Required
0x0f Invalid ASP Identifier 0x0f Invalid ASP Identifier
0x10 Invalid Routing Context 0x10 Not Used in M3UA
0x11 Invalid Parameter Value 0x11 Invalid Parameter Value
0x12 Parameter Field Error 0x12 Parameter Field Error
0x13 Unexpected Parameter 0x13 Unexpected Parameter
0x14 Destination Status Unknown 0x14 Destination Status Unknown
0x15 Invalid Network Appearance 0x15 Invalid Network Appearance
0x16 No configured AS for ASP 0x16 Missing Parameter
0x17 Not Used in M3UA
0x18 Not Used in M3UA
0x19 Invalid Routing Context
0x1a No Configured AS for ASP
The "Invalid Version" error is sent if a message was received with an The "Invalid Version" error is sent if a message was received with an
invalid or unsupported version. The Error message contains the invalid or unsupported version. The Error message contains the
supported version in the Common header. The Error message could supported version in the Common header. The Error message could
optionally provide the supported version in the Diagnostic Information optionally provide the supported version in the Diagnostic Information
area. area.
The "Invalid Network Appearance" error is sent by a SGP if an ASP sends
a message with an invalid (unconfigured) Network Appearance value.
For this error, the invalid (unconfigured) Network Appearance MUST be
included in the Network Appearance parameter.
The "Unsupported Message Class" error is sent if a message with an The "Unsupported Message Class" error is sent if a message with an
unexpected or unsupported Message Class is received. unexpected or unsupported Message Class is received.
The "Unsupported Message Type" error is sent if a message with an The "Unsupported Message Type" error is sent if a message with an
unexpected or unsupported Message Type is received. unexpected or unsupported Message Type is received.
The "Unsupported Traffic Handling Mode" error is sent by a SGP The "Unsupported Traffic Handling Mode" error is sent by a SGP
if an ASP sends an ASP Active message with an unsupported Traffic Mode if an ASP sends an ASP Active message with an unsupported Traffic Mode
Type or a Traffic Mode Type that is inconsistent with the presently Type or a Traffic Mode Type that is inconsistent with the presently
configured mode for the Application Server. An example would be a case configured mode for the Application Server. An example would be a case
skipping to change at page 61, line 5 skipping to change at page 64, line 5
message is received that is not expected in the current state (in some message is received that is not expected in the current state (in some
cases the ASP may optionally silently discard the message and not send cases the ASP may optionally silently discard the message and not send
an Error message). For example, silent discard is used by an ASP if it an Error message). For example, silent discard is used by an ASP if it
received a DATA message from an SGP while it was in the ASP-INACTIVE received a DATA message from an SGP while it was in the ASP-INACTIVE
state. If the Unexpected message contained Routing Context(s), the Routing Context(s) SHOULD be included in the Error message. state. If the Unexpected message contained Routing Context(s), the Routing Context(s) SHOULD be included in the Error message.
The "Protocol Error" error is sent for any protocol anomaly (i.e., The "Protocol Error" error is sent for any protocol anomaly (i.e.,
reception of a parameter that is syntactically correct but unexpected reception of a parameter that is syntactically correct but unexpected
in the current situation. in the current situation.
The "Invalid Routing Context" error is sent if a message is received
from a peer with an invalid (unconfigured) Routing Context value, or
if a message is received from a peer without a Routing Context
parameter and it is not known by configuration data which
Application Servers are referenced. For this error, the invalid Routing Context(s) MUST be included in the Error message.
The "No Configured AS for ASP" error is sent if a message is received
from a peer without a Routing Context parameter and it is not known by
configuration data which Application Servers are referenced.
The "Invalid Stream Identifier" error is sent if a message is received The "Invalid Stream Identifier" error is sent if a message is received
on an unexpected SCTP stream (e.g., a Management message was received on an unexpected SCTP stream (e.g., a Management message was received
on a stream other than "0"). on a stream other than "0").
The " Invalid Parameter Value " error is sent if a message is received
with an invalid parameter value (e.g., a DUPU message was received with
a Mask value other than "0" or a Data message was received on stream
"0").
The "Refused - Management Blocking" error is sent when an ASP Up or The "Refused - Management Blocking" error is sent when an ASP Up or
ASP Active message is received and the request is refused for ASP Active message is received and the request is refused for
management reasons (e.g., management lockout"). If this error is in management reasons (e.g., management lockout"). If this error is in
response to an ASP Active message, the Routing Context(s) in the ASP response to an ASP Active message, the Routing Context(s) in the ASP
Active message SHOULD be included in the Error message. Active message SHOULD be included in the Error message.
The "ASP Identifier Required" is sent by a SGP in response The "ASP Identifier Required" is sent by a SGP in response
to an ASP Up message which does not contain an ASP Identifier to an ASP Up message which does not contain an ASP Identifier
parameter when the SGP requires one. The ASP SHOULD resend the parameter when the SGP requires one. The ASP SHOULD resend the
ASP Up message with an ASP Identifier. ASP Up message with an ASP Identifier.
The "Invalid ASP Identifier" is send by a SGP in response The "Invalid ASP Identifier" is send by a SGP in response
to an ASP Up message with an invalid (i.e., non-unique) ASP Identifier. to an ASP Up message with an invalid (i.e., non-unique) ASP Identifier.
The "Invalid Parameter Value " error is sent if a message is received
with an invalid parameter value (e.g., a DUPU message was received with
a Mask value other than "0".
The "Parameter Field Error" would be sent if a message is received The "Parameter Field Error" would be sent if a message is received
with a parameter having a wrong length field. with a parameter having a wrong length field.
The "Unexpected Parameter" error would be sent if a message contains The "Unexpected Parameter" error would be sent if a message contains
an invalid parameter. an invalid parameter.
The "Destination Status Unknown" Error MAY be sent if a DAUD is The "Destination Status Unknown" Error MAY be sent if a DAUD is
received at an SG enquiring of the availability/congestion status of received at an SG enquiring of the availability/congestion status of
a destination, and the SG does not wish to provide the status (e.g., a destination, and the SG does not wish to provide the status (e.g.,
the sender is not authorized to know the status). For this error, the the sender is not authorized to know the status). For this error, the
invalid or unauthorized Point Code(s) MUST be included along with the invalid or unauthorized Point Code(s) MUST be included along with the
Network Appearance and/or Routing Context associated with the Point Network Appearance and/or Routing Context associated with the Point
Code(s). Code(s).
The "Invalid Network Appearance" error is sent by a SGP if an ASP sends
a message with an invalid (unconfigured) Network Appearance value.
For this error, the invalid (unconfigured) Network Appearance MUST be
included in the Network Appearance parameter.
The "Missing Parameter" error would be sent if a mandatory parameter
were not included in a message.
The "Invalid Routing Context" error is sent if a message is received
from a peer with an invalid (unconfigured) Routing Context value. For this error, the invalid Routing Context(s) MUST be included in the Error message.
The "No Configured AS for ASP" error is sent if a message is received
from a peer without a Routing Context parameter and it is not known by
configuration data which Application Servers are referenced.
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. The Diagnostic information identification of the error condition. The Diagnostic information
SHOULD contain the offending message. SHOULD contain the offending message.
Error messages MUST NOT be generated in response to other Error Error messages MUST NOT be generated in response to other Error
messages. messages.
skipping to change at page 63, line 41 skipping to change at page 66, line 41
1 Insufficient ASP Resources Active in AS 1 Insufficient ASP Resources Active in AS
2 Alternate ASP Active 2 Alternate ASP Active
3 ASP Failure 3 ASP Failure
These notifications are not based on the SGP reporting the state change These notifications are not based on the SGP reporting the state change
of an ASP or AS. In the Insufficent ASP Resources case, the SGP is of an ASP or AS. In the Insufficent ASP Resources case, the SGP is
indicating to an ASP_INACTIVE ASP in the AS that another ASP is indicating to an ASP_INACTIVE ASP in the AS that another ASP is
required to handle the load of the AS (Loadsharing or Broadcast mode). required to handle the load of the AS (Loadsharing or Broadcast mode).
For the Alternate ASP Active case, an ASP is informed when an alternate For the Alternate ASP Active case, an ASP is informed when an alternate
ASP transitions to the ASP-ACTIVE state in Override mode. ASP transitions to the ASP-ACTIVE state in Override mode. The ASP
Identifier (if available) of the Alternate ASP MUST be placed in the
message. For the ASP Failure case, the SGP is indicating to ASP(s)
in the AS that one of the ASPs has transitioned to ASP-DOWN. The ASP
Identifier (if available) of the failed ASP MUST be placed in the
message.
The format and description of the optional ASP Identifier, Routing The format and description of the optional ASP Identifier is the same as for the ASP Up message (See Section 3.5.1). The format and description of the Routing Context and Info String parameters is the same as for the ASP Active message (See Section 3.7.1)
Context and Info String parameters is the same as for the ASP Active
message (See Section 3.5.1)
4. Procedures 4. Procedures
The M3UA layer needs to respond to various local primitives it receives The M3UA layer needs to respond to various local primitives it receives
from other layers as well as the messages that it receives from the from other layers as well as the messages that it receives from the
peer M3UA layer. This section describes the M3UA procedures in peer M3UA layer. This section describes the M3UA procedures in
response to these events. response to these events.
4.1 Procedures to Support the M3UA-User 4.1 Procedures to Support the M3UA-User
skipping to change at page 65, line 31 skipping to change at page 68, line 37
notification primitive to the local M3UA layer. At the M3UA Layer that notification primitive to the local M3UA layer. At the M3UA Layer that
initiated the request, the M3UA layer will send an M-SCTP_RELEASE initiated the request, the M3UA layer will send an M-SCTP_RELEASE
confirm primitive to Layer Management when the association shutdown confirm primitive to Layer Management when the association shutdown
is complete. At the peer M3UA Layer, an M-SCTP_RELEASE indication is complete. At the peer M3UA Layer, an M-SCTP_RELEASE indication
primitive is sent to Layer Management upon abort or successful primitive is sent to Layer Management upon abort or successful
shutdown of an SCTP association. shutdown of an SCTP association.
An M-SCTP_STATUS request primitive supports a Layer Management query of An M-SCTP_STATUS request primitive supports a Layer Management query of
the local status of a particular SCTP association. The M3UA layer the local status of a particular SCTP association. The M3UA layer
simply maps the M-SCTP_STATUS request primitive to an SCTP-STATUS simply maps the M-SCTP_STATUS request primitive to an SCTP-STATUS
primitive to the SCTP layer. When the SCTP responds, the M3UA layer primitive to the SCTP layer. When the SCTP responds, the M3UA layer
maps the association status information to an M-SCTP_STATUS confirm maps the association status information to an M-SCTP_STATUS confirm
primitive. No peer protocol is invoked. primitive. No peer protocol is invoked.
Similar LM-to-M3UA-to-SCTP and/or SCTP-to-M3UA-to-LM primitive mappings Similar LM-to-M3UA-to-SCTP and/or SCTP-to-M3UA-to-LM primitive mappings
can be described for the various other SCTP Upper Layer primitives in can be described for the various other SCTP Upper Layer primitives in
RFC2960 [13] such as INITIALIZE, SET PRIMARY, CHANGE HEARTBEAT, RFC2960 [16] such as INITIALIZE, SET PRIMARY, CHANGE HEARTBEAT,
REQUEST HEARTBEAT, GET SRTT REPORT, SET FAILURE THRESHOLD, SET PROTOCOL REQUEST HEARTBEAT, GET SRTT REPORT, SET FAILURE THRESHOLD, SET PROTOCOL
PARAMETERS, DESTROY SCTP INSTANCE, SEND FAILURE, AND NETWORK STATUS PARAMETERS, DESTROY SCTP INSTANCE, SEND FAILURE, AND NETWORK STATUS
CHANGE. Alternatively, these SCTP Upper Layer primitives (and Status CHANGE. Alternatively, these SCTP Upper Layer primitives (and Status
as well) can be considered for modeling purposes as a Layer Management as well) can be considered for modeling purposes as a Layer Management
interaction directly with the SCTP Layer. interaction directly with the SCTP Layer.
M-NOTIFY indication and M-ERROR indication primitives indicate to Layer M-NOTIFY indication and M-ERROR indication primitives indicate to Layer
Management the notification or error information contained in a Management the notification or error information contained in a
received M3UA Notify or Error message respectively. These indications received M3UA Notify or Error message respectively. These indications
can also be generated based on local M3UA events. can also be generated based on local M3UA events.
skipping to change at page 66, line 34 skipping to change at page 69, line 37
M3UA layer MAY invoke corresponding M-ASP_UP, M-ASP_DOWN, M- M3UA layer MAY invoke corresponding M-ASP_UP, M-ASP_DOWN, M-
ASP_ACTIVE and M-ASP_INACTIVE, M-AS_ACTIVE, M-AS_INACTIVE, and M- ASP_ACTIVE and M-ASP_INACTIVE, M-AS_ACTIVE, M-AS_INACTIVE, and M-
AS_DOWN indication primitives to the local Layer Management. AS_DOWN indication primitives to the local Layer Management.
M-NOTIFY indication and M-ERROR indication primitives indicate to Layer M-NOTIFY indication and M-ERROR indication primitives indicate to Layer
Management the notification or error information contained in a Management the notification or error information contained in a
received M3UA Notify or Error message. These indications can also be received M3UA Notify or Error message. These indications can also be
generated based on local M3UA events. generated based on local M3UA events.
All Non-Transfer messages, except BEAT and BEAT Ack, SHOULD be sent All Non-Transfer messages, except BEAT and BEAT Ack, SHOULD be sent
with sequenced delivery to ensure ordering. All Non-Transfer with sequenced delivery to ensure ordering. ASPTM messages MAY be sent on one of the streams used to carry the data traffic related to the
messages, with the exception of ASPTM, BEAT and BEAT Ack messages,
SHOULD be sent on SCTP stream '0'. ASPTM messages MAY be sent on
one of the streams used to carry the data traffic related to the
Routing Context(s), to minimize possible message loss. BEAT and Routing Context(s), to minimize possible message loss. BEAT and
BEAT Ack messages MAY be sent using out-of-order delivery, and MAY BEAT Ack messages MAY be sent using out-of-order delivery, and MAY
be sent on any stream. be sent on any stream.
4.3 AS and ASP State Maintenance 4.3 AS and ASP State Maintenance
The M3UA layer on the SGP maintains the state of each remote ASP, in The M3UA layer on the SGP maintains the state of each remote ASP, in
each Application Server that the ASP is configured to receive traffic, each Application Server that the ASP is configured to receive traffic,
as input to the M3UA message distribution function. Similarly, where as input to the M3UA message distribution function. Similarly, where
IPSPs use M3UA in a point-to-point fashion, the M3UA layer in an IPSP IPSPs use M3UA in a point-to-point fashion, the M3UA layer in an IPSP
skipping to change at page 70, line 21 skipping to change at page 73, line 21
4.3.3 M3UA Management Procedures for Primitives 4.3.3 M3UA Management Procedures for Primitives
Before the establishment of an SCTP association the ASP state at both Before the establishment of an SCTP association the ASP state at both
the SGP and ASP is assumed to be in the state ASP-DOWN. the SGP and ASP is assumed to be in the state ASP-DOWN.
Once the SCTP association is established (see Section 4.2.1) and Once the SCTP association is established (see Section 4.2.1) and
assuming that the local M3UA-User is ready, the local M3UA ASP assuming that the local M3UA-User is ready, the local M3UA ASP
Maintenance (ASPM) function will initiate the relevant procedures, Maintenance (ASPM) function will initiate the relevant procedures,
using the ASP Up/ASP Down/ASP Active/ASP Inactive messages to convey using the ASP Up/ASP Down/ASP Active/ASP Inactive messages to convey
the ASP state to the SGP (see Section 4.4.3). the ASP state to the SGP (see Section 4.3.4).
If the M3UA layer subsequently receives an SCTP-COMMUNICATION_DOWN If the M3UA layer subsequently receives an SCTP-COMMUNICATION_DOWN
or SCTP-RESTART indication primitive from the underlying SCTP layer, it or SCTP-RESTART indication primitive from the underlying SCTP layer, it
will inform the Layer Management by invoking the M-SCTP_STATUS will inform the Layer Management by invoking the M-SCTP_STATUS
indication primitive. The state of the ASP will be moved to ASP-DOWN. indication primitive. The state of the ASP will be moved to ASP-DOWN.
At an ASP, the MTP3-User will be informed of the unavailability of any At an ASP, the MTP3-User will be informed of the unavailability of any
affected SS7 destinations through the use of MTP-PAUSE indication affected SS7 destinations through the use of MTP-PAUSE indication
primitives. In the case primitives.
of SS7 network isolation, the local MTP3-Users MAY be informed by
implementation-dependent means, as there is currently no primitive
defined for conveying this information.
In the case of SCTP-COMMUNICATION_DOWN, the SCTP client MAY try to re- In the case of SCTP-COMMUNICATION_DOWN, the SCTP client MAY try to re-
establish the SCTP Association. This MAY be done by the M3UA layer establish the SCTP Association. This MAY be done by the M3UA layer
automatically, or Layer Management MAY reestablish using the automatically, or Layer Management MAY reestablish using the
M-SCTP_ESTABLISH request primitive. M-SCTP_ESTABLISH request primitive.
In the case of an SCTP-RESTART indication at an ASP, the ASP is now In the case of an SCTP-RESTART indication at an ASP, the ASP is now
considered by its M3UA peer to be in the ASP-DOWN state. The ASP, if considered by its M3UA peer to be in the ASP-DOWN state. The ASP, if
it is to recover, must begin any recovery with the ASP-Up procedure. it is to recover, must begin any recovery with the ASP-Up procedure.
skipping to change at page 72, line 34 skipping to change at page 75, line 34
The ASP will send an ASP Down message to an SGP when the ASP wishes to The ASP will send an ASP Down message to an SGP when the ASP wishes to
be removed from service in all Application Servers that it is a be removed from service in all Application Servers that it is a
member and no longer receive any DATA, SSNM or ASPTM messages. member and no longer receive any DATA, SSNM or ASPTM messages.
This action MAY be initiated at the ASP by an M-ASP_DOWN request This action MAY be initiated at the ASP by an M-ASP_DOWN request
primitive from Layer Management or MAY be initiated automatically primitive from Layer Management or MAY be initiated automatically
by an M3UA management function. by an M3UA management function.
Whether the ASP is permanently removed from any AS is a function of Whether the ASP is permanently removed from any AS is a function of
configuration management. In the case where the ASP previously used configuration management. In the case where the ASP previously used
the Registration procedures (see Section 4.3.5) to register within the Registration procedures (see Section 4.4.1) 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 MUST consider the ASP as sending the ASP Down message, the SGP MUST consider the ASP as
Deregistered in all Application Servers that it is still a member. Deregistered in all Application Servers that it is still a member.
The SGP marks the ASP as ASP-DOWN, informs Layer Management with an M- The SGP marks the ASP as ASP-DOWN, informs Layer Management with an M-
ASP_Down indication primitive, and returns an ASP Down Ack message to ASP_Down indication primitive, and returns an ASP Down Ack message to
the ASP. the ASP.
The SGP MUST send an ASP Down Ack message in response to a received The SGP MUST send an ASP Down Ack message in response to a received
ASP Down message from the ASP even if the ASP is already marked as ASP Down message from the ASP even if the ASP is already marked as
skipping to change at page 73, line 25 skipping to change at page 76, line 25
the ASP MAY restart T(ack) and resend ASP Down messages until it the ASP MAY restart T(ack) and resend ASP Down messages until it
receives an ASP Down Ack message. T(ack) is provisionable, with a receives an ASP Down Ack message. T(ack) is provisionable, with a
default of 2 seconds. Alternatively, retransmission of ASP Down default of 2 seconds. Alternatively, retransmission of ASP Down
messages MAY be put under control of Layer Management. In this method, messages MAY be put under control of Layer Management. In this method,
expiry of T(ack) results in an M-ASP_DOWN confirm primitive carrying a expiry of T(ack) results in an M-ASP_DOWN confirm primitive carrying a
negative indication. negative indication.
4.3.4.3 ASP Active Procedures 4.3.4.3 ASP Active Procedures
Anytime after the ASP has received an ASP Up Ack message from the SGP Anytime after the ASP has received an ASP Up Ack message from the SGP
or IPSP, the ASP MAY send an ASP Active message to the SGP indicating or IPSP, the ASP MAY send an ASP Active message to the SGP indicating that the ASP is ready to start processing traffic. This action MAY be
that the ASP is ready to start processing traffic. This action MAY be
initiated at the ASP by an M-ASP_ACTIVE request primitive from Layer initiated at the ASP by an M-ASP_ACTIVE request primitive from Layer
Management or MAY be initiated automatically by an M3UA management Management or MAY be initiated automatically by an M3UA management
function. In the case where an ASP wishes to process the traffic for function. In the case where an ASP wishes to process the traffic for
more than one Application Server across a common SCTP association, the more than one Application Server across a common SCTP association, the
ASP Active message(s) SHOULD contain a list of one or more Routing ASP Active message(s) SHOULD contain a list of one or more Routing
Contexts to indicate for which Application Servers the ASP Active Contexts to indicate for which Application Servers the ASP Active
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
skipping to change at page 74, line 6 skipping to change at page 77, line 6
Routing Contexts. Depending on any Traffic Mode Type request in Routing Contexts. Depending on any Traffic Mode Type request in
the ASP Active message, or local configuration data if there is no the ASP Active message, or local configuration data if there is no
request, the SGP moves the ASP to the correct ASP traffic state request, the SGP moves the ASP to the correct ASP traffic state
within the associated Application Server(s). Layer Management is within the associated Application Server(s). Layer Management is
informed with an M-ASP_Active indication. If the SGP or IPSP informed with an M-ASP_Active indication. If the SGP or IPSP
receives any Data messages before an ASP Active message is receives any Data messages before an ASP Active message is
received, the SGP or IPSP MAY discard them. By sending an ASP received, the SGP or IPSP MAY discard them. By sending an ASP
Active Ack message, the SGP or IPSP is now ready to receive and Active Ack message, the SGP or IPSP is now ready to receive and
send traffic for the related Routing Context(s). The ASP SHOULD send traffic for the related Routing Context(s). The ASP SHOULD
NOT send Data or SNMM messages for the related Routing Context(s) before NOT send Data or SNMM messages for the related Routing Context(s) before receiving an ASP Active Ack message, or it will risk message loss.
receiving an ASP Active Ack message, or it will risk message loss.
Multiple ASP Active Ack messages MAY be used in response to an ASP Multiple ASP Active Ack messages MAY be used in response to an ASP
Active message containing multiple Routing Contexts, allowing the SGP Active message containing multiple Routing Contexts, allowing the SGP
or IPSP to independently acknowledge the ASP Active message for or IPSP to independently acknowledge the ASP Active message for
different (sets of) Routing Contexts. The SGP or IPSP MUST send an different (sets of) Routing Contexts. The SGP or IPSP MUST send an
Error message ("Invalid Routing Context") for each Routing Context Error message ("Invalid Routing Context") for each Routing Context
value that the ASP cannot be successfully activated . value that the ASP cannot be successfully activated .
In the case where an "out-of-the-blue" ASP Active message is received In the case where an "out-of-the-blue" ASP Active message is received
(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 29 skipping to change at page 78, line 29
currently active in the AS. The algorithm at the SGP for loadsharing currently active in the AS. The algorithm at the SGP for loadsharing
traffic within an AS to all the active ASPs is implementation traffic within an AS to all the active ASPs is implementation
dependent. The algorithm could, for example, be round-robin or based dependent. The algorithm could, for example, be round-robin or based
on information in the Data message (e.g., the SLS, SCCP SSN, ISUP CIC on information in the Data message (e.g., the SLS, SCCP SSN, ISUP CIC
value). value).
An SGP or IPSP, upon reception of an ASP Active message for the first An SGP or IPSP, upon reception of an ASP Active message for the first
ASP in a Loadshare AS, MAY choose not to direct traffic to a newly ASP in a Loadshare AS, MAY choose not to direct traffic to a newly
active ASP until it determines that there are sufficient resources to 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- handle the expected load (e.g., until there are "n" ASPs in state ASP-
ACTIVE in the AS). ACTIVE in the AS). In this case, the SGP or IPSP SHOULD withhold the Notify (AS-ACTIVE) until there are sufficient resources.
All ASPs within a loadsharing mode AS must be able to process any All ASPs within a loadsharing mode AS must be able to process any
Data message received for the AS, to accommodate any potential Data message received for the AS, to accommodate any potential
failover or rebalancing of the offered load. failover or rebalancing of the offered load.
In the case of a Broadcast mode AS, reception of an ASP Active message In the case of a Broadcast mode AS, reception of an ASP Active message
at an SGP or IPSP causes the direction of traffic to the ASP sending at an SGP or IPSP causes the direction of traffic to the ASP sending
the ASP Active message, in addition to all the other ASPs that are 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 currently active in the AS. The algorithm at the SGP for broadcasting
traffic within an AS to all the active ASPs is a simple broadcast traffic within an AS to all the active ASPs is a simple broadcast
algorithm, where every message is sent to each of the active ASPs. 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 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 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 active ASP until it determines that there are sufficient resources to
handle the expected load (e.g., until there are "n" ASPs in state handle the expected load (e.g., until there are "n" ASPs in state
ASP-ACTIVE in the AS). ASP-ACTIVE in the AS). In this case, the SGP or IPSP SHOULD withhold the Notify (AS-ACTIVE) until there are sufficient resources.
Whenever an ASP in a Broadcast mode AS becomes ASP-ACTIVE, the SGP Whenever an ASP in a Broadcast mode AS becomes ASP-ACTIVE, the SGP
MUST tag the first DATA message broadcast in each SCTP stream with MUST tag the first DATA message broadcast in each traffic flow with
a unique Correlation Id parameter. The purpose of this a unique Correlation Id parameter. The purpose of this Id is to permit the newly active ASP to synchronize its processing of traffic in each traffic flow with the other ASPs in the broadcast group.
Id is to permit the newly active ASP to synchronize its processing
of traffic in each ordered stream with the other ASPs in the
broadcast group.
4.3.4.3.1 IPSP Considerations (ASP Active) 4.3.4.3.1 IPSP Considerations (ASP Active)
Either of the IPSPs can initiate communication. When an IPSP receives an ASP Active, it should mark the peer as ASP-ACTIVE and return an ASP Active Ack message. An ASP receiving an ASP Active Ack message may mark the peer as ASP-Active, if it is not already in the ASP-ACTIVE state. Either of the IPSPs can initiate communication. When an IPSP receives an ASP Active, it should mark the peer as ASP-ACTIVE and return an ASP Active Ack message. An ASP receiving an ASP Active Ack message may mark the peer as ASP-Active, if it is not already in the ASP-ACTIVE state.
Alternatively, an interchange of ASP Active messages from each end can be performed. This option follows the ASP state transition diagram and gives the additional advantage of selecting a particular AS to be activated from each end. It is especially useful when an IPSP is serving more than one AS. It would need four messages for completion. Alternatively, an interchange of ASP Active messages from each end can be performed. This option follows the ASP state transition diagram and gives the additional advantage of selecting a particular AS to be activated from each end. It is especially useful when an IPSP is serving more than one AS. It would need four messages for completion.
4.3.4.4 ASP Inactive Procedures 4.3.4.4 ASP Inactive Procedures
When an ASP wishes to withdraw from receiving traffic within an AS, the When an ASP wishes to withdraw from receiving traffic within an AS, the
skipping to change at page 78, line 20 skipping to change at page 81, line 20
ASP. At the ASP, Layer Management is informed with an M-NOTIFY ASP. At the ASP, Layer Management is informed with an M-NOTIFY
indication primitive. The Notify message must be sent whether the indication primitive. The Notify message must be sent whether the
AS state change was a result of an ASP failure or reception of an AS state change was a result of an ASP failure or reception of an
ASP State management (ASPSM) / ASP Traffic Management (ASPTM) ASP State management (ASPSM) / ASP Traffic Management (ASPTM)
message. In the second case, the Notify message MUST be sent after message. In the second case, the Notify message MUST be sent after
any related acknowledgement messages (e.g., ASP Up Ack, ASP Down any related acknowledgement messages (e.g., ASP Up Ack, ASP Down
Ack, ASP Active Ack, or ASP Inactive Ack). Ack, ASP Active Ack, or ASP Inactive Ack).
In the case where a Notify message("AS-PENDING") message is sent by 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 an SGP that now has no ASPs active to service the traffic, or where a
Notify ("Insufficient ASP resources active in AS") message MUST be Notify ("Insufficient ASP resources active in AS") message is
sent in the Loadshare or Broadcast mode, the Notify message does not sent in the Loadshare or Broadcast mode, the Notify message does not
explicitly compel the ASP(s) receiving the message to become explicitly compel the ASP(s) receiving the message to become
active. The ASPs remain in control of what (and when) traffic action active. The ASPs remain in control of what (and when) traffic action
is taken. is taken.
In the case where a Notify message does not contain a Routing Context In the case where a Notify message does not contain a Routing Context
parameter, the receiver must know, via configuration data, of which parameter, the receiver must know, via configuration data, of which
Application Servers the ASP is a member and take the appropriate Application Servers the ASP is a member and take the appropriate
action in each AS. action in each AS.
4.3.4.5.1 IPSP Considerations (NTFY) 4.3.4.5.1 IPSP Considerations (NTFY)
Notify works in the same manner as in the SG-AS case. One of the IPSPs can send this message to any remote IPSP that is not in the ASP-DOWN state. Notify works in the same manner as in the SG-AS case. One of the IPSPs can send this message to any remote IPSP that is not in the ASP-DOWN state.
4.3.4.76 Heartbeat Procedures 4.3.4.6 Heartbeat Procedures
The optional Heartbeat procedures MAY be used when operating over The optional Heartbeat procedures MAY be used when operating over
transport layers that do not have their own heartbeat mechanism for transport layers that do not have their own heartbeat mechanism for
detecting loss of the transport association (i.e., other than SCTP). detecting loss of the transport association (i.e., other than SCTP).
Either M3UA peer may optionally send Heartbeat messages periodically, Either M3UA peer may optionally send Heartbeat messages periodically,
subject to a provisionable timer T(beat). Upon receiving a Heartbeat subject to a provisionable timer T(beat). Upon receiving a Heartbeat
message, the M3UA peer MUST respond with a Heartbeat Ack message. message, the M3UA peer MUST respond with a Heartbeat Ack message.
If no Heartbeat Ack message (or any other M3UA message) is received If no Heartbeat Ack message (or any other M3UA message) is received
skipping to change at page 82, line 12 skipping to change at page 85, line 12
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 specific SS7 network 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.
DUNA, DAVA, SCON, and DRST messages MUST be sent sequentially and DUNA, DAVA, SCON, and DRST messages SHOULD be sent sequentially and
processed at the receiver in the order sent. SCTP stream "0" is processed at the receiver in the order sent. 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.
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 unsequenced. Again, SCTP stream 0 is used, with optional use be sent unsequenced.
of the Unordered bit in the SCTP DATA chunk.
4.5.2 At an ASP 4.5.2 At an ASP
4.5.2.1 Single SGP Configurations 4.5.2.1 Single SG 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 SHOULD 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. are appropriate.
Implementation Note: To accomplish this, the M3UA layer at an ASP 4.5.2.2 Multiple SG Configurations
maintains the status of routes via the SG(P), much like an MTP3 layer
maintains route-set status.
4.5.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 SG and determines, whether or not the route(s) via the originating SG 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.
Implementation Note: To accomplish this, the M3UA layer at an ASP
maintains the status of routes via the SG, much like an MTP3 layer
maintains route-set status.
4.5.3 ASP Auditing 4.5.3 ASP Auditing
An ASP may optionally initiate an audit procedure 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.
skipping to change at page 83, line 24 skipping to change at page 86, line 24
ASP in the following cases: ASP in the following cases:
- Periodic. A Timer originally set upon reception of a DUNA, SCON - Periodic. A Timer originally set upon reception of a DUNA, SCON
or DRST message has expired without a subsequent DAVA, or DRST message has expired without a subsequent DAVA,
DUNA, SCON or DRST message updating the DUNA, SCON or DRST message updating the
availability/congestion status of the affected availability/congestion status of the affected
Destination Point Codes. The Timer is reset upon Destination Point Codes. The Timer is reset upon
issuing a DAUD. In this case the DAUD is sent to the issuing a DAUD. In this case the DAUD is sent to the
SGP that originally sent the SSNM message. SGP that originally sent the SSNM message.
- Isolation. The ASP is newly ASP-INACTIVE or ASP-ACTIVE or has been - Isolation. The ASP is newly ASP-ACTIVE or has been
isolated from an SGP for an extended period. The ASP isolated from an SGP for an extended period. The ASP
MAY request the availability/congestion status of one MAY request the availability/congestion status of one
or more SS7 destinations to which it expects to or more SS7 destinations to which it expects to
communicate. communicate.
In the first of the cases above, the auditing procedure must not be IMPLEMENTATION NOTE: In the first of the cases above, the auditing procedure must not be invoked for the case of a received SCON message containing a congestion level value of "no congestion" or undefined" (i.e., congestion Level = "0"). This is because the value indicates either congestion abatement or that the ITU MTP3 international congestion method is being used. In the international congestion method, the MTP3 layer at the SGP does not maintain the congestion status of any destinations and therefore the SGP cannot provide any congestion information in response to the DAUD. For the same reason, in the second of the cases above a DAUD message cannot reveal any congested destination(s).
invoked for the case of a received SCON message containing a congestion
level value of "no congestion" or undefined" (i.e., congestion Level =
"0"). This is because the value indicates either congestion abatement
or that the ITU MTP3 international congestion method is being used. In
the international congestion method, the MTP3 layer at the SGP does not
maintain the congestion status of any destinations and therefore the
SGP cannot provide any congestion information in response to the DAUD.
For the same reason, in the second of the cases above a DAUD message
cannot reveal any congested destination(s).
The SGP SHOULD respond to a DAUD message with the MTP3 The SGP SHOULD respond to a DAUD message with the MTP3
availability/congested status of the routeset associated with each availability/congested status of the routeset associated with each
Destination Point Code(s) in the DAUD message. The status of each SS7 Destination Point Code(s) in the DAUD message. The status of each SS7
destination requested is indicated in a DUNA message (if unavailable), destination requested is indicated in a DUNA message (if unavailable),
a DAVA message (if available), or a DRST (if restricted and the SGP a DAVA message (if available), or a DRST (if restricted and the SGP
supports this feature). Where the SGP maintains the congestion status supports this feature). Where the SGP maintains the congestion status
of the SS7 destination, and the SS7 destination is congested, the SGP of the SS7 destination, and the SS7 destination is congested, the SGP
MUST additionally respond with an SCON message before the DAVA or DRST MUST additionally respond with an SCON message before the DAVA or DRST
message. If the SS7 destination is available and congested, the SGP message. If the SS7 destination is available and congested, the SGP
MUST respond with an SCON message and then a DAVA message. If the SS7 MUST respond with an SCON message and then a DAVA message. If the SS7
destination is restricted and congested, the SGP MUST respond with destination is restricted and congested, the SGP MUST respond with
an SCON message immediately followed by a DRST message. If the SGP an SCON message immediately followed by a DRST message. If the SGP
has no information on the availability status of the SS7 destination, has no information on the availability status of the SS7 destination,
the SGP responds with a DUNA message, as it has no routing the SGP responds with a DUNA message, as it has no routing
information to allow it to route traffic to this destination. information to allow it to route traffic to this destination.
Any DUNA or DAVA message in response to a DAUD message MAY contain a Any DUNA or DAVA message in response to a DAUD message MAY contain a
list of up to sixteen Affected Point Codes. list of Affected Point Codes.
An SG MAY refuse to provide the availability or congestion status of An SG MAY refuse to provide the availability or congestion status of
a destination if, for example, the ASP is not authorized to know the a destination if, for example, the ASP is not authorized to know the
status of the destination. The SG MAY respond with an Error Message status of the destination. The SG MAY respond with an Error Message
(Error Code = "Destination Status Unknown") (Error Code = "Destination Status Unknown")
4.6 MTP3 Restart 4.6 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:
skipping to change at page 85, line 14 skipping to change at page 88, line 14
5. Examples of M3UA Procedures 5. Examples of M3UA Procedures
5.1 Establishment of Association and Traffic between SGPs and ASPs 5.1 Establishment of Association and Traffic between SGPs and ASPs
These scenarios show the example M3UA message flows for the These scenarios show the example M3UA message flows for the
establishment of traffic between an SGP and an ASP or between two establishment of traffic between an SGP and an ASP or between two
IPSPs. In all cases it is assumed that the SCTP association is IPSPs. In all cases it is assumed that the SCTP association is
already set up. already set up.
Note: Not all the Notify messages that are appropriate per the Notify procedures are shown in these examples.
5.1.1 Single ASP in an Application Server ("1+0" sparing), 5.1.1 Single ASP in an Application Server ("1+0" sparing),
These scenarios show the example M3UA message flows for the These scenarios show the example M3UA message flows for the
establishment of traffic between an SGP and an ASP where only one ASP establishment of traffic between an SGP and an ASP where only one ASP
is configured within an AS (no backup). is configured within an AS (no backup).
5.1.1.1 Single ASP/IPSP in an Application Server ("1+0" sparing), 5.1.1.1 Single ASP/IPSP in an Application Server ("1+0" sparing),
No Registration No Registration
The sending of any DUNA/SCON messages by the SGP is not shown but is similar to the case described in Section 5.1.2. The sending of any DUNA/SCON messages by the SGP is not shown but is similar to the case described in Section 5.1.2.
SGP ASP1 SGP ASP1
| | | |
|<-------------ASP Up------------| |<-------------ASP Up------------|
|-----------ASP Up Ack---------->| |-----------ASP Up Ack---------->|
| | | |
|<------- ASP Active(RCn)--------| RC: Routing Context |<------- ASP Active(RCn)--------| RC: Routing Context
|-----ASP Active Ack (RCn)------>| (optional) |-----ASP Active Ack (RCn)------>| (optional)
| | | |
لللللللللللل |-----NTFY(AS_Active)(RCn)------>|
| |
Note: If the ASP Active message contains an optional Routing Context Note: If the ASP Active message contains an optional Routing Context
parameter, The ASP Active message only applies for the specified RC parameter, The ASP Active message only applies for the specified RC
value(s). For an unknown RC value, the SGP responds with an Error value(s). For an unknown RC value, the SGP responds with an Error
message. message.
5.1.1.2 Single ASP in Application Server ("1+0" sparing), 5.1.1.2 Single ASP in Application Server ("1+0" sparing),
Dynamic Registration Dynamic Registration
This scenario is the same as for 5.1.1.1 but with the optional exchange This scenario is the same as for 5.1.1.1 but with the optional exchange
skipping to change at page 86, line 18 skipping to change at page 89, line 18
|----------ASP Up Ack----------->| |----------ASP Up Ack----------->|
| | | |
|<----REGISTER REQ(LRCn,RKn)-----| LRC: Local Routing |<----REGISTER REQ(LRCn,RKn)-----| LRC: Local Routing
| | Context | | Context
|----REGISTER RESP(LRCn,RCn)---->| RK: Routing Key |----REGISTER RESP(LRCn,RCn)---->| RK: Routing Key
| | RC: Routing Context | | RC: Routing Context
| | | |
|<------- ASP Active(RCn)--------| |<------- ASP Active(RCn)--------|
|-----ASP Active Ack (RCn)------>| |-----ASP Active Ack (RCn)------>|
| | | |
لللللللللللل |-----NTFY(AS_Active)(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 unsuccessful indication and the ASP will not subsequently send
an ASP Active message. an ASP Active message.
5.1.1.3 Single ASP in Multiple Application Servers (each 5.1.1.3 Single ASP in Multiple Application Servers (each
with "1+0" sparing), Dynamic Registration (Case 1 - Multiple with "1+0" sparing), Dynamic Registration (Case 1 - Multiple
Registration Requests) Registration Requests)
skipping to change at page 86, line 53 skipping to change at page 90, line 4
| | | |
|----REGISTER RESP(LRCn,RCn)---->| |----REGISTER RESP(LRCn,RCn)---->|
| | | |
| | | |
|<------- ASP Active(RCn)--------| |<------- ASP Active(RCn)--------|
|-----ASP Active Ack (RCn)------>| |-----ASP Active Ack (RCn)------>|
| | | |
Note: In the case of an unsuccessful registration attempt (e.g., Note: In the case of an unsuccessful registration attempt (e.g.,
invalid RKn), the Register Response message will contain an invalid RKn), the Register Response message will contain an
unsuccessful indication and the ASP will not subsequently send
an ASP Active message. Each LRC/RK pair registration is considered
independently. unsuccessful indication and the ASP will not subsequently send
an ASP Active message. Each LRC/RK pair registration is considered 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 5.1.1.4 Single ASP in Multiple Application Servers (each
with "1+0" sparing), Dynamic Registration (Case 2 - Single with "1+0" sparing), Dynamic Registration (Case 2 - Single
Registration Request) Registration Request)
skipping to change at page 89, line 31 skipping to change at page 92, line 31
|<--------------------------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----->| |
| | | | | | | |
|----------Notify (AS-ACTIVE)----------->| |
|-----------------------Notify (AS-ACTIVE)------------------>|
5.2 ASP/IPSP Traffic Failover Examples 5.2 ASP/IPSP Traffic Failover Examples
5.2.1 (1+1 Sparing, Withdrawal of ASP/IPSP, Backup Override) 5.2.1 (1+1 Sparing, Withdrawal of ASP/IPSP, Backup Override)
Following on from the example in Section 5.1.2, and ASP1 Following on from the example in Section 5.1.2, and ASP1
withdraws from service: withdraws from service:
SGP ASP1 ASP2 SGP ASP1 ASP2
| | | | | |
skipping to change at page 97, line 25 skipping to change at page 100, line 33
6.2 Threats 6.2 Threats
There is no quick fix, one-size-fits-all solution for security. As a There is no quick fix, one-size-fits-all solution for security. As a
transport protocol, M3UA has the following security objectives: transport protocol, M3UA has the following security objectives:
* Availability of reliable and timely user data transport. * Availability of reliable and timely user data transport.
* Integrity of user data transport. * Integrity of user data transport.
* Confidentiality of user data. * Confidentiality of user data.
M3UA is recommended to be transported on SCTP. SCTP [13] provides M3UA is recommended to be transported on SCTP. SCTP [16] provides
certain transport related security features, such as some protection certain transport related security features, such as some protection
against: against:
* Blind Denial of Service Attacks * Blind Denial of Service Attacks
* Flooding * Flooding
* Masquerade * Masquerade
* Improper Monopolization of Services * Improper Monopolization of Services
When M3UA is running in professionally managed corporate or service When M3UA is running in professionally managed corporate or service
provider network, it is reasonable to expect that this network includes provider network, it is reasonable to expect that this network includes
skipping to change at page 99, line 51 skipping to change at page 103, line 7
Tolga Asveren, Maria-Cruz Bartolome-Rodrigo, Dan Brendes, Nikhil Jain, Tolga Asveren, Maria-Cruz Bartolome-Rodrigo, Dan Brendes, Nikhil Jain,
Roland Jesske, Joe Keller, Kurt Kite, Ming Lin, Steve Lorusso, Naoto Roland Jesske, Joe Keller, Kurt Kite, Ming Lin, Steve Lorusso, Naoto
Makinae, Howard May, Francois Mouillaud, Barry Nagelberg, Neil Olson, Makinae, Howard May, Francois Mouillaud, Barry Nagelberg, Neil Olson,
Heinz Prantner, Shyamal Prasad, Mukesh Punhani, Selvam Rengasami, Heinz Prantner, Shyamal Prasad, Mukesh Punhani, Selvam Rengasami,
John Schantz, Ray Singh, Michael Tuexen, Nitin Tomar, Gery Verwimp, John Schantz, Ray Singh, Michael Tuexen, Nitin Tomar, Gery Verwimp,
Tim Vetter, Kazuo Watanabe, Ben Wilson and many others for their Tim Vetter, Kazuo Watanabe, Ben Wilson and many others for their
valuable comments and suggestions. valuable comments and suggestions.
9. References 9. References
[1] RFC 2719, "Framework Architecture for Signaling Transport", L. Ong 9.1 Normative References
et al, October 1999
[2] ITU-T Recommendations Q.761 to Q.767, "Signalling System No.7 (SS7) [1] 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" [2] ANSI T1.113 - "Signaling System Number 7 - ISDN User Part"
[4] ETSI ETS 300 356-1 "Integrated Services Digital Network (ISDN); [3] 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 [4] 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 [5] ANSI T1.112 "Signaling System Number 7 - Signaling Connection
Control Part" Control Part"
[7] ETSI ETS 300 009-1, "Integrated Services Digital Network (ISDN); [6] 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" [7] ITU-T Recommendations Q.701 to Q.705, "Signalling System No. 7
(SS7) - Message Transfer Part (MTP)"
[9] ITU-T Recommendations Q.771 to Q.775 "Signalling System No. 7 (SS7) [8] ANSI T1.111 "Signaling System Number 7 - Message Transfer Part"
- Transaction Capabilities (TCAP)"
[10] ANSI T1.114 "Signaling System Number 7 - Transaction Capabilities [9] ETSI ETS 300 008-1, "Integrated Services Digital Network (ISDN);
Signalling System No.7; Message Transfer Part (MTP) to support
international interconnection; Part 1: Protocol specification"
9.2 Informative References
[10] RFC 2719, "Framework Architecture for Signaling Transport", L. Ong
et al, October 1999
[11] ITU-T Recommendation Q.720, "Telephone User Part"
[12] ITU-T Recommendations Q.771 to Q.775 "Signalling System No. 7
(SS7) - Transaction Capabilities (TCAP)"
[13] ANSI T1.114 "Signaling System Number 7 - Transaction Capabilities
Application Part" Application Part"
[11] ETSI ETS 300 287-1, "Integrated Services Digital Network (ISDN); [14] 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 [15] 3G TS 25.410 V4.0.0 (2001-04) "Technical Specification - 3rd
Generation partnership Project; Technical Specification Group Generation partnership Project; Technical Specification Group
Radio Access Network; UTRAN Iu Interface: General Aspects and Radio Access Network; UTRAN Iu Interface: General Aspects and
Principles" Principles"
[13] RFC 2960, "Stream Control Transport Protocol", R. Stewart et al, [16] RFC 2960, "Stream Control Transport Protocol", R. Stewart et al,
October 2000. October 2000.
[14] ITU-T Recommendations Q.701 to Q.705, "Signalling System No. 7
(SS7) - Message Transfer Part (MTP)"
[15] ANSI T1.111 "Signaling System Number 7 - Message Transfer Part"
[16] ETSI ETS 300 008-1, "Integrated Services Digital Network (ISDN);
Signalling System No.7; Message Transfer Part (MTP) to support
international interconnection; Part 1: Protocol specification"
[17] ITU-T Recommendation Q.2140 "B-ISDN ATM Adaptation Layer - Service [17] ITU-T Recommendation Q.2140 "B-ISDN ATM Adaptation Layer - Service
Specific Coordination Function for signalling at the Network Node Specific Coordination Function for signalling at the Network Node
Interface (SSCF at NNI)" Interface (SSCF at NNI)"
[18] ITU-T Recommendation Q.2110 "B-ISDN ATM Adaptation Layer - Service [18] ITU-T Recommendation Q.2110 "B-ISDN ATM Adaptation Layer - Service
Specific Connection Oriented Protocol (SSCOP)" Specific Connection Oriented Protocol (SSCOP)"
[19] RFC 2119, "Key words for use in RFCs to Indicate Requirement [19] RFC 2119, "Key words for use in RFCs to Indicate Requirement
Levels", S. Bradner, March 1997. Levels", S. Bradner, March 1997.
skipping to change at page 101, line 32 skipping to change at page 104, line 46
[23] RFC 2406, "IP Encapsulating Security Payload (ESP)", S.Kent and [23] RFC 2406, "IP Encapsulating Security Payload (ESP)", S.Kent and
R. Atkinson, November 1998. R. Atkinson, November 1998.
[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
[26] <draft-ietf-sigtran-m2ua-10.txt>, "MTP2-User Adaptation Layer", [26] <draft-ietf-sigtran-m2ua-11.txt>, "MTP2-User Adaptation Layer",
K. Morneault et al, Sept 2001 (Work in Progress) K. Morneault et al, October 2001 (Work in Progress)
[27] <draft-ietf-sigtran-m2pa-03.txt>, "SS7 MTP2-User Peer-to-Peer [27] <draft-ietf-sigtran-m2pa-03.txt>, "SS7 MTP2-User Peer-to-Peer
Adaptation Layer", Tom George et al, July 2001 (Work in Progress) Adaptation Layer", Tom George et al, July 2001 (Work in Progress)
10. Author's Addresses 10. Author's Addresses
Greg Sidebottom Greg Sidebottom
gregside consulting gregside consulting
Kanata, Ontario, Canada Kanata, Ontario, Canada
EMail: gregside@home.com EMail: gregside@rogers.com
Javier Pastor-Balb‍s Javier Pastor-Balbas
Ericsson Espaکa S.A. Ericsson Espana S.A.
C/ Omb" 3 C/ Omb" 3
28045 Madrid - Spain 28045 Madrid - Spain
EMail: j.javier.pastor@ericsson.com EMail: j.javier.pastor@ericsson.com
Guy Mousseau Guy Mousseau
Nortel Networks Nortel Networks
3685 Richmond Rd 3685 Richmond Rd
Nepean, Ontario, Canada K2H 5B7 Nepean, Ontario, Canada K2H 5B7
Lyndon Ong Lyndon Ong
Ciena Ciena
10480 Ridgeview Court 10480 Ridgeview Court
Cupertino, CA 95014 Cupertino, CA 95014
EMail: lyong@ciena.com EMail: lyong@ciena.com
Ian Rytina Ian Rytina
Ericsson Australia Ericsson Australia
skipping to change at page 102, line 48 skipping to change at page 106, line 16
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@pt.com
Brian Bidulock Brian Bidulock
OpenSS7 Corporation OpenSS7 Corporation
c/o #424, 4701 Preston Park Blvd. c/o #424, 4701 Preston Park Blvd.
Plano, TX, USA 75093 Plano, TX, USA 75093
EMail: bidulock@openss7.org EMail: bidulock@openss7.org
John Loughney John Loughney
Nokia Research Center Nokia Research Center
PO Box 407 PO Box 407
FIN-00045 Nokia Group FIN-00045 Nokia Group
Finland Finland
EMail: john.loughney@nokia.com EMail: john.loughney@nokia.com
This draft expires May 2002. This draft expires July 2002.
Appendix A Appendix A
A.1 Signalling Network Architecture A.1 Signalling Network Architecture
A Signalling Gateway is used to support the transport of MTP3-User A Signalling Gateway is used to support the transport of MTP3-User
signalling traffic received from the SS7 network to multiple signalling traffic received from the SS7 network to multiple
distributed ASPs (e.g., MGCs and IP Databases). Clearly, the M3UA distributed ASPs (e.g., MGCs and IP Databases). Clearly, the M3UA
protocol is not designed to meet the performance and reliability protocol is not designed to meet the performance and reliability
requirements for such transport by itself. However, the conjunction requirements for such transport by itself. However, the conjunction
of distributed architecture and redundant networks provides support of distributed architecture and redundant networks provides support
for reliable transport of signalling traffic over IP. The M3UA for reliable transport of signalling traffic over IP. The M3UA
protocol is flexible enough to allow its operation and management protocol is flexible enough to allow its operation and management
in a variety of physical configurations, enabling Network Operators in a variety of physical configurations, enabling Network Operators
to meet their performance and reliability requirements. to meet their performance and reliability requirements.
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 might require requirements for carrier grade networks, Network Operators might require that no single point of failure is present in the end-to-end
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 MAY 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 could example, for a particular Application Server, the related ASPs could
be distributed over at least two Hosts. be distributed over at least two Hosts.
skipping to change at page 105, line 38 skipping to change at page 108, line 38
* ******** * * ******** * * ******** * * ******** *
* * SGPn * * * * ASPn * * * * SGPn * * * * ASPn * *
* ******** * * ******** * * ******** * * ******** *
************** ************** ************** **************
SGP1.1 and SGP1.2 are part of SG1 SGP1.1 and SGP1.2 are part of SG1
SGP2.1 and SGP2.2 are part of SG2 SGP2.1 and SGP2.2 are part of SG2
Figure 1 - Physical Model Figure 1 - Physical Model
In this model, each host MAY have many application processes. In the In this model, each host may have many application processes. In the
case of the MGC, an ASP may provide service to one or more Application case of the MGC, an ASP may provide service to one or more Application
Servers, and is identified as an SCTP end point. One or more Servers, and is identified as an SCTP end point. One or more
Signalling Gateway Processes make up a single Signalling Gateway. Signalling Gateway Processes make up a single Signalling Gateway.
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 MAY 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 more than one end point to more than one SCTP association, leading to more than one
other signalling processes. To support this, a signalling process must other signalling processes. To support this, a signalling process must
be 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 status of the signalling the status of provisioned Routing Keys, the status of the signalling
routes to signalling points in the SS7 network , and the redundancy routes to signalling points in the SS7 network , and the redundancy
model (active-standby, load sharing, broadcast, n+k) of the remote model (active-standby, load sharing, broadcast, n+k) of the remote
skipping to change at page 107, line 12 skipping to change at page 110, line 12
of the routing information to be used as the Routing Key for a of the routing information to be used as the Routing Key for a
particular AS. 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 failover, it is recommended that in the case of ASPs In the process of failover, it is recommended that in the case of ASPs
supporting call processing, stable calls do not fail. It is possible 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,
the two ASPs MAY share call state via shared memory, or MAY use an ASP the two ASPs may share call state via shared memory, or may use an ASP
to ASP protocol to pass call state information. Any ASP-to-ASP to ASP protocol to pass call state information. Any ASP-to-ASP
protocol to support this function is outside the scope of this protocol to support this function is outside the scope of this
document. document.
A.2.2 Signalling Gateway Redundancy A.2.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/backup or a distributed over one or more hosts, using an active/backup or a
loadsharing model. Should an SGP lose all or partial SS7 loadsharing model. Should an SGP lose all or partial SS7
connectivity and other SGPs exist, the SGP MUST terminate the SCTP connectivity and other SGPs exist, the SGP may terminate the SCTP
associations to the concerned ASPs. 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/backup redundancy model is possible, where the SG. A primary/backup 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 loadsharing model to reroute affected traffic to an alternate SGP. A loadsharing model
is possible, where the signalling messages are loadshared between is possible, where the signalling messages are loadshared between
multiple SGPs. A broadcast model is also possible, where signalling multiple SGPs. A broadcast model is also possible, where signalling
skipping to change at page 108, line 13 skipping to change at page 111, line 13
must maintain knowledge of the current capability of the SGPs to must maintain knowledge of the current capability of the SGPs to
handle traffic to destinations of interest. This information is handle traffic to destinations of interest. This information is
crucial to the overall reliability of the service, for active/backup, crucial to the overall reliability of the service, for active/backup,
loadsharing and broadcast models, in the event of failures, recovery loadsharing and broadcast models, in the event of failures, recovery
and maintenance activities. The ASP M3UA may also use this and maintenance activities. The ASP M3UA may also use this
information for congestion avoidance purposes. The distribution of information for congestion avoidance purposes. The distribution of
the MTP3-user messages over the SGPs should be done in such a way to the MTP3-user messages over the SGPs should be done in such a way to
minimize message missequencing, as required by the SS7 User Parts. minimize message missequencing, as required by the SS7 User Parts.
This draft expires May 2002 This draft expires July 2002
 End of changes. 

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