Network Working Group L. Ong
Request for Comments: 2719 Nortel Networks
Category: Informational I. Rytina
M. Garcia
Ericsson
H. Schwarzbauer
L. Coene
Siemens
H. Lin
Telcordia
I. Juhasz
Telia
M. Holdrege
Lucent
C. Sharp
Cisco Systems
October 1999
Network Working Group L. Ong
Request for Comments: 2719 Nortel Networks
Category: Informational I. Rytina
M. Garcia
Ericsson
H. Schwarzbauer
L. Coene
Siemens
H. Lin
Telcordia
I. Juhasz
Telia
M. Holdrege
Lucent
C. Sharp
Cisco Systems
October 1999
Framework Architecture for Signaling Transport
信令传输的框架结构
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.
版权所有（C）互联网协会（1999年）。版权所有。
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.
本文件定义了通过IP传输信令信息的体系结构框架和功能要求。该框架描述了交换信令信息的功能实体和物理实体之间的关系，如信令网关和媒体网关控制器。它确定了可使用信令传输的接口以及适用于现有交换电路网络（SCN）信令协议的功能和性能要求。
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........................................24
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........................................24
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.
本文档定义了IP网络上基于消息的信令协议传输的体系结构框架。这项工作的范围包括定义封装方法、端到端协议机制以及使用现有IP功能来支持信令传输的功能和性能要求。
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.
需求部分描述信令传输的功能和性能需求，例如流控制、顺序交付和特定SCN信令协议可能需要的其他功能。
The following are general terms are used in this document:
以下是本文件中使用的通用术语：
Backhaul:
回程：
Backhaul refers to the transport of signaling from the point of interface for the associated data stream (i.e., SG function in the MGU) back to the point of call processing (i.e., the MGCU), if this is not local.
回程是指从相关数据流的接口点（即MGU中的SG功能）到呼叫处理点（即MGCU）的信令传输，如果这不是本地的。
Signaling Transport (SIG):
信号传输（SIG）：
SIG refers to a protocol stack for transport of SCN signaling protocols over an IP network. It will support standard primitives to interface with an unmodified SCN signaling application being transported, and supplements a standard IP transport protocol underneath with functions designed to meet transport requirements for SCN signaling.
SIG是指通过IP网络传输SCN信令协议的协议栈。它将支持标准原语与正在传输的未经修改的SCN信令应用程序进行接口，并使用设计用于满足SCN信令传输要求的功能补充下面的标准IP传输协议。
Switched Circuit Network (SCN):
交换电路网络（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.
术语SCN用于指在预定义大小的信道化承载内承载业务的网络。示例包括公共交换电话网络（PSTN）和公共陆地移动网络（PLMN）。SCN中使用的信令协议示例包括Q.931、SS7 MTP级别3和SS7应用程序/用户部分。
The following are terms for functional entities relating to signaling transport in a distributed gateway model.
以下是分布式网关模型中与信令传输相关的功能实体的术语。
Media Gateway (MG):
媒体网关（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.
MG终止SCN媒体流，将媒体数据打包（如果尚未打包），并将打包的流量传送到分组网络。对于从分组网络流向SCN的媒体流，它以相反的顺序执行这些功能。
Media Gateway Controller (MGC):
媒体网关控制器（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.
MGC负责MG资源的注册和管理。MGC可以基于本地策略授权资源使用。出于信令传输目的，MGC充当SCN应用协议（如SS7 ISDN用户部分和Q.931/DSS1）的可能终止点和发起点。
Signaling Gateway (SG):
信令网关（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).
SG是在IP网络边缘接收/发送SCN本机信令的信令代理。SG功能可以中继、转换或终止SS7互联网网关中的SS7信令。SG功能还可以与MG功能共存，以处理与MG控制的线路或中继终端相关联的SCN信令（例如，信令回程）。
The following are terms for physical entities relating to signaling transport in a distributed gateway model:
以下是分布式网关模型中与信令传输相关的物理实体的术语：
Media Gateway Unit (MGU)
媒体网关单元（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.
MG单元是包含MG功能的物理实体。它可能包含其他功能，特别是处理设施相关信号的SG功能。
Media Gateway Control Unit (MGCU)
媒体网关控制单元（MGCU）
An MGC-Unit is a physical entity containing the MGC function.
MGC单元是包含MGC功能的物理实体。
Signaling Gateway Unit (SGU)
信令网关单元（SGU）
An SG-Unit is a physical entity containing the SG function.
SG单元是包含SG功能的物理实体。
Signaling End Point (SEP):
信号终点（SEP）：
This is a node in an SS7 network that originates or terminates signaling messages. One example is a central office switch.
这是SS7网络中发起或终止信令消息的节点。一个例子是中央局交换机。
Signal Transfer Point (STP):
信号传输点（STP）：
This is a node in an SS7 network that routes signaling messages based on their destination point code in the SS7 network.
这是SS7网络中的一个节点，它根据SS7网络中的目标点代码路由信令消息。
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.
信令传输通过IP网络提供基于消息的信令协议的透明传输。这项工作的范围包括定义封装方法、端到端协议机制以及使用IP功能来支持信令的功能和性能要求。
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 or signal transfer points in the SCN.
信令传输应用于在信令网关单元和媒体网关控制器单元之间传输SCN信令。信令传输还可用于在媒体网关单元和媒体网关控制器单元之间、在分散媒体网关控制器单元之间以及在连接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 SCN protocol translation functions taking place at the endpoints of the signaling transport, since its function is limited to the transport of the SCN protocol.
信令传输将以支持各种SCN协议的封装和传输的方式定义。它被定义为独立于在信令传输的端点处发生的任何SCN协议转换功能，因为其功能限于SCN协议的传输。
Since the function being provided is transparent transport, the following areas are considered outside the scope of the signaling transport work:
由于所提供的功能是透明运输，以下区域不在信号运输工作范围内：
- 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. - similarly, some management and addressing functions taking place within the SGU or MGU are also considered out of scope, such as determination of the destination IP address for signaling, or specific procedures for assessing the performance of the transport session (i.e., testing and proving functions).
- SCN协议本身的定义。-信令互通，例如从信道相关信令（CAS）到消息信令协议的转换。-SGU或MGU内发生的功能规范-尤其是，本工作不涉及SGU是否提供调解/互通，因为这对传输功能是透明的。-类似地，在SGU或MGU内发生的一些管理和寻址功能也被视为超出范围，例如确定用于信令的目的地IP地址，或用于评估传输会话性能的特定程序（即，测试和证明功能）。
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.
图1定义了一个常用的功能模型，该模型将SG、MGC和MG的功能分开。该模型可以多种方式实现，功能可以在单独的设备中实现，也可以在单个物理单元中组合。
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信令信息在具有所需功能和性能的实体之间传输。
+---------------+ +--------------+
| | | |
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
+---------------+ +--------------+
| | | |
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
图1:Sigtran功能模型
As discussed above, the interfaces pertaining to signaling transport include SG to MGC, SG to SG. Signaling transport may potentially be applied to the MGC to MGC or MG to MGC interfaces as well, depending on requirements for transport of the associated signaling protocol.
如上所述，与信令传输有关的接口包括SG到MGC、SG到SG。信令传输也可潜在地应用于MGC到MGC或MG到MGC接口，这取决于相关信令协议的传输要求。
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 many other examples are possible but are not shown to be concise. The use of signaling transport is independent of the implementation.
下面的图2显示了这些功能在物理实体中的一些示例实现，用于SS7和IP网络的互通，用于IP语音、ATM语音、网络访问服务器等。没有对功能分布提出建议，许多其他示例都是可能的，但显示得并不简洁。信令传输的使用与实现无关。
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.
为了与SS7控制的SCN网络互通，SG终止SS7链路，并使用信令传输将信令信息传输给MGC。MG终止交换机间中继，并根据从MGC接收的控制信令控制中继。如下例（a）所示，SG、MGC和MG可以在单独的物理单元中实现，或者如例（b）所示，MGC和MG可以在单个物理单元中实现。
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.
在替代情况（c）中，与设施相关联的SS7链路由终止交换机间中继的同一设备（即MGU）终止。在这种情况下，SG功能与MG功能位于同一位置，如下所示，信令传输用于“回程”控制发送至MGCU的信令。
Note: SS7 links may also be terminated directly on the MGCU by cross-connecting at the physical level before or at the MGU.
注：SS7链路也可以通过在MGU之前或MGU处的物理层交叉连接直接在MGCU上终止。
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
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)
(a) （b） （c）
Notes: ST = Signaling Transport used to carry SCN signaling
注：ST=用于承载SCN信令的信令传输
Figure 2: Example Implementations
图2：示例实现
In some implementations, the function of the SG may be divided into multiple physical entities to support scaling, signaling network management 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.
在一些实现中，SG的功能可以划分为多个物理实体，以支持扩展、信令网络管理和寻址关注点。因此，可以在SG之间以及从SG到MGC使用信令传输。这如下图3所示。
SGU MGCU
+---------+ +---------+
| | ST | |
| [SG2]------------------------------>[MGC] |
| ^ ^ | | |
+---|-|---+ +---------+
| |
| | ST
ST| +--------------------------------+
| |
| |
SS7 +---|----------+ SS7 +----|---------+
-----------> [SG1] | -----------> [SG1] |
media | | media | |
------------------->[MG] | ------------------->[MG] |
stream +--------------+ stream +--------------+
MGU MGU
SGU MGCU
+---------+ +---------+
| | ST | |
| [SG2]------------------------------>[MGC] |
| ^ ^ | | |
+---|-|---+ +---------+
| |
| | ST
ST| +--------------------------------+
| |
| |
SS7 +---|----------+ SS7 +----|---------+
-----------> [SG1] | -----------> [SG1] |
media | | media | |
------------------->[MG] | ------------------->[MG] |
stream +--------------+ stream +--------------+
MGU MGU
Figure 3: Multiple SG Case
图3：多个SG案例
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.
在该配置中，可能有多个MGU处理设施相关信令（即，多个MGU处理设施包含其自身的SG功能），并且只有一个SGU。因此，可以在SG1和SG2之间传输一个SS7层，在SG2和MGC之间传输另一个SS7层。例如，SG1可以将MTP3传输到SG2，SG2可以将ISUP传输到MGC。
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.
在ISDN接入信令中，信令信道与数据信道一起承载，因此用于处理Q.931信令的SG功能与用于处理数据流的MG功能位于同一位置。在Q.931随后被传输到MGC进行呼叫处理的情况下，将在SG功能和MGC之间使用信令传输。这如下图3所示。
MGCU
+-------------+
| [MGC] |
| | | |
+-----|-|-----+
| |
| O device control
| |
Q.931/ST O |
| |
+-----|-|-----+
| | | |
Q.931---->[SG]| |
signals| | |
| | |
Media---->[MG] |
stream | |
+-------------+
MGU
MGCU
+-------------+
| [MGC] |
| | | |
+-----|-|-----+
| |
| O device control
| |
Q.931/ST O |
| |
+-----|-|-----+
| | | |
Q.931---->[SG]| |
signals| | |
| | |
Media---->[MG] |
stream | |
+-------------+
MGU
Figure 4: Q.931 transport model
图4:Q.931运输模型
Transaction Capabilities (TCAP) is the application part within SS7 that is used for non-circuit-related signaling.
事务处理能力（TCAP）是SS7中用于非电路相关信令的应用程序部分。
TCAP signaling within IP networks may be used for cross-access between entities in the SS7 domain and the IP domain, such as, for example:
IP网络内的TCAP信令可用于SS7域和IP域中的实体之间的交叉访问，例如：
- 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.
- 从SS7网络到IP中的服务控制点（SCP）的访问。-从SS7网络访问MGC。-从MGC访问SS7网元。-从IP SCP访问SS7网元。
A basic functional model for TCAP over IP is shown in Figure 5.
TCAP over IP的基本功能模型如图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
+--------------+
| 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
图5:IP上的TCAP信令
This section provides a series of examples of protocol architecture for the use of Signaling Transport (SIG).
本节提供了一系列使用信令传输（SIG）的协议体系结构示例。
Signaling Transport in the protocol architecture figures below is assumed to consist of three components (see Figure 6):
以下协议架构图中的信令传输假定由三个组件组成（见图6）：
1) an adaptation sub-layer that supports specific primitives, e.g., management indications, required by a particular SCN signaling application protocol. 2) a Common Signaling Transport Protocol that supports a common set of reliable transport functions for signaling transport. 3) a standard, unmodified IP transport protocol.
1) 一种适配子层，支持特定SCN信令应用协议所需的特定原语，例如管理指示。2） 一种通用信令传输协议，支持信令传输的一组通用可靠传输功能。3） 一种标准的、未经修改的IP传输协议。
+-- +--------------------------------+
| | SCN adaptation module |
| +--------------------------------+
| |
S | +--------------------------------+
I | | Common Signaling Transport |
G | +--------------------------------+
| |
| +--------------------------------+
| | standard IP transport |
+-- +--------------------------------+
+-- +--------------------------------+
| | SCN adaptation module |
| +--------------------------------+
| |
S | +--------------------------------+
I | | Common Signaling Transport |
G | +--------------------------------+
| |
| +--------------------------------+
| | standard IP transport |
+-- +--------------------------------+
Figure 6: Signaling Transport Components
图6：信令传输组件
This section provides a protocol architecture for signaling transport supporting SS7 access for Media Gateway Control.
本节提供了一种协议体系结构，用于支持媒体网关控制的SS7访问的信令传输。
****** SS7 ******* SS7 ****** IP *******
*SEP *--------* STP *------* SG *------------* MGC *
****** ******* ****** *******
****** SS7 ******* SS7 ****** IP *******
*SEP *--------* STP *------* SG *------------* MGC *
****** ******* ****** *******
+----+ +-----+
|ISUP| | ISUP|
+----+ +-----+ +---------+ +-----+
|MTP | |MTP | |MTP | SIG| | SIG |
|L1-3| |L1-3 | |L1-3+----+ +-----+
| | | | | | IP | | IP |
+----+ +-----+ +---------+ +-----+
+----+ +-----+
|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 Controller
STP - Signal Transfer Point SEP - Signaling End Point
SG - Signaling Gateway SIG - Signaling Transport
MGC - Media Gateway Controller
Figure 7: SS7 Access to MGC
图7:7号信令接入MGC
This section provides a protocol architecture for signaling transport supporting ISDN point-to-point access (Q.931) for Media Gateway Control.
本节提供了支持ISDN点到点访问（Q.931）的信令传输协议体系结构，用于媒体网关控制。
****** ISDN ********* IP *******
* EP *--------------* SG/MG *------------* MGC *
****** ********* *******
****** ISDN ********* IP *******
* EP *--------------* SG/MG *------------* MGC *
****** ********* *******
+----+ +-----+
|Q931| | Q931|
+----+ +---------+ +-----+
|Q921| |Q921| SIG| | SIG |
+ + + +----+ +-----+
| | | | IP | | IP |
+----+ +---------+ +-----+
+----+ +-----+
|Q931| | Q931|
+----+ +---------+ +-----+
|Q921| |Q921| SIG| | SIG |
+ + + +----+ +-----+
| | | | IP | | IP |
+----+ +---------+ +-----+
MG/SG - Media Gateway with SG function for backhaul EP - ISDN End Point
MG/SG-用于回程EP-ISDN端点的具有SG功能的媒体网关
Figure 8: ISDN Access
图8:ISDN接入
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 SIG, depending on the SS7 application.
本节提供用于数据库访问的协议体系结构，例如提供两个IN节点或两个移动网络节点之间的信令。SIG中包含的协议栈和功能有许多场景，具体取决于SS7应用程序。
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.
在图中，SS7应用部分（S7AP）一般用于涵盖所有应用部分（如MAP、is-41、INAP等）。根据正在传输的协议，S7AP可以包括也可以不包括TCAP。S7AP下方SS7层的接口可以是TC用户接口或SCCP用户接口。
Figure 9a 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.
图9a显示了SCCP是SG和IP信令端点（ISEP）之间传输的信令协议的场景，即支持一些SS7应用协议的IP目的地。
****** SS7 ******* SS7 ****** IP *******
*SEP *--------* STP *------* SG *-------------* ISEP*
****** ******* ****** *******
****** SS7 ******* SS7 ****** IP *******
*SEP *--------* STP *------* SG *-------------* ISEP*
****** ******* ****** *******
+-----+ +-----+
|S7AP | |S7AP |
+-----+ +-----+
|SCCP | |SCCP |
+-----+ +-----+ +---------+ +-----+
|MTP | |MTP | |MTP |SIG | |SIG |
+ + + + + +----+ +-----+
| | | | | | IP | |IP |
+-----+ +-----+ +---------+ +-----+
+-----+ +-----+
|S7AP | |S7AP |
+-----+ +-----+
|SCCP | |SCCP |
+-----+ +-----+ +---------+ +-----+
|MTP | |MTP | |MTP |SIG | |SIG |
+ + + + + +----+ +-----+
| | | | | | IP | |IP |
+-----+ +-----+ +---------+ +-----+
Figure 9a: SS7 Access to IP node - SCCP being transported
图9a:SS7对IP节点的访问-正在传输的SCCP
Figure 9b shows the scenario where S7AP is the signaling protocol being transported between SG and ISEP. Depending on the protocol being transported, S7AP may or may not include TCAP, which implies that SIG must be able to support both the TC-user and the SCCP-user interfaces.
图9b显示了S7AP是SG和ISEP之间传输的信令协议的场景。根据传输的协议，S7AP可能包括也可能不包括TCAP，这意味着SIG必须能够同时支持TC用户和SCCP用户接口。
****** SS7 ******* SS7 ****** IP *******
*SEP *--------* STP *------* SG *-------------* ISEP*
****** ******* ****** *******
****** SS7 ******* SS7 ****** IP *******
*SEP *--------* STP *------* SG *-------------* ISEP*
****** ******* ****** *******
+-----+ +-----+
|S7AP | |S7AP |
+-----+ +----+----+ +-----+
|SCCP | |SCCP| | | |
+-----+ +-----+ +----|SIG | |SIG |
|MTP | |MTP | |MTP | | | |
+ + + + + +----+ +-----+
| | | | | |IP | |IP |
+-----+ +-----+ +---------+ +-----+
+-----+ +-----+
|S7AP | |S7AP |
+-----+ +----+----+ +-----+
|SCCP | |SCCP| | | |
+-----+ +-----+ +----|SIG | |SIG |
|MTP | |MTP | |MTP | | | |
+ + + + + +----+ +-----+
| | | | | |IP | |IP |
+-----+ +-----+ +---------+ +-----+
Figure 9b: SS7 Access to IP node - S7AP being transported
图9b:SS7对IP节点的访问-正在传输的S7AP
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.
本节确定了支持SCN信令网络中两个端点之间的信令的协议体系结构，使用两个SGs之间的直接信令传输。
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.
下图描述了两个SGs为SS7和IP互通提供不同级别功能的场景的协议体系结构。这与图3中给出的场景相对应。
The SS7 User Part (S7UP) shown is an SS7 protocol using MTP directly for transport within the SS7 network, for example, ISUP.
所示的SS7用户部分（S7UP）是直接使用MTP在SS7网络内传输的SS7协议，例如ISUP。
In this scenario, there are two different usage cases of SIG, one which transports MTP3 signaling, the other which transports ISUP signaling.
在此场景中，SIG有两种不同的使用情况，一种传输MTP3信令，另一种传输ISUP信令。
****** SS7 ****** IP ****** IP ******
*SEP *-------* SG1*----------* SG2*-------*MGC *
****** ****** ****** ******
****** SS7 ****** IP ****** IP ******
*SEP *-------* SG1*----------* SG2*-------*MGC *
****** ****** ****** ******
+----+ +----+
|S7UP| |S7UP|
+----+ +----+----+ +----+
|MTP3| |MTP3| | | |
+----+ +---------+ +----+ SIG| |SIG |
|MTP2| |MTP2|SIG | |SIG | | | |
+ + + +----+ +----+----+ +----+
| | | | IP | | IP | | IP |
+----+ +----+----+ +----+----+ +----+
+----+ +----+
|S7UP| |S7UP|
+----+ +----+----+ +----+
|MTP3| |MTP3| | | |
+----+ +---------+ +----+ SIG| |SIG |
|MTP2| |MTP2|SIG | |SIG | | | |
+ + + +----+ +----+----+ +----+
| | | | IP | | IP | | IP |
+----+ +----+----+ +----+----+ +----+
S7UP - SS7 User Part
S7UP-SS7用户部分
Figure 10: SG to SG Case 1
图10:SG至SG案例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互通在IP网络上传输SS7上层信令的更一般用途，其中端点都是SS7 SEP。
****** SS7 ****** IP ****** SS7 ******
*SEP *--------* SG *-----------* SG *--------*SEP *
****** ****** ****** ******
****** SS7 ****** IP ****** SS7 ******
*SEP *--------* SG *-----------* SG *--------*SEP *
****** ****** ****** ******
+----+ +-----+
|S7UP| | S7UP|
+----+ +-----+
|MTP3| | MTP3|
+----+ +---------+ +---------+ +-----+
|MTP2| |MTP2| SIG| |SIG |MTP2| | MTP2|
+ + + +----+ +----+ + + +
| | | | IP | | IP | | | |
+----+ +----+----+ +----+----+ +-----+
+----+ +-----+
|S7UP| | S7UP|
+----+ +-----+
|MTP3| | MTP3|
+----+ +---------+ +---------+ +-----+
|MTP2| |MTP2| SIG| |SIG |MTP2| | MTP2|
+ + + +----+ +----+ + + +
| | | | IP | | IP | | | |
+----+ +----+----+ +----+----+ +-----+
Figure 11: SG to SG Case 2
图11:SG至SG案例2
Signaling transport provides for the transport of native SCN protocol messages over a packet switched network.
信令传输用于通过分组交换网络传输本机SCN协议消息。
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).
1) 各种SCN协议类型的传输，例如SS7的应用程序和用户部分（包括MTP级别3、ISUP、SCCP、TCAP、MAP、INAP、IS-41等）和DSS1/PSS1协议的第3层（即Q.931和QSIG）。
2) Provide a means to identify the particular SCN protocol being transported.
2) 提供识别正在传输的特定SCN协议的方法。
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.
3) 提供一个通用的基本协议，定义报头格式、安全扩展和信令传输过程，并根据需要支持扩展，以在需要时添加单个SCN协议。
4) In conjunction with the underlying network protocol (IP), provide the relevant functionality as defined by the appropriate SCN lower layer.
4) 结合底层网络协议（IP），提供相应SCN底层定义的相关功能。
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 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.
- 如果本机SCN协议为ISUP或SCCP，则应提供MTP2/3提供的相关功能。-如果本机SCN协议为TCAP，则应支持SCCP无连接类和MTP 2/3提供的相关功能。-如果本机SCN协议为Q.931，则应支持Q.921提供的相关功能。-如果本机SCN协议为MTP3，则应支持MTP2的相关功能。
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.
5) 支持在一个底层信令传输会话上多路复用多个更高层SCN会话的能力。例如，这允许在一个信令传输会话中承载多个dss1d信道会话。
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. The protocol should also allow the SG to send different control streams to different destination ports if desired.
通常，对于单个控制流中的信令消息，需要顺序内交付，但是对于属于不同控制流的消息，不一定需要顺序内交付。如果可能，协议应利用此属性，以避免由于另一个控制流中的序列错误而阻塞一个控制流中的消息传递。如果需要，协议还应允许SG向不同的目标端口发送不同的控制流。
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.
6) 能够传输长度超过基础SCN分段/重组限制的完整消息。例如，信令传输不应受到为SS7低层协议定义的长度限制（例如，窄带SS7的情况下为272字节）的限制，但应能够承载更长的消息而无需分段。
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.
7) 允许一系列适当稳健的安全方案，以保护跨网络传输的信令信息。例如，信令传输应能够在可代理会话上运行，并能够通过防火墙传输。
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.
8) 通过支持对信令流量生成（包括SCN中生成的信令）和对网络拥塞的反应的适当控制，在互联网上避免拥塞。
This section provides basic values regarding performance requirements of key SCN protocols to be transported. Currently only message-based SCN protocols are considered. Failure to meet these requirements is likely to result in adverse and undesirable signaling and call behavior.
本节提供了有关要传输的关键SCN协议的性能要求的基本值。目前只考虑基于消息的SCN协议。未能满足这些要求可能会导致不利和不良的信令和呼叫行为。
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.
已为MTP 3级网络管理消息的传输规定了以下性能要求。此处给出的要求仅适用于通过IP网络传输所有MTP 3级消息的情况。
- Message Delay - MTP Level 3 peer-to-peer procedures require response within 500 to 1200 ms. 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.
- 消息延迟-MTP 3级对等程序要求在500到1200毫秒内响应。该值包括往返时间和远程端的处理。未能满足此限制将导致启动特定计时器的错误程序，例如ITU-T建议Q.704中的计时器T4。
The performance requirements below have been specified for transport of MTP Level 3 user part messages as part of ITU-T SS7 Recommendations [SS7].
以下性能要求已作为ITU-T SS7建议[SS7]的一部分，针对MTP 3级用户部件信息的传输进行了规定。
- Message Loss - no more than 1 in 10E+7 messages will be lost due to transport failure
- 消息丢失-由于传输故障，丢失的消息不超过1/10E+7
- Sequence Error - no more than 1 in 10E+10 messages will be delivered out-of-sequence (including duplicated messages) due to transport failure
- 顺序错误-由于传输失败，不超过1/10E+10的消息将按顺序发送（包括重复消息）
- 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)
- 消息错误-不超过1/10E+10的消息包含传输协议未检测到的错误（ANSI规范要求为10E+9）
- 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.
- 可用性-任何信令路由集的可用性为99.9998%或更高，即停机时间为10分钟/年或更短。信令路由集是从给定信令点到特定目的地的允许信令路径的完整集合。
- Message length (payload accepted from SS7 user parts) - 272 bytes for narrowband SS7, 4091 bytes for broadband SS7
- 消息长度（从SS7用户部分接受的有效负载）-窄带SS7为272字节，宽带SS7为4091字节
More detailed analysis of SS7 User Part Requirements can be found in [Lin].
有关SS7用户部件需求的更详细分析，请参见[Lin]。
ISUP Message Delay - Protocol Timer Requirements
ISUP消息延迟-协议计时器要求
- 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定时器要求的一个例子是连续性测试程序，该程序要求在发送指示连续性测试的IAM后2秒内，从接收端返回在发送端生成的音调。这意味着单向信令消息传输以及伴随的节点功能需要在2秒内完成。
ISUP Message Delay - End-to-End Requirements
ISUP消息延迟-端到端要求
- 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.
- ISUP中端到端呼叫设置延迟的要求是在IAM发送后20-30秒内收到端到端响应消息。注意：虽然这是协议保护计时器值，但用户通常期望更快的响应时间。
TCAP Requirements - Delay Requirements
TCAP要求-延迟要求
- 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.
- TCAP本身并不定义一组延迟要求。为了确定TCAP应用程序基于应用程序的延迟要求，已经做了一些工作[Lin2]。
Q.931 Message Delay
Q.931消息延迟
- round-trip delay should not exceed 4 seconds. A Timer of this length is used for a number of procedures, esp. RELASE/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.
- 往返延迟不得超过4秒。此长度的计时器用于许多程序，特别是RELASE/RELEASE COMPLETE和CONNECT/CONNECT ACK，在这些程序中，过度延迟可能导致通道上的管理操作，或释放正在设置的呼叫。注意：虽然该值由协议计时器规范指示，但用户通常期望更快的响应时间。
- 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.
- 12秒。定时器（T309）用于在数据链路丢失的情况下保持活动呼叫，等待重新建立。相关ETSI文件规定最大值为4秒，而ANSI规范[T1.607]默认值为90秒。
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.
IP网络或SCN网络的运营、管理和管理（OA&M）不属于SIGTRAN的范围。OA&M的示例包括传统电话管理系统或IETF SNMP管理器。OA&M实施者和用户应了解SG、MGC和MG的功能交互以及它们所占用的物理单元。
When SCN related signaling is transported over an IP network two possible network scenarios can be distinguished:
当通过IP网络传输SCN相关信令时，可以区分两种可能的网络场景：
- 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.
- 可用性：即使受到攻击，通信端点也必须保持服务状态以供授权使用。
Several security mechanisms are currently available for use in IP networks.
目前有几种安全机制可用于IP网络。
- 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.
- IPSEC（[RFC2401]）：IPSEC在IP层提供满足上述要求的安全服务。它分别定义了两个协议AH和ESP，它们基本上提供了数据完整性和数据机密性服务。
The ESP mechanism can be used in two different modes: - Transport mode; - Tunnel mode.
ESP机构可用于两种不同的模式：-传输模式；-隧道模式。
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.
在传输模式下，IPSEC保护IP数据包的高层协议数据部分，而在隧道模式下，完整的IP数据包封装在安全的IP隧道中。
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].
如果SIG在IP报头中嵌入SA/DA之外的任何IP地址，则通过NAT函数将导致问题。通常使用IPsec也是如此，除非按照RFC 2663[NAT]中的描述使用IPsec就绪RSIP函数。
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.
IPSEC的使用并不妨碍TCP或UDP作为SIG的基础。如果需要自动分发密钥，则可以应用IKE协议（[RFC2409]）。
- SSL, TLS ([RFC2246]): SSL and TLS also provide appropriate security services but operate on top of TCP/IP only.
- SSL、TLS（[RFC2246]）：SSL和TLS也提供适当的安全服务，但仅在TCP/IP之上运行。
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.
不需要在SIG中定义新的安全机制，因为使用当前可用的机制足以提供必要的安全性。建议使用IPSEC或某些等效方法，尤其是在公共Internet上传输SCN信令时。
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 Part
CAS信道相关信令DSS1数字用户信令INAP智能网应用部分ISEP IP信令端点ISUP信令系统7 ISDN用户部分MAP移动应用部分MG媒体网关MGU媒体网关单元MGC媒体网关控制器MGCU媒体网关控制器单元MTP信令系统7消息传输部分PLMN公共陆地移动网PSTN公共交换电话网S7AP SS7应用部分S7UP SS7用户部分SCCP SS7信令连接控制部分SCN交换电路网SEP信令端点SG信令网关SIG信令传输协议栈SS7信令系统7号TCAP信令系统7事务能力部分
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.
作者要感谢K.Chong、I.Elliott、Ian Spiers、Al Varney、Goutam Shaw、C.Huitema、Mike McGrew和Greg Sidebottom提出的宝贵意见和建议。
[NAT] Srisuresh P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[NAT]Srisuresh P.和M.Holdrege，“IP网络地址转换器（NAT）术语和注意事项”，RFC 2663，1999年8月。
[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"
[PSS1/QSIG]ISO/IEC 11572第2版（1997-06），“信息技术-系统间电信和信息交换-专用综合业务网-电路模式承载业务-交换间信令程序和协议”
[Q.931/DSS1] ITU-T Recommendation Q.931, ISDN user-network interface layer 3 specification (5/98)
[Q.931/DSS1]ITU-T建议Q.931，ISDN用户网络接口第3层规范（5/98）
[SS7] ITU-T Recommendations Q.700-775, Signalling System No. 7
[SS7]ITU-T建议Q.700-775，第7号信令系统
[SS7 MTP] ITU-T Recommendations Q.701-6, Message Transfer Part of SS7
[SS7 MTP]ITU-T建议Q.701-6，SS7的消息传输部分
[T1.607] ANSI T1.607-1998, Digital Subscriber Signaling System Number 1 (DSS1) - Layer 3 Signaling Specification for Circuit-Switched Bearer Services
[T1.607]ANSI T1.607-1998，数字用户信令系统1号（DSS1）-电路交换承载业务的第3层信令规范
[Lin] Lin, H., Seth, T., et al., "Performance Requirements for Signaling in Internet Telephony", Work in Progress.
[Lin]Lin，H.，Seth，T.，等，“互联网电话中信令的性能要求”，正在进行的工作。
[Lin2] Lin, H., et al., "Performance Requirements for TCAP Signaling in Internet Telephony", Work in Progress.
[Lin2]Lin，H.等人，“互联网电话中TCAP信令的性能要求”，正在进行中。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246]Dierks，T.和C.Allen，“TLS协议版本1.0”，RFC2246，1999年1月。
[RFC2409] Harkins, D. and C. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]Harkins，D.和C.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
Authors' Addresses
作者地址
Lyndon Ong Nortel Networks 4401 Great America Parkway Santa Clara, CA 95054, USA
林登北电网络4401大美洲大道圣克拉拉，加利福尼亚州95054，美国
EMail: long@nortelnetworks.com
EMail: long@nortelnetworks.com
Ian Rytina Ericsson Australia 37/360 Elizabeth Street Melbourne, Victoria 3000, Australia
澳大利亚维多利亚州墨尔本伊丽莎白街37/360号Ian Rytina Ericsson澳大利亚3000
EMail: ian.rytina@ericsson.com
EMail: ian.rytina@ericsson.com
Matt Holdrege Lucent Technologies 1701 Harbor Bay Parkway Alameda, CA 94502 USA
Matt Holdrege-Lucent Technologies 1701美国加利福尼亚州阿拉米达港湾公园路94502号
EMail: holdrege@lucent.com
EMail: holdrege@lucent.com
Lode Coene Siemens Atea Atealaan 34 Herentals, Belgium
Lode Coene Siemens Atea Atealan 34 Herentals，比利时
EMail: lode.coene@siemens.atea.be
EMail: lode.coene@siemens.atea.be
Miguel-Angel Garcia Ericsson Espana Retama 7 28005 Madrid, Spain
米格尔·安吉尔·加西亚·爱立信西班牙马德里7 28005
EMail: Miguel.A.Garcia@ericsson.com
EMail: Miguel.A.Garcia@ericsson.com
Chip Sharp Cisco Systems 7025 Kit Creek Road Res Triangle Pk, NC 27709, USA
Chip Sharp Cisco Systems 7025 Kit Creek Road Res Triangle Pk，美国北卡罗来纳州27709
EMail: chsharp@cisco.com
EMail: chsharp@cisco.com
Imre Juhasz Telia Sweden
Imre Juhasz Telia瑞典
EMail: imre.i.juhasz@telia.se
EMail: imre.i.juhasz@telia.se
Haui-an Paul Lin Telcordia Technologies Piscataway, NJ, USA
Haui an Paul Lin Telcordia Technologies Piscataway，新泽西州，美国
EMail: hlin@research.telcordia.com
EMail: hlin@research.telcordia.com
HannsJuergen Schwarzbauer SIEMENS AG Hofmannstr. 51 81359 Munich, Germany
汉斯吉尔根·施瓦茨鲍尔西门子股份有限公司Hofmannstr。51 81359德国慕尼黑
EMail: HannsJuergen.Schwarzbauer@icn.siemens.de
EMail: HannsJuergen.Schwarzbauer@icn.siemens.de
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
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.
RFC编辑功能的资金目前由互联网协会提供。