Internet Engineering Task Force INTERNET-DRAFT Authors Transport Working Group Lyndon Ong, Nortel Networks Category: Informational Ian Rytina, Miguel Garcia, Ericsson April 1999 HannsJuergen Schwarzbauer, Lode Coene, Siemens Expires: November 1999 Huai-an Paul Lin, Telcordia Imre Juhasz, Telia Matt Holdrege, Ascend Chip Sharp, Cisco Systems Architectural Framework for Signaling Transport < draft-ietf-sigtran-framework-arch-01.txt > Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document defines an architecture framework and functional requirements for transport of signaling information over IP. The framework describes relationships between functional and physical entities exchanging signaling information, such as Signaling Gateways and Media Gateway Controllers. It identifies interfaces where signaling transport may be used and the functional and performance requirements that apply from existing Switched Circuit Network (SCN) signaling protocols. INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [2] Table of Contents 1. Introduction..............................................2 1.1 Overview.................................................2 1.2 Terminology..............................................2 1.3 Scope...................................................4 2. Signaling Transport Architecture.........................5 2.1 Gateway Component Functions.............................5 2.2 SS7 Interworking for Connection Control.................5 2.3 ISDN Interworking for Connection Control................6 2.4 CAS Backhaul............................................7 2.5 Architecture for Database Access........................8 3. Protocol Architecture.....................................9 3.1. SS7 access for Media Gateway Control....................9 3.2. Q.931 Access to MGC....................................10 3.3. SS7 Access to IP/SCP...................................10 3.4. SG to SG...............................................11 4. Functional Requirements..................................13 5. Management...............................................16 6. Security.................................................17 7. Abbreviations............................................17 8. Acknowledgements.........................................18 9. References...............................................18 Authors' Contact Information................................19 1. Introduction 1.1 Overview This document defines an architecture framework for transport of message-based signaling protocols over IP networks. The scope of this work includes definition of encapsulation methods, end-to-end protocol mechanisms and use of existing IP capabilities to support the functional and performance requirements for signaling transport. The framework portion describes the relationships between functional and physical entities used in signaling transport, including the framework for control of Media Gateways, and other scenarios where signaling transport may be required. The requirements portion describes functional and performance requirements for signaling transport such as flow control, in-sequence delivery and other functions that may be required for specific SCN signaling protocols. 1.2 Terminology The following are general terms are used in this document: INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [3] Backhaul: Backhaul refers to the transport of signaling from the point of interface for the associated data stream (i.e., the MGU) back to the point of call processing (i.e., the MGCU), if this is not local. Common Transport Protocol (CTP): CTP is the transport layer protocol, which provides the interface for signaling transport across and within IP networks. CTP refers to both the transport function and the adaptation function (required to provide the SCN protocols with the same interface that exists towards the lower layers today). Switched Circuit Network (SCN): The term SCN is used to refer to a network that carries traffic within channelized bearers of pre-defined sizes. Examples include Public Switched Telephone Networks (PSTNs) and Public Land Mobile Networks (PLMNs). Examples of signaling protocols used in SCN include Q.931, SS7 MTP Level 3 and SS7 Application/User parts. The following are terms for functional entities relating to signaling transport in a distributed gateway model. Media Gateway (MG): A MG terminates SCN media streams, packetizes the media data,, if it is not already packetized, and delivers packetized traffic to the packet network. It performs these functions in reverse order for media streams flowing from the packet network to the SCN. Media Gateway Controller (MGC): An MGC handles the registration and management of resources at the MG. The MGC may have the ability to authorize resource usage based on local policy. For signaling transport purposes, the MGC serves as a possible termination and origination point for SCN application protocols, such as SS7 ISDN User Part and Q.931/DSS1. Signaling Gateway (SG): An SG is a signaling agent that receives/sends SCN native signaling at the edge of the IP network. The SG function may relay, translate or terminate SS7 signaling in an SS7-Internet Gateway. The SG function may also be co-resident with the MG function to process SCN signaling associated with line or trunk terminations controlled by the MG (e.g., signaling backhaul). The following are terms for physical entities relating to signaling transport in a distributed gateway model: INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [4] Media Gateway Unit (MGU) An MG-Unit is a physical entity that contains the MG function. It may contain other functions, esp. an SG function for handling facility- associated signaling. Media Gateway Control Unit (MGCU) An MGC-Unit is a physical entity containing the MGC function. Signaling Gateway Unit (SGU) An SG-Unit is a physical entity containing the SG function. Signaling End Point (SEP): This is a node in an SS7 network that originates or terminates signaling messages. One example is a central office switch. Signal Transfer Point (STP): This is a node in an SS7 network that routes signaling messages based on their destination point code in the SS7 network 1.3 Scope Signaling transport provides transparent transport of message-based signaling protocols over IP networks. The scope of this work includes definition of encapsulation methods, end-to-end protocol mechanisms and use of IP capabilities to support the functional and performance requirements for signaling. Signaling transport shall be used for transporting SCN signaling between a Signaling Gateway Unit and Media Gateway Controller Unit. Signaling transport may also be used for transport of message-based signaling between a Media Gateway Unit and Media Gateway Controller Unit, between dispersed Media Gateway Controller Units, and between two Signaling Gateway Units connecting signaling endpoints in the SCN. Signaling transport will be defined in such a way as to support encapsulation and carriage of a variety of SCN protocols. It is defined in such a way as to be independent of any protocol translation functions taking place within the Signaling Gateway Unit or Media Gateway Unit, since its function is limited to the transport of the protocol. Since the function being provided is transparent transport, the following areas are considered outside the scope of the signaling transport work: INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [5] - definition of the SCN protocols themselves - signaling interworking such as conversion from Channel Associated Signaling (CAS) to message signaling protocols - specification of the functions taking place within the SGU or MGU - in particular, this work does not address whether the SGU provides mediation/interworking, as this is transparent to the transport function. 2. Signaling Transport Architecture 2.1 Gateway Component Functions Figure 1 defines a commonly defined functional model that separates out the functions of SG, MGC and MG. This model may be implemented in a number of ways, with functions implemented in separate devices or combined in single physical units. Where physical separation exists between functional entities, Signaling Transport can be applied to ensure that SCN signaling information is transported between entities with the required functionality and performance. +---------------+ +--------------+ | | | | SCN<-------->[SG] <--+---------O------------+--> [SG] <------> SCN signal | | | | | | signal +-------|-------+ +-----|--------+ Signaling|gateway Signaling|gateway (opt) O O | | +-------|-------+ +-----|--------+ | | | | | | | [MGC] <--+--------O-------------+--> [MGC] | | | | | | | | | | | | | +-------|-------+ +-----|--------+ Gateway | controller Gateway | controller (opt) O O | | +-------|-------+ +-----|--------+ Media | | | | | | Media <------+---->[MG] <---+-----RTP stream-------+-> [MG] <----+--------> stream| | | | stream +---------------+ +--------------+ Media gateway Media gateway Figure 1: Sigtran Functional Model INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [6] As discussed above, the interfaces pertaining to signaling transport include SG to MGC, SG to SG and may potentially include MGC to MGC or MG to MGC as well. 2.2 SS7 Interworking for Connection Control Figure 2 below shows some example implementations of these functions in physical entities as used for interworking of SS7 and IP networks for Voice over IP, Voice over ATM, Network Access Servers, etc. No recommendation is made as to functional distribution and other implementations are possible. For interworking with SS7-controlled SCN networks, the SG terminates the SS7 link and transfers the signaling information to the MGC using signaling transport. The MG terminates the interswitch trunk and controls the trunk based on the control signaling it receives from the MGC. As shown below in case (a), the SG, MGC and MG may be implemented in separate physical units, or as in case (b), the MGC and MG may be implemented in a single physical unit. In alternative case (c), a facility-associated SS7 link is terminated by the same device (i.e., the MGU) that terminates the interswitch trunk. In this case, the SG function is co-located with the MG function, as shown below, and signaling transport is used to "backhaul" control signaling to the MGCU. Note: SS7 links may also be terminated directly on the MGCU by cross-connecting at the physical level before or at the MGU. SGU +--------+ SS7<------>[SG] | (ISUP) | | | +---|----+ ST | SGU MGCU +---|----+ +--------+ +--------+ | [MGC] | SS7---->[SG] | | [MGC] | | | | | | | | | | | +---|----+ +---|----+ +--|-|---+ MGCU | ST | | | | | ST | | Media +---|----+ Media +---|----+ +--|-|---+ ------->[MG] | ----->[MG/MGC]| SS7 link-->[SG]| | stream | | stream | | Media------> [MG] | +--------+ +--------+ stream +--------+ MGU MGU MGU (a) (b) (c) Notes: ST = Signaling Transport used to carry SCN signaling Figure 2: Example Implementations INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [7] In some implementations, the function of the SG may be divided into multiple physical entities to support scaling and addressing concerns. Thus, Signaling Transport can be used between SGs as well as from SG to MGC. This is shown in Figure 3 below. SGU MGCU +---------+ +---------+ | | ST | | | [SG2]------------------------------>[MGC] | | ^ ^ | | | +---|-|---+ +---------+ | | | | ST ST| +--------------------------------+ | | | | SS7 +---|----------+ SS7 +----|---------+ -----------> [SG1] | -----------> [SG1] | media | | media | | ------------------->[MG] | ------------------->[MG] | stream +--------------+ stream +--------------+ MGU MGU Figure 3: Multiple SG Case In this configuration, there may be more than one MGU handling facility associated signaling (i.e. more than one containing it's own SG function), and only a single SGU. It will therefore be possible to transport one SS7 layer between SG1 and SG2, and another SS7 layer between SG2 and MGC. For example, SG1 could transport MTP3 to SG2, and SG2 could transport ISUP to MGC. 2.3 ISDN Interworking for Connection Control In ISDN access signaling, the signaling channel is carried along with data channels, so that the SG function for handling Q.931 signaling is co-located with the MG function for handling the data stream. Where Q.931 is then transported to the MGC for call processing, signaling transport would be used between the SG function and MGC. This is shown in Figure 3 below. INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [8] MGCU +-------------+ | [MGC] | | | | | +-----|-|-----+ | | | O device control | | Q.931/ST O | | | +-----|-|-----+ | | | | Q.931---->[SG]| | signals| | | | | | Media---->[MG] | stream | | +-------------+ MGU Figure 4: Q.931 transport model 2.4 Architecture for Database Access Transaction Capabilities (TCAP) is the application part within SS7 that is used for non-circuit-related signaling. TCAP signaling within IP networks may be used for cross-access between entities in the SS7 domain and the IP domain, such as: - access from an SS7 network to a Service Control Point (SCP) in IP - access from an SS7 network to an MGC - access from an MGC to an SS7 network element - access from an IP SCP to an SS7 network element INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [9] A basic functional model for TCAP over IP is shown in Figure 4. +--------------+ | IP SCP | +--|----|------+ | | SGU | | SGU +--------------+ | | +--------------+ | | | | | | SS7<--------->[SG] ---------+ | | [SG]<---------> SS7 (TCAP) | | | | | | | +------|-------+ | +------|-------+ | | | O +------------+ O MGCU | | | MGCU +-------|----|--+ +-----|--------+ | | | | | | | | [MGC] | | [MGC] | | | | | | | +-------|-------+ +-----|--------+ | | +-------|-------+ +-----|------+ Media | | | | | | Media <------+---->[MG] <---+--RTP stream---+--> [MG] <-+--------> stream| | | | stream +---------------+ +------------+ MGU MGU Figure 5: TCAP Signaling over IP 3. Protocol Architecture This section provides a series of examples of protocol architecture for the use of Signaling Transport Common Transport Protocol (CTP). 3.1. SS7 access for Media Gateway Control This section provides a protocol architecture for signaling transport supporting SS7 access for Media Gateway Control. ****** SS7 ******* SS7 ****** IP ******* *SEP *--------* STP *------* SG*------------* MGC* ****** ******* ****** ******* +----+ +-----+ |ISUP| | ISUP| +----+ +-----+ +---------+ +-----+ |MTP | |MTP | |MTP | CTP| | CTP | + + + + + +----+ +-----+ | | | | | | IP | | IP | +----+ +-----+ +---------+ +-----+ INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [10] STP - Signal Transfer Point SEP - Signaling End Point SG - Signaling Gateway CTP - Common Transport Protocol MGC - Media Gateway Controller Figure 6: SS7 Access to MGC 3.2. Q.931 Access to MGC This section provides a protocol architecture for signaling transport supporting ISDN point-to-point access (Q.931) for Media Gateway Control. ****** ISDN ********* IP ******* * EP *--------------* SG/MG *------------* MGC * ****** ********* ******* +----+ +-----+ |Q931| | Q931| +----+ +---------+ +-----+ |Q921| |Q921| CTP| | CTP | + + + +----+ +-----+ | | | | IP | | IP | +----+ +---------+ +-----+ MG/SG - Media Gateway with SG function for backhaul EP - ISDN End Point Figure 7: ISDN Access 3.3. SS7 Access to IP/SCP This section provides a protocol architecture for database access, for example providing signaling between two IN nodes or two mobile network nodes. There are a number of scenarios for the protocol stacks and the functionality contained in the CTP, depending on the SS7 application. In the diagrams, SS7 Application Part (S7AP) is used for generality to cover all Application Parts (e.g. MAP, IS-41, INAP, etc). Depending on the protocol being transported, S7AP may or may not include TCAP. The interface to the SS7 layer below S7AP can be either the TC-user interface or the SCCP-user interface. INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [11] Figure 8a shows the scenario where SCCP is the signaling protocol being transported between the SG and an IP Signaling Endpoint (ISEP), that is, an IP destination supporting some SS7 application protocols. ****** SS7 ******* SS7 ****** IP ******* *SEP *--------* STP *------* SG *-------------* ISEP* ****** ******* ****** ******* +-----+ +-----+ |S7AP | |S7AP | +-----+ +-----+ |SCCP | |SCCP | +-----+ +-----+ +---------+ +-----+ |MTP | |MTP | |MTP |CTP | |CTP | + + + + + +----+ +-----+ | | | | | | IP | |IP | +-----+ +-----+ +---------+ +-----+ Figure 8a: SS7 Access to IP node - SCCP being transported Figure 8b shows the scenario where S7AP is the signaling protocol being transported between SG and ISEP. Depending on the usage case, S7AP may or may not include TCAP, which implies that CTP must be able to support both the TC-user and the SCCP-user interfaces. ****** SS7 ******* SS7 ****** IP ******* *SEP *--------* STP *------* SG *-------------* ISEP* ****** ******* ****** ******* +-----+ +-----+ |S7AP | |S7AP | +-----+ +----+----+ +-----+ |SCCP | |SCCP| | | | +-----+ +-----+ +----|CTP | |CTP | |MTP | |MTP | |MTP | | | | + + + + + +----+ +-----+ | | | | | |IP | |IP | +-----+ +-----+ +---------+ +-----+ Figure 8b: SS7 Access to IP node - S7AP being transported 3.4. SG to SG This section identifies a protocol architecture for support of signaling between two endpoints in an SCN signaling network, using signaling transport directly between two SGs. INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [12] The following figure describes protocol architecture for a scenario with two SGs providing different levels of function for interworking of SS7 and IP. This corresponds to the scenario given in Figure 3. The SS7 User Part (S7UP) shown is an SS7 protocol using MTP directly for transport within the SS7 network, for example, ISUP. In this scenario, there are two different usage cases of CTP, one which transports MTP3 signaling, the other which transports ISUP signaling. ****** SS7 ****** IP ****** IP ****** *SEP *-------* SG1*----------* SG2*-------*MGC * ****** ****** ****** ****** +----+ +----+ |S7UP| |S7UP| +----+ +----+----+ +----+ |MTP3| |MTP3| | | | +----+ +---------+ +----+ CTP| |CTP | |MTP2| |MTP2|CTP | |CTP | | | | + + + +----+ +----+----+ +----+ | | | | IP | | IP | | IP | +----+ +----+----+ +----+----+ +----+ S7UP - SS7 User Part Figure 9: SG to SG Case 1 The following figure describes a more generic use of SS7-IP interworking for transport of SS7 upper layer signaling across an IP network, where the endpoints are both SS7 SEPs. ****** SS7 ****** IP ****** SS7 ****** *SEP *--------* SG *-----------* SG *--------*SEP * ****** ****** ****** ****** +----+ +-----+ |S7UP| | S7UP| +----+ +-----+ |MTP3| | MTP3| +----+ +---------+ +---------+ +-----+ |MTP2| |MTP2| CTP| |CTP |MTP2| | MTP2| + + + +----+ +----+ + + + | | | | IP | | IP | | | | +----+ +----+----+ +----+----+ +-----+ Figure 10: SG to SG Case 2 INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [13] 4. Functional Requirements Signaling transport provides for the transport of native SCN protocol messages over a packet switched network. Signaling transport shall: 1) Transport of a variety of SCN protocol types, such as the application and user parts of SS7 (including MTP Level 3, ISUP, SCCP, TCAP, MAP, INAP, IS-41, etc.) and layer 3 of the DSS1/PSS1 protocols (i.e. Q.931 and QSIG). 2) Provide a means to identify the particular SCN protocol being transported. 3) Provide a common base protocol defining header formats, security extensions and procedures for signaling transport, and support extensions as necessary to add individual SCN protocols if and when required. 4) In conjunction with the underlying network protocol (IP) and transport protocol (CTP), provide the relevant functionality as defined by the appropriate SCN lower layer. Relevant functionality may include (according to the protocol being transported): - flow control - in sequence delivery of signaling messages within a control stream - logical identification of the entities on which the signaling messages originate or terminate - logical identification of the physical interface controlled by the signaling message - error detection - recovery from failure of components in the transit path - retransmission and other error correcting methods - detection of unavailability of peer entities. For example: - if the native SCN protocol is ISUP or SCCP, the relevant functionality provided by MTP2/3 shall be provided. - if the native SCN protocol is TCAP, the relevant functionality provided by SCCP and MTP 2/3 shall be supported. - if the native SCN protocol is Q.931, the relevant functionality provided by Q.921 shall be supported. - if the native SCN protocol is MTP3, the relevant functionality of MTP2 shall be supported. 5) Support the ability to multiplex several higher layer SCN sessions on one underlying signaling transport session. This allows, for example, several DSS1 D-Channel sessions to be carried in one signaling transport session. INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [14] In general, in-sequence delivery is required for signaling messages within a single control stream, but is not necessarily required for messages that belong to different control streams. The protocol should if possible take advantage of this property to avoid blocking delivery of messages in one control stream due to sequence error within another control stream. However, the SG will not be required to process the SCN application protocol in order to identify control streams. 6) Be able to transport complete messages of greater length than the underlying SCN segmentation/reassembly limitations. For example, signaling transport should not be constrained by the length limitations defined for SS7 lower layer protocol (e.g. 272 bytes in the case of narrowband SS7) but should be capable of carrying longer messages without requiring segmentation. 7) Allow for a range of suitably robust security schemes to protect signaling information being carried across networks. For example, signaling transport shall be able to operate over proxyable sessions, and be able to be transported through firewalls. 8) Provide for congestion avoidance on the Internet, by supporting appropriate controls on signaling traffic generation (including signaling generated in SCN) and reaction to network congestion. 4.2 Performance of SCN Signaling Protocols This section provides basic values regarding performance requirements of key SCN protocols to be transported. Currently only messaged based SCN protocols are considered. Failure to meet these requirements is likely to result in adverse and undesirable signaling and call behavior. 4.2.1 SS7 MTP requirements The performance requirements below have been specified for transport of MTP Level 3 network management messages. The requirements given here are only applicable if all MTP Level 3 messages are to be transported over the IP network. - Message Delay - MTP Level 3 peer-to-peer procedures require response within 500 to 1200 ms when terrestrial signaling links are used. This value includes round trip time and processing at the remote end. Failure to meet this limitation will result in the initiation of error procedures for specific timers, e.g., timer T4 of ITU-T Recommendation Q.704. 4.2.2 SS7 MTP Level 3 requirements The performance requirements below have been specified for transport of MTP Level 3 user part messages as part of ITU-T SS7 Recommendations [SS7]. INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [15] - Message Loss - no more than 1 in 10E+7 messages will be lost due to transport failure - Sequence Error - no more than 1 in 10E+10 messages will be delivered out-of-sequence (including duplicated messages) due to transport failure - Message Errors - no more than 1 in 10E+10 messages will contain an error that is undetected by the transport protocol (requirement is 10E+9 for ANSI specifications) - Availability - availability of any signaling route set is 99.9998% or better, i.e., downtime 10 min/year or less. A signaling route set is the complete set of allowed signaling paths from a given signaling point towards a specific destination. - Message length (payload accepted from SS7 user parts) - 272 bytes for narrowband SS7, 4091 bytes for broadband SS7 4.2.3 SS7 User Part Requirements ISUP Message Delay - Protocol Timer Requirements - to be provided. ISUP Message Delay - End-to-End Requirements - to be provided. TCAP Requirements - End-to-End Requirements - to be provided. 4.2.4 ISDN Signaling Requirements Q.931 Message Delay - round-trip delay should not exceed 4 seconds. A timer of this length is used for a number of procedures, esp. RELEASE/RELEASE COMPLETE and CONNECT/CONNECT ACK where excessive delay may result in management action on the channel, or release of a call being set up. Note: while this value is indicated by protocol timer specifications, faster response time is normally expected by the user. - 12 sec. timer (T309) is used to maintain an active call in case of loss of the data link, pending re-establishment. The related ETSI documents specify a maximum value of 4 seconds while ANSI specifications [T1.607] default to 90 seconds. INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [16] 5. Management Operations, Administration & Management (OA&M) of IP networks or SCN networks is outside the scope of SIGTRAN. Examples of OA&M include legacy telephony management systems or IETF SNMP managers. OA&M implementors and users should be aware of the functional interactions of the SG, MGC and MG and the physical units they occupy. 6. Security 6.1 Security requirements When SCN related signaling is transported over an IP network two possible network scenarios can be distinguished: - Signaling transported only within an Intranet; Security measures are applied at the discretion of the network owner. - Signaling transported, at least to some extent, in the public Internet; The public Internet should be regarded generally as an "insecure" network and usage of security measures is required. Generally security comprises several aspects - Authentication: It is required to ensure that the information is sent to/from a known and trusted partner. - Integrity: It is required to ensure that the information hasn't been modified while in transit. - Confidentiality: It might be sometimes required to ensure that the transported information is encrypted to avoid illegal use. - Availability: It is required that the communicating endpoints remain in service for authorized use even if under attack. 6.2 Security mechanisms currently available in IP networks Several security mechanisms are currently available for use in IP networks. - IPSEC ([RFC2401]): IPSEC provides security services at the IP layer that address the above mentioned requirements. It defines the two protocols AH and ESP respectively that essentially provide data integrity and data confidentiality services. INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [17] The ESP mechanism can be used in two different modes: - Transport mode; - Tunnel mode. In Transport mode IPSEC protects the higher layer protocol data portion of an IP packet, while in Tunnel mode a complete IP packet is encapsulated in a secure IP tunnel. If the CTP embeds any IP addresses outside of the SA/DA in the IP header, passage through a NAT function will cause problems. The same is true for using IPsec in general, unless an IPsec ready RSIP function is used as described in draft-ietf-nat-terminology-02.txt. The use of IPSEC does not hamper the use of TCP or UDP as the underlying basis of CTP. If automated distribution of keys is required the IKE protocol (RFC[2409]) can be applied. - SSL, TLS ([RFC2246]): SSL and TLS also provide appropriate security services but operate on top of TCP/IP only. It is not required to define new security mechanisms in CTP, as the use of currently available mechanisms is sufficient to provide the necessary security. It is recommended that IPSEC or some equivalent method be used, especially when transporting SCN signaling over public Internet. 7. Abbreviations CAS Channel-Associated Signaling CTP Common Transport Protocol DSS1 Digital Subscriber Signaling INAP Intelligent Network Application Part ISEP IP Signaling End Point ISUP Signaling System 7 ISDN User Part MAP Mobile Application Part MG Media Gateway MGU Media Gateway Unit MGC Media Gateway Controller MGCU Media Gateway Controller Unit MTP Signaling System 7 Message Transfer Part PLMN Public Land Mobile Network PSTN Public Switched Telephone Network S7AP SS7 Application Part S7UP SS7 User Part SCCP SS7 Signaling Connection Control Part SCN Switched Circuit Network SEP Signaling End Point SG Signaling Gateway SS7 Signaling System No. 7 TCAP Signaling System 7 Transaction Capabilities Part INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [18] 8. Acknowledgements The authors would like to thank K. Chong, I. Elliott, Ian Spiers, Al Varney, Goutam Shaw, C. Huitema, Mike McGrew and Greg Sidebottom for their valuable comments and suggestions. 9. References [NAT] IP Network Address Translator (NAT) Terminology and Considerations , P. Srisurech and M. Holdrege, April 1999, work in progress. [PSS1/QSIG] ECMA Standard ECMA-143 -Inter-Exchange Signalling Procedures and Protocol (QSIG-BC) [Q.931/DSS1] ITU-T Recommendation Q.931, ISDN user-network interface layer 3 specification (5/98) [SS7] ITU-T Recommendations Q.700-775, Signalling System No. 7 [SS7 MTP] ITU-T Recommendations Q.701-6, Message Transfer Part of SS7 [T1.607] ANSI T1.607-1998, Digital Subscriber Signaling System Number 1 (DSS1) - Layer 3 Signaling Specification for Circuit-Switched Bearer Services Authors' Contact Information Lyndon Ong Ian Rytina Nortel Networks Ericsson Australia 4401 Great America Parkway 37/360 Elizabeth Street Santa Clara, CA 95054, USA Melbourne, Victoria 3000, Australia long@nortelnetworks.com ian.rytina@ericsson.com Matt Holdrege Lode Coene Ascend Communications Siemens Atea 1701 Harbor Bay Parkway Atealaan 34 Alameda, CA 94502 USA Herentals, Belgium matt@ascend.com lode.coene@ntnet.atea.be Miguel-Angel Garcia Chip Sharp Ericsson Espana Cisco Systems Retama 7 7025 Kit Creek Road 28005 Madrid, Spain Res Triangle Pk, NC 27709, USA Miguel.A.Garcia@ericsson.com chsharp@cisco.com Imre Juhasz Haui-an Paul Lin Telia Telcordia Technologies Sweden Piscataway, NJ, USA imre.i.juhasz@telia.se hlin@research.telcordia.com Hanns Juergen Schwarzbauer Siemens AG Munich, Germany HannsJuergen.Schwarzbauer@ICN.SIEMENS.DE INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01. txt [19]