RFC 2719
Framework Architecture for Signaling Transport
RFC 2719: Framework Architecture for Signaling Transport ✨🎀
okay bestie, this is RFC 2719, and the title is Framework Architecture for Signaling Transport 🦋 It was published in October 1999 under the Network Working Group, and it's Informational 💅 That means it's sharing knowledge with the Internet community, not setting an official standard. The header doesn't list anything it obsoletes or updates, so it's a standalone doc 🌸
The authors are a whole squad 💖 L. Ong is from Nortel Networks. I. Rytina and M. Garcia are from Ericsson. H. Schwarzbauer and L. Coene are from Siemens. H. Lin is from Telcordia, I. Juhasz from Telia, M. Holdrege from Lucent, and C. Sharp from Cisco Systems. Nine people, one architecture, iconic teamwork 👑
Status of this Memo ✨
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited 🌈
Copyright Notice 🎀
Copyright (C) The Internet Society (1999). All Rights Reserved. 💜
Abstract 🦋
okay so this document defines an architecture framework and the functional requirements for carrying signaling information over IP 🌐 It lays out how the functional and physical entities that swap signaling info relate to each other. Think Signaling Gateways and Media Gateway Controllers 🧚 It also points out where signaling transport might be used, plus the functional and performance requirements that come from existing Switched Circuit Network (SCN) signaling protocols. The whole thing is giving blueprint energy 🔥
Table of Contents 🌸
1. Introduction..................................................2
1.1 Overview.....................................................2
1.2 Terminology..................................................3
1.3 Scope.......................................................5
2. Signaling Transport Architecture.............................5
2.1 Gateway Component Functions.................................5
2.2 SS7 Interworking for Connection Control.....................6
2.3 ISDN Interworking for Connection Control....................8
2.4 Architecture for Database Access............................9
3. Protocol Architecture........................................10
3.1 Signaling Transport Components..............................10
3.2 SS7 access for Media Gateway Control........................11
3.3 Q.931 Access to MGC.........................................12
3.4 SS7 Access to IP/SCP........................................12
3.5 SG to SG....................................................14
4. Functional Requirements......................................15
4.1 Transport of SCN Signaling Protocols........................15
4.2 Performance of SCN Signaling Protocols......................17
4.2.1 SS7 MTP Requirements......................................17
4.2.2 SS7 MTP Level 3 Requirements..............................17
4.2.3 SS7 User Part Requirements................................18
4.2.4 ISDN Signaling Requirements...............................18
5. Management...................................................19
6. Security Considerations......................................19
6.1 Security Requirements.......................................19
6.2 Security Mechanisms Currently Available in IP Networks......20
7. Abbreviations................................................21
8. Acknowledgements.............................................21
9. References...................................................21
Authors' Addresses..............................................22
Full Copyright Statement........................................241. Introduction 💖
1.1 Overview ✨
okay so this document defines an architecture framework for carrying message-based signaling protocols over IP networks 🌐 The scope covers encapsulation methods, end-to-end protocol mechanisms, and using the IP capabilities that already exist to meet the functional and performance requirements of signaling transport 💅
The framework part describes how the functional and physical entities in signaling transport relate to each other. That includes the framework for controlling Media Gateways, plus other scenarios where signaling transport might be needed 🦋
The requirements part describes the functional and performance requirements for signaling transport, like flow control, in-sequence delivery, and other functions that specific SCN signaling protocols might need 🔥
1.2 Terminology 🎀
okay bestie, here are the general terms used in this document 📚
Backhaul: backhaul is the transport of signaling from the point of interface for the associated data stream (that's the SG function in the MGU) back to the point of call processing (that's the MGCU), if that point isn't local 🌸
Signaling Transport (SIG): SIG is a protocol stack for carrying SCN signaling protocols over an IP network 🌐 It supports standard primitives so it can talk to an unmodified SCN signaling application being transported. It also sits on top of a standard IP transport protocol and adds functions designed to meet the transport requirements of SCN signaling 💜
Switched Circuit Network (SCN): the SCN is 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). SCN signaling protocols include Q.931, SS7 MTP Level 3, and SS7 Application/User parts 🧚
Next up are the functional entities for signaling transport in a distributed gateway model 🫶
Media Gateway (MG): an MG terminates SCN media streams and packetizes the media data (if it isn't already packetized), then delivers that packetized traffic to the packet network 🦋 It does 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 🎀 It may be able to authorize resource usage based on local policy. For signaling transport, the MGC serves as a possible termination and origination point for SCN application protocols, like the SS7 ISDN User Part and Q.931/DSS1 👑
Signaling Gateway (SG): an SG is a signaling agent that receives and 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. It may also be co-resident with the MG function, so it can process SCN signaling tied to line or trunk terminations that the MG controls (like signaling backhaul) 🧚
Okay, and now the physical entities for signaling transport in that same distributed gateway model 🌸
Media Gateway Unit (MGU): an MG-Unit is a physical entity that contains the MG function 🍓 It may contain other functions too, especially 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. A central office switch is one example 🦋
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 covers encapsulation methods, end-to-end protocol mechanisms, and the use of IP capabilities to meet the functional and performance requirements for signaling 🔥
Signaling transport shall be used for carrying SCN signaling between a Signaling Gateway Unit and a Media Gateway Controller Unit 🧚 Signaling transport may also be used for message-based signaling between a Media Gateway Unit and a Media Gateway Controller Unit, between dispersed Media Gateway Controller Units, and between two Signaling Gateway Units that connect signaling endpoints or signal transfer points in the SCN 🌸
Signaling transport will be defined so it can encapsulate and carry a variety of SCN protocols 🍓 It's also defined to be independent of any SCN protocol translation functions happening at the endpoints of the transport, since its only job is carrying the SCN protocol 💖
Because the function is transparent transport, the following areas are outside the scope of the signaling transport work 🫶
- definition of the SCN protocols themselves.
- signaling interworking, such as converting 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 or interworking, since that's transparent to the transport function.
- similarly, some management and addressing functions taking place within the SGU or MGU are also out of scope, like determining the destination IP address for signaling, or specific procedures for assessing the performance of the transport session (that's testing and proving functions) 🙈
2. Signaling Transport Architecture ✨
2.1 Gateway Component Functions 🧩
Okay so Figure 1 is the commonly defined functional model, and it splits the SG, MGC and MG functions apart 💅. This model may be implemented in a bunch of different ways, with the functions living in separate devices or squished together into single physical units. 🌸
Where there's physical separation between the functional entities, Signaling Transport can be applied so that SCN signaling information gets carried between entities with the functionality and performance they need. 🫶
+---------------+ +--------------+
| | | |
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 ModelAs we already covered, the interfaces that pertain to signaling transport include SG to MGC and SG to SG. 🎀 Signaling transport may potentially also be applied to the MGC to MGC or MG to MGC interfaces, depending on what the transport of the associated signaling protocol needs. ✨
2.2 SS7 Interworking for Connection Control 📞
Figure 2 shows some example implementations of these functions in physical entities, used for interworking SS7 and IP networks for Voice over IP, Voice over ATM, Network Access Servers, etc. 🦋 No recommendation is made about how to distribute the functions, and there are loads of other examples that are possible but aren't shown, just to keep things concise. The use of signaling transport is independent of the implementation. 💜
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 that trunk based on the control signaling it gets 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 the 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 ImplementationsIn some implementations, the function of the SG may be split into multiple physical entities to support scaling, signaling network management and addressing concerns. 🌈 So Signaling Transport can be used between SGs as well as from SG to MGC, as Figure 3 shows below. 🧚
SGU MGCU
+---------+ +---------+
| | ST | |
| [SG2]------------------------------>[MGC] |
| ^ ^ | | |
+---|-|---+ +---------+
| |
| | ST
ST| +--------------------------------+
| |
| |
SS7 +---|----------+ SS7 +----|---------+
-----------> [SG1] | -----------> [SG1] |
media | | media | |
------------------->[MG] | ------------------->[MG] |
stream +--------------+ stream +--------------+
MGU MGU
Figure 3: Multiple SG CaseIn 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 the data channels, so 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. 🦋
MGCU
+-------------+
| [MGC] |
| | | |
+-----|-|-----+
| |
| O device control
| |
Q.931/ST O |
| |
+-----|-|-----+
| | | |
Q.931---->[SG]| |
signals| | |
| | |
Media---->[MG] |
stream | |
+-------------+
MGU
Figure 4: Q.931 transport model2.4 Architecture for Database Access 🗄️
Okay, Transaction Capabilities (TCAP) is the application part within SS7 that gets 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. For example:
- 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.
A basic functional model for TCAP over IP is shown in Figure 5. 💖
+--------------+
| 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 IP3. Protocol Architecture 🏗️
This section gives a series of examples of protocol architecture for the use of Signaling Transport (SIG). ✨
3.1 Signaling Transport Components 💖
In the protocol architecture figures below, Signaling Transport is assumed to consist of three components (see Figure 6): 🧩
- an adaptation sub-layer that supports specific primitives, e.g., management indications, required by a particular SCN signaling application protocol.
- a Common Signaling Transport Protocol that supports a common set of reliable transport functions for signaling transport.
- a standard, unmodified IP transport protocol.
+-- +--------------------------------+
| | SCN adaptation module |
| +--------------------------------+
| |
S | +--------------------------------+
I | | Common Signaling Transport |
G | +--------------------------------+
| |
| +--------------------------------+
| | standard IP transport |
+-- +--------------------------------+
Figure 6: Signaling Transport Components3.2. SS7 access for Media Gateway Control 🎀
okay so this section is the protocol architecture for signaling transport that supports SS7 access for Media Gateway Control 💅 picture it like a group chat with a few different stops along the way 🦋
****** SS7 ******* SS7 ****** IP *******
*SEP *--------* STP *------* SG *------------* MGC *
****** ******* ****** *******
+----+ +-----+
|ISUP| | ISUP|
+----+ +-----+ +---------+ +-----+
|MTP | |MTP | |MTP | SIG| | SIG |
|L1-3| |L1-3 | |L1-3+----+ +-----+
| | | | | | IP | | IP |
+----+ +-----+ +---------+ +-----+
STP - Signal Transfer Point SEP - Signaling End Point
SG - Signaling Gateway SIG - Signaling Transport
MGC - Media Gateway ControllerFigure 7: SS7 Access to MGC
3.3. Q.931 Access to MGC 🌸
so this one is the protocol architecture for signaling transport that supports ISDN point-to-point access (Q.931) for Media Gateway Control 🧚 same energy, different outfit ✨
****** ISDN ********* IP *******
* EP *--------------* SG/MG *------------* MGC *
****** ********* *******
+----+ +-----+
|Q931| | Q931|
+----+ +---------+ +-----+
|Q921| |Q921| SIG| | SIG |
+ + + +----+ +-----+
| | | | IP | | IP |
+----+ +---------+ +-----+
MG/SG - Media Gateway with SG function for backhaul
EP - ISDN End PointFigure 8: ISDN Access
3.4. SS7 Access to IP/SCP 💜
this section is about the protocol architecture for database access, like signaling between two IN nodes or two mobile network nodes 📱 there are a bunch of different scenarios for the protocol stacks, and what the SIG does depends on which SS7 application you're using 🔥
in the diagrams, the SS7 Application Part (S7AP) is used as a general term so it covers all the Application Parts (e.g. MAP, IS-41, INAP, etc.) 🌈 depending on what's being transported, S7AP may or may not include TCAP. and the interface to the SS7 layer below S7AP can be either the TC-user interface or the SCCP-user interface 🫶
Figure 9a shows the case where SCCP is the signaling protocol being carried between the SG and an IP Signaling Endpoint (ISEP). the ISEP is just an IP destination that supports some SS7 application protocols 👑
****** SS7 ******* SS7 ****** IP *******
*SEP *--------* STP *------* SG *-------------* ISEP*
****** ******* ****** *******
+-----+ +-----+
|S7AP | |S7AP |
+-----+ +-----+
|SCCP | |SCCP |
+-----+ +-----+ +---------+ +-----+
|MTP | |MTP | |MTP |SIG | |SIG |
+ + + + + +----+ +-----+
| | | | | | IP | |IP |
+-----+ +-----+ +---------+ +-----+Figure 9a: SS7 Access to IP node - SCCP being transported
Figure 9b is the one where S7AP is the signaling protocol being carried between the SG and the ISEP. since S7AP may or may not include TCAP, the SIG has to be able to support both the TC-user and the SCCP-user interfaces 🧠💖
****** SS7 ******* SS7 ****** IP *******
*SEP *--------* STP *------* SG *-------------* ISEP*
****** ******* ****** *******
+-----+ +-----+
|S7AP | |S7AP |
+-----+ +----+----+ +-----+
|SCCP | |SCCP| | | |
+-----+ +-----+ +----|SIG | |SIG |
|MTP | |MTP | |MTP | | | |
+ + + + + +----+ +-----+
| | | | | |IP | |IP |
+-----+ +-----+ +---------+ +-----+Figure 9b: SS7 Access to IP node - S7AP being transported
3.5. SG to SG 🦋
this section describes a protocol architecture for signaling between two endpoints in an SCN signaling network, where the signaling transport runs directly between two SGs 🌸 it's giving direct message, no middle person 💅
the figure below shows the protocol architecture for a setup with two SGs that offer different levels of function for interworking SS7 and IP. this matches the scenario from Figure 3 ✨
the SS7 User Part (S7UP) shown here is an SS7 protocol that uses MTP directly for transport inside the SS7 network, like ISUP 🧚
in this scenario, SIG shows up in two different use cases: one transports MTP3 signaling and the other transports ISUP signaling 🎀
****** SS7 ****** IP ****** IP ******
*SEP *-------* SG1*----------* SG2*-------*MGC *
****** ****** ****** ******
+----+ +----+
|S7UP| |S7UP|
+----+ +----+----+ +----+
|MTP3| |MTP3| | | |
+----+ +---------+ +----+ SIG| |SIG |
|MTP2| |MTP2|SIG | |SIG | | | |
+ + + +----+ +----+----+ +----+
| | | | IP | | IP | | IP |
+----+ +----+----+ +----+----+ +----+
S7UP - SS7 User PartFigure 10: SG to SG Case 1
next up is a more generic use of SS7-IP interworking, for carrying SS7 upper layer signaling across an IP network. here, the endpoints are both SS7 SEPs 🔥
****** SS7 ****** IP ****** SS7 ******
*SEP *--------* SG *-----------* SG *--------*SEP *
****** ****** ****** ******
+----+ +-----+
|S7UP| | S7UP|
+----+ +-----+
|MTP3| | MTP3|
+----+ +---------+ +---------+ +-----+
|MTP2| |MTP2| SIG| |SIG |MTP2| | MTP2|
+ + + +----+ +----+ + + +
| | | | IP | | IP | | | |
+----+ +----+----+ +----+----+ +-----+Figure 11: SG to SG Case 2
4. Functional Requirements 🌈
4.1 Transport of SCN Signaling Protocols 💅
okay so signaling transport is how native SCN protocol messages get carried over a packet switched network 📦
signaling transport shall:
- transport a bunch of SCN protocol types, like 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) 🧚
- give a way to identify which particular SCN protocol is being transported 🔍
- provide a common base protocol that defines header formats, security extensions and procedures for signaling transport. it should also support extensions when needed to add individual SCN protocols, if and when that's required 🎀
- work together with the underlying network protocol (IP) to provide the relevant functionality from the appropriate SCN lower layer 🫶
relevant functionality may include (depending on 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 connectionless classes 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.
- support multiplexing several higher layer SCN sessions onto one underlying signaling transport session. this lets, for example, several DSS1 D-Channel sessions be carried in one signaling transport session 🌸
in general, in-sequence delivery is required for signaling messages within a single control stream, but it isn't necessarily required for messages that belong to different control streams. the protocol should, if possible, take advantage of this so that one control stream doesn't get blocked from delivering messages because of a sequence error in another control stream 🧠. the protocol should also let the SG send different control streams to different destination ports if desired ✨
- be able to transport complete messages longer than the underlying SCN segmentation/reassembly limits. for example, signaling transport shouldn't be constrained by the length limits defined for SS7 lower layer protocols (e.g. 272 bytes in the case of narrowband SS7) and should be able to carry longer messages without needing segmentation 💖
- 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 🔥
- 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 gives basic values for the performance requirements of key SCN protocols that get transported. right now, only message-based SCN protocols are considered. failing to meet these requirements is likely to cause adverse and undesirable signaling and call behavior 💀
4.2.1 SS7 MTP requirements 🫶
the performance requirements below were specified for transporting MTP Level 3 network management messages. these requirements only apply if all MTP Level 3 messages are going to be transported over the IP network 🦋
- Message Delay
- MTP Level 3 peer-to-peer procedures require a response within 500 to 1200 ms. this value includes round trip time and processing at the remote end.
- failing to meet this limit 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 ✨
okay so these are the performance requirements for carrying MTP Level 3 user part messages as part of the ITU-T SS7 Recommendations [SS7] 💅
- 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
ngl this part is so detailed. If you want the full tea, check out [Lin] 🍵
ISUP Message Delay - Protocol Timer Requirements ⏱️
- one example of ISUP timer requirements is the Continuity Test procedure, which requires that a tone generated at the sending end be returned from the receiving end within 2 seconds of sending an IAM indicating continuity test. This implies that one way signaling message transport, plus accompanying nodal functions need to be accomplished within 2 seconds. 🔁
ISUP Message Delay - End-to-End Requirements 🌍
- the requirement for end-to-end call setup delay in ISUP is that an end-to-end response message be received within 20-30 seconds of the sending of the IAM. Note: while this is the protocol guard timer value, users will generally expect faster response time. 🏃♀️💨
TCAP Requirements - Delay Requirements 🧩
- TCAP does not itself define a set of delay requirements. Some work has been done [Lin2] to identify application-based delay requirements for TCAP applications. 📚
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.
RELASE/RELEASE COMPLETEand 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. 🎀
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 Considerations 🔐
Okay, this section is serious business, bestie. No cap. 🚨
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.
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 SIG 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 RFC 2663 [NAT]. 🙃
The use of IPSEC does not hamper the use of TCP or UDP as the underlying basis of SIG. If automated distribution of keys is required the IKE protocol ([RFC2409]) 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 SIG, 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
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
SIG Signaling Transport protocol stack
SS7 Signaling System No. 7
TCAP Signaling System 7 Transaction Capabilities Part8. 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] Srisuresh P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
- [PSS1/QSIG] ISO/IEC 11572 Ed. 2 (1997-06), "Information technology - Telecommunications and information exchange between systems - Private Integrated Services Network - Circuit mode bearer services - Inter-exchange signalling procedures and protocol"
- [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
- [Lin] Lin, H., Seth, T., et al., "Performance Requirements for Signaling in Internet Telephony", Work in Progress.
- [Lin2] Lin, H., et al., "Performance Requirements for TCAP Signaling in Internet Telephony", Work in Progress.
- [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
- [RFC2409] Harkins, D. and C. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
- [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
Authors' Addresses 📮
Lyndon Ong
Nortel Networks
4401 Great America Parkway
Santa Clara, CA 95054, USA
EMail: long@nortelnetworks.comIan Rytina
Ericsson Australia
37/360 Elizabeth Street
Melbourne, Victoria 3000, Australia
EMail: ian.rytina@ericsson.comMatt Holdrege
Lucent Technologies
1701 Harbor Bay Parkway
Alameda, CA 94502 USA
EMail: holdrege@lucent.comLode Coene
Siemens Atea
Atealaan 34
Herentals, Belgium
EMail: lode.coene@siemens.atea.beMiguel-Angel Garcia
Ericsson Espana
Retama 7
28005 Madrid, Spain
EMail: Miguel.A.Garcia@ericsson.comChip Sharp
Cisco Systems
7025 Kit Creek Road
Res Triangle Pk, NC 27709, USA
EMail: chsharp@cisco.comImre Juhasz
Telia
Sweden
EMail: imre.i.juhasz@telia.seHaui-an Paul Lin
Telcordia Technologies
Piscataway, NJ, USA
EMail: hlin@research.telcordia.comHannsJuergen Schwarzbauer
SIEMENS AG
Hofmannstr. 51
81359 Munich, Germany
EMail: HannsJuergen.Schwarzbauer@icn.siemens.deFull Copyright Statement ©️
Copyright (C) The Internet Society (1999). 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 RFC Editor function is currently provided by the Internet Society. 🎉
📦 where this page comes from
- ietf: rfc2719 1999-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms