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
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.
これがローカルでない場合、バックホールは、コールバック処理（即ち、MGCU）の点に関連するデータストリーム（MGUですなわち、SG機能）のためのインターフェースの点からのシグナリングの輸送を指します。
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は、SS7 ISDNユーザ部とQ.931 / DSS1としてSCNアプリケーション・プロトコルのための可能な終了と起点として機能します。
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によって制御されるラインまたはトランク終端に関連付けられたSCNシグナリングを処理するためのMGの機能（例えば、シグナリングバックホール）と共存することができます。
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の機能が含まれている物理的な実体です。これは、ESP、他の機能が含まれていてもよいです。設備関連のシグナリングを処理するための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シグナリングエンドポイントまたは信号転送点を結ぶ2つのシグナリングゲートウェイユニット間で、メディアゲートウェイユニット及びメディアゲートウェイコントローラユニットとの間のメッセージベースのシグナリングを搬送するためにも使用することができます。
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
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.
いいえ推奨が機能分散されており、他の多くの例が行われていない等ATM上のIP上の音声、音声のためのSS7とIPネットワーク、ネットワークアクセスサーバのインターワーキングのために使用される以下の図2は、物理的なエンティティにこれらの機能のいくつかの例示的実装を示します可能ですが、が簡潔であることが示されていません。輸送シグナル伝達の使用は、実装とは無関係です。
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に物理レベルで相互接続することによって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
(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間ならびにMGCへSGから使用することができます。これは以下の図3に示されています。
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処理施設関連シグナリング（それ自身のSGの機能を含む、すなわち複数）、及び単一SGUがあってもよいです。したがって、SG1及びSG2、及びSG2とMGCとの間の別のSS7層の間の1つのSS7層を輸送することが可能となります。例えば、SG1は、SG2にMTP3を運ぶことができ、及びSG2はMGCにISUPを運ぶことができます。
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.
Q.931シグナリングを処理するためのSGの機能がデータストリームを処理するためのMGの機能と同じ場所に配置されるように、ISDNアクセスシグナリングは、シグナリング・チャネルは、データチャネルと共に運ばれます。 931は、呼処理のためにMGCへと搬送される場合、シグナリングトランスポートは、SG機能とMGCとの間に使用されるであろう。これは以下の図3に示されています。
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.
- IPにおけるサービス制御ポイント（SCP）へのSS7ネットワークからのアクセス。 - MGCへのSS7ネットワークからのアクセス。 - SS7ネットワーク要素へのMGCからのアクセス。 - SS7ネットワーク要素へのIP SCPからのアクセス。
A basic functional model for TCAP over IP is shown in Figure 5.
IP上TCAPのための基本的な機能モデルは、図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 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):
次の3つの構成要素（図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 |
+-- +--------------------------------+
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 *
****** ******* ****** *******
+----+ +-----+
|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 - シグナルポイント9月転送 - シグナリングエンドポイントSG - シグナリングゲートウェイSIG - シグナリング交通MGC - メディアゲートウェイコントローラ
Figure 7: SS7 Access to MGC
図7：MGCへのSS7のアクセス
This section provides a protocol architecture for signaling transport supporting ISDN point-to-point access (Q.931) for Media Gateway Control.
このセクションでは、メディアゲートウェイ制御のためのISDNポイントツーポイント接続（931）を支持する輸送をシグナリングするためのプロトコルアーキテクチャを提供します。
****** 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 Point
MG / SG - バックホールEPのためのSG機能付きメディアゲートウェイ - ISDNエンドポイント
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.
このセクションでは、ノードまたは2つのモバイルネットワークノード内の二つの間のシグナリングを提供例えば、データベース・アクセスのためのプロトコルアーキテクチャを提供します。プロトコルスタックのためのシナリオの数とSS7の用途に応じて、SIGに含まれる機能があります。
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*
****** ******* ****** *******
+-----+ +-----+
|S7AP | |S7AP |
+-----+ +-----+
|SCCP | |SCCP |
+-----+ +-----+ +---------+ +-----+
|MTP | |MTP | |MTP |SIG | |SIG |
+ + + + + +----+ +-----+
| | | | | | IP | |IP |
+-----+ +-----+ +---------+ +-----+
Figure 9a: SS7 Access to IP node - SCCP being transported
図9a：IPノードへのアクセスは、SS7 - 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はまたはSIGは、TC-ユーザとSCCPユーザ・インターフェースの両方をサポートすることができなければならないことを意味する、TCAPを含んでも含まなくてもよいです。
****** 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
図9b：IPノードにSS7アクセス - 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.
このセクションでは、2つのSG間で直接のシグナリングトランスポートを使用して、SCNシグナリングネットワーク内の2つのエンドポイント間のシグナリングをサポートするためのプロトコルアーキテクチャを識別する。
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.
次の図は、2つの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）は、SS7ネットワーク内輸送のために直接MTPを使用してSS7プロトコル、例えば、ISUPです。
In this scenario, there are two different usage cases of SIG, one which transports MTP3 signaling, the other which transports ISUP signaling.
このシナリオでは、ISUPシグナリングを搬送SIG、MTP3シグナリングを搬送する一つの他の二つの異なる使用ケースがあります。
****** SS7 ****** IP ****** IP ******
*SEP *-------* SG1*----------* SG2*-------*MGC *
****** ****** ****** ******
+----+ +----+
|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ケース1 SG
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のSEPであるIPネットワークを介してSS7上位層シグナリングの輸送のためのSS7-IPインターワーキングのより一般的な使用を記載しています。
****** 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
図11：SGケース2のSG
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）このようなSS7のアプリケーションとユーザ部品としてSCNプロトコルタイプ、様々なトランスポート（MTPレベル3、ISUP、SCCP、TCAP、MAP、INAP、IS-41、等）とDSS1の層3 /含みますPSS1プロトコル（つまり、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.
適切なSCN下位層によって定義されるような4）基本的なネットワークプロトコル（IP）に関連して、関連する機能を提供します。
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プロトコルが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）1つの基礎となるシグナルのトランスポートセッションでいくつかの上位層のSCNセッションを多重化する能力をサポートしています。これは、例えば、いくつかのDSS1 Dチャネルセッションはつのシグナリングトランスポートセッションで実施することが、可能となります。
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.
一般に、インシーケンス配信は、単一の制御ストリーム内のシグナリングメッセージのために必要とされるが、必ずしも異なる制御ストリームに属するメッセージのために必要とされません。プロトコルは、可能な場合は、原因別の制御ストリーム内のシーケンスエラーに1つの制御ストリームにメッセージの配信をブロックしないように、この性質を利用する必要があります。プロトコルはまた、所望であれば、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）ネットワークを介して搬送されるシグナリング情報を保護するために適当に強固なセキュリティ方式の範囲を許可。例えば、トランスポートシグナリングするproxyableセッションにわたって動作することができ、およびファイアウォールを介して輸送することができなければなりません。
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のネットワーク管理メッセージの輸送のために指定されています。すべてのMTPレベル3メッセージは、IPネットワーク上で転送される場合は、ここで与えられた要求事項にのみ適用されます。
- 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 7 + 10E内のメッセージが原因輸送障害のために失われます
- Sequence Error - no more than 1 in 10E+10 messages will be delivered out-of-sequence (including duplicated messages) due to transport failure
- シーケンスエラー - これ以上10 + 10Eにおける1以上のメッセージが原因輸送障害に（重複したメッセージを含む）アウトオブシーケンス配信されます
- 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)
- メッセージエラー - トランスポートプロトコルによって検出されないエラーを含むことになる10E + 10メッセージでない1以上（要件は、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ユーザ部の要件のより詳細な分析は[林]で見つけることができます。
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自体は遅延要件のセットを定義していません。いくつかの作業が行われている[LIN2] TCAPアプリケーションのためのアプリケーションベースの遅延要件を識別します。
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秒を超えてはいけません。この長さのタイマは、ESP、手順の数のために使用されます。過度の遅延は、コールのチャネル、または放出の管理アクションをもたらすことができる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文書は、ANSI仕様[T1.607]デフォルトながら、90秒に4秒の最大値を指定します。
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:
SCN関連シグナリングは、IPネットワークを介して搬送されるときに、2つの可能なネットワークシナリオを区別することができます。
- 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レイヤでセキュリティサービスを提供します。それは本質的に、データの整合性とデータの機密性サービスを提供し、それぞれ2つのプロトコルAHとESPを定義します。
The ESP mechanism can be used in two different modes: - Transport mode; - Tunnel mode.
ESPメカニズムは、2つの異なるモードで使用することができます： - トランスポートモード。 - トンネルモード。
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.
トンネルモードでは、完全なIPパケットがセキュアなIPトンネルにカプセル化されながら、トランスポート・モードのIPsecは、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機能を通る通路は、問題が発生します。 RFC 2663 [NAT]に記載されるようにIPsec準備RSIP機能が使用されない限り、同じことが、一般的にIPsecを使用しても同様です。
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の使用は、SIGの基礎ベースとして、TCPやUDPの使用を妨げません。キーの自動配布が必要な場合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の新しいセキュリティ・メカニズムを定義する必要はありません。公共のインターネット上でSCNシグナリングを輸送する場合は特に、IPSECまたは何らかの同等の方法を使用することをお勧めします。
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は、回路網9月シグナリングエンドポイント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.チョン、I.エリオット、イアン・スピアーズ、アルバーニー、Goutamショー、C.のHuitema、マイクマグリューとGreg Sidebottomに感謝したいと思います。
[NAT] Srisuresh P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[NAT] Srisuresh P.とM.ホールドレッジ、 "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年から1906年）、「情報技術 - 電気通信及びシステム間情報交換 - 私設総合サービス網 - 相互交換のシグナリング手順とプロトコル - 回線交換モードベアラサービス」
[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.
[林]林、H.、セス、T.、ら。、「インターネット電話におけるシグナリングに関する性能要件」、進行中の作業。
[Lin2] Lin, H., et al., "Performance Requirements for TCAP Signaling in Internet Telephony", Work in Progress.
[LIN2]林、H.、ら、「インターネット電話でTCAPのシグナリングのためのパフォーマンス要件」、進行中の作業。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246]ダークス、T.とC.アレン、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
[RFC2409] Harkins, D. and C. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とC.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
Authors' Addresses
著者のアドレス
Lyndon Ong Nortel Networks 4401 Great America Parkway Santa Clara, CA 95054, USA
リンドン・オングNortel Networksの4401グレートアメリカパークウェイサンタクララ、CA 95054、USA
EMail: long@nortelnetworks.com
メールアドレス：long@nortelnetworks.com
Ian Rytina Ericsson Australia 37/360 Elizabeth Street Melbourne, Victoria 3000, Australia
イアンRytinaエリクソンオーストラリア360分の37エリザベスストリートメルボルン、ビクトリア3000、オーストラリア
EMail: ian.rytina@ericsson.com
メールアドレス：ian.rytina@ericsson.com
Matt Holdrege Lucent Technologies 1701 Harbor Bay Parkway Alameda, CA 94502 USA
マット・ホールドレッジルーセント・テクノロジーズ1701ハーバー・ベイ・パークウェイアラメダ、CA 94502 USA
EMail: holdrege@lucent.com
メールアドレス：holdrege@lucent.com
Lode Coene Siemens Atea Atealaan 34 Herentals, Belgium
鉱脈CoeneシーメンスATEA Atealaan 34 Herentalsの、ベルギー
EMail: lode.coene@siemens.atea.be
メールアドレス：lode.coene@siemens.atea.be
Miguel-Angel Garcia Ericsson Espana Retama 7 28005 Madrid, Spain
ミゲル・アンヘル・ガルシア・エリクソンエスパーニャRetama 7 28005マドリード、スペイン
EMail: Miguel.A.Garcia@ericsson.com
メールアドレス：Miguel.A.Garcia@ericsson.com
Chip Sharp Cisco Systems 7025 Kit Creek Road Res Triangle Pk, NC 27709, USA
チップシャープシスコシステムズ7025キットクリーク道路レッドトライアングルパーク、NC 27709、USA
EMail: chsharp@cisco.com
メールアドレス：chsharp@cisco.com
Imre Juhasz Telia Sweden
イムレ・ジュハスツテリアスウェーデン
EMail: imre.i.juhasz@telia.se
メールアドレス：imre.i.juhasz@telia.se
Haui-an Paul Lin Telcordia Technologies Piscataway, NJ, USA
Hauiポール・林-のTelcordia Technologies社ピスカタウェイ、NJ、USA
EMail: hlin@research.telcordia.com
メールアドレス：hlin@research.telcordia.com
HannsJuergen Schwarzbauer SIEMENS AG Hofmannstr. 51 81359 Munich, Germany
ハンスユルゲン・シュヴァルツェンバウアーSIEMENS AG Hofmannstr。 51 81359ミュンヘン、ドイツ
EMail: HannsJuergen.Schwarzbauer@icn.siemens.de
メールアドレス：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 Editor機能のための基金は現在、インターネット協会によって提供されます。