10.  References

10.1.  Normative References

   [1123]         Braden, R., Ed., "Requirements for Internet Hosts -
                  Application and Support", STD 3, RFC 1123, October
                  1989.

   [2119]         Bradner, S., "Key words for use in RFCs to Indicate
                  Requirement Levels", BCP 14, RFC 2119, March 1997.

   [2960]         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.

   [3629]         Yergeau, F., "UTF-8, a transformation format of ISO
                  10646", STD 63, RFC 3629, November 2003.

   [3788]         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

   [2434]         Narten, T. and H. Alvestrand, "Guidelines for Writing
                  an IANA Considerations Section in RFCs", BCP 26, RFC
                  2434, October 1998.

   [2719]         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.

   [3761]         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: greg@signatustechnologies.com

   Lode Coene
   Siemens n.v.
   Atealaan 34
   B-2200 Herentals
   Belgium

   Phone: +32-14-252081
   EMail: lode.coene@siemens.com


   Gery Verwimp
   Siemens n.v.
   34 Atealaan
   PO 2200
   Herentals
   Belgium

   Phone: +32 14 25 3424
   EMail: gery.verwimp@siemens.com


   Joe Keller
   Tekelec
   5200 Paramount Parkway
   Morrisville, NC 27560
   USA

   EMail: joe.keller@tekelec.com


   Brian Bidulock
   OpenSS7 Corporation
   1469 Jeffreys Crescent
   Edmonton, AB  T6L 6T1
   Canada

   Phone: +1 780 490 1141
   EMail: bidulock@openss7.org

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-
   ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.