10. References 10.1. Normative References  Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.  Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.  Loughney, J., Tuexen, M., Ed., and J. Pastor-Balbas, "Security Considerations for Signaling Transport (SIGTRAN) Protocols", RFC 3788, June 2004.
[ANSI SCCP] ANSI T1.112 "Signalling System Number 7 - Signalling Connection Control Part". [ITU SCCP] ITU-T Recommendations Q.711-714, "Signalling System No. 7 (SS7) - Signalling Connection Control Part (SCCP)." ITU-T Telecommunication Standardization Sector of ITU, formerly CCITT, Geneva (July 1996). 10.2. Informative References  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.  Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L., Lin, H., Juhasz, I., Holdrege, M., and C. Sharp, "Framework Architecture for Signalling Transport", RFC 2719, October 1999.  Falstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004. [ANSI TCAP] ANSI T1.114 'Signalling System Number 7 - Transaction Capabilities Application Part' [ITU TCAP] ITU-T Recommendation Q.771-775 'Signalling System No. 7 SS7) - Transaction Capabilities (TCAP).' [RANAP] 3G TS 25.413 V3.5.0 (2001-03) 'Technical Specification 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu Interface RANAP Signalling'
Appendix A. Signalling Network Architecture A.1. Generalized Peer-to-Peer Network Architecture Figure 3 shows an example network architecture that can support robust operation and fail-over. There needs to be some management resources at the AS to manage traffic. *********** * AS1 * * +-----+ * SCTP Associations * |ASP1 +-------------------+ * +-----+ * | *********** * * | * AS3 * * +-----+ * | * +-----+ * * |ASP2 +-----------------------------------------+ASP1 | * * +-----+ * | * +-----+ * * * | * * * +-----+ * | * +-----+ * * |ASP3 | * +--------------------------+ASP2 | * * +-----+ * | | * +-----+ * *********** | | *********** | | *********** | | *********** * AS2 * | | * AS4 * * +-----+ * | | * +-----+ * * |ASP1 +--------------+ +---------------------+ASP1 | * * +-----+ * * +-----+ * * * * * * +-----+ * * +-----+ * * |ASP2 +-----------------------------------------+ASP1 | * * +-----+ * * +-----+ * * * *********** * +-----+ * * |ASP3 | * * +-----+ * * * *********** Figure 3: Generalized Architecture In this example, the Application Servers are shown residing within one logical box, with ASPs located inside. In fact, an AS could be distributed among several hosts. In such a scenario, the host should share state as protection in the case of a failure. This is out of scope of this protocol. Additionally, in a distributed system, one ASP could be registered to more than one AS. This document should not restrict such systems - though such a case in not specified.
A.2. Signalling Gateway Network Architecture When interworking between SS7 and IP domains is needed, the SGP acts as the gateway node between the SS7 network and the IP network. The SGP will transport SCCP-user signalling traffic from the SS7 network to the IP-based signalling nodes (for example IP-resident Databases). The Signalling Gateway can be considered as a group of Application Servers with additional functionality to interface toward an SS7 network. The SUA protocol should be flexible enough to allow different configurations and transport technology to allow the network operators to meet their operation, management and performance requirements. An ASP may be connected to multiple SGPs (see figure 4). In such a case, a particular SS7 destination may be reachable via more than SG, therefore, more than one route. Given that proper SLS selection, loadsharing, and SG selection based on point code availability is performed at the ASP, it will be necessary for the ASP to maintain the status of each distant SGPs to which it communicates on the basis of the SG through which it may route.
Signalling Gateway SCTP Associations +----------+ ************** | SG1 | * AS3 * | ******** | * ******** * | * SGP11+--------------------------------------------+ ASP1 * * | ******** | / * ******** * | ******** | | * ******** * | * SGP12+--------------------------------------------+ ASP2 * * | ******** | \ / | * ******** * +----------+ \ | | * . * \ | | * . * +---------- \ | | * . * | SG2 | \ | | * . * | ******** | \ | | * ******** * | * SGP21+---------------------------------+-+ * * ASPN * * | ******** | \ * ******** * | ******** | \ ************** | * SGP22+---+--+ \ | ******** | | | \ ************** +----------+ | | \ * AS4 * | | \ * ******** * | +-------------------------------------+ ASP1 * * | * ******** * | * . * | * . * | * * | * ******** * +----------------------------------------+ ASPn * * * ******** * ************** Figure 4: Signalling Gateway Architecture The pair of SGs can either operate as replicated endpoints or as replicated relay points from the SS7 network point of view. Replicated endpoints: the coupling between the SGs and the ASPs when the SGs act as replicated endpoints is an implementation issue. Replicated relay points: in normal circumstances, the path from SEP to ASP will always go via the same SGP when in-sequence-delivery is requested. However, linkset failures may cause MTP to reroute to the other SG.
A.3. Signalling Gateway Message Distribution Recommendations A.3.1. Connectionless Transport By means of configuration, the SG knows the local SCCP-user is actually represented by an AS, and serviced by a set of ASPs working in n+k redundancy mode. An ASP is selected and a CLDT message is sent on the appropriate SCTP association/stream. The selection criterion can be based on a round robin mechanism, or any other method that guarantees a balanced loadsharing over the active ASPs. However, when TCAP messages are transported, load sharing is only possible for the first message in a TCAP dialogue (TC_Begin, TC_Query, TC_Unidirectional). All other TCAP messages in the same dialogue are sent to the same ASP that was selected for the first message, unless the ASPs are able to share state and maintain sequenced delivery. To this end, the SGP needs to know the TID allocation policy of the ASPs in a single AS: - State sharing - Fixed range of TIDs per ASP in the AS This information may be provisioned in the SG, or may be dynamically exchanged via the ASP_Active message. An example for an INAP/TCAP message exchange between SEP and ASP is given below. Address information in CLDT message (e.g., TC_Query) from SGP to ASP, with association ID = SG-ASP, Stream ID based on sequence control and possibly other parameters, e.g., OPC: - Routing Context: based on SS7 Network ID and AS membership, so that the message can be transported to the correct ASP. - Source address: valid combination of SSN, PC and GT, as needed for back routing to the SEP. - Destination address: at least SSN, to select the SCCP/SUA-user at the ASP. Address information in CLDT message (e.g., TC_Response) from ASP to SG, with association ID = ASP-SG, stream ID selected by implementation dependent means with regards to in-sequence-delivery: - Routing Context: as received in previous message. - Source address: unique address provided so that when used as the SCCP called party address in the SEP, it must yield the same AS, the SSN might be sufficient.
- Destination address: copied from source address in received CLDT message. Further messages from the SEP belonging to the same TCAP transaction will now reach the same ASP. A.3.2. Connection-Oriented Transport Further messages for this connection are routed on DPC in the SS7 connection section (MTP routing label), and on IP address in the IP connection section (SCTP header). No other routing information is present in the SCCP or SUA messages themselves. Resources are kept within the SG to forward messages from one section to another and to populate the MTP routing label or SCTP header, based on the destination local reference of these messages (Connect Confirm, Data Transfer, etc.) This means that in the SG, two local references are allocated, one 3-byte value used for the SS7 section and one 4-byte value for the IP section. Also a resource containing the connection data for both sections is allocated, and either of the two local references can be used to retrieve this data e.g., for an incoming DT1 or CODT, for example. Authors' Addresses John Loughney Nokia Research Center PO Box 407 FIN-00045 Nokia Group Finland EMail: john.Loughney@nokia.com Greg Sidebottom Signatus Technologies Kanata, Ontario Canada EMail: email@example.com
Lode Coene Siemens n.v. Atealaan 34 B-2200 Herentals Belgium Phone: +32-14-252081 EMail: firstname.lastname@example.org Gery Verwimp Siemens n.v. 34 Atealaan PO 2200 Herentals Belgium Phone: +32 14 25 3424 EMail: email@example.com Joe Keller Tekelec 5200 Paramount Parkway Morrisville, NC 27560 USA EMail: firstname.lastname@example.org Brian Bidulock OpenSS7 Corporation 1469 Jeffreys Crescent Edmonton, AB T6L 6T1 Canada Phone: +1 780 490 1141 EMail: email@example.com
Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- firstname.lastname@example.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.