RFC4166 日本語訳
4166 Telephony Signalling Transport over Stream Control TransmissionProtocol (SCTP) Applicability Statement. L. Coene, J. Pastor-Balbas. February 2006. (Format: TXT=46659 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group L. Coene
Request for Comments: 4166 Siemens
Category: Informational J. Pastor-Balbas
Ericsson
February 2006
Coeneがコメントのために要求するワーキンググループL.をネットワークでつないでください: 4166年のジーメンスカテゴリ: 情報のJ.牧師-Balbasエリクソン2006年2月
Telephony Signalling Transport over
Stream Control Transmission Protocol (SCTP) Applicability Statement
ストリーム制御伝動プロトコル(SCTP)適用性証明の上の電話合図輸送
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 (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
This document describes the applicability of the several protocols developed under the signalling transport framework. A description of the main issues regarding the use of the Stream Control Transmission Protocol (SCTP) and an explanation of each adaptation layer for transport of telephony signalling information over IP infrastructure are given.
このドキュメントは合図輸送フレームワークの下で開発されたいくつかのプロトコルの適用性について説明します。 Stream Control Transmissionプロトコル(SCTP)の使用に関する本題の記述とIPインフラストラクチャの上で情報に合図する電話の輸送のためのそれぞれの適合層に関する説明をします。
Coene & Pastor-Balbas Informational [Page 1] RFC 4166 Telephony Signalling over SCTP AS February 2006
2006年2月としてSCTPの上で合図するCoeneと牧師-Balbasの情報[1ページ]のRFC4166電話
Table of Contents
目次
1. Introduction ....................................................2
1.1. Scope ......................................................2
1.2. Terminology ................................................3
1.3. Contributors ...............................................3
2. SIGTRAN Architecture ............................................3
3. Issues for Transporting Telephony Signalling over SCTP ..........5
3.1. Congestion Control .........................................5
3.2. Detection of Failures ......................................6
3.2.1. Retransmission TimeOut (RTO) Calculation ............6
3.2.2. Heartbeat ...........................................7
3.2.3. Maximum Number of Retransmissions ...................7
3.3. Shorten End-to-End Message Delay ...........................7
3.4. Bundling Considerations ....................................7
3.5. Stream Usage ...............................................7
4. User Adaptation Layers ..........................................7
4.1. Access Signalling .........................................10
4.1.1. IUA (ISDN Q.921 User Adaptation) ...................10
4.1.2. V5UA (V5.2-User Adaptation) Layer ..................12
4.1.3. DUA (DPNSS/DASS User adaptation) Layer .............13
4.2. Network Signalling ........................................13
4.2.1. MTP lvl3 over IP ...................................14
4.2.2. M3UA (SS7 MTP3 User Adaptation) Layer ..............17
4.2.3. SUA (SS7 SCCP User Adaptation) Layer ...............18
5. Security Considerations ........................................20
6. Informative References .........................................20
1. 序論…2 1.1. 範囲…2 1.2. 用語…3 1.3. 貢献者…3 2. SIGTRANアーキテクチャ…3 3. SCTPの上で合図する電話を輸送するための問題…5 3.1. 混雑コントロール…5 3.2. 失敗の検出…6 3.2.1. 再送タイムアウト(RTO)計算…6 3.2.2. 鼓動…7 3.2.3. Retransmissionsの最大数…7 3.3. 終わりから終わりへのメッセージ遅延を短くしてください…7 3.4. バンドリング問題…7 3.5. 用法を流してください…7 4. ユーザ適合は層にされます…7 4.1. 合図にアクセスしてください…10 4.1.1. IUA(ISDN Q.921ユーザ適合)…10 4.1.2. V5UA(V5.2-ユーザ適合)は層にします…12 4.1.3. デュア(DPNSS/ダスのUser適合)Layer…13 4.2. 合図をネットワークでつないでください…13 4.2.1. IPの上のMTP lvl3…14 4.2.2. M3UA(SS7 MTP3ユーザ適合)は層にします…17 4.2.3. SUA(SS7 SCCPユーザ適合)は層にします…18 5. セキュリティ問題…20 6. 有益な参照…20
1. Introduction
1. 序論
This document is intended to describe how to transport telephony signalling protocols, used in classic telephony systems, over IP networks. As described in [RFC2719], the whole architecture is called SIGTRAN (Signalling Transport) and is composed of a transport protocol (SCTP) and several User Adaptation Layers (UALs). The transport protocol SCTP has been developed to fulfill the stringent requirements of telephony signalling networks [RFC3257]. The set of UALs has also been introduced to make it possible for different signalling protocols to use the SCTP layer.
このドキュメントがIPネットワークの上で古典的な電話技術システムで使用される電話合図プロトコルを輸送する方法を説明することを意図します。 [RFC2719]で説明されるように、全体のアーキテクチャは、SIGTRAN(合図Transport)と呼ばれて、トランスポート・プロトコル(SCTP)と数個のUser Adaptation Layers(UALs)で構成されます。 トランスポート・プロトコルSCTPは、電話合図ネットワーク[RFC3257]の厳しい要件を実現させるために開発されました。 また、異なった合図プロトコルがSCTP層を使用するのを可能にするようにUALsのセットを導入しました。
1.1. Scope
1.1. 範囲
The scope of this document is the SIGTRAN user adaptation layers and SCTP protocols and how they are used to transport telephony signalling information over IP networks.
このドキュメントの範囲は、SIGTRANユーザ適合層と、SCTPプロトコルとそれらがIPネットワークの上で電話合図情報を輸送するのにどう使用されるかということです。
Coene & Pastor-Balbas Informational [Page 2] RFC 4166 Telephony Signalling over SCTP AS February 2006
2006年2月としてSCTPの上で合図するCoeneと牧師-Balbasの情報[2ページ]のRFC4166電話
1.2. Terminology
1.2. 用語
The following terms are commonly identified in related work:
次の用語は関連する仕事で一般的に特定されます:
Association: SCTP connection between two endpoints.
協会: 2つの終点の間のSCTP接続。
Stream: A uni-directional logical channel established within an
association, within which all user messages are
delivered in sequence except for those submitted to the
unordered delivery service.
以下を流してください。 協会で中連続してそれらを除いて、すべてのユーザメッセージが提供される確立したuni方向の論理チャネルは順不同のデリバリ・サービスに提出されました。
SPU: Signalling protocol user, the application on top of the
User adaptation layer.
SPU: User適合層の上でプロトコルユーザ、アプリケーションに合図します。
CTSP: Classical Telephony Signalling Protocol (examples
include: MTP level 2, MTP level 3, and SCCP).
CTSP: 古典的なTelephony Signallingプロトコル(例は: MTPレベル2、MTPレベル3、およびSCCPを含んでいます)。
UAL: User Adaptation Layer, the protocol that encapsulates
the upper layer telephony signalling protocols that are
to be transported over SCTP/IP.
UAL: ユーザAdaptation Layer、上側の層がSCTP/IPの上で輸送されることになっている電話合図プロトコルであるとカプセル化するプロトコル。
ISEP: IP Signalling Endpoint, an IP node that implements SCTP
and a User adaptation layer.
ISEP: IP Signalling Endpoint、SCTPを実装するIPノード、およびUser適合は層にされます。
SP: Signalling Point.
SP: ポイントに合図します。
1.3. Contributors
1.3. 貢献者
The following people contributed to the document: L. Coene (Editor), M. Tuexen, G. Verwimp, J. Loughney, R.R. Stewart, Qiaobing Xie, M. Holdrege, M.C. Belinchon, A. Jungmaier, J. Pastor, and L. Ong.
以下の人々はドキュメントに貢献しました: L。 Coene(エディタ)、M.Tuexen、G.Verwimp、J.Loughney、R.R.スチュワート、Qiaobingシェ、M.Holdrege、M.C.Belinchon、A.Jungmaier、J.牧師、およびL.オング。
2. SIGTRAN Architecture
2. SIGTRANアーキテクチャ
The SIGTRAN architecture describes the transport of signalling information over IP infrastructure.
SIGTRANアーキテクチャはIPインフラストラクチャの上で合図情報の輸送について説明します。
Coene & Pastor-Balbas Informational [Page 3] RFC 4166 Telephony Signalling over SCTP AS February 2006
2006年2月としてSCTPの上で合図するCoeneと牧師-Balbasの情報[3ページ]のRFC4166電話
Telephony signalling transport over IP normally uses the following architecture:
通常、IPの上の輸送に合図する電話が以下のアーキテクチャを使用します:
Telephony Signalling Protocol
|
+------------------------------------+
| User Adaptation Layers |
+------------------------------------+
|
+------------------------------------+
|Stream Control Transmission Protocol|
| (SCTP) |
+------------------------------------+
|
Internet Protocol (IPv4/IPv6)
電話合図プロトコル| +------------------------------------+ | ユーザ適合層| +------------------------------------+ | +------------------------------------+ |ストリーム制御伝動プロトコル| | (SCTP) | +------------------------------------+ | インターネットプロトコル(IPv4/IPv6)
Figure 1: Telephony SIGnalling TRANsport Protocol Stack
図1: 電話合図トランスポート・プロトコルスタック
The components of the protocol stack are:
プロトコル・スタックの部品は以下の通りです。
1. Adaptation layers used when the telephony application needs to
preserve an existing primitive interface (e.g., management
indications or data operation primitives for a particular
user/application protocol).
2. SCTP, specially configured to meet the telephony application
performance requirements.
3. The standard Internet Protocol.
1. 電話アプリケーションが、既存の原始のインタフェース(特定のユーザ/アプリケーション・プロトコルのための例えば、管理指摘かデータ操作基関数)を保持する必要があると、適合は使用されていた状態で層にされます。 2. 特に、電話アプリケーション性能必要条件を満たすために構成されたSCTP。 3. 標準のインターネットプロトコル。
The telephony signalling protocols to be transported can be:
輸送されるようにプロトコルに合図する電話は以下の通りであることができます。
o [RFC3332] SS7 MTP3 users: SCCP, ISUP, TUP... o [RFC3331] SS7 MTP2 users: MTP3 o [RFC3868] SS7 SCCP users: RANAP, MAP(+TCAP), INAP(+TCAP)... o [RFC3057] ISDN Q.921 users: Q.931 o [RFC3807] V5.2 / DSS1 o ....
o [RFC3332]SS7 MTP3ユーザ: SCCP、ISUP、TUP o[RFC3331]…SS7 MTP2ユーザ: MTP3o[RFC3868]SS7 SCCPユーザ: RANAP、MAP(+ TCAP)、INAP(+ TCAP)… o[RFC3057]ISDN Q.921ユーザ: Q.931o[RFC3807]V5.2 / DSS1o…
The user adaptation layers (UALs) are a set of protocols that encapsulate a specific signalling protocol to be transported over SCTP. The adaption is done in a way that the upper signalling protocols, which are relayed, remain unaware that the lower layers are different from the original lower telephony signalling layers. In that sense, the upper interface of the user adaptation layers needs to be the same as the upper layer interface is to its original lower layer. If a MTP user is being relayed over the IP network, the related UAL used to transport the MTP user will have the same upper interface as MTP has.
ユーザ適合(UALs)層はSCTPの上で輸送されるために特定の合図プロトコルをカプセル化する1セットのプロトコルです。 適応は下層がオリジナルの低級電話合図層と異なっているのを気づかない上側の合図プロトコル(リレーされる)のままである方法で完了しています。 その意味で、オリジナルの下層には上側の層のインタフェースがあって、ユーザ適合層の上側のインタフェースは、同じである必要があります。 MTPユーザがIPネットワークの上でリレーされていると、MTPユーザを輸送するのに使用される関連するUALはMTPが持っていたように同じ上側のインタフェースを持つでしょう。
Coene & Pastor-Balbas Informational [Page 4] RFC 4166 Telephony Signalling over SCTP AS February 2006
2006年2月としてSCTPの上で合図するCoeneと牧師-Balbasの情報[4ページ]のRFC4166電話
The Stream Control Transmission Protocol was designed to fulfill the stringent transport requirements that classical signalling protocols have and is therefore the recommended transport protocol to use for this purpose.
Stream Control Transmissionプロトコルは、古典的な合図プロトコルが持っている厳しい輸送要件を実現させるように設計されて、したがって、このために使用するお勧めのトランスポート・プロトコルです。
SCTP provides the following functions:
SCTPは以下の機能を提供します:
o Reliable Data Transfer o Multiple streams to help avoid head-of-line blocking o Ordered and unordered data delivery on a per-stream basis o Bundling and fragmentation of user data o Congestion and flow control o Support for continuous monitoring of reachability o Graceful termination of association o Support of multi-homing for added reliability o Protection against blind denial-of-service attacks o Protection against blind masquerade attacks
o 助ける信頼できるData Transfer o Multipleストリームは1ストリームあたりの基礎o Bundlingにおける系列のヘッドブロッキングo Orderedと順不同のデータ配送を避けます、そして、盲目の仮面舞踏会に対する盲目のサービス不能攻撃o Protectionに対する加えられた信頼性oのProtectionのためのマルチホーミングの協会o Supportの可到達性o Graceful終了の連続監視のための利用者データo Congestionとフロー制御o Supportの断片化は攻撃されます。
SCTP is used as the transport protocol for telephony signalling applications. Message boundaries are preserved during data transport by SCTP, so each UAL can specify its own message structure within the SCTP user data. The SCTP user data can be delivered by the order of transmission within a stream (in sequence delivery) or unordered.
SCTPは電話合図アプリケーションにトランスポート・プロトコルとして使用されます。 メッセージ限界がデータ伝送の間、SCTPによって保持されるので、各UALはSCTP利用者データの中でそれ自身のメッセージ構造を指定できます。 SCTP利用者データは、ストリーム(連続して配送)の中でトランスミッションの注文で提供されて、順不同のである場合があります。
SCTP can be used to provide redundancy at the transport layer and below. Telephony applications needing this level of redundancy can make use of SCTP's multi-homing support.
トランスポート層における以下の冗長を提供するのにSCTPを使用できます。 このレベルの冗長を必要とする電話アプリケーションはSCTPのマルチホーミングサポートを利用できます。
SCTP can be used for telephony applications where head-of-line blocking is a concern. Such an application should use multiple streams to provide independent ordering of telephony signalling messages.
系列のヘッドブロッキングが関心である電話アプリケーションにSCTPを使用できます。 そのようなアプリケーションは、電話合図メッセージの独立している注文を提供するのに複数のストリームを使用するべきです。
3. Issues for Transporting Telephony Signalling over SCTP
3. SCTPの上で合図する電話を輸送するための問題
Transport of telephony signalling requires special considerations. In order to use SCTP, an implementation must take special care to meet the performance, timing, and failure management requirements.
電話合図の輸送は特別な問題を必要とします。 SCTPを使用して、実装は、性能、タイミング、および失敗管理必要条件を満たすために特別に注意を払わなければなりません。
3.1. Congestion Control
3.1. 輻輳制御
The basic mechanism of congestion control in SCTP has been described in [RFC2960]. SCTP congestion control sometimes conflicts with the timing requirements of telephony signalling application messages which are transported by SCTP. During congestion, messages may be delayed by SCTP, thus sometimes violating the timing requirements of those telephony applications.
SCTPの輻輳制御の基本的機構は[RFC2960]で説明されます。 SCTP輻輳制御は時々SCTPによって輸送されるアプリケーションメッセージを示す電話のタイミング要件と闘争します。 混雑の間、メッセージはSCTPで遅れて、その結果、時々それらの電話アプリケーションのタイミング要件に違反するかもしれません。
Coene & Pastor-Balbas Informational [Page 5] RFC 4166 Telephony Signalling over SCTP AS February 2006
2006年2月としてSCTPの上で合図するCoeneと牧師-Balbasの情報[5ページ]のRFC4166電話
In an engineered network (e.g., a private intranet), in which network capacity and maximum traffic are very well controlled, some telephony signalling applications may choose to relax the congestion control rules of SCTP in order to satisfy the timing requirements. In order to do this, they should employ their own congestion control mechanisms. This must be done without destabilizing the network; otherwise, it would lead to potential congestion collapse of the network.
設計されたネットワーク(例えば、個人的なイントラネット)では、いくつかの電話合図アプリケーションが、タイミング要件を満たすためにSCTPの混雑制御規則を弛緩するのを選ぶかもしれません。(ネットワーク容量と最大のトラフィックは非常によくそれで制御されます)。 これをするために、彼らはそれら自身の混雑制御機構を使うべきです。ネットワークを動揺させないで、これをしなければなりません。 さもなければ、それはネットワークの潜在的混雑崩壊に通じるでしょう。
Some telephony signalling applications may have their own congestion control and flow control techniques. These techniques may interact with the congestion control procedures in SCTP.
いくつかの電話合図アプリケーションには、それら自身の輻輳制御とフロー制御のテクニックがあるかもしれません。 これらのテクニックはSCTPの輻輳制御手順と対話するかもしれません。
3.2. Detection of Failures
3.2. 失敗の検出
Often, telephony systems must have no single point of failure in operation.
しばしば、電話技術システムには、稼働中である失敗のどんな単一のポイントもなければならないというわけではありません。
The UAL must meet certain service availability and performance requirements according to the classical signalling layers they are replacing. Those requirements may be specific for each UAL.
それらが取り替えている古典的な合図層に従って、UALはあるサービスの有用性と性能必要条件を満たさなければなりません。 各UALに、それらの要件は特定であるかもしれません。
For example, telephony systems are often required to be able to preserve stable calls during a component failure. Therefore, error situations at the transport layer and below must be detected quickly so that the UAL can take appropriate steps to recover and preserve the calls. This poses special requirements on SCTP to discover unreachability of a destination address or a peer.
例えば、電話技術システムが、コンポーネント故障の間、安定した呼び出しを保存できるようにしばしば必要です。 したがって、UALが呼び出しを回復して、保存するために適切な手段を講じることができるように、すぐにトランスポート層における以下のエラー状態を検出しなければなりません。 これは送付先アドレスか同輩の「非-可到達性」を発見するというSCTPに関する特別な要件を引き起こします。
3.2.1. Retransmission TimeOut (RTO) Calculation
3.2.1. 再送タイムアウト(RTO)計算
The SCTP protocol parameter RTO.Min value has a direct impact on the calculation of the RTO itself. Some telephony applications want to lower the value of the RTO.Min to less than 1 second. This would allow the message sender to reach the maximum number-of-retransmission threshold faster in the case of network failures. However, lowering RTO.Min may have a negative impact on network behaviour [ALLMAN99].
SCTPプロトコルパラメタRTO.Min価値はRTO自身の計算に直接的な衝撃を持っています。 いくつかの電話アプリケーションが1秒未満までRTO.Minの値を下げたがっています。 これで、メッセージ送付者はネットワーク失敗の場合で、より速く「再-トランスミッション」の最大の数の敷居に達することができるでしょう。 しかしながら、RTO.Minを下ろすのはネットワークのふるまい[ALLMAN99]のときにマイナスの影響があるかもしれません。
In some rare cases, telephony applications might not want to use the exponential timer back-off concept in RTO calculation in order to speed up failure detection. The danger of doing this is that, when network congestion occurs, not backing off the timer may worsen the congestion situation. Therefore, this strategy should never be used on the public Internet.
いくつかのまれなケースでは、電話アプリケーションは、失敗検出を早くするのにRTO計算に指数のタイマ下に後部概念を使用したがっていないかもしれません。 これをするという危険はネットワークの混雑が起こるとき、タイマを戻さないと混雑状況が悪化させられるかもしれないということです。 したがって、この戦略は公共のインターネットで決して使用されるべきではありません。
It should be noted that not using delayed SACK will also increase the speed of failure detection.
また、遅れたSACKを使用しないと失敗検出の速度が増強されることに注意されるべきです。
Coene & Pastor-Balbas Informational [Page 6] RFC 4166 Telephony Signalling over SCTP AS February 2006
2006年2月としてSCTPの上で合図するCoeneと牧師-Balbasの情報[6ページ]のRFC4166電話
3.2.2. Heartbeat
3.2.2. 鼓動
For faster detection of (un)availability of idle paths, the telephony application may consider lowering the SCTP parameter HB.interval. It should be noted this might result in a higher traffic load.
より速い検出、(不-、)、活動していない経路の有用性、電話アプリケーションは、SCTPパラメタHB.intervalを下ろすと考えるかもしれません。 これが、より高いトラヒック負荷をもたらすかもしれないことに注意されるべきです。
3.2.3. Maximum Number of Retransmissions
3.2.3. Retransmissionsの最大数
Setting Path.Max.Retrans and Association.Max.Retrans SCTP parameters to lower values will speed up both destination address and peer failure detection. However, if these values are set too low, the probability of false fault detections might increase.
Path.Max.RetransとAssociation.Max.Retrans SCTPパラメタに値を下げるように設定するのが送付先アドレスと同輩失敗検出の両方を早くするでしょう。 しかしながら、これらの値があまりに低く設定されるなら、誤った欠点発覚の確率は増加するかもしれません。
3.3. Shorten End-to-End Message Delay
3.3. 終わりから終わりへのメッセージ遅延を短くしてください。
Telephony applications often require short end-to-end message delays. The method described in Section 3.2.1 for lowering RTO may be considered. The different paths within a single association will have a different RTO, so using the path with the lowest RTO will lead to a shorter end-to-end message delay for the application running on top of the UALs.
電話アプリケーションはしばしば終わりから終わりへの短いメッセージ遅延を必要とします。 RTOを下ろすためにセクション3.2.1で説明されたメソッドは考えられるかもしれません。 単一の協会の中の異なった経路には異なったRTOがあって、したがって、最も低いRTOがある経路を使用するのはUALsの上で稼働するアプリケーションのための終わりから終わりへの、より短いメッセージ遅延に通じるでしょう。
3.4. Bundling Considerations
3.4. バンドリング問題
Bundling small telephony signalling messages at transmission helps improve the bandwidth usage efficiency of the network. On the downside, bundling may introduce additional delay to some of the messages. This should be taken into consideration when end-to-end delay is a concern.
トランスミッションで小さい電話合図メッセージを添付するのは、ネットワークの帯域幅用法効率を高めるのを助けます。 下落傾向では、バンドリングはメッセージのいくつかに追加遅れを紹介するかもしれません。 終わりから終わりへの遅れが関心であるときに、これは考慮に入れられるべきです。
3.5. Stream Usage
3.5. ストリーム用法
Telephony signalling traffic is often composed of multiple, independent message sequences. It is highly desirable to transfer those independent message sequences in separate SCTP streams. This reduces the probability of head-of-line blocking in which the retransmission of a lost message affects the delivery of other messages not belonging to the same message sequence.
電話合図トラフィックは複数の、そして、独立しているメッセージ系列でしばしば構成されます。 別々のSCTPストリームにおけるそれらの独立しているメッセージ系列を移すのは非常に望ましいです。これは無くなっているメッセージの「再-トランスミッション」が同じメッセージ系列に属さない他のメッセージの配送に影響する系列のヘッドブロッキングの確率を減少させます。
4. User Adaptation Layers
4. ユーザ適合層
Users Adaptation Layers (UALs) are defined to encapsulate different signalling protocols for transport over SCTP/IP.
ユーザAdaptation Layers(UALs)は、SCTP/IPの上の輸送のために異なった合図プロトコルをカプセル化するために定義されます。
There are UALs for both access signalling (DSS1) and trunk signalling (SS7). A brief description of the standardized UALs follows in the next sub-sections.
アクセス合図(DSS1)とトランク合図(SS7)の両方のためのUALsがあります。 標準化されたUALsの簡単な説明は次の小区分で続きます。
Coene & Pastor-Balbas Informational [Page 7] RFC 4166 Telephony Signalling over SCTP AS February 2006
2006年2月としてSCTPの上で合図するCoeneと牧師-Balbasの情報[7ページ]のRFC4166電話
The delivery mechanism in several UALs supports:
数個のUALsの排紙機構は以下をサポートします。
o Seamless operation of UALs user peers over an IP network
connection.
o The interface boundary that the UAL user had with the traditional
lower layer.
o Management of SCTP transport associations and traffic between SGs
and ISEPs or two ISEPs
o Asynchronous reporting of status changes to management.
o UALsユーザのシームレスの操作はIPネットワーク接続の上をじっと見ます。○ UALユーザがo AsynchronousにSGsとISEPsか2ISEPsの間のSCTP輸送協会とトラフィックの伝統的下層o Managementと共に状態について報告させたインタフェース境界は管理に変化します。
Signalling User Adaptation Layers have been developed for both Access and Trunk Telephony Signalling. They are defined as follows.
合図User Adaptation LayersはAccessとTrunk Telephony Signallingの両方のために開発されました。 それらは以下の通り定義されます。
Access Signalling: This is the signalling that is needed between an access device and an exchange in the core network in order to establish, manage, or release the voice or data call paths. Several protocols have been developed for this purpose.
合図にアクセスしてください: これは声かデータ呼び出し経路を確立するか、管理するか、またはリリースするのにアクセスデバイスとコアネットワークの交換の間で必要である合図です。 このためにいくつかのプロトコルを開発してあります。
Trunk Signalling: This is the signalling that is used between the exchanges inside the core network in order to establish, manage, or release the voice or data call paths. The most common protocols used for this purpose are known as the SS7 system, which belongs to the Common Channel Signalling (CCS) philosophy. The SS7 protocol stack is depicted below:
トランク合図: これは声かデータ呼び出し経路を確立するか、管理するか、またはリリースするのにコアネットワークの中で交換の間で使用される合図です。 このために使用される中で最も一般的なプロトコルはSS7システムとして知られています。(それは、Common Channel Signalling(CCS)哲学に属します)。 SS7プロトコル・スタックは以下に表現されます:
+------+-----+-------+- -+-------+------+-----+------+
| | | | | | MAP | CAP | INAP |
+ | + RANAP |...| BSSAP +-------------------+
| ISUP | TUP | | | | TCAP |
+ | +---------------------------------------+
| | | SCCP |
+----------------------------------------------------+
| MTP3 |
+----------------------------------------------------+
| MTP2 |
+----------------------------------------------------+
| MTP1 |
+----------------------------------------------------+
+------+-----+-------+- -+-------+------+-----+------+ | | | | | | 地図| 上限| INAP| + | + RANAP|...| BSSAP+-------------------+ | ISUP| 雄羊| | | | TCAP| + | +---------------------------------------+ | | | SCCP| +----------------------------------------------------+ | MTP3| +----------------------------------------------------+ | MTP2| +----------------------------------------------------+ | MTP1| +----------------------------------------------------+
Figure 2: SS7 Protocol Stack
図2: SS7プロトコル・スタック
Coene & Pastor-Balbas Informational [Page 8] RFC 4166 Telephony Signalling over SCTP AS February 2006
2006年2月としてSCTPの上で合図するCoeneと牧師-Balbasの情報[8ページ]のRFC4166電話
The Telephony Signalling Protocols to be transported with the already designed UALS are:
既に設計されたUALSと共に輸送されるべきTelephony Signallingプロトコルは以下の通りです。
o ISDN Q.921 Users: Q.931 o V5.2/DSS1 o DPNSS/DASS2 [RFC4129] o SS7 MTP3 Users: SCCP, ISUP, TUP o SS7 MTP2 Users: MTP3 o SS7 SCCP Users: TCAP, RANAP, BSSAP, ...
o ISDN Q.921ユーザ: Q.931o V5.2/DSS1o DPNSS/DASS2[RFC4129]o SS7 MTP3 Users: SCCP、ISUP、TUP o SS7 MTP2 Users: MTP3o SS7 SCCP Users: TCAP、RANAP、BSSAP…
Two main scenarios have been developed to use the different UALS for IP Signalling Transport:
IP Signalling Transportに異なったUALSを使用するために2つの主なシナリオを開発してあります:
1. Intercommunication of traditional Signalling transport nodes and
IP based nodes.
1. 伝統的なSignalling輸送ノードとIPに関する相互通信はノードを基礎づけました。
Traditional Telephony
Telephony Signalling
********* Signalling ********** over IP ********
* SEP *----------------* SG *--------------* ISEP *
********* ********** ********
*********IP*********9月*の上で**********に合図しながら合図する伝統的な電話電話----------------* SG*--------------* ISEP****************************
+-------+ +-------+
|SigProt| |SigProt|
+-------+ +----+----+ +-------+
| | | |UAL | | UAL |
| | | +----+ +-------+
| TTST | |TTST|SCTP| | SCTP |
| | | +----+ +-------+
| | | | IP | | IP |
+-------+ +---------+ +-------+
+-------+ +-------+ |SigProt| |SigProt| +-------+ +----+----+ +-------+ | | | |UAL| | UAL| | | | +----+ +-------+ | TTST| |TTST|SCTP| | SCTP| | | | +----+ +-------+ | | | | IP| | IP| +-------+ +---------+ +-------+
SEP - Signalling Endpoint
SG - Signalling Gateway
ISEP - IP Signalling Endpoint
SigProt - Signalling Protocol
TTSP - Traditional Telephony Signalling Protocol
UAL - User Adaptation Layer
SCTP - Stream Control Transport Protocol
9月--ゲートウェイISEPに合図して、終点SGに合図します--プロトコルTTSPに合図して、終点SigProtに合図するIP--伝統的な電話合図プロトコルUAL--ユーザ適合層のSCTP--ストリーム規制トランスポート・プロトコル
Figure 3: General Architecture of SS7-IP Interworking
図3: SS7-IPの織り込むことの一般アーキテクチャ
This is also referred to as SG-to-AS communication. AS is the name that UAL usually gives to the ISEP nodes. It stands for Application Server.
また、これはSGからASへのコミュニケーションと呼ばれます。 ASは通常、UALがISEPノードに与える名前です。 それはApplication Serverを表します。
Coene & Pastor-Balbas Informational [Page 9] RFC 4166 Telephony Signalling over SCTP AS February 2006
2006年2月としてSCTPの上で合図するCoeneと牧師-Balbasの情報[9ページ]のRFC4166電話
2. Communication inside the IP network.
2. IPネットワークにおけるコミュニケーション。
Telephony
Signalling
********* over IP *********
* ISEP *------------------* ISEP *
********* *********
IP**********ISEP*の上で*********に合図する電話------------------* ISEP*******************
+-------+ +-------+
|SigProt| |SigProt|
+-------+ +-------+
| UAL | | UAL |
+-------+ +-------+
| SCTP | | SCTP |
+-------+ +-------+
| IP | | IP |
+-------+ +-------+
+-------+ +-------+ |SigProt| |SigProt| +-------+ +-------+ | UAL| | UAL| +-------+ +-------+ | SCTP| | SCTP| +-------+ +-------+ | IP| | IP| +-------+ +-------+
Figure 4: General Architecture of Intra-IP Communication
図4: イントラIPコミュニケーションの一般アーキテクチャ
This is also referred to as IPSP communication. IPSP stands for IP Signalling Point and describes the role that the UAL plays on an IP-based node.
また、これはIPSPコミュニケーションと呼ばれます。 IPSPはIP Signalling Pointを表して、UALがIPベースのノードの上で果たす役割について説明します。
The first scenario is applied for both types of signalling (access and trunk signalling). On the other hand, the peer-to-peer basis can only be used for trunk signalling.
最初のシナリオは合図(アクセスとトランク合図)の両方のタイプのために適用されます。 他方では、トランク合図にピアツーピア基礎を使用できるだけです。
4.1. Access Signalling
4.1. アクセス合図
The SIGTRAN WG has developed UALs to transport the following Access Signalling protocols:
SIGTRAN WGは以下のAccess Signallingプロトコルを輸送するためにUALsを開発しました:
o ISDN Q.931 o V5.2 o DPNSS/DASS2
o ISDN Q.931o V5.2o DPNSS/DASS2
4.1.1. IUA (ISDN Q.921 User Adaptation)
4.1.1. IUA(ISDN Q.921ユーザ適合)
UAL: IUA (ISDN Q.921 User Adaptation)
UAL: IUA(ISDN Q.921ユーザ適合)
This document supports both ISDN Primary Rate Access (PRA) as well as Basic Rate Access (BRA) including the support for both point-to-point and point-to-multipoint modes of communication. This support includes Facility Associated Signalling (FAS), Non-Facility Associated Signalling (NFAS), and NFAS with backup D channel.
ポイントツーポイントとコミュニケーションのポイントツーマルチポイントモードの両方のサポートを含んでいて、このドキュメントはISDN Primary Rate Access(PRA)とBasic Rate Access(BRA)の両方をサポートします。 このサポートはFacility Associated Signalling(FAS)、Non-施設Associated Signalling(NFAS)、およびバックアップDチャネルがあるNFASを含んでいます。
Coene & Pastor-Balbas Informational [Page 10] RFC 4166 Telephony Signalling over SCTP AS February 2006
2006年2月としてSCTPの上で合図するCoeneと牧師-Balbasの情報[10ページ]のRFC4166電話
It implements the client/server architecture. The default orientation is for the SG to take on the role of server while the ISEP is the client. The SCTP (and UDP/TCP) Registered User Port Number Assignment for IUA is 9900.
それは、クライアント/サーバがアーキテクチャであると実装します。 ISEPはクライアントですが、デフォルトオリエンテーションはSGがサーバの役割を引き受けることです。 IUAのためのSCTP(そして、UDP/TCP)の登録されたUser Port Number Assignmentは9900です。
Examples of the upper layers to be transported are Q.931 and QSIG.
輸送されるべき上側の層に関する例は、Q.931とQSIGです。
The main scenario supported by this UAL is the SG-to-ISP communication where the ISEP role is typically played by a node called an MGC, as defined in [RFC2719].
このUALによってサポートされた主なシナリオはSGからISPへのISEPの役割がMGCと呼ばれるノードによって通常果たされるコミュニケーションです、[RFC2719]で定義されるように。
****** ISDN ****** IP *******
*PBX *---------------* SG *--------------* MGC *
****** ****** *******
****** ISDN******IP********PBX*---------------* SG*--------------* MGC********************
+-----+ +-----+
|Q.931| (NIF) |Q.931|
+-----+ +----------+ +-----+
| | | | IUA| | IUA |
| | | +----+ +-----+
|Q.921| |Q.921|SCTP| |SCTP |
| | | +----+ +-----+
| | | | IP | | IP |
+-----+ +-----+----+ +-----+
+-----+ +-----+ |Q.931| (NIF) |Q.931| +-----+ +----------+ +-----+ | | | | IUA| | IUA| | | | +----+ +-----+ |Q.921| |Q.921|SCTP| |SCTP| | | | +----+ +-----+ | | | | IP| | IP| +-----+ +-----+----+ +-----+
NIF - Nodal Interworking Function
PBX - Private Branch Exchange
SCTP - Stream Control Transmission Protocol
IUA - ISDN User Adaptation Layer Protocol
NIF--こぶのような織り込む機能PBX--構内交換機SCTP--ストリーム制御伝動プロトコルIUA--ISDNユーザ適合層のプロトコル
Figure 5: ISDN-IP Interworking using IUA
図5: IUAを使用するISDN IPの織り込むこと
The SCTP (and UDP/TCP) Registered User Port Number Assignment for IUA is 9900.
IUAのためのSCTP(そして、UDP/TCP)の登録されたUser Port Number Assignmentは9900です。
The value assigned by IANA for the Payload Protocol Identifier in the SCTP Payload Data chunk is "1".
SCTP有効搭載量Data塊における有効搭載量プロトコルIdentifierのためにIANAによって割り当てられた値は「1インチ」です。
Coene & Pastor-Balbas Informational [Page 11] RFC 4166 Telephony Signalling over SCTP AS February 2006
2006年2月としてSCTPの上で合図するCoeneと牧師-Balbasの情報[11ページ]のRFC4166電話
4.1.2. V5UA (V5.2-User Adaptation) Layer
4.1.2. V5UA(V5.2-ユーザ適合)層
UAL: V5UA (V5.2-User Adaptation)
UAL: V5UA(V5.2-ユーザ適合)
V5UA is an extension from the IUA layer with the modifications needed to support the differences between Q.921/Q.931, and V5.2 layer 2/layer 3. It supports analog telephone access, ISDN basic rate access and ISDN primary rate access over a V5.2 interface. It is typically implemented in an interworking scenario with SG.
V5UAはIUA層からのQ.921/Q.931と、V5.2層の2/層の3の間の変更が違いをサポートするのに必要であることの拡大です。 それは、アナログがV5.2インタフェースの上の電話アクセスと、ISDNの基本的なレートアクセスとISDN一次群速度アクセスであるとサポートします。 それはSGと共に織り込むシナリオで通常実装されます。
****** V5.2 ****** IP *******
* AN *---------------* SG *--------------* MGC *
****** ****** *******
****** V5.2******IP********は*です。---------------* SG*--------------* MGC********************
+-----+ +-----+
|V5.2 | (NIF) |V5.2 |
+-----+ +----------+ +-----+
| | | |V5UA| |V5UA |
| | | +----+ +-----+
|LAPV5| |LAPV5|SCTP| |SCTP |
| | | +----+ +-----+
| | | | IP + | IP |
+-----+ +-----+----+ +-----+
+-----+ +-----+ |V5.2| (NIF) |V5.2| +-----+ +----------+ +-----+ | | | |V5UA| |V5UA| | | | +----+ +-----+ |LAPV5| |LAPV5|SCTP| |SCTP| | | | +----+ +-----+ | | | | IP+| IP| +-----+ +-----+----+ +-----+
AN - Access Network
NIF - Nodal Interworking Function
LAPV5 - Link Access Protocol for the V5 channel
SCTP - Stream Control Transmission Protocol
AN--アクセスNetwork NIF--こぶのようなInterworking Function LAPV5--V5チャンネルSCTPのためのリンクAccessプロトコル--ストリームControl Transmissionプロトコル
Figure 6: V5.2-IP Interworking using V5UA
図6: V5UAを使用するV5.2-IPの織り込むこと
The SCTP (and UDP/TCP) Registered User Port Number Assignment for V5UA is 5675.
V5UAのためのSCTP(そして、UDP/TCP)の登録されたUser Port Number Assignmentは5675です。
The value assigned by IANA for the Payload Protocol Identifier in the SCTP Payload Data chunk is "6".
SCTP有効搭載量Data塊における有効搭載量プロトコルIdentifierのためにIANAによって割り当てられた値は「6インチ」です。
Coene & Pastor-Balbas Informational [Page 12] RFC 4166 Telephony Signalling over SCTP AS February 2006
2006年2月としてSCTPの上で合図するCoeneと牧師-Balbasの情報[12ページ]のRFC4166電話
4.1.3. DUA (DPNSS/DASS User adaptation) Layer
4.1.3. デュア(DPNSS/ダスのUser適合)Layer
UAL: DUA (DPNSS/DASS2 User Adaptation)
UAL: デュア(DPNSS/DASS2ユーザ適合)
The DUA is built on top of IUA and defines the necessary extensions to IUA for a DPNSS/DASS2 transport. DPNSS stands for Digital Private Network Signalling System and DASS2 for Digital Access Signalling System 2.
DUAはDPNSS/DASS2輸送のためにIUAの上で組み込まれて、必要な拡大をIUAと定義します。 DPNSSはDigital Access Signalling System2のためにDigital兵士のNetwork Signalling SystemとDASS2を表します。
****** DPNSS ****** IP *******
*PBX *---------------* SG *--------------* MGC *
****** ****** *******
****** DPNSS******IP********PBX*---------------* SG*--------------* MGC********************
+-----+ +-----+
|DPNSS| (NIF) |DPNSS|
| L3 | | L3 |
+-----+ +-----+----+ +-----+
| | | | DUA| | DUA |
|DPNSS| |DPNSS+----+ +-----+
| L2 | | L2 |SCTP| |SCTP |
| | | +----+ +-----+
| | | | IP + | IP |
+-----+ +-----+----+ +-----+
+-----+ +-----+ |DPNSS| (NIF) |DPNSS| | L3| | L3| +-----+ +-----+----+ +-----+ | | | | デュア| | デュア| |DPNSS| |DPNSS+----+ +-----+ | L2| | L2|SCTP| |SCTP| | | | +----+ +-----+ | | | | IP+| IP| +-----+ +-----+----+ +-----+
PBX - Private Branch eXchange
NIF - Nodal Interworking Function
SCTP - Stream Control Transmission Protocol
DUA - DPNSS User Adaptation Layer Protocol
PBX--構内交換機NIF--こぶのような織り込む機能SCTP--ストリーム制御伝動Protocolデュア--DPNSSユーザ適合層のプロトコル
Figure 7: DPNSS-IP Interworking using DUA
図7: DUAを使用するDPNSS-IPの織り込むこと
The value assigned by IANA for the Payload Protocol Identifier in the SCTP Payload Data chunk is "10". .
SCTP有効搭載量Data塊における有効搭載量プロトコルIdentifierのためにIANAによって割り当てられた値は「10インチ」です。 .
4.2. Network Signalling
4.2. ネットワーク合図
The SIGTRAN WG has developed UALs to transport the following SS7 protocols:
SIGTRAN WGは以下のSS7プロトコルを輸送するためにUALsを開発しました:
o MTP2 Users: MTP3 o MTP3 Users: ISUP, TUP, SCCP o SCCP Users: TCAP, RNSAP, RANAP, BSSAP, ...
o MTP2ユーザ: MTP3o MTP3 Users: ISUP、TUP、SCCP o SCCP Users: TCAP、RNSAP、RANAP、BSSAP…
Coene & Pastor-Balbas Informational [Page 13] RFC 4166 Telephony Signalling over SCTP AS February 2006
2006年2月としてSCTPの上で合図するCoeneと牧師-Balbasの情報[13ページ]のRFC4166電話
4.2.1. MTP lvl3 over IP
4.2.1. IPの上のMTP lvl3
UALs:
UALs:
o M2UA (SS7 MTP2 User Adaptation [RFC3331]) o M2PA (SS7 MTP2-User Peer-to-Peer Adaptation [RFC4165])
o M2UA(SS7 MTP2 User Adaptation[RFC3331])o M2PA(SS7 MTP2-ユーザピアツーピア適合[RFC4165])
4.2.1.1. M2UA (SS7 MTP2-User Adaptation) Layer
4.2.1.1. M2UA(SS7 MTP2-ユーザ適合)層
M2UA protocol is typically used between a Signalling Gateway (SG) and Media Gateway Controller (MGC). The SG will terminate up to MTP Level 2, and the MGC will terminate MTP Level 3 and above. In other words, the SG will transport MTP Level 3 messages over an IP network to an MGC.
M2UAプロトコルはSignallingゲートウェイ(SG)とメディアゲートウェイController(MGC)の間で通常使用されます。 SGはMTP Level2まで終わるでしょう、そして、MGCはより多くのMTP Level3を終えるでしょう。 言い換えれば、SGはIPネットワークの上でMTP Level3メッセージをMGCに輸送するでしょう。
MTP3 and MTP3b are the only SS7 MTP2 User protocols that are transported by this UAL.
MTP3とMTP3bはこのUALによって輸送される唯一のSS7 MTP2 Userプロトコルです。
The SG provides an interworking of transport functions with the IP transport to transfer MTP2-User signalling messages with an Application Server (e.g., MGC) where the peer MTP2-User exists.
SGは、Application Server(例えば、MGC)と共に同輩MTP2-ユーザが存在するところにMTP2-ユーザ合図メッセージを移すために輸送機能を織り込むのにIP輸送を提供します。
****** SS7 ****** IP *******
*SEP *-----------* SG *-------------* MGC *
****** ****** *******
****** SS7******IP********9月*-----------* SG*-------------* MGC********************
+----+ +----+
|S7UP| |S7UP|
+----+ +----+
|MTP3| |MTP3|
| | (NIF) | |
+----+ +----+----+ +----+
| | | |M2UA| |M2UA|
| | | +----+ +----+
|MTP2| |MTP2|SCTP| |SCTP|
| | | +----+ +----+
| | | |IP | |IP |
+----+ +---------+ +----+
+----+ +----+ |S7UP| |S7UP| +----+ +----+ |MTP3| |MTP3| | | (NIF) | | +----+ +----+----+ +----+ | | | |M2UA| |M2UA| | | | +----+ +----+ |MTP2| |MTP2|SCTP| |SCTP| | | | +----+ +----+ | | | |IP| |IP| +----+ +---------+ +----+
MGC - Media Gateway Controller
SG - Signalling Gateway
SEP - SS7 Signalling Endpoint
NIF - Nodal Interworking Function
IP - Internet Protocol
SCTP - Stream Control Transmission Protocol
MGC--メディアゲートウェイコントローラSG--ゲートウェイ9月に合図します--SS7合図終点NIF--こぶのような織り込む機能IP--インターネットプロトコルSCTP--ストリーム制御伝動プロトコル
Figure 8: SS7-IP Interworking using M2UA
エイト環: M2UAを使用するSS7-IPの織り込むこと
Coene & Pastor-Balbas Informational [Page 14] RFC 4166 Telephony Signalling over SCTP AS February 2006
2006年2月としてSCTPの上で合図するCoeneと牧師-Balbasの情報[14ページ]のRFC4166電話
The SCTP (and UDP/TCP) Registered User Port Number Assignment for M2UA is 2904.
M2UAのためのSCTP(そして、UDP/TCP)の登録されたUser Port Number Assignmentは2904です。
The value assigned by IANA for the Payload Protocol Identifier in the SCTP Payload Data chunk is "2".
SCTP有効搭載量Data塊における有効搭載量プロトコルIdentifierのためにIANAによって割り当てられた値は「2インチ」です。
4.2.1.2. M2PA (SS7 MTP2-User Peer-to-Peer Adaptation)
4.2.1.2. M2PA(SS7 MTP2-ユーザピアツーピア適合)
M2PA protocol is used between SS7 Signalling Points employing the MTP Level 3 protocol. The SS7 Signalling Points may also use standard SS7 links using the SS7 MTP Level 2 to provide transport of MTP Level 3 signalling messages.
M2PAプロトコルはMTP Level3プロトコルを使うSS7 Signalling Pointsの間で使用されます。 また、SS7 Signalling Pointsは、MTP Level3合図メッセージの輸送を提供するのにSS7 MTP Level2を使用することで標準のSS7リンクを使用するかもしれません。
Both configurations: communication of SS7 and IP with SG and communication between ISEPs are possible.
両方の構成: SGとSS7とIPに関するコミュニケーションとISEPsのコミュニケーションは可能です。
Connection of SS7 and IP nodes:
SS7とIPノードの接続:
******** SS7 *************** IP ********
* SEP *--------* SG *--------* IPSP *
******** *************** ********
******** SS7***************IP*********9月*--------* SG*--------* IPSP********************************
+------+ +------+
| TCAP | | TCAP |
+------+ +------+
| SCCP | | SCCP |
+------+ +-------------+ +------+
| MTP3 | | MTP3 | | MTP3 |
+------+ +------+------+ +------+
| | | | M2PA | | M2PA |
| | | +------+ +------+
| MTP2 | | MTP2 | SCTP | | SCTP |
| | | +------+ +------+
| | | | IP | | IP |
+------+ +------+------+ +------+
+------+ +------+ | TCAP| | TCAP| +------+ +------+ | SCCP| | SCCP| +------+ +-------------+ +------+ | MTP3| | MTP3| | MTP3| +------+ +------+------+ +------+ | | | | M2PA| | M2PA| | | | +------+ +------+ | MTP2| | MTP2| SCTP| | SCTP| | | | +------+ +------+ | | | | IP| | IP| +------+ +------+------+ +------+
SEP - SS7 Signalling Endpoint
9月--SS7合図終点
Figure 9: SS7-IP Interworking with M2PA
図9: M2PAとのSS7-IPの織り込むこと
Coene & Pastor-Balbas Informational [Page 15] RFC 4166 Telephony Signalling over SCTP AS February 2006
2006年2月としてSCTPの上で合図するCoeneと牧師-Balbasの情報[15ページ]のRFC4166電話
Communication between two IP nodes:
2つのIPノードのコミュニケーション:
******** IP ********
* IPSP *--------* IPSP *
******** ********
******** IP*********IPSP*--------* IPSP*****************
+------+ +------+
| TCAP | | TCAP |
+------+ +------+
| SCCP | | SCCP |
+------+ +------+
| MTP3 | | MTP3 |
+------+ +------+
| M2PA | | M2PA |
+------+ +------+
| SCTP | | SCTP |
+------+ +------+
| IP | | IP |
+------+ +------+
+------+ +------+ | TCAP| | TCAP| +------+ +------+ | SCCP| | SCCP| +------+ +------+ | MTP3| | MTP3| +------+ +------+ | M2PA| | M2PA| +------+ +------+ | SCTP| | SCTP| +------+ +------+ | IP| | IP| +------+ +------+
IP - Internet Protocol
IPSP - IP Signalling Point
SCTP - Stream Control Transmission Protocol
IP--インターネットプロトコルIPSP--IP合図ポイントSCTP--ストリーム制御伝動プロトコル
Figure 10: Intra-IP Communication using M2PA
図10: M2PAを使用するイントラIPコミュニケーション
These figures are only an example. Other configurations are possible. For example, IPSPs without traditional SS7 links could use the protocol layers MTP3/M2PA/SCTP/IP to route SS7 messages in a network with all IP links.
これらの数字は例にすぎません。 他の構成は可能です。 例えば、伝統的なSS7リンクのないIPSPsは、すべてのIPリンクでネットワークでSS7メッセージを発送するのにMTP3/M2PA/SCTP/IPプロトコル層を使用するかもしれません。
Another example is that two SGs could be connected over an IP network to form an SG mated pair, similar to the way STPs are provisioned in traditional SS7 networks.
別の例はSGメーテッド・ペアを形成するためにIPネットワークの上に2SGsを接続できたということです、伝統的なSS7ネットワークでSTPsが食糧を供給される方法と同様です。
The SCTP (and UDP/TCP) Registered User Port Number Assignment for M2PA is 3565.
M2PAのためのSCTP(そして、UDP/TCP)の登録されたUser Port Number Assignmentは3565です。
The value assigned by IANA for the Payload Protocol Identifier in the SCTP Payload Data chunk is "5".
SCTP有効搭載量Data塊における有効搭載量プロトコルIdentifierのためにIANAによって割り当てられた値は「5インチ」です。
Coene & Pastor-Balbas Informational [Page 16] RFC 4166 Telephony Signalling over SCTP AS February 2006
2006年2月としてSCTPの上で合図するCoeneと牧師-Balbasの情報[16ページ]のRFC4166電話
4.2.1.3. Main Differences between M2PA and M2UA
4.2.1.3. M2PAとM2UAの主な違い
o M2PA: IPSP processes MTP3/MTP2 primitives.
o M2UA: MGC transports MTP3/MTP2 primitives between the SG's MTP2
and the MGC's MTP3 (via the NIF) for processing.
o M2PA: SG-IPSP connection is an SS7 link.
o M2UA: SG-MGC connection is not an SS7 link. It is an extension of
MTP to a remote entity.
o M2PA: IPSPはMTP3/MTP2基関数o M2UAを処理します: MGCは処理o M2PAのためにSGのMTP2とMGCのMTP3(NIFを通した)の間のMTP3/MTP2基関数を輸送します: SG-IPSP接続はSS7が. o M2UAをリンクするということです: SG-MGC接続はSS7リンクではありません。 それはリモート実体へのMTPの拡大です。
4.2.2. M3UA (SS7 MTP3 User Adaptation) Layer
4.2.2. M3UA(SS7 MTP3ユーザ適合)層
UAL: M3UA (SS7 MTP3 User Adaptation)
UAL: M3UA(SS7 MTP3ユーザ適合)
M3UA protocol supports the transport of any SS7 MTP3-User signalling such as TUP, ISUP, and SCCP over IP using the services of SCTP.
M3UAプロトコルは、TUPや、ISUPや、SCCPなどのようにIPの上でSCTPのサービスを利用することでどんなSS7 MTP3-ユーザ合図の輸送もサポートします。
Interconnection of SS7 and IP nodes:
SS7とIPノードのインタコネクト:
******** SS7 ***************** IP ********
* SEP *---------* SGP *--------* ASP *
******** ***************** ********
******** SS7*****************IP*********9月*---------* SGP*--------* ASP**********************************
+------+ +---------------+ +------+
| ISUP | | (NIF) | | ISUP |
+------+ +------+ +------+ +------+
| MTP3 | | MTP3 | | M3UA | | M3UA |
+------| +------+-+------+ +------+
| MTP2 | | MTP2 | | SCTP | | SCTP |
+------+ +------+ +------+ +------+
| L1 | | L1 | | IP | | IP |
+------+ +------+ +------+ +------+
+------+ +---------------+ +------+ | ISUP| | (NIF) | | ISUP| +------+ +------+ +------+ +------+ | MTP3| | MTP3| | M3UA| | M3UA| +------| +------+-+------+ +------+ | MTP2| | MTP2| | SCTP| | SCTP| +------+ +------+ +------+ +------+ | L1| | L1| | IP| | IP| +------+ +------+ +------+ +------+
SEP - SS7 Signalling End Point
SCTP - Stream Control Transmission Protocol
NIF - Nodal Interworking Function
9月--SS7合図エンドポイントSCTP--ストリーム制御伝動プロトコルNIF--こぶのような織り込む機能
Figure 11: SS7-IP Interworking using M3UA
図11: M3UAを使用するSS7-IPの織り込むこと
Coene & Pastor-Balbas Informational [Page 17] RFC 4166 Telephony Signalling over SCTP AS February 2006
2006年2月としてSCTPの上で合図するCoeneと牧師-Balbasの情報[17ページ]のRFC4166電話
Communication between two IP nodes:
2つのIPノードのコミュニケーション:
******** IP ********
* IPSP *----------* IPSP *
******** ********
******** IP*********IPSP*----------* IPSP*****************
+------+ +------+
|SCCP- | |SCCP- |
| User | | User |
+------+ +------+
| SCCP | | SCCP |
+------+ +------+
| M3UA | | M3UA |
+------+ +------+
| SCTP | | SCTP |
+------+ +------+
| IP | | IP |
+------+ +------+
+------+ +------+ |SCCP| |SCCP| | ユーザ| | ユーザ| +------+ +------+ | SCCP| | SCCP| +------+ +------+ | M3UA| | M3UA| +------+ +------+ | SCTP| | SCTP| +------+ +------+ | IP| | IP| +------+ +------+
Figure 12: Intra-IP Communication using M3UA
図12: M3UAを使用するイントラIPコミュニケーション
M3UA uses a client-server architecture. It is recommended that the ISEP acts as the client and initiate the SCTP associations with the SG. The port reserved by IANA is 2905. This is the port upon which the SG should listen for possible client connections.
M3UAはクライアント/サーバアーキテクチャを使用します。 ISEPがクライアントと開始としてSGとのSCTP協会を機能させるのは、お勧めです。 IANAによって予約されたポートは2905です。 これはSGが可能なクライアント接続の聞こうとするはずであるポートです。
The assigned payload protocol identifier for the SCTP DATA chunks is "3".
SCTP DATA塊のための割り当てられたペイロードプロトコル識別子は「3インチ」です。
4.2.3. SUA (SS7 SCCP User Adaptation) Layer
4.2.3. SUA(SS7 SCCPユーザ適合)層
UAL: SUA (SS7 SCCP User Adaptation)
UAL: SUA(SS7 SCCPユーザ適合)
SUA protocol supports the transport of any SS7 SCCP-User signalling such as MAP, INAP, SMS, BSSAP, or RANAP over IP using the services of SCTP. Each of the applications using SUA has its own set of timing requirements that can be found in its respective standards documents.
SUAプロトコルは、MAP、INAP、SMS、BSSAP、またはRANAPなどのようにIPの上でSCTPのサービスを利用することでどんなSS7 SCCP-ユーザ合図の輸送もサポートします。 SUAを使用するそれぞれのアプリケーションはそれ自身のそれぞれの規格文書で見つけることができるタイミング要件のセットを持っています。
Coene & Pastor-Balbas Informational [Page 18] RFC 4166 Telephony Signalling over SCTP AS February 2006
2006年2月としてSCTPの上で合図するCoeneと牧師-Balbasの情報[18ページ]のRFC4166電話
Possible configurations are showed in the pictures below.
可能な構成はそうです。画像では、以下で目立ちました。
- Interconnection of SS7 and IP:
- SS7とIPのインタコネクト:
******** *************** ********
* SEP * SS7 * * IP * *
* or *---------* SG *--------* ASP *
* STP * * * * *
******** *************** ********
******** *************** ******** * 9月*SS7**IP***か*---------* SG*--------* ASP**STP************************************
+------ +------+
| SUAP | | SUAP |
+------+ +------+------+ +------+
| SCCP | | SCCP | SUA | | SUA |
+------+ +------+------+ +------+
| | | | | | |
| MTP3 | | MTP3 | SCTP | | SCTP |
| | | | | | |
+------+ +------+------+ +------+
| MTP2 | | MTP2 | IP | | IP |
+------+ +------+------+ +------+
+------ +------+ | SUAP| | SUAP| +------+ +------+------+ +------+ | SCCP| | SCCP| SUA| | SUA| +------+ +------+------+ +------+ | | | | | | | | MTP3| | MTP3| SCTP| | SCTP| | | | | | | | +------+ +------+------+ +------+ | MTP2| | MTP2| IP| | IP| +------+ +------+------+ +------+
SUAP - SCCP/SUA User Protocol (TCAP, for example)
STP - SS7 Signalling Transfer Point
SUAP--SCCP/SUA Userプロトコル(例えば、TCAP)STP--SS7 Signalling Transfer Point
Figure 13: SS7-IP Interworking using SUA
図13: SUAを使用するSS7-IPの織り込むこと
- IP Node to IP Node communication:
- IP NodeコミュニケーションへのIP Node:
******** ********
* * IP * *
* IPSP *--------* IPSP *
* * * *
******** ********
******** ******** * * IP***IPSP*--------* IPSP*********************
+------+ +------+
| SUAP | | SUAP |
+------+ +------+
| SUA | | SUA |
+------+ +------+
| SCTP | | SCTP |
+------+ +------+
| IP | | IP |
+------+ +------+
+------+ +------+ | SUAP| | SUAP| +------+ +------+ | SUA| | SUA| +------+ +------+ | SCTP| | SCTP| +------+ +------+ | IP| | IP| +------+ +------+
Figure 14: Intra-IP Communication using SUA
図14: SUAを使用するイントラIPコミュニケーション
Coene & Pastor-Balbas Informational [Page 19] RFC 4166 Telephony Signalling over SCTP AS February 2006
2006年2月としてSCTPの上で合図するCoeneと牧師-Balbasの情報[19ページ]のRFC4166電話
IANA has registered SCTP Port Number 14001 for SUA. It is recommended that SGs use this SCTP port number for listening for new connections. The payload protocol identifier for the SCTP DATA chunks is "4".
IANAはSUAのためにSCTP Port Number14001を登録しました。 SGsが新しい接続の聞こうとするのにこのSCTPポートナンバーを使用するのは、お勧めです。 SCTP DATA塊のためのペイロードプロトコル識別子は「4インチ」です。
5. Security Considerations
5. セキュリティ問題
UALs are designated to carry signalling messages for telephony services. As such, UALs must involve the security needs of several parties: the end users of the services, the network providers, and the applications involved. Additional requirements may come from local regulation. Although some security needs overlap, any security solution should fulfill all the different parties' needs. See specific Security Considerations in each UAL Technical specification for details (for general security principles of SIGTRAN, see [RFC3788]).
UALsは、電話サービスへの合図メッセージを伝えるために指定されます。 そういうものとして、UALsは数人のパーティーの安全要求にかかわらなければなりません: サービス、ネットワーク内の提供者、およびかかわったアプリケーションのエンドユーザ。 追加要件は地方条例から来るかもしれません。 いくつかの安全要求が重なりますが、どんなセキュリティソリューションもすべての異なったパーティーの必要性を実現させるべきです。 詳細のためのそれぞれのUAL Technical仕様で特定のSecurity Considerationsを見てください(SIGTRANの総合証券本質に関して、[RFC3788]を見てください)。
SCTP only tries to increase the availability of a network. SCTP does not contain any protocol mechanisms directly related to communication security, i.e., user message authentication, integrity, or confidentiality functions. For such features, SCTP depends on security protocols. In the field of system security, SCTP includes mechanisms for reducing the risk of blind denial-of-service attacks as described in Section 11 of [RFC2960].
SCTPはネットワークの有用性を増強するだけであろうとします。 SCTPはすなわち、直接コミュニケーションセキュリティに関連するどんなプロトコルメカニズム、ユーザ通報認証、保全、または秘密性機能も含んでいません。 そのような特徴のために、SCTPはセキュリティプロトコルによります。 システムセキュリティの分野では、SCTPが[RFC2960]のセクション11で説明されるように盲目のサービス不能攻撃の危険を減少させるためのメカニズムを含んでいます。
This document does not add any new components to the protocols included in the discussion. For secure use of the SIGTRAN protocols, readers should go through the "Security Considerations for SIGTRAN Protocols" [RFC3788]). According to that document, the use of the IPsec is the main requirement to secure SIGTRAN protocols in the Internet, but Transport Layer Security (TLS) is also considered a perfectly valid option for use in certain scenarios (see [RFC3436] for more information on using TLS with SCTP). Recommendations of usage are also included.
議論にプロトコルへのどんな新しいコンポーネントも含んでいて、このドキュメントは加えません。 SIGTRANプロトコルの安全な使用のために、読者は「SIGTRANプロトコルのためのセキュリティ問題」[RFC3788)を通るべきです。 そのドキュメントによると、IPsecの使用はインターネットでSIGTRANにプロトコルを保証するという主な要件ですが、また、Transport Layer Security(TLS)はあるシナリオ(SCTPと共にTLSを使用する詳しい情報に関して[RFC3436]を見る)における使用のための完全に有効なオプションであると考えられます。 また、用法の推薦は含まれています。
6. Informative References
6. 有益な参照
[ALLMAN99] Allman, M. and V. Paxson, "On Estimating End-to-End
Network Path Properties", Proc. SIGCOMM'99, 1999.
[ALLMAN99] オールマン、M.、および「終わりから端へのネットワーク経路が土地であると見積もっている」Proc対パクソン SIGCOMM'99、1999'。
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000.
[RFC2960] スチュワート、R.、シェ、Q.、K.の、そして、鋭いMorneault、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カッラ、M.、チャン、L.、および「ストリーム制御伝動プロトコル」、RFC2960(2000年10月)対パクソン
[RFC3257] Coene, L., "Stream Control Transmission Protocol
Applicability Statement", RFC 3257, April 2002.
[RFC3257] Coene、L.、「ストリーム制御伝動プロトコル適用性証明」、RFC3257、2002年4月。
Coene & Pastor-Balbas Informational [Page 20] RFC 4166 Telephony Signalling over SCTP AS February 2006
2006年2月としてSCTPの上で合図するCoeneと牧師-Balbasの情報[20ページ]のRFC4166電話
[RFC2719] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene,
L., Lin, H., Juhasz, I., Holdrege, M., and C. Sharp,
"Framework Architecture for Signaling Transport", RFC
2719, October 1999.
[RFC2719] オング、L.、Rytina、I.、ガルシア、M.、Schwarzbauer、H.、Coene、L.、リン、H.、Juhasz、I.、Holdrege、M.、および鋭く、「シグナリングのためのフレームワークアーキテクチャは輸送する」C.、RFC2719(1999年10月)。
[RFC3057] Morneault, K., Rengasami, S., Kalla, M., and G.
Sidebottom, "ISDN Q.921-User Adaptation Layer", RFC 3057,
February 2001.
[RFC3057] Morneault、K.、Rengasami、S.、カッラ、M.、およびG.Sidebottom、「ISDN Q.921-ユーザ適合層」、RFC3057、2001年2月。
[RFC3331] Morneault, K., Dantu, R., Sidebottom, G., Bidulock, B.,
and J. Heitz, "Signaling System 7 (SS7) Message Transfer
Part 2 (MTP2) - User Adaptation Layer", RFC 3331,
September 2002.
[RFC3331] Morneault、K.、Dantu、R.、Sidebottom、G.、Bidulock、B.、およびJ.ハイツ、「システム7(SS7)メッセージに合図して、第2部(MTP2)を移してください--ユーザ適合層」、RFC3331、2002年9月。
[RFC3332] Sidebottom, G., Morneault, K., and J. Pastor-Balbas,
"Signaling System 7 (SS7) Message Transfer Part 3 (MTP3)
- User Adaptation Layer (M3UA)", RFC 3332, September
2002.
[RFC3332] Sidebottom、G.、Morneault、K.、およびJ.牧師-Balbas、「システム7(SS7)メッセージに合図して、パート3(MTP3)を移してください--ユーザ適合層の(M3UA)」、RFC3332、2002年9月。
[RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport
Layer Security over Stream Control Transmission
Protocol", RFC 3436, December 2002.
[RFC3436] Jungmaier、A.、レスコラ、E.、およびM.Tuexen、「ストリーム制御伝動プロトコルの上のトランスポート層セキュリティ」、RFC3436、2002年12月。
[RFC3868] Loughney, J., Sidebottom, G., Coene, L., Verwimp, G.,
Keller, J., and B. Bidulock, "Signalling Connection
Control Part User Adaptation Layer (SUA)", RFC 3868,
October 2004.
[RFC3868] Loughney、J.、Sidebottom、G.、Coene、L.、Verwimp、G.、ケラー、J.、およびB.Bidulock、「接続コントロールに合図して、ユーザ適合層の(SUA)を分けてください」、RFC3868、2004年10月。
[RFC4165] George, T., Dantu, R., Kalla, M., Schwarzbauer, H.J.,
Sidebottom, G., Morneault, K.,"SS7 MTP2-User Peer-to-Peer
Adaptation Layer", RFC 4165, September 2005.
[RFC4165] ジョージ、T.、Dantu、R.、カッラ、M.、Schwarzbauer、H.J.、Sidebottom、G.、Morneault、K.、「SS7 MTP2-ユーザピアツーピア適合層」、RFC4165(2005年9月)。
[RFC3807] Weilandt, E., Khanchandani, N., and S. Rao, "V5.2-User
Adaptation Layer (V5UA)", RFC 3807, June 2004.
[RFC3807] Weilandt、E.、Khanchandani、N.、およびS.ラオ、「V5.2-ユーザ適合層の(V5UA)」、RFC3807 2004年6月。
[RFC4129] Mukundan, R., Morneault, K., and N. Mangalpally, "Digital
Private Network Signaling System (DPNSS)/Digital Access
Signaling System 2 (DASS 2) Extensions to the IUA
Protocol", RFC 4129, September 2005.
[RFC4129] Mukundan、R.、Morneault、K.、およびN.Mangalpally、「デジタル私設のネットワークシグナリングシステム(DPNSS)/Digitalはシグナリングシステム2(ダス2)拡大にIUAプロトコルにアクセスします」、RFC4129、2005年9月。
[RFC3788] Loughney, J., Tuexen, M., and J. Pastor-Balbas, "Security
Considerations for Signaling Transport (SIGTRAN)
Protocols", RFC 3788, June 2004.
[RFC3788] Loughney、J.、Tuexen、M.、およびJ.牧師-Balbas、「シグナリング輸送(SIGTRAN)プロトコルのためのセキュリティ問題」、RFC3788、2004年6月。
Coene & Pastor-Balbas Informational [Page 21] RFC 4166 Telephony Signalling over SCTP AS February 2006
2006年2月としてSCTPの上で合図するCoeneと牧師-Balbasの情報[21ページ]のRFC4166電話
Authors' Addresses
作者のアドレス
Lode Coene Siemens Atealaan 34 Herentals B-2200 Belgium
鉱脈CoeneジーメンスAtealaan34ヘーレンタルスB-2200ベルギー
Phone: +32-14-252081 EMail: lode.coene@siemens.com
以下に電話をしてください。 +32-14-252081はメールされます: lode.coene@siemens.com
Javier Pastor-Balbas Ericsson Via de los Poblados 13 Madrid 28033 Spain
ハビエルPastor-BalbasエリクソンVia de los Poblados13マドリード28033スペイン
Phone: +34 91 339 1397 EMail: J.Javier.Pastor@ericsson.com
以下に電話をしてください。 +34 91 339 1397はメールされます: J.Javier.Pastor@ericsson.com
Coene & Pastor-Balbas Informational [Page 22] RFC 4166 Telephony Signalling over SCTP AS February 2006
2006年2月としてSCTPの上で合図するCoeneと牧師-Balbasの情報[22ページ]のRFC4166電話
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Coene & Pastor-Balbas Informational [Page 23]
Coeneと牧師-Balbas情報です。[23ページ]
一覧
スポンサーリンク
