[要約] RFC 2719は、信号輸送のためのフレームワークアーキテクチャに関するものであり、信号輸送の要件とプロトコルの設計に関するガイドラインを提供しています。目的は、信号輸送の効率性と信頼性を向上させるための統一されたアーキテクチャを提供することです。
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.
Copyright（c）The Internet Society（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を介したシグナリング情報の輸送のためのアーキテクチャフレームワークと機能要件を定義しています。このフレームワークは、シグナリングゲートウェイやメディアゲートウェイコントローラーなどのシグナル伝達情報を交換する機能的エンティティと物理エンティティの関係について説明します。シグナリング輸送を使用する可能性のあるインターフェイスと、既存のSwitched Circuit Network（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.
Backhaulとは、関連するデータストリーム（つまり、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):
Switched Circuit Network（SCN）：
The term SCN is used to refer to a network that carries traffic within channelized bearers of pre-defined sizes. Examples include Public Switched Telephone Networks (PSTNs) and Public Land Mobile Networks (PLMNs). Examples of signaling protocols used in SCN include Q.931, SS7 MTP Level 3 and SS7 Application/User parts.
SCNという用語は、事前に定義されたサイズのチャネル化されたベアラー内にトラフィックを運ぶネットワークを参照するために使用されます。例には、パブリックスイッチ付き電話ネットワーク（PSTN）と公共の土地モバイルネットワーク（PLMNS）が含まれます。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関数との共同住宅であり、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の信号エンドポイントまたは信号転送ポイントを接続する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が調停/インターワーキングを提供するかどうかには対応していません。 - 同様に、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.
以下の図2は、音声オーバーIP、音声オーバーATM、ネットワークアクセスサーバーなどのSS7およびIPネットワークのインターワークに使用される物理エンティティでのこれらの機能の実装のいくつかを示しています。可能ですが、簡潔であることは示されていません。シグナリング輸送の使用は、実装とは無関係です。
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は別々の物理ユニットに実装される場合があります。
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
(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
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機能を含む複数のSG機能を含む）があり、SGUが1つだけです。したがって、SG1とSG2の間に1つの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
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のSS7ネットワークからサービス制御ポイント（SCP）へのアクセス。-SS7ネットワークからMGCへのアクセス。-MGCからSS7ネットワーク要素へのアクセス。-IPSCPからSS7ネットワーク要素へのアクセス。
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
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ポイントツーポイントアクセス（Q.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-バックホールのSG機能を備えたメディアゲートウェイEP -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つのノードまたは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にはTCAPが含まれている場合と含まれていない場合があります。これは、SIGがTCユーザーとSCCPユーザーインターフェイスの両方をサポートできる必要があることを意味します。
****** 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.
このセクションでは、SCNシグナリングネットワーク内の2つのエンドポイント間のシグナル伝達をサポートするプロトコルアーキテクチャを識別し、2つのSG間のシグナル伝達輸送を使用します。
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.
このシナリオでは、SIGには2つの異なる使用法があり、1つはMTP3シグナリングを輸送し、もう1つはISUPシグナリングを輸送します。
****** 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から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 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から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) SS7のアプリケーションやユーザーパーツ（MTPレベル3、ISUP、SCCP、TCAP、MAP、IS-41など）やレイヤー3のアプリケーションやユーザーパーツなど、DSS1/PSS1プロトコルなど、さまざまなSCNプロトコルタイプの輸送（つまり、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) ヘッダー形式を定義する一般的なベースプロトコル、シグナリング輸送のためのセキュリティ拡張および手順を定義し、必要に応じて必要に応じて拡張をサポートします。
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 Connectionlessクラスと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) 1つの基礎となるシグナリング輸送セッションでいくつかの高層SCNセッションを多重化する機能をサポートします。これにより、たとえば、いくつかのDSS1 Dチャネルセッションを1つのシグナリング輸送セッションで携帯することができます。
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ネットワーク管理メッセージの輸送のために指定されています。ここに記載されている要件は、すべての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推奨のタイマーT4 Q.704。
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
- メッセージの損失 - 輸送の故障により、10e7のメッセージが1つ以下で失われます
- Sequence Error - no more than 1 in 10E+10 messages will be delivered out-of-sequence (including duplicated messages) due to transport failure
- シーケンスエラー-10e10のメッセージが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)
- メッセージエラー-10E10のメッセージに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ユーザーパーツから受け入れられたペイロード）-272バイトの狭帯域SS7、4091バイトブロードバンド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タイマーの要件の1つの例は、連続テスト手順です。これには、送信端で生成されたトーンが、連続性テストを示すIAMを送信してから2秒以内に受信側から返す必要があります。これは、メッセージトランスポートをシグナリングする1つの方法と、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秒を超えてはなりません。この長さのタイマーは、多くの手順に使用されます。リレーセ/リリース完了および接続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:
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.
トランスポートモードでは、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 READY RSIP関数がRFC 2663 [NAT]に記載されているように使用されない限り、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ユーザーパーツマップモバイルアプリケーションパート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。チョン、I。エリオット、イアン・スパイアー、アル・バーニー、グータム・ショー、C・フイエマ、マイク・マクグリュー、グレッグ・サイドボトムの貴重なコメントと提案に感謝したいと思います。
[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 ed。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、シグナリングシステムNo. 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.、et al。、「インターネットテレフォニーでのシグナリングのパフォーマンス要件」、進行中の作業。
[Lin2] Lin, H., et al., "Performance Requirements for TCAP Signaling in Internet Telephony", Work in Progress.
[Lin2] Lin、H.、et al。、「インターネットテレフォニーにおける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」、RFC 2246、1999年1月。
[RFC2409] Harkins, D. and C. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409] Harkins、D。およびC. Carrel、「The Internet Key Exchange（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
Lyndon Ong Nortel Networks 4401 Great America Parkway Santa Clara、CA 95054、米国
EMail: long@nortelnetworks.com
Ian Rytina Ericsson Australia 37/360 Elizabeth Street Melbourne, Victoria 3000, Australia
イアン・リティナ・エリクソン・オーストラリア37/360エリザベス・ストリート・メルボルン、ビクトリア3000、オーストラリア
EMail: ian.rytina@ericsson.com
Matt Holdrege Lucent Technologies 1701 Harbor Bay Parkway Alameda, CA 94502 USA
Mattrege Lucent Technologies 1701 Harbor Bay Parkway Alameda、CA 94502 USA
EMail: holdrege@lucent.com
Lode Coene
Siemens Atea
Atealaan 34
Herentals, Belgium
EMail: lode.coene@siemens.atea.be
Miguel-Angel Garcia Ericsson Espana Retama 7 28005 Madrid, Spain
ミゲル・アンジェル・ガルシア・エリクソン・エスパナ・レタマ7 28005マドリード、スペイン
EMail: Miguel.A.Garcia@ericsson.com
Chip Sharp Cisco Systems 7025 Kit Creek Road Res Triangle Pk, NC 27709, USA
チップシャープシスコシステム7025キットクリークロードレッドトライアングルパーク、ノースカロライナ州27709、米国
EMail: chsharp@cisco.com
Imre Juhasz Telia Sweden
Imre Juhasz Telia Sweden
EMail: imre.i.juhasz@telia.se
Haui-an Paul Lin Telcordia Technologies Piscataway, NJ, USA
ハウイアンポールリンテルコルディアテクノロジーズピスカタウェイ、ニュージャージー州、米国
EMail: hlin@research.telcordia.com
HannsJuergen Schwarzbauer SIEMENS AG Hofmannstr. 51 81359 Munich, Germany
Hannsjuergen Schwarzbauer Siemens Ag Hofmannstr。51 81359ミュンヘン、ドイツ
EMail: HannsJuergen.Schwarzbauer@icn.siemens.de
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。