(SS7) - ISDN User Part (ISUP)"
[2] ANSI T1.113 - "Signaling System Number 7 - ISDN User Part"
[3] ETSI ETS 300 356-1 "Integrated Services Digital Network (ISDN);
Signalling System No.7; ISDN User Part (ISUP) version 2 for the
international interface; Part 1: Basic services"
[4] ITU-T Recommendations Q.711 to Q.715, "Signalling System No. 7
(SS7) - Signalling Connection Control Part (SCCP)"
[5] ANSI T1.112 "Signaling System Number 7 - Signaling Connection
Control Part"
[6] ETSI ETS 300 009-1, "Integrated Services Digital Network (ISDN);
Signalling System No.7; Signalling Connection Control Part
(SCCP) (connectionless and connection-oriented class 2) to
support international interconnection; Part 1: Protocol
specification"
[7] ITU-T Recommendations Q.701 to Q.705, "Signalling System No. 7
(SS7) - Message Transfer Part (MTP)"
[8] ANSI T1.111 "Signaling System Number 7 - Message Transfer Part"
[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"
[10] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998.
8.2 Informative References
[11] Ong, L., Rytina, M., Garcia, H., Schwarzbauer, L., Coene, H.,
Lin, I., Juhasz, M. and C. Holdrege, "Framework Architecture for
Signaling Transport", RFC2719, October 1999.
[12] ITU-T Recommendation Q.720, "Telephone User Part"
[13] ITU-T Recommendations Q.771 to Q.775 "Signalling System No. 7
(SS7) - Transaction Capabilities (TCAP)"
[14] ANSI T1.114 "Signaling System Number 7 - Transaction
Capabilities Application Part"
[15] ETSI ETS 300 287-1, "Integrated Services Digital Network (ISDN);
Signalling System No.7; Transaction Capabilities (TC) version 2;
Part 1: Protocol specification"
[16] 3G TS 25.410 V4.0.0 (2001-04) "Technical Specification - 3rd
Generation partnership Project; Technical Specification Group
Radio Access Network; UTRAN Iu Interface: General Aspects and
Principles"
[17] Stewart, R., Xie, Q., Mornmeault, K., Sharp, H., Taylor, T.,
Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control
Transport Protocol", RFC2960, October 2000.
[18] ITU-T Recommendation Q.2140 "B-ISDN ATM Adaptation Layer -
Service Specific Coordination Function for signalling at the
Network Node Interface (SSCF at NNI)"
[19] ITU-T Recommendation Q.2110 "B-ISDN ATM Adaptation Layer -
Service Specific Connection Oriented Protocol (SSCOP)"
[20] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC2119, March 1997.
[21] ITU-T Recommendation Q.2210 "Message Transfer Part Level 3
functions and messages using the services of ITU Recommendation
Q.2140"
[22] Fraser, B., "Site Security Handbook", FYI 8, RFC2196, September
1997.
[23] Ramakrishnan, S., Floyd, S. and D. Black, "Security Architecture
for the Internet Protocol", RFC3168, November 1998.
[24] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC2406, November 1998.
[25] Maughan, D., Schertler, M., Schneider, M. and J. Turner,
"Internet Security Association and Key Management Protocol", RFC
2408, November 1998.
[26] Narten, T. and H. Alverstrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC2434, October 1998.
[27] Morneault, K., Dantu, R., Sidebottom, G., Bidulock, B. and J.
Heitz, "Signaling System 7 (SS7) Message Transfer Part 2 (MTP2)
- User Adaptation Layer", RFC3331, August 2002.
[28] George, T., et. al., "SS7 MTP2-User Peer-to-Peer Adaptation
Layer", Work in Progress.
[29] Telecommunication Technology Committee (TTC) Standard JT-Q704,
"Message Transfer Part Signaling Network Functions", April 28,
1992.
9. Acknowledgements
The authors would like to thank Antonio Roque Alvarez, Joyce
Archibald, Tolga Asveren, Maria-Cruz Bartolome-Rodrigo, Dan Brendes,
Antonio Caete, Nikhil Jain, Roland Jesske, Joe Keller, Kurt Kite,
Ming Lin, Steve Lorusso, Naoto Makinae, Howard May, Francois
Mouillaud, Barry Nagelberg, Neil Olson, Heinz Prantner, Shyamal
Prasad, Mukesh Punhani, Selvam Rengasami, John Schantz, Ray Singh,
Michael Tuexen, Nitin Tomar, Gery Verwimp, Tim Vetter, Kazuo
Watanabe, Ben Wilson and many others for their valuable comments and
suggestions.
10. Document Contributors
Ian Rytina - Ericsson
Guy Mousseau - Nortel Networks
Lyndon Ong - Ciena
Hanns Juergen Schwarzbauer - Siemens
Klaus Gradischnig - Detecon Inc.
Mallesh Kalla - Telcordia
Normand Glaude - Performance Technologies
Brian Bidulock - OpenSS7
John Loughney - Nokia
Appendix A
A.1 Signalling Network Architecture
A Signalling Gateway is used to support the transport of MTP3-User
signalling traffic received from the SS7 network to multiple
distributed ASPs (e.g., MGCs and IP Databases). Clearly, the M3UA
protocol is not designed to meet the performance and reliability
requirements for such transport by itself. However, the conjunction
of distributed architecture and redundant networks provides support
for reliable transport of signalling traffic over IP. The M3UA
protocol is flexible enough to allow its operation and management in
a variety of physical configurations, enabling Network Operators to
meet their performance and reliability requirements.
To meet the stringent SS7 signalling reliability and performance
requirements for carrier grade networks, Network Operators might
require that no single point of failure is present in the end-to-end
network architecture between an SS7 node and an IP-based application.
This can typically be achieved through the use of redundant SGPs or
SGs, redundant hosts, and the provision of redundant QOS-bounded IP
network paths for SCTP Associations between SCTP End Points.
Obviously, the reliability of the SG, the MGC and other IP-based
functional elements also needs to be taken into account. The
distribution of ASPs and SGPs within the available Hosts MAY also be
considered. As an example, for a particular Application Server, the
related ASPs could be distributed over at least two Hosts.
One example of a physical network architecture relevant to SS7
carrier grade operation in the IP network domain is shown in Figure 5
below:
SGs MGCs
Host#1 ************** ************** Host#3
* ********__*__________________________*__******** * =
* *SGP1.1*__*_____ _______________*__* ASP1 * * MGC1
* ******** * \ / * ******** *
* ********__*______\__/________________*__******** *
* *SGP2.1*__*_______\/______ _____*__* ASP2 * *
* ******** * /\ | | * ******** *
* : * / \ | | * : *
* ******** * / \ | | * ******** *
* * SGPn * * | | | | * * ASPn * *
* ******** * | | | | * ******** *
************** | | | | **************
| | \ /
Host#2 ************** | | \ / ************** Host#4
* ********__*_____| |______\/_______*__******** * =
* *SGP1.2*__*_________________/\_______*__* ASP1 * * MGC2
* ******** * / \ * ******** *
* ********__*_______________/ \_____*__******** *
* *SGP2.2*__*__________________________*__* ASP2 * *
* ******** * * ******** *
* : * SCTP Associations * : *
* ******** * * ******** *
* * SGPn * * * * ASPn * *
* ******** * * ******** *
************** **************
SGP1.1 and SGP1.2 are part of SG1
SGP2.1 and SGP2.2 are part of SG2
Figure 5 - Physical Model
In this model, each host may have many application processes. In the
case of the MGC, an ASP may provide service to one or more
Application Servers, and is identified as an SCTP end point. One or
more Signalling Gateway Processes make up a single Signalling
Gateway.
This example model can also be applied to IPSP-IPSP signalling. In
this case, each IPSP may have its services distributed across 2 hosts
or more, and may have multiple server processes on each host.
In the example above, each signalling process (SGP, ASP or IPSP) is
the end point to more than one SCTP association, leading to more than
one other signalling processes. To support this, a signalling
process must be able to support distribution of M3UA messages to many
simultaneous active associations. This message distribution function
is based on the status of provisioned Routing Keys, the status of the
signalling routes to signalling points in the SS7 network, and the
redundancy model (active-standby, load sharing, broadcast, n+k) of
the remote signalling processes.
For carrier grade networks, the failure or isolation of a particular
signalling process should not cause stable calls or transactions to
be lost. This implies that signalling processes need, in some cases,
to share the call/transaction state or be able to pass the call state
information between each other. In the case of ASPs performing call
processing, coordination may also be required with the related Media
Gateway to transfer the MGC control for a particular trunk
termination. However, this sharing or communication of
call/transaction state information is outside the scope of this
document.
This model serves as an example. M3UA imposes no restrictions as to
the exact layout of the network elements, the message distribution
algorithms and the distribution of the signalling processes.
Instead, it provides a framework and a set of messages that allow for
a flexible and scalable signalling network architecture, aiming to
provide reliability and performance.
A.2 Redundancy Models
A.2.1 Application Server Redundancy
At the SGP, an Application Server list contains active and inactive
ASPs to support ASP broadcast, loadsharing and failover procedures.
The list of ASPs within a logical Application Server is kept updated
in the SGP to reflect the active Application Server Process(es).
For example, in the network shown in Figure 1, all messages to DPC x
could be sent to ASP1 in Host3 or ASP1 in Host4. The AS list at SGP1
in Host 1 might look like the following:
Routing Key {DPC=x) - "Application Server #1"
ASP1/Host3 - State = Active
ASP1/Host4 - State = Inactive
In this "1+1" redundancy case, ASP1 in Host3 would be sent any
incoming message with DPC=x. ASP1 in Host4 would normally be brought
to the "active" state upon failure of, or loss of connectivity to,
ASP1/Host1.
The AS List at SGP1 in Host1 might also be set up in loadshare mode:
Routing Key {DPC=x) - "Application Server #1"
ASP1/Host3 - State = Active
ASP1/Host4 - State = Active
In this case, both the ASPs would be sent a portion of the traffic.
For example the two ASPs could together form a database, where
incoming queries may be sent to any active ASP.
Care might need to be exercised by a Network Operator in the
selection of the routing information to be used as the Routing Key
for a particular AS.
For example, where Application Servers are defined using ranges of
ISUP CIC values, the Operator is implicitly splitting up control of
the related circuit groups. Some CIC value range assignments may
interfere with ISUP circuit group management procedures.
In the process of failover, it is recommended that in the case of
ASPs supporting call processing, stable calls do not fail. It is
possible that calls in "transition" may fail, although measures of
communication between the ASPs involved can be used to mitigate this.
For example, the two ASPs may share call state via shared memory, or
may use an ASP to ASP protocol to pass call state information. Any
ASP-to-ASP protocol to support this function is outside the scope of
this document.
A.2.2 Signalling Gateway Redundancy
Signalling Gateways may also be distributed over multiple hosts.
Much like the AS model, SGs may comprise one or more SG Processes
(SGPs), distributed over one or more hosts, using an active/backup or
a loadsharing model. Should an SGP lose all or partial SS7
connectivity and other SGPs exist, the SGP may terminate the SCTP
associations to the concerned ASPs.
It is therefore possible for an ASP to route signalling messages
destined to the SS7 network using more than one SGP. In this model,
a Signalling Gateway is deployed as a cluster of hosts acting as a
single SG. A primary/backup redundancy model is possible, where the
unavailability of the SCTP association to a primary SGP could be used
to reroute affected traffic to an alternate SGP. A loadsharing model
is possible, where the signalling messages are loadshared between
multiple SGPs. A broadcast model is also possible, where signalling
messages are sent to each active SGP in the SG. The distribution of
the MTP3-user messages over the SGPs should be done in such a way to
minimize message missequencing, as required by the SS7 User Parts.
It may also be possible for an ASP to use more than one SG to access
a specific SS7 end point, in a model that resembles an SS7 STP mated
pair. Typically, SS7 STPs are deployed in mated pairs, with traffic
loadshared between them. Other models are also possible, subject to
the limitations of the local SS7 network provisioning guidelines.
From the perspective of the M3UA layer at an ASP, a particular SG is
capable of transferring traffic to a provisioned SS7 destination X if
an SCTP association with at least one SGP of the SG is established,
the SGP has returned an acknowledgement to the ASP to indicate that
the ASP is actively handling traffic for that destination X, the SGP
has not indicated that the destination X is inaccessible and the SGP
has not indicated MTP Restart. When an ASP is configured to use
multiple SGPs for transferring traffic to the SS7 network, the ASP
must maintain knowledge of the current capability of the SGPs to
handle traffic to destinations of interest. This information is
crucial to the overall reliability of the service, for active/backup,
loadsharing and broadcast models, in the event of failures, recovery
and maintenance activities. The ASP M3UA may also use this
information for congestion avoidance purposes. The distribution of
the MTP3-user messages over the SGPs should be done in such a way to
minimize message missequencing, as required by the SS7 User Parts.
Editors' Addresses
Greg Sidebottom
Signatus Technologies
Kanata, Ontario, Canada
EMail: greg@signatustechnologies.com
Ken Morneault
Cisco Systems Inc.
13615 Dulles Technology Drive
Herndon, VA, USA 20171
EMail: kmorneau@cisco.com
Javier Pastor-Balbas
Ericsson Espana S.A.
C/ Retama 1
28045 Madrid - Spain
EMail: j.javier.pastor@ericsson.com
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other
than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.