RFC4165 日本語訳
4165 Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - UserPeer-to-Peer Adaptation Layer (M2PA). T. George, B. Bidulock, R.Dantu, H. Schwarzbauer, K. Morneault. September 2005. (Format: TXT=114669 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group T. George
Request for Comments: 4165 B. Bidulock
Category: Standards Track OpenSS7
R. Dantu
University of North Texas
H. Schwarzbauer
Siemens
K. Morneault
Cisco Systems
September 2005
コメントを求めるワーキンググループT.ジョージ要求をネットワークでつないでください: 4165年のB.Bidulockカテゴリ: 規格はK.Morneaultシスコシステムズ2005年9月にOpenSS7R.Dantuノーステキサス大学H.Schwarzbauerジーメンスを追跡します。
Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) -
User Peer-to-Peer Adaptation Layer (M2PA)
シグナリングシステム7(SS7)メッセージ転送第2部(MTP2)--ユーザピアツーピア適合層(M2PA)
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This document defines a protocol supporting the transport of Signaling System Number 7 (SS7) Message Transfer Part (MTP) Level 3 signaling messages over Internet Protocol (IP) using the services of the Stream Control Transmission Protocol (SCTP). This protocol would be used between SS7 Signaling Points using the MTP Level 3 protocol. The SS7 Signaling Points may also use standard SS7 links using the SS7 MTP Level 2 to provide transport of MTP Level 3 signaling messages. The protocol operates in a manner similar to MTP Level 2 so as to provide peer-to-peer communication between SS7 endpoints.
このドキュメントはインターネットプロトコル(IP)の上でStream Control Transmissionプロトコル(SCTP)のサービスを利用することでSignaling System Number7(SS7)メッセージTransfer Part(MTP)レベル3シグナリングメッセージの輸送をサポートするプロトコルを定義します。 このプロトコルは、SS7 Signaling Pointsの間でMTP Level3プロトコルを使用することで使用されるでしょう。 また、SS7 Signaling Pointsは、MTP Level3シグナリングメッセージの輸送を提供するのにSS7 MTP Level2を使用することで標準のSS7リンクを使用するかもしれません。 プロトコルは、SS7終点のピアツーピアコミュニケーションを提供するためにMTP Level2と同様の方法で作動します。
George, et al. Standards Track [Page 1] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[1ページ]。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Scope ......................................................3
1.2. Terminology ................................................3
1.3. Abbreviations ..............................................4
1.4. Conventions ................................................5
1.5. Signaling Transport Architecture ...........................5
1.6. Services Provided by M2PA ..................................7
1.7. Functions Provided by M2PA .................................9
1.8. Definition of the M2PA Boundaries .........................10
1.9. Differences Between M2PA and M2UA .........................10
2. Protocol Elements ..............................................12
2.1. Common Message Header .....................................12
2.2. M2PA Header ...............................................13
2.3. M2PA Messages .............................................14
3. State Control ..................................................17
3.1. SCTP Association State Control ............................17
3.2. M2PA Link State Control ...................................18
4. Procedures .....................................................19
4.1. Procedures to Support MTP2 Features .......................19
4.2. Procedures to Support the MTP3/MTP2 Interface .............30
4.3. SCTP Considerations .......................................33
5. Examples of M2PA Procedures ....................................34
5.1. Link Initialization (Alignment) ...........................34
5.2. Message Transmission and Reception ........................37
5.3. Link Status Indication ....................................37
5.4. Link Status Message (Processor Outage) ....................38
5.5. Level 2 Flow Control ......................................42
5.6. MTP3 Signaling Link Congestion ............................44
5.7. Link Deactivation .........................................45
5.8. Link Changeover ...........................................45
6. Security Considerations ........................................47
7. IANA Considerations ............................................47
7.1. SCTP Payload Protocol Identifier ..........................47
7.2. M2PA Protocol Extensions ..................................48
8. Acknowledgements ...............................................49
9. References .....................................................50
9.1. Normative References ......................................50
9.2. Informative References ....................................51
1. 序論…3 1.1. 範囲…3 1.2. 用語…3 1.3. 略語…4 1.4. コンベンション…5 1.5. シグナリングはアーキテクチャを輸送します…5 1.6. M2PAによって提供されたサービス…7 1.7. M2PAによって提供された機能…9 1.8. M2PA境界の定義…10 1.9. M2PAとM2UAの違い…10 2. Elementsについて議定書の中で述べてください…12 2.1. 一般的なメッセージヘッダー…12 2.2. M2PAヘッダー…13 2.3. M2PAメッセージ…14 3. コントロールを述べてください…17 3.1. SCTP協会州のコントロール…17 3.2. M2PAは州のコントロールをリンクします…18 4. 手順…19 4.1. MTP2の特徴であるとサポートする手順…19 4.2. MTP3/MTP2をサポートする手順は連結します…30 4.3. SCTP問題…33 5. M2PA手順に関する例…34 5.1. 初期設定(整列)をリンクしてください…34 5.2. メッセージ送信とレセプション…37 5.3. 状態指示をリンクしてください…37 5.4. ステータスメッセージ(プロセッサ供給停止)をリンクしてください…38 5.5. 2フロー制御を平らにしてください…42 5.6. MTP3シグナリングは混雑をリンクします…44 5.7. 非活性化をリンクしてください…45 5.8. 転換をリンクしてください…45 6. セキュリティ問題…47 7. IANA問題…47 7.1. SCTP有効搭載量プロトコル識別子…47 7.2. M2PAは拡大について議定書の中で述べます…48 8. 承認…49 9. 参照…50 9.1. 標準の参照…50 9.2. 有益な参照…51
George, et al. Standards Track [Page 2] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[2ページ]。
1. Introduction
1. 序論
1.1. Scope
1.1. 範囲
There is a need for Switched Circuit Network (SCN) signaling protocol delivery over an IP network. This includes message transfer between the following:
IPネットワークの上のSwitched Circuit Network(SCN)シグナリングプロトコル配送の必要があります。 これは以下の間のメッセージ転送を含んでいます:
- a Signaling Gateway (SG) and a Media Gateway Controller (MGC)
[RFC2719]
- シグナリングゲートウェイ(SG)とメディアゲートウェイコントローラ(MGC)[RFC2719]
- a SG and an IP Signaling Point (IPSP)
- SGとポイントに合図するIP(IPSP)
- an IPSP and an IPSP
- IPSPとIPSP
This could allow for convergence of some signaling and data networks. SCN signaling nodes would have access to databases and other devices in the IP network domain that do not use SS7 signaling links. Likewise, IP telephony applications would have access to SS7 services. There may also be operational cost and performance advantages when traditional signaling links are replaced by IP network "connections".
これはいくつかのシグナリングとデータ網の集合を考慮するかもしれません。 SCNシグナリングノードはIPネットワークドメインのSS7シグナリングリンクを使用しないデータベースと対向機器に近づく手段を持っているでしょう。 同様に、IP電話技術アプリケーションはSS7サービスに近づく手段を持っているでしょう。 また、伝統的なシグナリングリンクをIPネットワーク「接続」に取り替えるとき、運用コストと性能利点があるかもしれません。
The delivery mechanism described in this document allows for full MTP3 message handling and network management capabilities between any two SS7 nodes communicating over an IP network. An SS7 node equipped with an IP network connection is called an IP Signaling Point (IPSP). The IPSPs function as traditional SS7 nodes using the IP network instead of SS7 links.
本書では説明された排紙機構は、IPネットワークの上で交信しながら、どんな2つのSS7ノードの間でも完全なMTP3メッセージハンドリングとネットワークマネージメント能力を考慮します。 IPネットワーク接続に持たせるSS7ノードはIP Signaling Point(IPSP)と呼ばれます。 IPを使用する伝統的なSS7ノードがSS7の代わりにリンクをネットワークでつなぐとき、IPSPsは機能します。
The delivery mechanism should:
排紙機構はそうするべきです:
- Support seamless operation of MTP3 protocol peers over an IP
network connection.
- IPネットワーク接続の上でMTP3プロトコル同輩のシームレスの操作をサポートしてください。
- Support the MTP Level 2 / MTP Level 3 interface boundary.
- MTP Levelが2 / MTP Level3インタフェース境界であるとサポートしてください。
- Support management of SCTP transport associations and traffic
instead of MTP2 Links.
- MTP2リンクスの代わりにSCTP輸送協会とトラフィックの経営をサポートしてください。
- Support asynchronous reporting of status changes to management.
- 管理への状態変化の非同期な報告をサポートしてください。
1.2. Terminology
1.2. 用語
MTP - The Message Transfer Part of the SS7 protocol [Q.700] [Q.701] [Q.702] [Q.703] [Q.704] [Q.705] [T1.111].
MTP--SS7プロトコル[Q.700][Q.701][Q.702][Q.703][Q.704][Q.705][T1.111]のMessage Transfer Part。
MTP2 - MTP Level 2, the MTP signaling link layer.
MTP2--MTP Level2、MTPシグナリングリンクは層にされます。
George, et al. Standards Track [Page 3] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[3ページ]。
MTP3 - MTP Level 3, the MTP signaling network layer.
MTP3--MTP Level3、MTPシグナリングネットワークは層にされます。
MTP2-User - A protocol that normally uses the services of MTP Level 2. The only MTP2 user is MTP3. The MTP2 user is equivalent to the M2PA user.
MTP2-ユーザ--通常、MTP Level2のサービスを利用するプロトコル。 唯一のMTP2ユーザがMTP3です。 M2PAユーザにとって、MTP2ユーザは同等です。
Signaling End Point (SEP) - An SS7 Signaling Point that originates or terminates signaling messages. One example is a central office switch. [RFC2719]
シグナリングEnd Point(9月)--シグナリングメッセージを溯源するか、または終えるSS7 Signaling Point。 1つの例が電話局スイッチです。 [RFC2719]
IP Signaling Point (IPSP) - An SS7 Signaling Point with an IP network connection used for SS7 over IP.
IP Signaling Point(IPSP)--IPネットワーク接続がSS7にIPの上で使用されているSS7 Signaling Point。
Signaling Gateway (SG) - A signaling agent that receives/sends SCN native signaling at the edge of the IP network [RFC2719]. In this context, an SG is an SS7 Signaling Point that has both an IP network connection used for SS7 over IP, and a traditional (non-IP) link to an SS7 network.
シグナリングゲートウェイ(SG)--IPの縁でネイティブのシグナリングをSCNに受けるか、または送るシグナリングエージェントは[RFC2719]をネットワークでつなぎます。 このような関係においては、SGはSS7にIPの上で使用されるIPネットワーク接続とSS7ネットワークへの伝統的な(非IPの)リンクの両方があるSS7 Signaling Pointです。
Signal Transfer Point (STP) - A Signal Transfer Point as defined by MTP standards, e.g., [Q.700].
Transfer Point(STP)に合図してください--MTP規格によって定義されるSignal Transfer Point、例えば、[Q.700。]
Signaling Point (STP) - A Signaling Point as defined by MTP standards, e.g., [Q.700].
シグナリングPoint(STP)--MTP規格によって定義されるSignaling Point、例えば、[Q.700。]
Association - An association refers to an SCTP association [RFC2960]. The association provides the transport for MTP3 protocol data units and M2PA adaptation layer peer messages.
協会--協会はSCTP協会[RFC2960]について言及します。 協会はMTP3プロトコルデータ単位とM2PA適合層の同輩メッセージのための輸送を提供します。
Network Byte Order - Most significant byte first, also known as "Big Endian". See [RFC791], Appendix B "Data Transmission Order".
Byte Orderをネットワークでつないでください--最初に、また、「ビッグエンディアン」として知られている中で最も重要なバイト。 付録B「データ伝送オーダー」と見てください[RFC791]。
Stream - A stream refers to an SCTP stream [RFC2960].
ストリーム--ストリームはSCTPストリーム[RFC2960]について言及します。
1.3. Abbreviations
1.3. 略語
BSNT - Backward Sequence Number to be Transmitted
BSNT--Transmittedである後方のSequence Number
FSNC - Forward Sequence Number of last message accepted by remote
level 2
FSNC--前方に、最後のメッセージのSequence Numberはリモートレベル2で受け入れました。
LI - Length Indicator
LI--長さのインディケータ
MSU - Message Signal Unit
MSU--メッセージ信号ユニット
SCCP - Signaling Connection Control Part
SCCP--シグナリング接続コントロール部分
SCN - Switched Circuit Network
SCN--交換回線網ネットワーク
George, et al. Standards Track [Page 4] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[4ページ]。
SCTP - Stream Control Transmission Protocol
SCTP--ストリーム制御伝動プロトコル
SIF - Signaling Information Field
SIF--シグナリング情報フィールド
SIO - Service Information Octet
SIO--サービス情報八重奏
SLC - Signaling Link Code
SLC--シグナリングリンクコード
SS7 - Signaling System Number 7
SS7--シグナリングシステムNo.7
SSN - Stream Sequence Number
SSN--ストリーム一連番号
STP - Signal Transfer Point
STP--信号転送ポイント
1.4. Conventions
1.4. コンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
1.5. Signaling Transport Architecture
1.5. シグナリング輸送アーキテクチャ
The architecture that has been defined [RFC2719] for Switched Circuit Network (SCN) signaling transport over IP uses multiple components, including an IP transport protocol, the Stream Control Transmission Protocol (SCTP), and an adaptation module to support the services expected by a particular SCN signaling protocol from its underlying protocol layer.
IPの上のSwitched Circuit Network(SCN)シグナリング輸送のために定義された[RFC2719]アーキテクチャは複数のコンポーネントを使用します、特定のSCNシグナリングプロトコルによって基本的なプロトコル層から予想されたサービスをサポートするためにIPトランスポート・プロトコル、Stream Control Transmissionプロトコル(SCTP)、および適合モジュールを含んでいて。
Within this framework architecture, this document defines an SCN adaptation module that is suitable for the transport of SS7 MTP3 messages. The adaptation layer, known as the MTP2 User Peer-to-peer Adaptation Layer (M2PA), provides MTP3 with an interface and services similar to MTP2. In effect, MTP2 and lower layers of the traditional SS7 protocol stack are replaced by an IP equivalent.
このフレームワークアーキテクチャの中では、このドキュメントはSS7 MTP3メッセージの輸送に適したSCN適合モジュールを定義します。 MTP2 User Peerから同輩へのAdaptation Layer(M2PA)として知られている適合層はインタフェースとMTP2と同様のサービスをMTP3に提供します。 事実上、伝統的なSS7プロトコル・スタックのMTP2と下層をIP同等物に取り替えます。
Figure 1 shows the seamless interworking at the MTP3 layer. MTP3 is adapted to the SCTP layer using the MTP2 User Peer-to-peer Adaptation Layer (M2PA). All the primitives between MTP3 and MTP2 are supported by M2PA. The SCTP association acts as one SS7 link between the IPSPs. An IPSP may have the Signaling Connection Control Part (SCCP) and other SS7 layers above MTP3.
図1はMTP3層にシームレスの織り込むことを示しています。 MTP3は、MTP2 User Peerから同輩へのAdaptation Layer(M2PA)を使用することでSCTP層に適合させられます。 MTP3とMTP2の間のすべての基関数がM2PAによってサポートされます。 1SS7がIPSPsの間でリンクするとき、SCTP協会は行動します。 IPSPはMTP3の上にSignaling Connection Control Part(SCCP)と他のSS7層を持っているかもしれません。
George, et al. Standards Track [Page 5] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[5ページ]。
******** 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 Signaling Point
SCTP - Stream Control Transmission Protocol [RFC2960]
IP--インターネットプロトコルIPSP--IPシグナリングポイントSCTP--ストリーム制御伝動プロトコル[RFC2960]
Figure 1. M2PA Symmetrical Peer-to-Peer Architecture
図1。 M2PAの対称のピアツーピアアーキテクチャ
Figure 2 shows an example of M2PA used in a Signaling Gateway (SG). The SG is an IPSP that is equipped with both traditional SS7 and IP network connections.
図2はSignalingゲートウェイ(SG)に使用されるM2PAに関する例を示しています。 SGは伝統的なSS7とIPネットワーク接続の両方に持たせるIPSPです。
The SEP and the SG communicate through a traditional SS7 link, which follows a protocol such as [Q.702]. The SG and the IPSP communicate through an IP link using the M2PA protocol. Messages sent from the SEP to the IPSP (and vice versa) are routed by the SG.
9月、SGは伝統的なSS7リンクを通って交信します。リンクは[Q.702]などのプロトコルに従います。 SGとIPSPは、IPリンクを通ってM2PAプロトコルを使用することで交信します。 9月からIPSPに送られたメッセージはSGによって(逆もまた同様に)発送されます。
Any of the nodes in the diagram could have SCCP or other SS7 layers above MTP3. The Signaling Gateway acts as a Signal Transfer Point (STP). Other STPs MAY be present in the SS7 path between the SEP and the SG.
ダイヤグラムによるノードのいずれもMTP3の上にSCCPか他のSS7層を持っているかもしれません。 SignalingゲートウェイはSignal Transfer Point(STP)として機能します。 他のSTPsは9月、SGの間のSS7経路に存在しているかもしれません。
George, et al. Standards Track [Page 6] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[6ページ]。
******** SS7 *************** IP ********
* SEP *--------* SG *--------* IPSP *
******** *************** ********
******** SS7***************IP*********9月*--------* SG*--------* IPSP********************************
+------+ +------+
| TCAP | | TCAP |
+------+ +------+
| SCCP | | SCCP |
+------+ +-------------+ +------+
| MTP3 | | MTP3 | | MTP3 |
+------+ +------+------+ +------+
| MTP2 | | MTP2 | M2PA | | M2PA |
| | | +------+ +------+
| | | | SCTP | | SCTP |
+------+ +------+------+ +------+
| MTP1 | | MTP1 | IP | | IP |
+------+ +------+------+ +------+
+------+ +------+ | TCAP| | TCAP| +------+ +------+ | SCCP| | SCCP| +------+ +-------------+ +------+ | MTP3| | MTP3| | MTP3| +------+ +------+------+ +------+ | MTP2| | MTP2| M2PA| | M2PA| | | | +------+ +------+ | | | | SCTP| | SCTP| +------+ +------+------+ +------+ | MTP1| | MTP1| IP| | IP| +------+ +------+------+ +------+
SEP - SS7 Signaling Endpoint
9月--SS7シグナリング終点
Figure 2. M2PA in IP Signaling Gateway
図2。 IPシグナリングゲートウェイにおけるM2PA
Figure 2 is only an example. Other configurations are possible. In short, M2PA uses the SCTP association as an SS7 link. The M2PA/SCTP/IP stack can be used in place of an MTP2/MTP1 stack.
図2は例にすぎません。 他の構成は可能です。 要するに、M2PAはSS7リンクとしてSCTP協会を使用します。 MTP2/MTP1スタックに代わってM2PA/SCTP/IPスタックを使用できます。
1.5.1. Point Code Representation
1.5.1. ポイントコード表現
MTP requires that each node with an MTP3 layer is identified by an SS7 point code. In particular, each IPSP MUST have its own SS7 point code.
MTPは、MTP3層がある各ノードがSS7ポイントコードによって特定されるのを必要とします。 各IPSP MUSTには、特に、それ自身のSS7ポイントコードがあります。
1.6. Services Provided by M2PA
1.6. M2PAによって提供されたサービス
The SS7 MTP3/MTP2 (MTP2-User) interface is retained in the IPSP. The M2PA protocol layer is required to provide a set of services to its user equivalent to that provided by MTP Level 2 to MTP Level 3.
SS7 MTP3/MTP2(MTP2-ユーザ)インタフェースはIPSPで保有されます。 M2PAプロトコル層はMTP Level2によってMTP Level3に提供されたそれに同等なユーザに対する1セットのサービスを提供しなければなりません。
These services are described in the following subsections.
これらのサービスは以下の小区分で説明されます。
1.6.1. Support for MTP Level 2 / MTP Level 3 Interface Boundary
1.6.1. MTPレベルには、レベル3 2 / MTPがインタフェース境界であるとサポートしてください。
This interface is the same as the MTP2/MTP3 interface described in the applicable SS7 standards [Q.703] [Q.704] [T1.111] [Q.2140], with the addition of support for the larger sequence numbers found in [T1.111] and [Q.2210].
このインタフェースはMTP2/MTP3インタフェースが適切なSS7規格[Q.703][Q.704][T1.111][Q.2140]で説明したのと同じです、より大きい一連番号のサポートの追加が[T1.111]と[Q.2210]で見つけられている状態で。
George, et al. Standards Track [Page 7] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[7ページ]。
M2PA receives the primitives sent from MTP3 to its lower layer. M2PA processes these primitives or maps them to appropriate primitives at the M2PA/SCTP interface. Likewise, M2PA sends primitives to MTP3 similar to those used in the MTP3/MTP2 interface.
M2PAはMTP3から下層に送られた基関数を受け取ります。 M2PAは、M2PA/SCTPインタフェースで基関数を当てるためにこれらの基関数を処理するか、またはそれらを写像します。 同様に、M2PAはMTP3/MTP2インタフェースで使用されるものと同様のMTP3に基関数を送ります。
Because M2PA uses larger sequence numbers than MTP2, the MTP3 Changeover procedure MUST use the Extended Changeover Order and Extended Changeover Acknowledgement messages described in [Q.2210] and [T1.111].
M2PAがMTP2より大きい一連番号を使用するので、MTP3 Changeover手順はメッセージが[Q.2210]と[T1.111]で説明したExtended Changeover OrderとExtended Changeover Acknowledgementを使用しなければなりません。
Also, the following MTP3/MTP2 primitives must use the larger sequence numbers:
また、以下のMTP3/MTP2基関数は、より大きい一連番号を使用しなければなりません:
- BSNT Confirmation
- BSNT確認
- Retrieval Request and FSNC
- 検索要求とFSNC
1.6.2. Support for Peer-to-Peer Communication
1.6.2. ピアツーピアコミュニケーションのサポート
In SS7, MTP Level 2 sends three types of messages, known as signal units: Message Signal Units (MSUs), Link Status Signal Units (LSSUs), and Fill-In Signal Units (FISUs).
SS7では、MTP Level2は信号ユニットとして知られている3つのタイプに関するメッセージを送ります: メッセージ信号ユニット(MSU)、リンクステータス信号ユニット(LSSUs)、および代理はユニット(FISUs)を示します。
MSUs originate at a higher level than MTP2, and are destined for a peer at another node. Likewise, M2PA passes these messages from MTP3 to SCTP as data for transport across a link. These are called User Data messages in M2PA.
MSUは、MTP2より高いレベルで起因して、同輩のために別のノードで運命づけられています。 同様に、M2PAは輸送のためのデータとしてMTP3からSCTPまでリンクの反対側にこれらのメッセージを通過します。 これらはM2PAのUser Dataメッセージと呼ばれます。
LSSUs allow peer MTP2 layers to exchange status information. Analogous messages are needed for M2PA. The Link Status message serves this purpose.
LSSUsは同輩MTP2層に状態情報を交換させます。 類似のメッセージがM2PAに必要です。 Link Statusメッセージはこの目的に役立ちます。
FISUs are transmitted continuously when no other signal units are waiting to be sent. FISUs also carry acknowledgement of messages. Since an IP network is a shared resource, it would be undesirable to have a message type that is sent continuously as is the case with FISUs. Furthermore, SCTP does not require its upper layer to continuously transmit messages. Therefore, M2PA does not provide a protocol data unit like the FISU. The M2PA User Data message is used to carry acknowledgement of messages. If M2PA needs to acknowledge a message, and it has no MTP3 message of its own to send, an empty User Data message can be sent.
他のどんな信号ユニットも、送られるのを待っていないとき、FISUsは絶え間なく伝えられます。 また、FISUsはメッセージの承認を運びます。 IPネットワークが共用資源であるので、FISUsに関してそうであるように絶え間なく送られるメッセージタイプがあるのは、望ましくないでしょう。 その上、SCTPは、絶え間なくメッセージを送るために上側の層を必要としません。 したがって、M2PAはFISUのようなプロトコルデータ単位を提供しません。 M2PA User Dataメッセージは、メッセージの承認を運ぶのに使用されます。 M2PAが、メッセージを承認する必要があって、それにそれ自身のものが発信するMTP3メッセージが全くないなら、空のUser Dataメッセージを送ることができます。
George, et al. Standards Track [Page 8] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[8ページ]。
1.7. Functions Provided by M2PA
1.7. M2PAによって提供された機能
1.7.1. MTP2 Functionality
1.7.1. MTP2の機能性
M2PA provides MTP2 functionality that is not provided by SCTP; thus, together M2PA and SCTP provide functionality similar to that of MTP2.
M2PAはSCTPによって提供されない機能性をMTP2に供給します。 M2PAとSCTPはMTP2のものと同様の機能性をこのようにして、一緒に、提供します。
SCTP provides reliable, sequenced delivery of messages.
SCTPはメッセージの信頼できて、配列された配送を提供します。
M2PA functionality includes:
M2PAの機能性は:
- Data retrieval to support the MTP3 changeover procedure
- MTP3転換手順をサポートするデータの検索
- Reporting of link status changes to MTP3
- MTP3へのリンク状態変化の報告
- Processor outage procedure
- プロセッサ供給停止手順
- Link alignment procedure
- リンク整列手順
1.7.2. Mapping of SS7 and IP Entities
1.7.2. SS7とIP実体に関するマッピング
The M2PA layer must maintain a map of each of its SS7 links to the corresponding SCTP association.
M2PA層は対応するSCTP協会へのそれぞれのSS7リンクの地図を維持しなければなりません。
1.7.3. SCTP Association Management
1.7.3. SCTP協会管理
SCTP allows a user-specified number of streams to be opened during the initialization. It is the responsibility of the M2PA layer to ensure proper management of the streams allowed within each association.
SCTPは初期化の間、ユーザによって指定された数のストリームを開かせます。 各協会の中に許容されたストリームの適切な管理を確実にするのは、M2PA層の責任です。
M2PA uses two streams in each direction for each association. Stream 0 in each direction is designated for Link Status messages. Stream 1 is designated for User Data messages, as well as Link Status messages that must remain in sequence with the User Data messages. Separating the Link Status and User Data messages into separate streams allows M2PA to prioritize the messages in a manner similar to MTP2.
M2PAは各協会に各方向への2つのストリームを使用します。 各方向へのストリーム0はLink Statusメッセージのために指定されます。 ストリーム1はUser Dataメッセージのために指定されます、User Dataメッセージで連続して残らなければならないLink Statusメッセージと同様に。 Link StatusとUser Dataメッセージを別々のストリームに切り離すのに、M2PAはMTP2と同様の方法によるメッセージを最優先させることができます。
Notifications received from SCTP are processed by M2PA or translated into an appropriate notification to be sent to the upper layer MTP3.
SCTPから受け取られた通知は、MTP3の上側の層に送るためにM2PAによって処理されるか、または適切な通知に翻訳されます。
1.7.4. Retention of MTP3 in the SS7 Network
1.7.4. SS7ネットワークにおける、MTP3の保有
M2PA allows MTP3 to perform all of its Message Handling and Network Management functions with IPSPs as it does with other SS7 nodes.
他のSS7ノードを処理するとき、M2PAはMTP3にIPSPsと共にMessage HandlingとNetwork Management機能のすべてを実行させます。
George, et al. Standards Track [Page 9] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[9ページ]。
1.8. Definition of the M2PA Boundaries
1.8. M2PA境界の定義
1.8.1. Definition of the M2PA / MTP Level 3 Boundary
1.8.1. M2PA / MTPの平らな3境界の定義
The upper layer primitives provided by M2PA are the same as those provided by MTP2 to MTP3. These primitives are described in the applicable SS7 standards [Q.703] [Q.704] [T1.111] [Q.2140].
M2PAによって提供された上側の層の基関数はMTP2によってMTP3に提供されたものと同じです。 これらの基関数は適切なSS7規格[Q.703][Q.704][T1.111][Q.2140]で説明されます。
1.8.2. Definition of the Lower Layer Boundary between M2PA and SCTP
1.8.2. M2PAとSCTPの間の下層境界の定義
The upper layer primitives provided by SCTP are described in [RFC2960] Section 10 "Interface with Upper Layer".
SCTPによって提供された上側の層の基関数は「上側の層とのインタフェース」という[RFC2960]セクション10で説明されます。
1.9. Differences Between M2PA and M2UA
1.9. M2PAとM2UAの違い
The MTP2 User Adaptation Layer (M2UA) [M2UA] also adapts the MTP3 layer to the SCTP/IP stack. It does so through a backhauling architecture [RFC2719]. This section is intended to clarify some of the differences between the M2PA and M2UA approaches.
また、MTP2 User Adaptation Layer(M2UA)[M2UA]はSCTP/IPスタックにMTP3層を適合させます。 それはbackhaulingアーキテクチャ[RFC2719]を通してそうします。 このセクションがM2PAとM2UAアプローチの違いのいくつかをはっきりさせることを意図します。
A possible M2PA architecture is shown in Figure 3. Here the IPSP's MTP3 uses its underlying M2PA as a replacement for MTP2. Communication between the two layers MTP3/M2PA is defined by the same primitives as in SS7 MTP3/MTP2. M2PA performs functions similar to MTP2.
可能なM2PAアーキテクチャは図3に示されます。 ここで、IPSPのMTP3はMTP2に交換として基本的なM2PAを使用します。 MTP3/M2PA2つの層のコミュニケーションはSS7 MTP3/MTP2のように同じ基関数によって定義されます。 M2PAはMTP2と同様の機能を実行します。
******** SS7 *************** IP ********
* SEP *--------* SG *--------* IPSP *
******** *************** ********
******** SS7***************IP*********9月*--------* SG*--------* IPSP********************************
+------+ +-------------+ +------+
| SCCP | | SCCP | | SCCP |
+------+ +-------------+ +------+
| MTP3 | | MTP3 | | MTP3 |
+------+ +------+------+ +------+
| MTP2 | | MTP2 | M2PA | | M2PA |
| | | +------+ +------+
| | | | SCTP | | SCTP |
+------+ +------+------+ +------+
| MTP1 | | MTP1 | IP | | IP |
+------+ +------+------+ +------+
+------+ +-------------+ +------+ | SCCP| | SCCP| | SCCP| +------+ +-------------+ +------+ | MTP3| | MTP3| | MTP3| +------+ +------+------+ +------+ | MTP2| | MTP2| M2PA| | M2PA| | | | +------+ +------+ | | | | SCTP| | SCTP| +------+ +------+------+ +------+ | MTP1| | MTP1| IP| | IP| +------+ +------+------+ +------+
Figure 3. M2PA in IP Signaling Gateway
図3。 IPシグナリングゲートウェイにおけるM2PA
A comparable architecture for M2UA is shown in Figure 4. In M2UA, the MGC's MTP3 uses the SG's MTP2 as its lower SS7 layer. Likewise, the SG's MTP2 uses the MGC's MTP3 as its upper SS7 layer. In SS7,
M2UAにおいて、匹敵するアーキテクチャは図4に示されます。 M2UAでは、下側のSS7が層にするとき、MGCのMTP3はSGのMTP2を使用します。 同様に、上側のSS7が層にするとき、SGのMTP2はMGCのMTP3を使用します。 SS7で
George, et al. Standards Track [Page 10] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[10ページ]。
communication between the MTP3 and MTP2 layers is defined by primitives. In M2UA, the MTP3/MTP2 communication is defined as M2UA messages and sent over the IP connection.
MTP3とMTP2層とのコミュニケーションは基関数によって定義されます。 M2UAでは、MTP3/MTP2コミュニケーションをM2UAメッセージと定義して、IP接続の上に送ります。
******** SS7 *************** IP ********
* SEP *--------* SG *--------* MGC *
******** *************** ********
******** SS7***************IP*********9月*--------* SG*--------* MGC********************************
+------+ +------+
| SCCP | | SCCP |
+------+ +------+
| MTP3 | (NIF) | MTP3 |
+------+ +------+------+ +------+
| MTP2 | | MTP2 | M2UA | | M2UA |
| | | +------+ +------+
| | | | SCTP | | SCTP |
+------+ +------+------+ +------+
| MTP1 | | MTP1 | IP | | IP |
+------+ +------+------+ +------+
+------+ +------+ | SCCP| | SCCP| +------+ +------+ | MTP3| (NIF) | MTP3| +------+ +------+------+ +------+ | MTP2| | MTP2| M2UA| | M2UA| | | | +------+ +------+ | | | | SCTP| | SCTP| +------+ +------+------+ +------+ | MTP1| | MTP1| IP| | IP| +------+ +------+------+ +------+
NIF - Nodal Interworking Function
NIF--こぶのような織り込む機能
Figure 4. M2UA in IP Signaling Gateway
図4。 IPシグナリングゲートウェイにおけるM2UA
M2PA and M2UA are similar in that:
M2PAとM2UAはそれで同様です:
a. Both transport MTP3 data messages.
a。 両方がMTP3データメッセージを輸送します。
b. Both present an MTP2 upper interface to MTP3.
b。 両方がMTP2の上側のインタフェースをMTP3に提示します。
Differences between M2PA and M2UA include:
M2PAとM2UAの違いは:
a. M2PA: IPSP processes MTP3/MTP2 primitives.
M2UA: MGC transports MTP3/MTP2 primitives between the SG's MTP2
and the MGC's MTP3 (via the NIF) for processing.
a。 M2PA: IPSPはMTP3/MTP2基関数を処理します。 M2UA: MGCは処理のためにSGのMTP2とMGCのMTP3(NIFを通した)の間のMTP3/MTP2基関数を輸送します。
b. M2PA: SG-IPSP connection is an SS7 link.
M2UA: SG-MGC connection is not an SS7 link. It is an
extension of MTP to a remote entity.
b。 M2PA: SG-IPSP接続はSS7リンクです。 M2UA: SG-MGC接続はSS7リンクではありません。 それはリモート実体へのMTPの拡大です。
c. M2PA: SG is an SS7 node with a point code.
M2UA: SG is not an SS7 node and has no point code.
c。 M2PA: SGはポイントコードがあるSS7ノードです。 M2UA: SGはSS7ノードでなく、またポイントコードを全く持っていません。
d. M2PA: SG can have upper SS7 layers, e.g., SCCP.
M2UA: SG does not have upper SS7 layers since it has no MTP3.
d。 M2PA: SGは上側のSS7層、例えばSCCPを持つことができます。 M2UA: MTP3を全く持っていないので、SGには、上側のSS7層がありません。
e. M2PA: relies on MTP3 for management procedures.
M2UA: uses M2UA management procedures.
e。 M2PA: 管理手順のためにMTP3を当てにします。 M2UA: M2UA管理手順を用います。
George, et al. Standards Track [Page 11] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[11ページ]。
Potential users of M2PA and M2UA should be aware of these differences when deciding how to use them for SS7 signaling transport over IP networks.
IPネットワークの上のSS7シグナリング輸送にそれらを使用する方法を決めるとき、M2PAとM2UAの潜在的ユーザはこれらの違いを知っているべきです。
2. Protocol Elements
2. プロトコル要素
This section describes the format of various messages used in this protocol.
このセクションはこのプロトコルに使用される様々なメッセージの形式について説明します。
All fields in an M2PA message must be transmitted in the network byte order, i.e., most significant byte first, unless otherwise stated.
ネットワークバイトオーダーでM2PAメッセージのすべての野原を伝えなければならなくて、すなわち、最も重要なバイトは1番目です、別の方法で述べられない場合。
2.1. Common Message Header
2.1. 一般的なメッセージヘッダー
The protocol messages for M2PA require a message header structure that contains a version, message class, message type, and message length. The header structure is shown in Figure 5.
M2PAへのプロトコルメッセージはバージョンを含むaメッセージヘッダー構造、メッセージのクラス、メッセージタイプ、およびメッセージ長を必要とします。 ヘッダー構造は図5で見せられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Spare | Message Class | Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン| 予備| メッセージのクラス| メッセージタイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5. Common Message Header
図5。 一般的なメッセージヘッダー
2.1.1. Version
2.1.1. バージョン
The version field contains the version of M2PA. The supported versions are:
バージョン分野はM2PAのバージョンを含んでいます。 サポートしているバージョンは以下の通りです。
Value
(decimal) Version
--------- -------
1 Release 1.0 of M2PA protocol
値(10進)のバージョン--------- ------- 1 M2PAプロトコルのリリース1.0
2.1.2. Spare
2.1.2. 予備
The Spare field SHOULD be set to all zeroes (0's) by the sender and ignored by the receiver. The Spare field SHOULD NOT be used for proprietary information.
SpareはSHOULDをさばきます。. 送付者であって受信機で無視されるのによるすべてのゼロ(0)へのセットがSpare分野SHOULD NOTであったなら、知的財産情報には、使用されてください。
George, et al. Standards Track [Page 12] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[12ページ]。
2.1.3. Message Class
2.1.3. メッセージのクラス
The following List contains the valid Message Classes:
以下のListは有効なMessage Classesを含んでいます:
Value
(decimal) Message Class
--------- -------------
11 M2PA Messages
値(10進)のメッセージのクラス--------- ------------- 11 M2PAメッセージ
Other values are invalid for M2PA.
M2PAに、他の値は無効です。
2.1.4. Message Type
2.1.4. メッセージタイプ
The following list contains the message types for the defined messages.
以下のリストは定義されたメッセージのためのメッセージタイプを含んでいます。
Value
(decimal) Message Type
--------- -------------
1 User Data
2 Link Status
値(10進)のメッセージタイプ--------- ------------- 1 ユーザデータ2リンク状態
Other values are invalid.
他の値は無効です。
2.1.5. Message Length
2.1.5. メッセージ長
The Message Length defines the length of the message in octets, including the Common Header.
Message LengthはCommon Headerを含む八重奏における、メッセージの長さを定義します。
2.2. M2PA Header
2.2. M2PAヘッダー
All protocol messages for M2PA require an M2PA-specific header. The header structure is shown in Figure 6.
M2PAへのすべてのプロトコルメッセージがM2PA特有のヘッダーを必要とします。 ヘッダー構造は図6で見せられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused | BSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused | FSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 未使用| BSN| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 未使用| FSN| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6. M2PA-specific Message Header
図6。 M2PA特有のメッセージヘッダー
2.2.1. Backward Sequence Number (BSN)
2.2.1. 後方の一連番号(BSN)
This is the FSN of the message last received from the peer.
これは最後に同輩から受け取られたメッセージのFSNです。
George, et al. Standards Track [Page 13] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[13ページ]。
2.2.2. Forward Sequence Number (FSN)
2.2.2. 前進の一連番号(FSN)
This is the M2PA sequence number of the User Data message being sent.
これは送られるUser DataメッセージのM2PA一連番号です。
The FSN and BSN values range from 0 to 16,777,215.
FSNとBSN値は0〜1677万7215まで及びます。
2.3. M2PA Messages
2.3. M2PAメッセージ
The following section defines the messages and parameter contents. An M2PA message consists of a Common Message Header and M2PA Header, followed by the data appropriate to the message.
以下のセクションはメッセージとパラメタコンテンツを定義します。 M2PAメッセージはメッセージに適切なデータがあとに続いたCommon Message HeaderとM2PA Headerから成ります。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Common Message Header / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / M2PA-specific Message Header / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Message Data / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Common Message Header / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / M2PA-specific Message Header / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Message Data / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The field "Message Data" contains either:
分野「メッセージデータ」はどちらかを含んでいます:
- a User Data message (Section 2.3.1), or
- a Link State message (Section 2.3.2)
- または、User Dataメッセージ(セクション2.3.1)、--Link州が通信する(セクション2.3.2)
2.3.1. User Data
2.3.1. 利用者データ
The User Data is the data sent from MTP3. The User Data is an optional field. It need not be included in an acknowledgement-only message.
User DataはMTP3から送られたデータです。 User Dataは任意の分野です。 それは承認だけメッセージに含まれる必要はありません。
The format of the User Data message is as follows:
User Dataメッセージの形式は以下の通りです:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
データ
George, et al. Standards Track [Page 14] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[14ページ]。
The Data field contains the following fields of the MTP Message Signal Unit (MSU):
Data分野はMTP Message Signal Unit(MSU)の以下の分野を含んでいます:
- the Message Priority field (PRI)
- Service Information Octet (SIO)
- Signaling Information Field (SIF)
- Message Priority分野(PRI)--サービス情報Octet(SIO)--シグナリング情報Field(シフ)
The MTP MSU is described in Q.703 [Q.703], Section 2.2, "Signal Unit Format", and T1.111.3 [T1.111], Section 2.2, "Signal Unit Format". The Japanese TTC standard uses the PRI field as an MTP3 Message Priority field [JT-Q703] [JT-Q704]. For versions of MTP that do not use these two bits, the entire first octet of the Data field is spare.
MTP MSUはQ.703[Q.703]、「信号ユニット形式」というセクション2.2で説明されます、そして、T1.111.3[T1.111](セクション2.2)は「ユニット形式に合図します」。 日本のTTC規格はMTP3 Message Priority分野[JT-Q703][JT-Q704]としてPRI分野を使用します。 これらの2ビットを使用しないMTPのバージョンのために、Data分野の全体の最初の八重奏は予備です。
The format of the first octet of the Data field is:
Data分野の最初の八重奏の形式は以下の通りです。
0
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|PRI| spare | (followed by SIO, SIF)
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |PRI| 予備| (SIO、SIFによって続かれています) +-+-+-+-+-+-+-+-+
PRI - Priority used only in national MTP defined in [JT-Q703] and
[JT-Q704]. These bits are spare for other MTP versions.
PRI--優先権は国家だけで[JT-Q703]と[JT-Q704]で定義されたMTPを使用しました。 これらのビットは他のMTPバージョンのための予備です。
Note that the Data field SHALL NOT contain other components of the MTP MSU format:
Data分野SHALL NOTがMTP MSU形式の他のコンポーネントを含むことに注意してください:
- Flag
- Backward Sequence Number (BSN)
- Backward Indicator Bit (BIB)
- Forward Sequence Number (FSN)
- Forward Indicator Bit (FIB)
- Length Indicator (LI)
- Check bits (CK)
- 旗--後方に、Sequence Number(BSN)(後方のIndicator Bit(BIB))はSequence Number(FSN)を送ります--Indicator Bit(FIB)(長さのIndicator(LI))にチェックビットを送ってください。(CK)
The Data field SHALL be transmitted in the byte order as defined by MTP3.
MTP3によって定義されるようにDataは伝えられたコネがバイトオーダーであったならSHALLをさばきます。
M2PA SHALL NOT add padding to the MTP3 message.
M2PA SHALL NOTはMTP3メッセージに詰め物を追加します。
Note: In the SS7 Recommendations, the format of the messages and fields within the messages are based on bit transmission order. In these recommendations, the Least Significant Bit (LSB) of each field is positioned to the right. The received SS7 fields are populated octet by octet as received into the 4-octet word, as shown below.
以下に注意してください。 SS7 Recommendationsでは、メッセージの形式とメッセージの中の分野はビット伝送命令に基づいています。 これらの推薦では、それぞれの分野のLeast Significant Bit(LSB)は右に置かれます。 以下に示されるように4八重奏の単語に受けられる八重奏によって容認されたSS7分野は居住された八重奏です。
George, et al. Standards Track [Page 15] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[15ページ]。
As an example, in the ANSI MTP protocol, the Data field format is shown below:
例として、ANSI MTPプロトコルで、Dataフィールド形式は以下に示されます:
|MSB---------------------------------------------------------LSB|
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PRI| spare | SIO | SIF octet | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ : /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ... | ... | SIF octet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSB---------------------------------------------------------LSB| 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PRI| 予備| SIO| SIF八重奏| ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / : / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | ... | ... | SIF八重奏| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Within each octet, the Least Significant Bit (LSB) per the SS7 Recommendations is to the right (e.g., bit 15 of SIO is the LSB).
各八重奏の中に、右には1SS7 RecommendationsあたりのLeast Significant Bit(LSB)があります(例えば、SIOのビット15はLSBです)。
2.3.2. Link Status
2.3.2. リンク状態
The MTP2 Link Status message can be sent between M2PA peers to indicate link status. This message performs a function similar to the Link Status Signal Unit in MTP2. The format of the Link Status message is as follows:
リンク状態を示すためにM2PA同輩の間にMTP2 Link Statusメッセージを送ることができます。 このメッセージはMTP2でLink Status Signal Unitと同様の機能を実行します。 Link Statusメッセージの形式は以下の通りです:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 状態| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for State are shown in the following table.
州のための有効値は以下のテーブルに示されます。
Value
(decimal) Description
--------- -----------
1 Alignment
2 Proving Normal
3 Proving Emergency
4 Ready
5 Processor Outage
6 Processor Recovered
7 Busy
8 Busy Ended
9 Out of Service (OOS)
値(10進)の記述--------- ----------- 1 非常時4が持ち合わせの5プロセッサ供給停止6プロセッサであると立証する標準3が忙しい8が忙しくする7を回復したと立証する整列2が使われなくなった状態で9を終わらせました。(OOS)
George, et al. Standards Track [Page 16] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[16ページ]。
2.3.2.1. Link Status Proving
2.3.2.1. リンク状態立証
The Link Status Proving message may optionally carry additional bytes. If the optional bytes are used, the format of the message is as follows.
Link Status Provingメッセージは任意に追加バイトを運ぶかもしれません。 任意のバイトが使用されているなら、メッセージの形式は以下の通りです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ filler /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 状態| フィラー
It is RECOMMENDED that the length of the Link Status Proving message be similar to the size of the User Data messages that will be carried on the link.
Link Status Provingメッセージの長さがリンクで伝えられるUser Dataメッセージのサイズと同様であることは、RECOMMENDEDです。
It is RECOMMENDED that the filler field contain a number pattern that varies among the Link Status Proving messages, and that allows the SCTP checksum [RFC3309] to be used to verify the accuracy of transmission.
フィラー分野がLink Status Provingメッセージの中で異なって、SCTPチェックサム[RFC3309]が通信の正確度を確認するのに使用されるのを許容する数のパターンを含んでいるのは、RECOMMENDEDです。
3. State Control
3. 州のコントロール
3.1. SCTP Association State Control
3.1. SCTP協会州のコントロール
Figure 7 illustrates state changes in the M2PA management of the SCTP association, together with the causing events. Note that some of the error conditions are not shown in the state diagram.
図7は引き起こす出来事と共にSCTP協会のM2PA経営における州の変化を例証します。 エラー条件のいくつかが州のダイヤグラムで示されないことに注意してください。
Following is a list of the M2PA Association States and a description of each.
以下に、M2PA Association Statesのリストとそれぞれの記述があります。
IDLE - State of the association during power-up initialization.
IDLE--パワーアップする初期化の間の協会の状態。
ASSOCIATING - M2PA is attempting to establish an SCTP association.
ASSOCIATING--M2PAは、SCTP協会を設立するのを試みています。
ESTABLISHED - SCTP association is established.
ESTABLISHED--SCTP協会は設立されます。
George, et al. Standards Track [Page 17] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[17ページ]。
+-----------+
| IDLE |
+-----------+
|
| Associate
| (Issue SCTP associate)
|
| +----------------------+
| | (Issue SCTP |
V V associate) |
+-------------+ |
| ASSOCIATING |----------------->+
+-------------+ SCTP Comm Error |
| |
| |
| SCTP Comm Up |
| |
V |
+-------------+ |
| ESTABLISHED |----------------->+
+-------------+ SCTP Comm Error
OR SCTP Comm Lost
+-----------+ | 怠けてください。| +-----------+ | | 仲間| (SCTPが関連づける問題) | | +----------------------+ | | (SCTPを発行してください| V V関連) | +-------------+ | | 交際します。|----------------->++-------------+ SCTP Comm誤り| | | | | | SCTP Commは上昇します。| | | V| +-------------+ | | 設立されます。|----------------->++-------------+ SCTP Comm誤りかSCTP Commが損をしました。
Figure 7. M2PA Association State Transition Diagram
図7。 M2PA協会状態遷移ダイヤグラム
3.2. M2PA Link State Control
3.2. M2PAリンク州のコントロール
The M2PA link moves from one state to another in response to various events. The events that may result in a change of state include:
M2PAリンクは1つの州から別の州まで様々な出来事に対応して動きます。 状態の変化をもたらすかもしれない出来事は:
- MTP3 primitive requests
- MTP3の原始の要求
- Receipt of messages from the peer M2PA
- 同輩M2PAからのメッセージの領収書
- Expiration of timers
- タイマの満了
- SCTP notifications
- SCTP通知
These events affect the M2PA link state in a manner similar to MTP2.
MTP2と同様の方法でこれらの出来事はM2PAリンク状態に影響します。
George, et al. Standards Track [Page 18] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[18ページ]。
4. Procedures
4. 手順
Because M2PA provides MTP3 with an interface and functionality like MTP2, its internal functioning is similar to that of MTP2.
M2PAがMTP2のようなインタフェースと機能性をMTP3に提供するので、内部の機能はMTP2のものと同様です。
Except as modified in this document, M2PA SHOULD follow the requirements of the applicable MTP2 specification. These may include [Q.703] or [T1.111]. The same standard MUST be followed on both ends of the M2PA link.
本書では変更されるのを除いて、M2PA SHOULDは適切なMTP2仕様の要件に続きます。 これらは[Q.703]か[T1.111]を含むかもしれません。 M2PAリンクの両端で同じ規格に続かなければなりません。
In particular, the corresponding applicable timer value defaults and ranges specified for the applicable MTP2 standard should be used for the M2PA timers.
特に、対応する適切なタイマ値はデフォルトとします、そして、適切なMTP2規格に指定された範囲はM2PAタイマに使用されるべきです。
When referring to MTP2 terminology in this document, the terminology of [Q.703] is used. This does not imply that the requirements of [Q.703] are to be followed.
本書ではMTP2用語を示すとき、[Q.703]の用語は使用されています。 [Q.703]の要件はこれが続かれないつもりであることです。
4.1. Procedures to Support MTP2 Features
4.1. MTP2の特徴を支持する手順
4.1.1. Signal Unit Format, Delimitation, Acceptance
4.1.1. 信号ユニット形式、区切り、承認
Messages for transmission across the network must follow the format described in Section 2.
ネットワークの向こう側のトランスミッションへのメッセージはセクション2で説明された形式に続かなければなりません。
SCTP provides reliable, in-sequence delivery of user messages. Therefore the related functionality of MTP2 is not needed. SCTP does not provide functions related to Link State Control in MTP2. These functions must be provided by M2PA.
SCTPはユーザメッセージの信頼できて、系列の配送を提供します。 したがって、MTP2の関連する機能性は必要ではありません。 SCTPはLink州Controlに関連する機能をMTP2に供給しません。 M2PAはこれらの機能を提供しなければなりません。
Since SCTP provides delivery of messages, there is no need for M2PA to delimit its messages with a flag, as is done in MTP2. Furthermore, M2PA does not need to perform zero bit insertion and deletion on its messages.
SCTPがメッセージの配送を提供するので、M2PAがそのままな旗でMTP2でしていた状態でメッセージを区切る必要は全くありません。 その上、M2PAは噛み付いている挿入と削除を全くメッセージに実行する必要はありません。
Since SCTP uses a checksum to detect transmission errors, there is no need for an M2PA checksum, as is needed in MTP2. This also eliminates the need for the error rate monitors of MTP2.
SCTPが伝送エラーを検出するのにチェックサムを使用するので、M2PAチェックサムの必要は全くありません、MTP2で必要であるように。 また、これはMTP2の誤り率モニターの必要性を排除します。
Since SCTP provides reliable delivery and ordered delivery, M2PA does not perform retransmissions. This eliminates the need for the forward and backward indicator bits in MTP2 signal units.
SCTPが信頼できる配信と命令された配送を提供するので、M2PAは「再-トランスミッション」を実行しません。 これはMTP2信号ユニットで前進の、そして、後方のインディケータビットの必要性を排除します。
Acceptance of a message is indicated by a successful receipt of the message from SCTP.
メッセージの承認はSCTPからメッセージのうまくいっている領収書で示されます。
George, et al. Standards Track [Page 19] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[19ページ]。
4.1.2. MTP and SCTP Entities
4.1.2. MTPとSCTP実体
This section describes how M2PA relates MTP and SCTP entities.
このセクションはM2PAがどうMTPとSCTP実体を関係づけるかを説明します。
Each MTP link corresponds to an SCTP association. To prevent duplicate associations from being established, it is RECOMMENDED that each endpoint know the IP address (or IP addresses, if multi-homing is used) and port number of both endpoints. SCTP prevents two associations with the same IP addresses and port numbers from being established.
それぞれのMTPリンクはSCTP協会に対応しています。 各終点がIPアドレスを知るのが、写し協会が設立されるのを防ぐためには、RECOMMENDEDである、(または、IPアドレス、使用されるマルチホーミング) そして、両方の終点のポートナンバー。 SCTPは、同じIPアドレスとポートナンバーとの2つの協会が設立されるのを防ぎます。
It is necessary for at least one of the endpoints to be listening on the port on which the other endpoint is trying to establish the association. Therefore, at least one of the port numbers SHOULD be the M2PA registered port.
少なくとも終点の1つがもう片方の終点が協会を設立しようとしているポートの上で聴かれるのが必要です。 したがって、少なくともポートの1つはM2PAが登録されたポートであったならSHOULDに付番します。
If only one association is to be established between these two IP addresses, then the association SHOULD be established using the M2PA registered port at each endpoint.
協会が設立されることになっているこれらの2IPが記述する1つ、次に、協会SHOULDだけが確立しているなら、M2PAを使用すると、ポートは各終点に登録されました。
If it is desirable to create multiple associations (for multiple links) between the two IP addresses, different port numbers can be used for each association. Nevertheless, the M2PA registered port number SHOULD be used at one end of each association.
2つのIPアドレスの間に複数の協会を創設するのが(複数のリンクに)望ましいなら、各協会に異なったポートナンバーを使用できます。 それにもかかわらず、M2PAはポートナンバーSHOULDを登録しました。それぞれの協会の片端では、使用されます。
Each combination of IP address/port for the two endpoints (i.e., each association) MUST be mapped to the same Signaling Link Code (SLC) at each endpoint, so that each endpoint knows which link is being created at the time the SCTP association is established. However, M2PA does not do any processing based on the SLC.
すなわち、2つの終点へのIPアドレス/ポートの各組み合わせ、(各協会) 各終点で同じSignaling Link Code(SLC)に写像しなければなりません、各終点が、SCTP協会が設立されるときどのリンクが作成されているかを知るように。 しかしながら、M2PAはSLCに基づく少しの処理もしません。
Following are examples of the relationships between associations and links. Note that a link is an SCTP association identified by two endpoints. Each endpoint is identified by an IP address and port number. Each association is mapped to an SLC.
以下に、協会とリンクの間には、関係に関する例があります。 リンクが2つの終点によって特定されたSCTP協会であることに注意してください。 各終点はIPアドレスとポートナンバーによって特定されます。 各協会はSLCに写像されます。
Figure 8 shows a case with two IPSPs, each with two IP addresses. Two associations are the links that connect the two IPSPs. Since these links are in the same link set, they MUST have different SLCs.
エイト環は2IPSPsと、それぞれ2つのIPアドレスでケースを見せています。 2つの協会が2IPSPsを接続するリンクです。 同じリンクセットにこれらのリンクがあるので、それらには、異なったSLCsがなければなりません。
Table 1 shows the relationships in tabular form. Table 1 is only conceptual. The actual method for mapping the SCTP associations to the SLCs is implementation dependent.
テーブル1は表にして関係を示しています。 テーブル1は概念的であるだけです。 SCTP協会をSLCsに写像するための実際の方法は実現に依存しています。
George, et al. Standards Track [Page 20] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[20ページ]。
IPSP X IPSP Y
IPSP X IPSP Y
+-------------+ +-------------+
| | SCTP | |
| IPA | association 1 | IPB |
| port = PW +---------------+ port = PW |
| SLC = a | | SLC = a |
| | | |
| | | |
| | SCTP | |
| IPC | association 2 | IPD |
| port = PW +---------------+ port = PW |
| SLC = b | | SLC = b |
| | | |
| | | |
+-------------+ +-------------+
+-------------+ +-------------+ | | SCTP| | | IPA| 協会1| IPB| | ポートはPW+と等しいです。---------------+ ポート=PW| | SLCはaと等しいです。| | SLCはaと等しいです。| | | | | | | | | | | SCTP| | | IPC| 協会2| IPD| | ポートはPW+と等しいです。---------------+ ポート=PW| | SLCはbと等しいです。| | SLCはbと等しいです。| | | | | | | | | +-------------+ +-------------+
IPx = IP address
PW = Registered port number for M2PA
IPアドレスIPx=PWはM2PAのために登録されたポートナンバーと等しいです。
Figure 8. Two IPSPs with Two IP Addresses Each
エイト環。 それぞれ2つのIPアドレスがある2IPSPs
+-------------+---------------------------------------+-----+
| Association | IPSP X | IPSP Y | SLC |
| +------------+------+------------+------+ |
| | IP address | Port | IP address | Port | |
+=============+============+======+============+======+=====+
| 1 | IPA | PW | IPB | PW | a |
+-------------+------------+------+------------+------+-----+
| 2 | IPC | PW | IPD | PW | b |
+-------------+------------+------+------------+------+-----+
+-------------+---------------------------------------+-----+ | 協会| IPSP X| IPSP Y| SLC| | +------------+------+------------+------+ | | | IPアドレス| ポート| IPアドレス| ポート| | +=============+============+======+============+======+=====+ | 1 | IPA| PW| IPB| PW| a| +-------------+------------+------+------------+------+-----+ | 2 | IPC| PW| IPD| PW| b| +-------------+------------+------+------------+------+-----+
Table 1. Two IPSPs with Two IP Addresses Each
1を見送ってください。 それぞれ2つのIPアドレスがある2IPSPs
Figure 9 and Table 2 show an example with three IPSPs. Note that in this example, the two links are in different link sets. Therefore, it is possible that the SLC values a and b MAY be equal.
図9とTable2は3IPSPsと共に例を示しています。 異なったリンクセットに2個のリンクがこの例には、あることに注意してください。 したがって、SLC値aとbが等しいのは、可能です。
George, et al. Standards Track [Page 21] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[21ページ]。
IPSP X IPSP Y
IPSP X IPSP Y
+-------------+ +-------------+
| | SCTP | |
| IPA | association 1 | IPB |
| port = PW +---------------+ port = PW |
| SLC = a | | SLC = a |
| | | |
| | | |
| | SCTP | |
| IPC | association 2 | |
| port = PW +-------+ | |
| SLC = b | | | |
| | | | |
| | | | |
+-------------+ | +-------------+
|
|
| IPSP Z
|
| +-------------+
| | |
| | IPD |
+-------+ port = PW |
| SLC = b |
| |
| |
| |
| |
| |
| |
| |
| |
+-------------+
+-------------+ +-------------+ | | SCTP| | | IPA| 協会1| IPB| | ポートはPW+と等しいです。---------------+ ポート=PW| | SLCはaと等しいです。| | SLCはaと等しいです。| | | | | | | | | | | SCTP| | | IPC| 協会2| | | ポートはPW+と等しいです。-------+ | | | SLCはbと等しいです。| | | | | | | | | | | | | | +-------------+ | +-------------+ | | | IPSP Z| | +-------------+ | | | | | IPD| +-------+ ポート=PW| | SLCはbと等しいです。| | | | | | | | | | | | | | | | | +-------------+
IPx = IP address
PW = Registered port number for M2PA
IPアドレスIPx=PWはM2PAのために登録されたポートナンバーと等しいです。
Figure 9. One IPSP Connected to Two IPSPs
図9。 2IPSPsに接続された1IPSP
George, et al. Standards Track [Page 22] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[22ページ]。
+-------------+---------------------------------------+-----+
| Association | IPSP X | IPSP Y/Z | SLC |
| +------------+------+------------+------+ |
| | IP address | Port | IP address | Port | |
+=============+============+======+============+======+=====+
| 1 | IPA | PW | IPB | PW | a |
+-------------+------------+------+------------+------+-----+
| 2 | IPC | PW | IPD | PW | b |
+-------------+------------+------+------------+------+-----+
+-------------+---------------------------------------+-----+ | 協会| IPSP X| IPSP Y/Z| SLC| | +------------+------+------------+------+ | | | IPアドレス| ポート| IPアドレス| ポート| | +=============+============+======+============+======+=====+ | 1 | IPA| PW| IPB| PW| a| +-------------+------------+------+------------+------+-----+ | 2 | IPC| PW| IPD| PW| b| +-------------+------------+------+------------+------+-----+
Table 2. One IPSP Connected to Two IPSPs
2を見送ってください。 2IPSPsに接続された1IPSP
Figure 10 and Table 3 show two associations between the same IP addresses. This is accomplished by using different port numbers for each association at one endpoint.
図10とTable3は同じIPアドレスの間の2つの協会を示しています。 これは、1つの終点の各協会に異なったポートナンバーを使用することによって、達成されます。
IPSP X IPSP Y
IPSP X IPSP Y
+-------------+ +-------------+
| | SCTP | |
| IPA | association 1 | IPB |
| port = P1 +---------------+ port = PW |
| SLC = a | | SLC = a |
| | | |
| | | |
| | SCTP | |
| IPA | association 2 | IPB |
| port = PW +---------------+ port = PW |
| SLC = b | | SLC = b |
| | | |
| | | |
+-------------+ +-------------+
+-------------+ +-------------+ | | SCTP| | | IPA| 協会1| IPB| | ポートはP1+と等しいです。---------------+ ポート=PW| | SLCはaと等しいです。| | SLCはaと等しいです。| | | | | | | | | | | SCTP| | | IPA| 協会2| IPB| | ポートはPW+と等しいです。---------------+ ポート=PW| | SLCはbと等しいです。| | SLCはbと等しいです。| | | | | | | | | +-------------+ +-------------+
IPx = IP address
P1 = Pre-selected port number
PW = Registered port number for M2PA
IPアドレスIPx=P1=はM2PAのために登録されたポートナンバーPW=ポートナンバーを前選択しました。
Figure 10. Multiple Associations Between Two IP Addresses
図10。 2つのIPアドレスの間の複数の協会
George, et al. Standards Track [Page 23] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[23ページ]。
+-------------+---------------------------------------+-----+
| Association | IPSP X | IPSP Y | SLC |
| +------------+------+------------+------+ |
| | IP address | Port | IP address | Port | |
+=============+============+======+============+======+=====+
| 1 | IPA | P1 | IPB | PW | a |
+-------------+------------+------+------------+------+-----+
| 2 | IPA | PW | IPB | PW | b |
+-------------+------------+------+------------+------+-----+
+-------------+---------------------------------------+-----+ | 協会| IPSP X| IPSP Y| SLC| | +------------+------+------------+------+ | | | IPアドレス| ポート| IPアドレス| ポート| | +=============+============+======+============+======+=====+ | 1 | IPA| P1| IPB| PW| a| +-------------+------------+------+------------+------+-----+ | 2 | IPA| PW| IPB| PW| b| +-------------+------------+------+------------+------+-----+
Table 3. Multiple Associations Between Two IP Addresses
3を見送ってください。 2つのIPアドレスの間の複数の協会
The association SHALL contain two streams in each direction. Stream 0 is designated for Link Status messages. Stream 1 is designated for User Data messages, as well as Link Status messages that must remain in sequence with the User Data messages.
協会SHALLは各方向に2つの流れを含んでいます。 流れ0はLink Statusメッセージのために指定されます。 流れ1はUser Dataメッセージのために指定されます、User Dataメッセージで連続して残らなければならないLink Statusメッセージと同様に。
The following Link Status messages SHALL be sent on the Link Status stream (stream 0):
以下のLink StatusはSHALLを通信させます。Link Statusの流れ(流れ0)に送ってください:
- Alignment
- Proving Normal
- Proving Emergency
- Ready (when sent during alignment)
- Busy
- Busy Ended
- Out of Service
- 整列--Emergencyを立証するというNormalが準備ができていると(整列の間、送ると)立証するのが(忙しいです)ServiceからEndedと忙しくします。
The following Link Status messages SHALL be sent on the User Data stream (stream 1):
以下のLink StatusはSHALLを通信させます。User Dataの流れ(流れ1)に送ってください:
- Processor Outage
- Processor Recovered
- Ready (when sent at the end of processor outage)
- プロセッサ供給停止(回収されたプロセッサ)準備ができています。(プロセッサ供給停止の終わりに送ると)
4.1.3. Link Alignment
4.1.3. リンク整列
The purposes of the alignment procedure are:
整列手順の目的は以下の通りです。
(1) To provide a handshaking procedure so that both endpoints are
prepared to send SS7 traffic, and to prevent traffic from
being sent before the other end is ready.
両方の終点がSS7交通を送って、交通がもう一方の端の前に送られるのを防ぐように準備されるようにハンドシェイク手順を提供する(1)は準備ができています。
(2) To verify that the SCTP association is suitable for use as an
SS7 link.
(2) SCTP協会がSS7として使用に適していることを確かめるには、リンクしてください。
George, et al. Standards Track [Page 24] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[24ページ]。
Link alignment takes place after the association is established. If SCTP fails to establish the association, and M2PA has received a Start Request from its MTP3, then M2PA SHALL report to MTP3 that the link is out of service.
協会が設立された後にリンク整列は行われます。 SCTPが協会を設立しないで、M2PAがMTP3からStart Requestを受けたなら、M2PA SHALLは、リンクが使われなくなっているとMTP3に報告します。
The Link Status Out of Service message replaces the SIOS message of MTP2. Unlike MTP2, the message SHOULD NOT be transmitted continuously. After the association is established, M2PA SHALL send a Link Status Out of Service message to its peer. Prior to the beginning of alignment, M2PA MAY send additional Link Status Out of Service messages.
ServiceメッセージのLink Status OutはMTP2に関するSIOSメッセージを置き換えます。 SHOULD NOTを通信させてください。MTP2と異なって伝える、絶え間なく伝えられます。 協会が設立された後に、M2PA SHALLはServiceメッセージのLink Status Outを同輩に送ります。 整列の始まりの前に、M2PA MAYはServiceメッセージの追加Link Status Outを送ります。
The Link Status Alignment message replaces the SIO message of MTP2. This message is sent to signal the beginning of the alignment procedure. The Link Status Alignment message SHOULD NOT be transmitted continuously. M2PA MAY send additional Link Status Alignment until it receives Link Status Alignment, Link Status Proving Normal, or Link Status Proving Emergency from the peer.
Link Status AlignmentメッセージはMTP2に関するSIOメッセージを置き換えます。 整列手順の始まりに合図するためにこのメッセージを送ります。 Link Status AlignmentはSHOULD NOTを通信させます。絶え間なく伝えられます。 それが同輩からLink Status Alignment、Link Status Proving Normal、またはLink Status Proving Emergencyを受けるまで、M2PA MAYは追加Link Status Alignmentを送ります。
The Link Status Proving Normal message replaces the SIN message of MTP2. The Link Status Proving Emergency message replaces the SIE message of MTP2.
Link Status Proving NormalメッセージはMTP2に関するSINメッセージを置き換えます。 Link Status Proving EmergencyメッセージはMTP2に関するSIEメッセージを置き換えます。
The proving period MAY be omitted if this is allowed by the applicable MTP2 standard (e.g., [Q.2140]).
適切なMTP2規格(例えば、[Q.2140])によってこれが許容されているなら、立証の期間は省略されるかもしれません。
If proving is performed, then during the proving period (i.e., after M2PA starts the proving period timer T4), M2PA SHALL send Link Status Proving messages to its peer at an interval defined by the protocol parameter Proving_Interval. It is RECOMMENDED that Proving_Interval be set so that the traffic load generated with the Link Status Proving messages during the proving period is comparable to the normal traffic load expected when the link is in service.
立証が実行されるなら、立証の期間(すなわち、M2PAが立証の期間のタイマT4を始動した後に)、M2PA SHALLはプロトコルパラメタProving_Intervalによって定義された間隔で、同輩へのメッセージをLink Status Provingに送ります。 Proving_Intervalが用意ができているのが、RECOMMENDEDであるので、立証の期間、Link Status Provingメッセージで生成されたトラヒック負荷はリンクが使用中であるときに期待された正常なトラヒック負荷に匹敵しています。
The Link Status Ready message replaces the FISU of MTP2 that is sent at the end of the proving period. The Link Status Ready message is used to verify that both ends have completed proving. When M2PA starts timer T1, it SHALL send a Link Status Ready message to its peer in the case where MTP2 would send a FISU after proving is complete. If the Link Status Ready message is sent, then M2PA MAY send additional Link Status Ready messages while timer T1 is running. These Link Status Ready messages are sent on the Link Status stream.
Link Status Readyメッセージは立証の期間の終わりに送られるMTP2のFISUを取り替えます。 Link Status Readyメッセージは、両端が、立証するのを完了したことを確かめるのに使用されます。 いつM2PAはタイマT1を始動するか、それ。立証が完全になった後にSHALLはMTP2がFISUを送るところに場合における同輩にLink Status Readyメッセージを送ります。 Link Status Readyメッセージを送るなら、タイマT1が稼働している間、M2PA MAYは追加Link Status Readyメッセージを送ります。 Link StatusストリームでこれらのLink Status Readyメッセージを送ります。
In the case that MTP2 sends an MSU or SIPO message at the end of proving, M2PA SHALL send (respectively) a User Data or Link Status Processor Outage message.
MTP2がMSUかSIPOメッセージを立証の終わりに送って、M2PA SHALLはUser DataかLink Status Processor Outageメッセージを送ります(それぞれ)。
George, et al. Standards Track [Page 25] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[25ページ]。
4.1.4. Processor Outage
4.1.4. プロセッサ供給停止
The Link Status Processor Outage message replaces the SIPO message of MTP2. Unlike MTP2, the message SHOULD NOT be transmitted continuously. M2PA SHALL send a Link Status Processor Outage message to its peer at the beginning of a processor outage condition where MTP2 would send SIPO. M2PA MAY send additional Link Status Processor Outage messages as long as that condition persists. The Link Status Processor Outage message SHALL be sent on the User Data stream.
Link Status Processor OutageメッセージはMTP2に関するSIPOメッセージを置き換えます。 SHOULD NOTを通信させてください。MTP2と異なって伝える、絶え間なく伝えられます。 M2PA SHALLはMTP2がSIPOを送るプロセッサ供給停止状態の始めにLink Status Processor Outageメッセージを同輩に送ります。 その状態が持続している限り、M2PA MAYは追加Link Status Processor Outageメッセージを送ります。 Link Status Processor OutageはSHALLを通信させます。User Dataストリームでは、送ります。
While in a local processor outage (LPO) condition:
地方のプロセッサ供給停止(LPO)にはある間、以下を条件とさせてください。
(a) Any User Data messages received from the peer MUST NOT be
acknowledged and MUST be buffered.
(a) 同輩から受け取られたどんなUser Dataメッセージも、承認されてはいけなくて、バッファリングしなければなりません。
(b) M2PA SHOULD continue to acknowledge User Data messages
received and accepted by MTP3 before the local processor
outage.
(b) M2PA SHOULDは、地方のプロセッサ供給停止の前にMTP3によって受け取られて、受け入れられたUser Dataメッセージを承認し続けています。
(c) M2PA SHOULD continue to transmit messages that have been sent
by its upper layer MTP3.
(c) M2PA SHOULDは、MTP3の上側の層で送られたメッセージを送り続けています。
While there is a remote processor outage (RPO) condition:
リモートプロセッサ供給停止(RPO)がある間、以下を条件とさせてください。
(a) M2PA SHOULD continue to acknowledge User Data messages
received and accepted by MTP3, regardless of the remote
processor outage.
(a) M2PA SHOULDは、リモートプロセッサ供給停止にかかわらずMTP3によって受け取られて、受け入れられたUser Dataメッセージを承認し続けています。
(b) If any User Data messages received from the peer after the
Link Status Processor Outage cannot be delivered to MTP3, then
these messages MUST NOT be acknowledged and MUST be buffered.
(b) Link Status Processor OutageをMTP3に提供されなかったことができた後に何かUser Dataメッセージが同輩から受信されたなら、これらのメッセージを承認されなければならなくなくて、バッファリングしなければなりません。
If M2PA receives a Flush command from MTP3,
M2PAがFlushを受けるなら、MTP3から、命令してください。
(a) M2PA SHALL discard any incoming messages that were queued and
unacknowledged during the processor outage condition.
(a) M2PA SHALLはどんなプロセッサ供給停止状態の間列に並ばせられて、認められなかった入力メッセージも捨てます。
(b) M2PA SHALL discard messages in the transmit and retransmit
queues as required by MTP2.
(b)M2PA SHALLがメッセージを捨てる、必要に応じてMTP2で待ち行列を伝えて、再送してください。
If M2PA receives a Continue command from MTP3, M2PA SHALL begin processing the incoming messages that were queued and unacknowledged during the processor outage condition.
M2PAがMTP3からContinueコマンドを受け取るなら、M2PA SHALLはプロセッサ供給停止状態の間列に並ばせられて、認められなかった入力メッセージを処理し始めます。
When the local processor outage condition ends, M2PA SHALL send a Link Status Processor Recovered message to its peer on the User Data stream. This message is used to signal the end of the processor outage condition, instead of an MSU or FISU, as is used in MTP2. The
地方のプロセッサ供給停止状態が終わると、M2PA SHALLはUser DataストリームでLink Status Processor Recoveredメッセージを同輩に送ります。 このメッセージは、そのままなMSUかFISUの代わりにMTP2で使用されていた状態でプロセッサ供給停止状態の終わりに合図するのに使用されます。 The
George, et al. Standards Track [Page 26] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[26ページ]。
BSN in the Link Status Processor Recovered message is set to the FSN of the last User Data message received (and not discarded) from the peer M2PA. M2PA SHALL cease transmitting User Data messages after sending the Link Status Processor Recovered message, until it has received the Link Status Ready message (see below).
Link Status Processor RecoveredメッセージのBSNは同輩M2PAから受け取られた(そして、捨てられません)最後のUser DataメッセージのFSNに用意ができています。 M2PA SHALLは、Link Status Processor Recoveredメッセージを送った後にUser Dataメッセージを送るのをやめます、Link Status Readyメッセージを受け取るまで(以下を見てください)。
Upon receiving the Link Status Processor Recovered message, the M2PA in RPO SHALL respond with a Link Status Ready message on the User Data stream. The BSN in the Link Status Ready message is set to the FSN of the last User Data message received (and not discarded) from the peer M2PA.
Link Status Processor Recoveredメッセージを受け取ると、RPO SHALLのM2PAはUser Dataストリームに関するLink Status Readyメッセージで応じます。 Link Status ReadyメッセージのBSNは同輩M2PAから受け取られた(そして、捨てられません)最後のUser DataメッセージのFSNに用意ができています。
Upon receiving the Link Status Ready message, the M2PA formerly in LPO SHALL respond with a Link Status Ready message on the User Data stream. The BSN in the Link Status Ready message is set to the FSN of the last User Data message received (and not discarded) from the peer M2PA.
Link Status Readyメッセージを受け取ると、M2PAは以前、LPO SHALLでUser Dataストリームに関するLink Status Readyメッセージで応じます。 Link Status ReadyメッセージのBSNは同輩M2PAから受け取られた(そして、捨てられません)最後のUser DataメッセージのFSNに用意ができています。
M2PA (at both the LPO and RPO ends) uses the BSN value in the received Link Status Ready message to resynchronize its sequence numbers, if this is required by MTP2. M2PA SHALL NOT resume transmitting User Data messages until it has sent the Link Status Ready message.
M2PA(LPOとRPOエンドの両方の)は一連番号を再連動させる受信されたLink Status ReadyメッセージでBSN値を使用します、これがMTP2によって必要とされるなら。 M2PA SHALL NOTは、Link Status Readyメッセージを送るまでUser Dataメッセージを送るのを再開します。
During resynchronization, M2PA SHALL NOT discard any received User Data messages that were sent after the processor outage ended.
再同期の間、M2PA SHALL NOTはプロセッサ供給停止が終わった後に送られたどんな受信されたUser Dataメッセージも捨てます。
When M2PA experiences a local processor outage, it MAY put the link out of service by sending a Link Status Out of Service message, if this is allowed by the applicable MTP2 standard (e.g., [Q.2140]).
M2PAが地方のプロセッサ供給停止を経験するとき、ServiceメッセージのLink Status Outを送ることによって、リンクを動かなくするかもしれません、適切なMTP2規格(例えば、[Q.2140])によってこれが許容されているなら。
In other respects, M2PA SHOULD follow the same procedures as MTP2 in processor outage.
その他の点では、M2PA SHOULDはプロセッサ供給停止でMTP2と同じ手順に従います。
4.1.5. Level 2 Flow Control
4.1.5. レベル2 フロー制御
The Link Status Busy message replaces the SIB message of MTP2. The message SHOULD NOT be transmitted continuously. M2PA SHALL send a Link Status Busy message to its peer at the beginning of a receive congestion condition where MTP2 would send SIB. M2PA MAY send additional Link Status Busy messages as long as that condition persists. When the condition ends, M2PA SHALL send a Link Status Busy Ended message to its peer.
Link Status BusyメッセージはMTP2に関するSIBメッセージを置き換えます。 SHOULD NOTを通信させてください。絶え間なく伝えられます。 M2PA SHALLは始めにLink Status Busyメッセージを同輩に送ります。aでは、MTP2がSIBを送るところに混雑状態を受け取ってください。 その状態が持続している限り、M2PA MAYは追加Link Status Busyメッセージを送ります。 状態が終わると、M2PA SHALLはLink Status Busy Endedメッセージを同輩に送ります。
M2PA SHALL continue transmitting messages while it is in receive congestion, but MUST NOT acknowledge the message that triggered the sending of the Link Status Busy message, nor any messages received before the sending of Link Status Busy Ended.
M2PA SHALLは、Link Status Busyメッセージの発信の引き金となったメッセージ、およびLink Status Busy Endedの発信の前に受け取られたどんなメッセージも承認してはいけないのを除いて、混雑が中で受信するということである間、メッセージを送り続けています。
George, et al. Standards Track [Page 27] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[27ページ]。
When the peer M2PA receives the first Link Status Busy message, it SHALL start the Remote Congestion timer T6 if there are messages in the retransmission buffer awaiting acknowledgement (i.e., T7 is running). M2PA SHALL stop the T7 timer if it is running. Additional Link Status Busy messages received while T6 is running do not cause T6 to be reset and do not cause T7 to be started. While T6 is running, T7 SHALL NOT be started.
同輩であるときに、M2PAは最初のLink Status Busyメッセージを受け取ります、それ。承認を待って、「再-トランスミッション」バッファにメッセージがあれば、SHALLはRemote CongestionタイマT6を始動します(すなわち、T7は稼働する予定です)。 稼働する予定であるなら、M2PA SHALLはT7タイマを止めます。 T6が稼働している間に受け取られた追加Link Status BusyメッセージはT6がリセットされて、T7を始動させないことを引き起こしません。 T7 SHALL NOT、T6は稼働する予定です。始められます。
When the peer M2PA receives the Link Status Busy Ended message and T6 has not expired, it SHALL stop T6 (if T6 is running) and start T7 (if there are messages awaiting acknowledgement in the retransmission buffer).
同輩M2PAがいつLink Status Busy EndedメッセージとT6を受け取るかが期限が切れていなくて、それは、SHALL停止T6(T6が稼働する予定であるなら)とスタートT7(「再-トランスミッション」バッファに承認を待つメッセージがあれば)です。
The peer M2PA SHOULD continue receiving and acknowledging messages while the other end is busy, but MUST NOT send User Data messages after receiving Link Status Busy and before receiving Link Status Busy Ended.
同輩M2PA SHOULDが、受信し続けていて、もう一方の端である間、メッセージを承認するのは、忙しいのですが、Link Status Busyを受けた後とLink Status Busy Endedを受ける前に、メッセージをUser Dataに送ってはいけません。
4.1.6. Link Out of Service
4.1.6. 使われなくなっていた状態で、リンクしてください。
The Link Status Out of Service message replaces the SIOS message of MTP2. Unlike MTP2, the message SHOULD NOT be transmitted continuously. M2PA SHALL send a Link Status Out of Service message to its peer at the beginning of a condition where MTP2 would send SIOS. M2PA MAY send additional Link Status Out of Service messages as long as that condition persists.
ServiceメッセージのLink Status OutはMTP2に関するSIOSメッセージを置き換えます。 SHOULD NOTを通信させてください。MTP2と異なって伝える、絶え間なく伝えられます。 M2PA SHALLはMTP2がSIOSを送る状態の始めにServiceメッセージのLink Status Outを同輩に送ります。 その状態が持続している限り、M2PA MAYはServiceメッセージの追加Link Status Outを送ります。
When M2PA places a link in the OUT OF SERVICE state, M2PA SHOULD NOT terminate the SCTP association.
M2PAがOUT OF SERVICE状態にリンクを置くとき、M2PA SHOULD NOTはSCTP協会を終えます。
4.1.7. SCTP Association Problems
4.1.7. SCTP協会問題
The SCTP association for a link may become unusable, such as when one of the following occurs:
リンクへのSCTP協会は以下の1つが起こる時のように使用不可能になるかもしれません:
- SCTP sends a Send Failure notification to M2PA.
- SCTPはSend Failure通知をM2PAに送ります。
- SCTP sends a Communication Lost notification to M2PA.
- SCTPはCommunication Lost通知をM2PAに送ります。
- SCTP sends a Communication Error notification to M2PA.
- SCTPはCommunication Error通知をM2PAに送ります。
- The SCTP association is lost.
- SCTP協会は無くなっています。
If the SCTP association for a link becomes unable to transmit or receive messages, M2PA SHALL report to MTP3 that the link is out of service and enter the OUT OF SERVICE state.
リンクへのSCTP協会がメッセージを送るか、または受け取ることができないようになるなら、M2PA SHALLはリンクが使われなくなっているとMTP3に報告して、OUT OF SERVICE状態に入ります。
George, et al. Standards Track [Page 28] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[28ページ]。
4.1.8. Transmission and Reception Priorities
4.1.8. トランスミッションとレセプションプライオリティ
In MTP, Link Status messages have priority over User Data messages ([Q.703], Section 11.2). To achieve this in M2PA, M2PA uses separate streams in its SCTP association for Link Status messages and User Data messages.
MTPでは、Link StatusメッセージはUser Dataメッセージ([Q.703]、セクション11.2)より優先権を持っています。 M2PAでこれを達成するために、M2PAはLink StatusメッセージとUser DataメッセージにSCTP協会で別々のストリームを使用します。
M2PA SHALL send all messages using the ordered delivery option of SCTP.
M2PA SHALLは、SCTPの規則正しい配送オプションを使用することですべてのメッセージを送ります。
M2PA SHOULD give higher priority to messages sent on the Link Status stream than to messages sent on the User Data stream when sending messages to SCTP.
メッセージをSCTPに送るとき、M2PA SHOULDはLink Statusストリームで送られたメッセージのUser Dataストリームで送られたメッセージより高い優先を与えます。
M2PA SHOULD give higher priority to reading the Link Status stream than to reading the User Data stream.
M2PA SHOULDはLink Statusストリームを読むUser Dataストリームを読むより高い優先を与えます。
M2PA SHOULD give higher priority to receiving notifications from SCTP than to reading either the Link Status stream or the User Data stream.
M2PA SHOULDはSCTPから通知を受け取るLink StatusストリームかUser Dataストリームのどちらかを読むより高い優先を与えます。
4.1.9. M2PA Version Control
4.1.9. M2PAバージョンコントロール
A node upgraded to a newer version of M2PA SHOULD support the older versions used on other nodes with which it is communicating. If that is the case, then alignment can proceed normally.
ノードはそれが交信する予定である他のノードの上で使用される旧式のバージョンをM2PA SHOULDサポートの、より新しいバージョンに上げました。 それがそうであるなら、通常、整列は続くことができます。
In particular, it is recommended that for future modifications to this protocol:
特に、それはこのプロトコルへの今後の変更のためにそれに推薦されます:
- Any newer version SHOULD be able to process the messages from an
older version.
- どんなより新しいバージョンSHOULD、も旧式のバージョンからメッセージを処理できてください。
- A newer version of M2PA SHOULD refrain from sending messages to
an older version of M2PA messages that the older version cannot
process.
- 送付メッセージから旧式のバージョンが処理されることができないというM2PAメッセージの旧式のバージョンまでのM2PA SHOULDリフレインの、より新しいバージョン。
- If an older version of M2PA receives a message that it cannot
process, it SHOULD discard the message.
- M2PAの旧式のバージョンがメッセージを受け取るなら、処理できないで、SHOULDであることはメッセージを捨てます。
- In cases where different processing is done in two versions for
the same format of a message, then the newer version SHOULD
contain procedures to recognize and handle this appropriately.
- そして、異なった処理がメッセージの同じ形式のための2つのバージョンで行われる場合では、より新しいバージョンSHOULDは適切にこれを認識して、扱う手順を含んでいます。
In case a newer version of M2PA is incompatible with an older version, the newer version SHOULD recognize this and prevent the alignment of the link. If a Link Status Alignment message with an
M2PAの、より新しいバージョンが旧式のバージョンと両立しないといけないので、より新しいバージョンSHOULDはこれを認識して、リンクの整列を防ぎます。 a Link Status Alignmentは通信します。
George, et al. Standards Track [Page 29] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[29ページ]。
unsupported version is received by the newer version, the receiving end's M2PA SHOULD reply with a Link Status Out of Service message and not complete the alignment procedure.
より新しいバージョンでサポートされないバージョンを受け取って、犠牲者のM2PA SHOULDはServiceメッセージのLink Status Outと共に返答して、整列手順を完了しません。
4.2. Procedures to Support the MTP3/MTP2 Interface
4.2. MTP3/MTP2インタフェースをサポートする手順
4.2.1. Sending and Receiving Messages
4.2.1. メッセージの送受信
When MTP3 sends a message for transmission to M2PA, M2PA passes the corresponding M2PA message to SCTP using the SEND primitive.
MTP3がM2PAへの伝送のためメッセージを送るとき、M2PAは、原始的にSENDを使用することで対応するM2PAメッセージをSCTPに通過します。
User Data messages SHALL be sent via the User Data stream (stream 1) of the association.
ユーザDataはSHALLを通信させます。協会のUser Dataの流れ(ストリーム1)で、送ってください。
M2PA Link Status messages are passed to SCTP using the SEND primitive.
M2PA Link Statusメッセージは、原始的にSENDを使用することでSCTPに通過されます。
The following Link Status messages SHALL be sent on the Link Status stream (stream 0):
以下のLink StatusはSHALLを通信させます。Link Statusストリーム(ストリーム0)で送ってください:
- Alignment
- Proving Normal
- Proving Emergency
- Ready (when sent during alignment)
- Busy
- Busy Ended
- Out of Service
- 整列--Emergencyを立証するというNormalが準備ができていると(整列の間、送ると)立証するのが(忙しいです)ServiceからEndedと忙しくします。
The following Link Status messages SHALL be sent on the User Data stream (stream 1):
以下のLink StatusはSHALLを通信させます。User Dataストリーム(ストリーム1)で送ってください:
- Processor Outage
- Processor Recovered
- Ready (when sent at the end of processor outage)
- プロセッサ供給停止(回収されたプロセッサ)準備ができています。(プロセッサ供給停止の終わりに送ると)
If M2PA receives a message from SCTP with an invalid Message Class or unsupported Message Type in the Common Message Header, M2PA SHALL discard the message.
M2PAがCommon Message Headerの無効のMessage ClassかサポートされないMessage Typeと共にSCTPからメッセージを受け取るなら、M2PA SHALLはメッセージを捨てます。
For message types other than User Data, the Forward Sequence Number is set to the FSN of the last User Data message sent.
User Data以外のメッセージタイプにおいて、Forward Sequence NumberはUser Dataメッセージが送った最終FSNに用意ができています。
If M2PA receives a User Data message with an FSN that is out of order, M2PA SHALL discard the message.
M2PAが故障しているFSNと共にUser Dataメッセージを受け取るなら、M2PA SHALLはメッセージを捨てます。
Note: In all calculations involving FSN and BSN, the programmer should be aware that the value wraps around to 0 after reaching its maximum value.
以下に注意してください。 FSNとBSNにかかわるすべての計算をプログラマは最大値に達した後に値が0に巻きつけられるのを意識しているべきです。
George, et al. Standards Track [Page 30] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[30ページ]。
When there is a message to acknowledge, M2PA MUST acknowledge the message with the next User Data message sent. If there is no User Data message available to be sent when there is a message to acknowledge, M2PA SHOULD generate and send a User Data message with no data payload, without delay. (In other words, in the case where MTP2 would acknowledge a message with a FISU, M2PA SHOULD acknowledge the message with an empty User Data message.) The FSN for this empty User Data message is not incremented. It MUST contain the same FSN as the most recently sent User Data message that contains data. Delaying of acknowledgements can result in poor SS7 performance.
承認するメッセージがあるとき、M2PA MUSTは次のUser Dataメッセージを送ってメッセージを承認します。 承認するメッセージがあるとき、送るために利用可能などんなUser Dataメッセージもなければ、M2PA SHOULDはデータペイロードなしでUser Dataメッセージを即刻生成して、送ります。 (言い換えれば、MTP2がFISUがあるメッセージを承認する場合では、M2PA SHOULDは空のUser Dataメッセージがあるメッセージを承認します。) この空のUser DataメッセージのためのFSNは増加されていません。 それはデータを含む最も最近送られたUser Dataメッセージと同じFSNを含まなければなりません。 承認の延着は不十分なSS7性能をもたらすことができます。
If M2PA receives an empty User Data message, it SHALL NOT send an acknowledgement of that message.
M2PAは空のUser Dataメッセージを受け取って、それはSHALL NOTです。そのメッセージの承認を送ってください。
Note that there is no reason to place Link Status messages or empty User Data messages in the M2PA retransmit buffer, since these messages are not retrieved for changeover and timer T7 does not apply to them.
Link Statusメッセージを置く理由が全くないか、またはM2PAの空のUser Dataメッセージがバッファを再送することに注意してください、これらのメッセージが転換のために検索されないで、またタイマT7がそれらに申し込まないので。
Note that since SCTP provides reliable delivery and ordered delivery within the stream, M2PA does not perform retransmissions. Nevertheless, M2PA SHALL retain transmitted User Data messages in a retransmit queue until they are acknowledged. These messages are needed in case MTP3 performs data retrieval as part of a changeover procedure.
SCTPがストリームの中で信頼できる配信と命令された配送を提供するのでM2PAが「再-トランスミッション」を実行しないことに注意してください。 それにもかかわらず、それらが承認されるまで、M2PA SHALLは再送キューにおける伝えられたUser Dataメッセージを保有します。 MTP3が転換手順の一部としてデータの検索を実行するといけないので、これらのメッセージが必要です。
Because propagation delays in IP networks are more variable than in traditional SS7 networks, a single T7 timer (excessive delay of acknowledgement), as in MTP2, is inadequate. If any message is unacknowledged after a period equal to the T7 value, the T7 timer SHALL expire.
IPネットワークの伝播遅延が伝統的なSS7ネットワークより可変であるので、単一のT7タイマ(承認の過度の遅れ)はMTP2のように不十分です。 何かメッセージがT7値と等しい期間の後に認められないなら、T7タイマSHALLは期限が切れます。
4.2.2. MTP3 Signaling Link Congestion
4.2.2. MTP3シグナリングリンク混雑
M2PA SHALL detect transmit congestion in its buffers according to the requirements for signaling link transmit congestion in MTP3, e.g., Q.704 [Q.704], Section 3.8.
M2PA SHALLが検出する、シグナリングリンクがMTP3、例えば、Q.704[Q.704](セクション3.8)で混雑を伝えるので、要件に従って、バッファにおける混雑を伝えてください。
4.2.3. Changeover
4.2.3. 転換
The objective of the changeover is to ensure that signaling traffic carried by the unavailable signaling link is diverted to the alternative signaling link(s) as quickly as possible while avoiding message loss, duplication, or mis-sequencing. For this purpose, the changeover procedure includes data retrieval, which is performed before opening the alternative signaling links to the diverted traffic. Data retrieval consists of these steps:
転換の目的は入手できないシグナリングリンクによって運ばれたシグナリングトラフィックがメッセージの損失、複製、または誤配列を避けている間にできるだけはやくリンクを示す代替手段に紛らされるのを保証することです。 このために、転換手順はデータの検索を含んでいます。(紛らされたトラフィックへのリンクを示す代替手段を開く前に、それは、実行されます)。 データの検索はこれらのステップから成ります:
George, et al. Standards Track [Page 31] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[31ページ]。
(1) buffer updating, i.e., identifying all those User Data
messages in the retransmission buffer of the unavailable
signaling link which have not been received by the far end
M2PA, as well as untransmitted messages, and
そして(1) すなわち、遠端M2PAによって受け取られて、メッセージを「非-伝え」ていない入手できないシグナリングリンクに関する「再-トランスミッション」バッファのそれらのすべてのUser Dataメッセージを特定しながらアップデートをバッファリングしてください。
(2) transferring those messages to the transmission buffers of the
alternate links.
(2) 補欠のトランスミッションバッファにそれらのメッセージを移すのはリンクされます。
Note that only User Data messages containing data are retrieved and transmitted over the alternate links. Link Status messages and empty User Data messages SHALL NOT be retrieved and transmitted over the alternate links.
データを含むUser Dataメッセージだけが代替のリンクの上に検索されて、送られることに注意してください。 代替のリンクの上に検索されて、送られたStatusメッセージと空のUser DataメッセージSHALL NOTをリンクしてください。
M2PA's Sequence Numbers are 24 bits long. MTP2's Forward and Backward Sequence Numbers are only seven bits long. Hence, it is necessary for MTP3 to accommodate the larger sequence numbers. This is done through the use of the Extended Changeover Order (XCO) and Extended Changeover Acknowledgement (XCA) messages instead of the Changeover Order (COO) and Changeover Acknowledgement (COA) messages. The XCO and XCA messages are specified in [Q.2210] Section 9.8.1 and T1.111.4 [T1.111], Section 15.4. Only the XCO and XCA messages from [Q.2210] or [T1.111] are required. The BSN is placed in the XCO/XCA message as explained in [Q.2210] and [T1.111].
M2PAのSequence民数記は長さ24ビットです。 MTP2のForwardとBackward Sequence民数記は長さ7ビットであるだけです。 したがって、MTP3が、より大きい一連番号を収容するのが必要です。 Changeover Order(最高運営責任者)とChangeover Acknowledgement(COA)メッセージの代わりにExtended Changeover Order(XCO)とExtended Changeover Acknowledgement(XCA)メッセージの使用でこれをします。 XCOとXCAメッセージは[Q.2210]セクション9.8.1とT1.111.4[T1.111]、セクションで15.4に指定されます。 [Q.2210]か[T1.111]からのXCOとXCAメッセージだけが必要です。 BSNは[Q.2210]と[T1.111]で説明されるようにXCO/XCAメッセージに置かれます。
Also, the following MTP3/MTP2 primitives MUST use the larger sequence numbers:
また、以下のMTP3/MTP2基関数は、より大きい一連番号を使用しなければなりません:
- BSNT Confirmation
- BSNT確認
- Retrieval Request and FSNC
- 検索要求とFSNC
If M2PA receives a Retrieval Request and FSNC request from MTP3, M2PA SHALL retrieve from its buffers and deliver to MTP3 in order:
M2PAがMTP3からRetrieval RequestとFSNC要求を受け取るなら、M2PA SHALLはMTP3に整然とした状態でバッファから検索して、配送します:
(a) any transmitted User Data messages beginning with the first
unacknowledged message with FSN greater than FSNC.
(a) いずれもFSNがFSNCよりすばらしい状態で最初の不承認のメッセージで始まるUser Dataメッセージを送りました。
(b) any untransmitted User Data messages.
(b) どんなuntransmitted User Dataメッセージ。
For emergency changeover, MTP3 retrieves only the unsent messages for transmission on the alternate link(s). If M2PA receives a Retrieval Request and FSNC request with no FSNC value, or with an invalid FSNC, then M2PA SHALL retrieve from its buffers and deliver to MTP3 in order:
非常時の転換のために、MTP3は代替のリンクの上にトランスミッションへのunsentメッセージだけを検索します。 M2PAがFSNC値のはない無効のFSNCとのRetrieval RequestとFSNC要求を受け取るなら、M2PA SHALLはMTP3に整然とした状態でバッファから検索して、配送します:
(a) any untransmitted User Data messages.
(a) どんなuntransmitted User Dataメッセージ。
George, et al. Standards Track [Page 32] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[32ページ]。
The Japanese TTC version of MTP defined in [JT-Q703] and [JT-Q704] has a Retrieval Request (as well as Retrieval Request and FSNC). The Retrieval allows MTP3 to retrieve both unsent and unacknowledged messages for transmission on the alternate link(s). In this version of MTP, if M2PA receives a Retrieval Request, then M2PA SHALL retrieve from its buffers and deliver to MTP3 in order:
[JT-Q703]と[JT-Q704]で定義されたMTPの日本のTTCバージョンには、Retrieval Request(Retrieval RequestとFSNCと同様に)があります。 RetrievalはMTP3に代替のリンクの上にトランスミッションのためのunsentと不承認のメッセージの両方を検索させます。 MTPのこのバージョンでは、M2PAがRetrieval Requestを受けるなら、M2PA SHALLはMTP3に整然とした状態でバッファから検索して、果たします:
(a) any transmitted but unacknowledged User Data messages.
(a) どんな伝えられましたが、不承認のUser Dataメッセージ。
(b) any untransmitted User Data messages.
(b) どんなuntransmitted User Dataメッセージ。
4.2.3.1. Multiple User Data Streams and Changeover
4.2.3.1. 複数のユーザデータ・ストリームと転換
The changeover procedure makes it problematic for M2PA to have multiple User Data streams in one direction for a link. Buffer updating would have to be done separately for each User Data stream to avoid duplication or loss of messages. But MTP3 provides for only one XCO/XCA message for sending the last-received sequence number.
転換手順で、M2PAが複数のUser Dataストリームを一方向に持っているのがリンクのために問題が多くなります。 それぞれのUser Dataストリームがメッセージの複製か損失を避けるように、別々にバッファアップデートをしなければならないでしょう。 しかし、MTP3は最後容認された一連番号を送ることへの1つのXCO/XCAメッセージだけに備えます。
Even with sequence numbering of User Data messages at the M2PA layer, it is necessary to perform buffer updating on each stream. Since the M2PA messages would be delivered over multiple streams, there could be a gap in the M2PA sequence numbers at the receiving end when the changeover procedure begins. If only the M2PA sequence number is used in the XCO/XCA message, there would be a possibility of losing the messages in the gap, or duplicating messages after the gap.
M2PA層のUser Dataメッセージの系列付番があっても、各ストリームでのバッファアップデートを実行するのが必要です。 M2PAメッセージは複数のストリームの上に提供されるでしょう、したがって、転換手順が始まる犠牲者に、M2PA一連番号にはギャップがあるかもしれません。 M2PA一連番号だけがXCO/XCAメッセージで使用されるなら、ギャップでメッセージを失うか、またはギャップの後にメッセージをコピーする可能性があるでしょう。
M2PA links with multiple User Data streams would be possible if a multiple-BSNT XCO/XCA message is defined in MTP3, or if MTP3 allows multiple XCO/XCA messages (one for each User Data stream) to be sent during a changeover. This is beyond the scope of this document.
複数のBSNT XCO/XCAメッセージがMTP3で定義されるか、またはMTP3が複数の転換の間に送られるべきXCO/XCAメッセージ(それぞれのUser Dataストリームあたり1つ)を許容するなら、複数のUser DataストリームとのM2PAリンクは可能でしょう。これはこのドキュメントの範囲を超えています。
4.3. SCTP Considerations
4.3. SCTP問題
Some M2PA procedures may be affected by the use of SCTP as a transport layer. These considerations are discussed in this section.
いくつかのM2PA手順がトランスポート層としてSCTPの使用で影響を受けるかもしれません。 このセクションでこれらの問題について議論します。
4.3.1. SCTP Slow Start
4.3.1. SCTP遅れた出発
SCTP contains a slow start algorithm to control the amount of data being injected into the network. The algorithm allows SCTP to probe the network to determine the available capacity. The algorithm is invoked in these cases: when transmission begins on an association, after a sufficiently long idle period, or after repairing loss detected by the SCTP retransmission timer.
SCTPはネットワークに注がれるデータの量のコントロールに遅れた出発アルゴリズムを含んでいます。 アルゴリズムで、SCTPは、有効な容量を測定するためにネットワークを調べることができます。 アルゴリズムはこれらの場合で呼び出されます: 十分長い活動していない期間の後、またはトランスミッションが協会で始まるか、またはSCTP再送信タイマーによって検出された損失を修理した後に。
George, et al. Standards Track [Page 33] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[33ページ]。
It is possible that transmission of M2PA messages MAY be delayed by SCTP slow start under certain conditions, including the following:
M2PAメッセージの伝達がSCTP遅れた出発で一定の条件の下で遅れるのは、可能です、以下を含んでいて:
(a) Link Alignment. Link alignment takes place after an
association is established. SCTP invokes the slow start
algorithm since transmission is beginning on the association.
(a) 整列をリンクしてください。 協会が設立された後にリンク整列は行われます。 トランスミッションが協会で始まっているので、SCTPは遅れた出発アルゴリズムを呼び出します。
(b) Changeover. Messages are retrieved from one link
(association) and transferred to another for transmission. If
the second link had previously been idle, or is in the process
of link alignment, SCTP may invoke the slow start algorithm.
(b)転換メッセージを1個のリンク(協会)から検索して、トランスミッションのために別のものに移します。 2番目のリンクが以前に、活動していないか、またはリンク整列の途中に活動していなかったなら、SCTPは遅れた出発アルゴリズムを呼び出すかもしれません。
(c) Path failure (multi-homing). If SCTP switches from a failed
path to a new path, and the new path had previously been idle,
SCTP may invoke the slow start algorithm.
(c) 経路失敗(マルチホーミング)。 SCTPが失敗した経路から新しい経路に切り替わって、新しい経路が以前に活動していなかったなら、SCTPは遅れた出発アルゴリズムを呼び出すかもしれません。
(d) Reduced traffic volume. Any time that M2PA sends a low volume
of traffic on a link and then the volume increases, SCTP may
invoke the slow start algorithm.
(d) 減少している交通量。 M2PAが低交通量をリンクに送って、次に、ボリュームが増加する何時でも、SCTPは遅れた出発アルゴリズムを呼び出すかもしれません。
Programmers should be aware of this condition and how it may affect M2PA performance. In some cases, it may be possible to avoid the negative effects of slow start. For example, the Link Status Proving messages sent during the proving period may be used to complete slow start before the link is placed in service.
プログラマはこの状態とそれがどうM2PA性能に影響するかもしれないかを知っているべきです。 いくつかの場合、遅れた出発のマイナスの効果を避けるのは可能であるかもしれません。 例えば、立証の期間、送られたLink Status Provingメッセージは、リンクが使用中の状態で置かれる前に遅れた出発を終了するのに使用されるかもしれません。
5. Examples of M2PA Procedures
5. M2PA手順に関する例
In general, messages passed between MTP3 and M2PA are the same as those passed between MTP3 and MTP2. M2PA interprets messages from MTP3 and sends the appropriate message to SCTP. Likewise, messages from SCTP are used to generate a meaningful message to MTP3.
一般に、MTP3とM2PAの間で通過されたメッセージはそれらがMTP3とMTP2の間を通ったのと同じです。 M2PAはMTP3からメッセージを解釈して、適切なメッセージをSCTPに送ります。 同様に、SCTPからのメッセージは、重要なメッセージをMTP3に生成するのに使用されます。
Note that throughout this section, the primitives between MTP3 and M2PA are named using the MTP terminology [Q.700] [Q.701] [Q.702] [Q.703] [Q.704] [Q.705]. Communications between M2PA and SCTP are named using SCTP terminology.
このセクション中では、MTP3とM2PAの間の基関数がMTP用語[Q.700][Q.701][Q.702][Q.703][Q.704][Q.705]を使用すると命名されることに注意してください。 M2PAとSCTPとのコミュニケーションはSCTP用語を使用すると命名されます。
5.1. Link Initialization (Alignment)
5.1. リンク初期設定(整列)
An example of the message flow used to bring an SS7 link in service is shown in Figures 11 and 12. Alignment is done by both ends of the link. To simplify the diagram, alignment is shown on one end only. Some messages from the remote end are not shown. It is assumed in this example that SCTP has been initialized.
流れが使用中の状態でSS7リンクを持って来るのに使用したメッセージに関する例は図11と12に示されます。 リンクの両端で、整列します。 ダイヤグラムを簡素化するために、整列は片端だけに示されます。 リモートエンドからのいくつかのメッセージは示されません。 この例では、SCTPが初期化されたと思われます。
George, et al. Standards Track [Page 34] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[34ページ]。
MTP3 M2PA SCTP SCTP M2PA MTP3
---- ---- ---- ---- ---- ----
. . . . . .
. Associate . . . .
. ------------> . . .
. . . . . .
. . (SCTP Association . .
. . procedure) . .
. . . . . .
. Communication Up Communication Up .
. <------------ ------------> .
. . . . . .
. Link Status Out of Service . .
. ------------------------------------> .
. . . . . .
Emergency OR . . . .
Emergency Ceases . . . .
------------> . . . .
. . . . . .
Start . . . . .
------------> . . . .
. . . . . .
. . . . . .
. Link Status Alignment . . .
. ------------------------------------> .
. . . . . .
. Start timer T2 . . .
. . . . . .
. . . Link Status Alignment .
. <------------------------------------ .
. . . . . .
. Stop timer T2 . . .
. . . . . .
MTP3 M2PA SCTP SCTP M2PA MTP3---- ---- ---- ---- ---- ---- . . . . . . . 交際してください…------------>… (SCTP Association… 手順)………Communication Up Communication Up<。------------ ------------>… 使われなくなっていた状態で状態をリンクしてください…------------------------------------>……. 非常時がやめる非常時か……------------>… 始まってください…------------>… 状態整列をリンクしてください…------------------------------------>… T2…………Link Status Alignmentタイマ<を始動してください。------------------------------------ . . . . . . . . タイマT2を止めてください…
Proving period begins.
以上と立証するのが始まります。
Figure 11. Example: Link Initialization - Alignment
図11。 例: リンク初期設定--整列
George, et al. Standards Track [Page 35] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[35ページ]。
MTP3 M2PA SCTP SCTP M2PA MTP3
---- ---- ---- ---- ---- ----
. . . . . .
. Start timer T3 . . .
. Link Status Proving . . .
. ------------------------------------> .
. . . . . .
. . . Link Status Proving .
. <------------------------------------ .
. . . . . .
. Stop timer T3 . . .
. . . . . .
. Start timer T4 . . .
. Link Status Proving . . .
. ------------------------------------> .
. ------------------------------------> .
. ------------------------------------> .
. ------------------------------------> .
. ------------------------------------> .
. ------------------------------------> .
. . . . . .
. Timer T4 expires . . .
. . . . . .
MTP3 M2PA SCTP SCTP M2PA MTP3---- ---- ---- ---- ---- ---- . . . . . . . タイマT3を始動してください… Status Provingをリンクしてください…------------------------------------>… リンク状態立証<。------------------------------------ . . . . . . . . タイマT3を止めてください… タイマT4を始動してください… Status Provingをリンクしてください…------------------------------------>。------------------------------------>。------------------------------------>。------------------------------------>。------------------------------------>。------------------------------------>… タイマT4は期限が切れます…
Send Link Status Ready (one or more) and wait for the remote end
to complete its proving period.
Link Status Ready(1以上)を送ってください、そして、リモートエンドが、以上と立証するのを完了するのを待ってください。
. . . . . .
. Start timer T1 . . .
. . . . . .
. Link Status Ready . . .
. ------------------------------------> .
. . . . . .
. . . . . .
. . . Link Status Ready .
. <------------------------------------ .
. . . . . .
. Stop timer T1 . . .
. . . . . .
In Service . . In Service
<------------ . . ------------>
. . . . . .
…… タイマT1を始動してください… Status Readyをリンクしてください…------------------------------------>… 準備ができていた状態で状態をリンクしてください、<。------------------------------------ . . . . . . . . 停止タイマ、T1………In ServiceコネService<。------------ . . ------------>……
MTP3 MAY begin sending data messages.
MTP3 MAYはデータメッセージを送り始めます。
Figure 12. Example: Link Initialization - Proving
図12。 例: リンク初期設定--立証
George, et al. Standards Track [Page 36] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[36ページ]。
5.2. Message Transmission and Reception
5.2. メッセージ送信とレセプション
Messages are transmitted using the Data Request primitive from MTP3 to M2PA. Figure 13 shows the case where the Link is In Service. The message is passed from MTP3 of the source to MTP3 of the destination.
メッセージは、MTP3からM2PAまでの原始のData Requestを使用することで送られます。 図13は、LinkがどこのIn Serviceであるかをケースに示します。 メッセージはソースのMTP3から目的地のMTP3まで通過されます。
MTP3 M2PA SCTP SCTP M2PA MTP3
---- ---- ---- ---- ---- ----
. . . . . .
Message for . . . .
transmission . . . .
------------> . . . .
. . . . . .
. Send . . . .
. (Data Message) . . .
. ------------> . . .
. . . . . .
. . (SCTP sends message) . .
. . . . . .
. . . Receive .
. . . ------------> .
. . . . . .
. . . . Received message
. . . . ------------>
. . . . . .
MTP3 M2PA SCTP SCTP M2PA MTP3---- ---- ---- ---- ---- ---- . . . . . . …には. トランスミッションを通信させてください…------------>… 発信してください… (データメッセージ)…------------>… (SCTPはメッセージを送ります)… 受信してください…------------>… メッセージを受け取ります…------------>……
Figure 13. Example: Link Initialization - In Service
図13。 例: サービスにおけるリンク初期設定
5.3. Link Status Indication
5.3. リンク状態指示
An example of a Link Status Indication is shown in Figure 14. If SCTP sends a Communication Lost primitive to M2PA, M2PA notifies MTP3 that the link is out of service. MTP3 responds in its usual way.
Link Status Indicationに関する例は図14に示されます。 SCTPがM2PAへの原始のCommunication Lostを送るなら、M2PAは、リンクが使われなくなっているようにMTP3に通知します。 MTP3はいつものように応じます。
MTP3 M2PA SCTP SCTP M2PA MTP3
---- ---- ---- ---- ---- ----
. . . . . .
. Communication Lost . . .
. <------------ . . .
. . . . . .
Out of Service . . . .
<------------ . . . .
. . . . . .
MTP3 M2PA SCTP SCTP M2PA MTP3---- ---- ---- ---- ---- ---- . . . . . . . 失われたコミュニケーション… <。------------ . . . . . . . . . 使われなくなっている. …<。------------ . . . . . . . . . .
Figure 14. Example: Link Status Indication
図14。 例: リンク状態指示
George, et al. Standards Track [Page 37] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[37ページ]。
5.4. Link Status Message (Processor Outage)
5.4. リンクステータスメッセージ(プロセッサ供給停止)
Figure 15 shows how M2PA responds to a local processor outage. M2PA sends a Link Status message to its peer. The peer M2PA notifies MTP3 of the outage. MTP3 can then follow the processor outage procedures as in [Q.703].
図15はM2PAがどう地方のプロセッサ供給停止に応じるかを示しています。 M2PAはLink Statusメッセージを同輩に送ります。 同輩M2PAは供給停止についてMTP3に通知します。 そして、MTP3は[Q.703]のようにプロセッサ供給停止手順に従うことができます。
MTP3 M2PA SCTP SCTP M2PA MTP3
---- ---- ---- ---- ---- ----
. . . . . .
. M2PA detects . . . .
. Local Processor . . . .
. Outage . . . .
. . . . . .
. Link Status . . . .
. Processor Outage . . .
. ------------------------------------> .
. . . . . .
. . . . Remote Processor
. . . . Outage .
. . . . ------------>
. . . . . .
. Link Status . . .
. Processor . . .
. Recovered . . .
. ------------------------------------> .
. . . . . .
. . . . Remote Processor
. . . . Outage Ceases
. . . . ------------>
. . . . . .
. . . Link Status Ready .
. <------------------------------------ .
. . . . . .
. Link Status Ready . . .
. ------------------------------------> .
. . . . . .
Message for . . . .
transmission . . . .
------------> . . . .
. . . . . .
. User Data . . .
. ------------------------------------> .
. . . . . .
MTP3 M2PA SCTP SCTP M2PA MTP3---- ---- ---- ---- ---- ---- . . . . . . . M2PAは…を検出します。地方のProcessor… 供給停止… Status…プロセッサOutageを…リンクしてください。------------------------------------>… リモートプロセッサ…供給停止…。------------>… リンク状態… プロセッサ… 回復されます…------------------------------------>… リモートプロセッサ…供給停止はやみます…------------>… 準備ができていた状態で状態をリンクしてください、<。------------------------------------ . . . . . . . . 準備ができていた状態で状態をリンクしてください…------------------------------------>… …には. トランスミッションを通信させてください…------------>… 利用者データ…。------------------------------------>……。
Figure 15. Example: Link Status Message - Processor Outage
図15。 例: リンクステータスメッセージ--プロセッサ供給停止
George, et al. Standards Track [Page 38] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[38ページ]。
Figure 16 shows an example of processor outage in more detail. All M2PA messages in this example are sent on the Data stream (stream 1).
図16はさらに詳細にプロセッサ供給停止に関する例を示しています。 Dataの流れ(流れ1)にこの例のすべてのM2PAメッセージを送ります。
A B
---------------------------- ----------------------------
B---------------------------- ----------------------------
MTP3 M2PA SCTP SCTP M2PA MTP3
---- ---- ---- ---- ---- ----
. . . . . .
6 Messages for . . . .
transmission . . . .
------------> . . 6 Messages for
. . . . transmission
. . . . <------------
. User Data FSN=1 . . .
. ------------------------------------> .
. User Data FSN=2 . . .
. ------------------------------------> .
. User Data FSN=3 . . .
. ------------------------------------> .
. . . User Data FSN=11 .
. <------------------------------------ .
. . . User Data FSN=12 .
. <------------------------------------ .
. . . User Data FSN=13 .
. <------------------------------------ .
MTP3 M2PA SCTP SCTP M2PA MTP3---- ---- ---- ---- ---- ---- . . . . . . 6 …のために. トランスミッションを通信させます…------------. トランスミッション……<への>. . 6メッセージ------------ . 利用者データFSN=1…------------------------------------>利用者データFSN=2…------------------------------------>利用者データFSN=3…------------------------------------>… 利用者データFSN=11<。------------------------------------ . . . . 利用者データFSN=12<。------------------------------------ . . . . 利用者データFSN=13<。------------------------------------ .
Side A detects LPO.
側AはLPOを検出します。
. . . . . .
. . . User Data FSN=14 BSN=3 .
. <------------------------------------ .
. . . User Data FSN=15 BSN=3 .
. <------------------------------------ .
. . . User Data FSN=16 BSN=3 .
. <------------------------------------ .
. LS PO FSN=3 BSN=11 . . .
. ------------------------------------> .
. . . . Remote Processor
. . . . Outage .
. . . . ------------>
…… 利用者データFSN=14 BSN=3<。------------------------------------ . . . . 利用者データFSN=15 BSN=3<。------------------------------------ . . . . 利用者データFSN=16 BSN=3<。------------------------------------ . . LSポーFSN=3 BSN=11…------------------------------------>… リモートプロセッサ…供給停止…。------------>。
While in LPO, A must buffer messages 14-16 without acknowledging them. A may continue transmitting messages from MTP3, and acknowledging messages that were received before LPO.
それらを承認しないで、AはLPOでメッセージ14-16をバッファリングしなければなりませんが。 Aは、MTP3からメッセージを送って、LPOの前に受け取られたメッセージを承認し続けるかもしれません。
George, et al. Standards Track [Page 39] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[39ページ]。
. . . . . .
. User Data FSN=4 BSN=13 . . .
. ------------------------------------> .
. User Data FSN=5 BSN=13 . . .
. ------------------------------------> .
. User Data FSN=6 BSN=13 . . .
. ------------------------------------> .
. . . . . .
…… 利用者データFSN=4 BSN=13…------------------------------------>利用者データFSN=5 BSN=13…------------------------------------>利用者データFSN=6 BSN=13…------------------------------------>……。
While in RPO, B may continue acknowledging messages. Suppose that
B receives message 4 and 5, but has not processed 6 yet.
Bは、RPOでメッセージを承認し続けるかもしれませんが。 Bがメッセージ4と5を受け取りますが、まだ6を処理していないと仮定してください。
. . . . . .
. (empty) User Data FSN=16 BSN=4
. <------------------------------------ .
. (empty) User Data FSN=16 BSN=5
. <------------------------------------ .
…… (空)の利用者データFSN=16 BSN=4<。------------------------------------ . . (空)です。 利用者データFSN=16 BSN=5<。------------------------------------ .
LPO ends at A. A flushes 14-16 (the messages that were buffered
without acknowledgement).
LPOはA.A水洗14-16(承認なしでバッファリングされたメッセージ)のときに終わります。
. . . . . .
. LS PR FSN=6 BSN=13 . . .
. ------------------------------------> .
. . . . Remote Processor
. . . . Outage Ceases
. . . . ------------>
. . . . . .
…… LS PR FSN=6 BSN=13…------------------------------------>… リモートプロセッサ…供給停止はやみます…------------>……
Suppose that B processed message 5, but never processed message 6.
B flushes message 6 from its Receive Buffer. B notifies A of this
using the Link Status Ready message setting BSN=5, the last message
that was processed at B.
Bがメッセージ5を処理しましたが、メッセージ6は決して処理しなかったと仮定してください。 BはReceive Bufferからのメッセージ6を洗い流します。 Link Status Readyメッセージ設定BSN=5、Bで処理された最後のメッセージを使用することでBはこのAに通知します。
. . . . . .
. . . . . .
. . . LS Ready FSN=13 BSN=5 .
. <------------------------------------ .
. . . . . .
…… LSの持ち合わせのFSN=13 BSN=5<。------------------------------------ . . . . . . .
B has completed synchronization of sequence numbers and has sent
an LS Ready, so it is able to resume sending data at this point
with the new sequence numbers (starting with FSN=14).
Bが一連番号の同期を終了して、LS Readyを送ったので、それは、ここに新しい一連番号と共にデータを送るのを再開できます(FSN=14から始まって)。
George, et al. Standards Track [Page 40] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[40ページ]。
. . . . . .
. . . . . Message for
. . . . transmission
. . . . <------------
. . . User Data FSN=14 BSN=5 .
. <------------------------------------ .
. . . . . .
…… . トランスミッション……<へのメッセージ------------ . . . 利用者データFSN=14 BSN=5<。------------------------------------ . . . . . . .
A can use the Link Status Ready information to resynchronize its
sequence numbers to begin with FSN=6 in the next User Data message.
Aは初めに一連番号を再連動させるように、次のUser DataのFSN=6が通信するというLink Status Ready情報を使用できます。
. . . . . .
. LS Ready FSN=5 BSN=13 . . .
. ------------------------------------> .
. . . . . .
…… LSの持ち合わせのFSN=5 BSN=13…------------------------------------>……。
A has completed synchronization of sequence number and has both
received and sent an LS Ready, so it is able to resume sending data
at this point with the new sequence numbers and acknowledging data
received after receiving LS Ready.
Aが一連番号の同期を完了して、両方は受け取られて、LS Readyを送るように持っているので、それは、ここにデータを送るのをLS Readyを受けた後に新しい一連番号とデータを承認するのを受け取っていて再開できます。
. . . . . .
. . . . . .
. User Data FSN=5 BSN=14 (empty) . .
. ------------------------------------> .
. . . . . .
Message for . . . Message for
transmission . . transmission
------------> . . <------------
. User Data FSN=6 BSN=14 . . .
. ------------------------------------> .
. . . User Data FSN=15 BSN=5 .
. <------------------------------------ .
. . . . . .
. . (empty) User Data FSN=15 BSN=6 .
. <------------------------------------ .
. User Data FSN=6 BSN=15 (empty) . .
. ------------------------------------> .
. . . . . .
. . . . . .
. . . . . .
…… 利用者データFSN=5 BSN=14(空の)…------------------------------------>… トランスミッショントランスミッションのための…Messageへのメッセージ------------><。------------ . 利用者データFSN=6 BSN=14…------------------------------------>… 利用者データFSN=15 BSN=5<。------------------------------------ . . . . . . . . . (空)です。 利用者データFSN=15 BSN=6<。------------------------------------ . . 利用者データFSN=6 BSN=15(空の)…------------------------------------>………………。
Figure 16. Example: Processor Outage and Recovery
図16。 例: プロセッサ供給停止と回復
George, et al. Standards Track [Page 41] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[41ページ]。
5.5. Level 2 Flow Control
5.5. レベル2 フロー制御
Figures 17 and 18 illustrate the Level 2 Flow Control procedure. In Figure 17, congestion ceases before timer T6 expires. Figure 18 shows the case where T6 expires.
数字17と18はLevel2Flow Control手順を例証します。 図17では、タイマT6が期限が切れる前に混雑はやみます。 図18は、T6がどこで期限が切れるかをケースに示します。
MTP3 M2PA SCTP SCTP M2PA MTP3
---- ---- ---- ---- ---- ----
. . . . . .
. Implementation dependent . .
. determination of M2PA . .
. receive congestion onset . .
. . . . . .
. Link Status Busy . . .
. ------------------------------------> .
. . . . . .
. . . . Start .
. . . . Timer T6 .
. . . . . .
. Implementation dependent . .
. determination of M2PA . .
. receive congestion abatement . .
. . . . . .
. Link Status Busy Ended . . .
. ------------------------------------> .
. . . . . .
. . . . Stop .
. . . . Timer T6 .
. . . . . .
MTP3 M2PA SCTP SCTP M2PA MTP3---- ---- ---- ---- ---- ---- . . . . . . . 実現に依存する… M2PAの決断… 混雑開始を……受ける…Link Status Busy…------------------------------------>… 始まってください… タイマT6……実現の依存する… M2PAの決断… 混雑減少を……受ける…Link Status Busy Ended…。------------------------------------>… 止まってください… タイマT6……。
Figure 17. Example: Level 2 Flow Control - Congestion Ceases
図17。 例: 2フロー制御を平らにしてください--混雑はやみます。
George, et al. Standards Track [Page 42] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[42ページ]。
MTP3 M2PA SCTP SCTP M2PA MTP3
---- ---- ---- ---- ---- ----
. . . . . .
. Implementation dependent . .
. determination of M2PA . .
. receive congestion onset . .
. . . . . .
. Link Status Busy . . .
. ------------------------------------> .
. . . . . .
. . . . Start .
. . . . Timer T6 .
. . . . : .
. . . . : .
. . . . Timer T6 .
. . . . Expires .
. . . . . .
. . Link Status Out of Service .
. <------------------------------------ .
. . . . . .
. . . . Out of Service
. . . . ------------>
. . . . . .
MTP3 M2PA SCTP SCTP M2PA MTP3---- ---- ---- ---- ---- ---- . . . . . . . 実現に依存する… M2PAの決断… 混雑開始を……受ける…Link Status Busy…------------------------------------>… 始まってください… タイマT6…: . . . . . : . . . . . タイマT6… 使われなくなっていた状態で………リンク状態を吐き出す、<。------------------------------------ . . . . . . . . . . . 使われなくなっている…------------>……
Figure 18. Example: Level 2 Flow Control - Timer T6 Expires
図18。 例: レベル2 T6が吐き出すフロー制御--タイマ
George, et al. Standards Track [Page 43] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[43ページ]。
5.6. MTP3 Signaling Link Congestion
5.6. MTP3シグナリングリンク混雑
In Figure 19, M2PA notifies MTP3 of congestion onset and abatement. The notification includes the congestion level, if there are levels of congestion defined.
図19では、M2PAは混雑開始と減少についてMTP3に通知します。 定義された混雑のレベルがあれば、通知は混雑レベルを含んでいます。
MTP3 M2PA SCTP SCTP M2PA MTP3
---- ---- ---- ---- ---- ----
. . . . . .
. Implementation dependent . .
. determination of M2PA . . .
. transmit congestion . . .
. onset (level) . . .
. . . . . .
Congestion Indication . . . .
(level) . . . . .
<------------ . . . .
. . . . . .
. Implementation dependent . .
. determination of M2PA . . .
. transmit congestion . . .
. abatement (level) . . .
. . . . . .
Congestion Indication . . . .
(level) . . . . .
<------------ . . . .
. . . . . .
MTP3 M2PA SCTP SCTP M2PA MTP3---- ---- ---- ---- ---- ---- . . . . . . . 実現扶養家族… M2PAの決断… 混雑…開始(レベル)……… Congestion Indication…(レベル)…<を伝えてください。------------ . . . . . . . . . . . 実現扶養家族… M2PAの決断… 混雑…減少(レベル)……… Congestion Indication…(レベル)…<を伝えてください。------------ . . . . . . . . . .
Figure 19. Example: MTP3 Signaling Link Congestion
図19。 例: MTP3シグナリングリンク混雑
George, et al. Standards Track [Page 44] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[44ページ]。
5.7. Link Deactivation
5.7. リンク非活性化
Figure 20 shows an example of link deactivation. MTP3 can request that a link be taken out of service.
図20はリンク非活性化に関する例を示しています。 MTP3は、リンクが使われなくなっていた状態で取られるよう要求できます。
MTP3 M2PA SCTP SCTP M2PA MTP3
---- ---- ---- ---- ---- ----
. . . . . .
Stop . . . . .
------------> . . . .
. . . . . .
. Link Status Out of Service . .
. ------------------------------------> .
. . . . . .
Out of Service . . . .
<------------ . . . .
. . . . . .
MTP3 M2PA SCTP SCTP M2PA MTP3---- ---- ---- ---- ---- ---- . . . . . . 止まってください…------------>… 使われなくなっていた状態で状態をリンクしてください…------------------------------------>… 使われなくなっている…、<。------------ . . . . . . . . . .
Figure 20. Example: Link Deactivation
図20。 例: リンク非活性化
5.8. Link Changeover
5.8. リンク転換
In Figure 21, MTP3 performs a changeover because the link went out of service. MTP3 selects a different link to retransmit the unacknowledged and unsent messages.
図21では、リンクが使われなくなるようになったので、MTP3は転換を実行します。 MTP3は、不承認とunsentメッセージを再送するために異なったリンクを選択します。
George, et al. Standards Track [Page 45] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[45ページ]。
MTP3 M2PA SCTP SCTP M2PA MTP3
---- ---- ---- ---- ---- ----
. . . . . .
. Communication Lost . . .
. <------------ . . .
. . . . . .
Out of Service . . . .
<------------ . . . .
. . . . . .
Retrieve BSNT . . . .
------------> . . . .
. . . . . .
BSNT Confirmation . . . .
<------------ . . . .
. . . . . .
XCO (BSNT) on another link . . .
------------------------------------------------------------>
. . . . . .
. . . . Retrieve BSNT
. . . . <------------
. . . . . .
. . . . BSNT Confirmation
. . . . ------------>
. . . . . .
. . . . . XCA (BSNT)
<------------------------------------------------------------
. . . . . .
Retrieval Request . . . .
and FSNC . . . . .
------------> . . . .
. . . . . .
Retrieved Message . . . .
<------------ . . . .
. : . . . . .
. : . . . . .
<------------ . . . .
. . . . . .
Retrieval Complete . . . .
<------------ . . . .
. . . . . .
Send messages on another link.
MTP3 M2PA SCTP SCTP M2PA MTP3---- ---- ---- ---- ---- ---- . . . . . . . 失われたコミュニケーション… <。------------ . . . . . . . . . 使われなくなっている. …<。------------ . . . . . . . . . . BSNTを検索してください…------------>… BSNT確認…<。------------ . . . . . . . . . . 別のもののXCO(BSNT)はリンクします…------------------------------------------------------------>… BSNT…<を検索してください。------------ . . . . . . . . . . BSNT確認…------------>… XCA(BSNT)<。------------------------------------------------------------ . . . . . . 検索要求…FSNC…。------------>… 検索されたメッセージ…<。------------ . . . . . : . . . . . . : . . . . . <、-、-、-、-、-、-、-、-、-、-、-- . . . . . . . . . . 検索は. …<を完成します。------------ . . . . . . . . . . 別のリンクにメッセージを送ってください。
Figure 21. Example: Link Changeover
図21。 例: リンク転換
George, et al. Standards Track [Page 46] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[46ページ]。
6. Security Considerations
6. セキュリティ問題
M2PA is designed to carry signaling messages for telephony services. As such, M2PA MUST involve the security needs of several parties:
M2PAは、電話サービスへのシグナリングメッセージを伝えるように設計されています。 そういうものとして、M2PA MUSTは数人のパーティーの安全要求にかかわります:
- the end users of the services
- サービスのエンドユーザ
- the network providers
- ネットワーク内の提供者
- the applications involved
- かかわったアプリケーション
Additional requirements MAY come from local regulation.
追加要件は地方条例から来るかもしれません。
While these parties may have some overlapping security needs, their needs may not be identical. Any security solution SHOULD fulfill all of the different parties' needs.
これらのパーティーにはセキュリティが必要とするいくつかの重なることがあるかもしれない間、彼らの必要性が同じでないかもしれません。 どんなセキュリティソリューションSHOULDも異なったパーティーの必要性のすべてを実現させます。
Consult [RFC3788] for a discussion of security requirements and for guidance on the use of security protocols. Implementers of M2PA MUST follow the guidelines in [RFC3788].
セキュリティ要件の議論と指導のためにセキュリティプロトコルの使用に関して[RFC3788]に相談してください。 M2PA MUSTのImplementersは[RFC3788]のガイドラインに従います。
7. IANA Considerations
7. IANA問題
7.1. SCTP Payload Protocol Identifier
7.1. SCTP有効搭載量プロトコル識別子
The SCTP Registered User Port Number Assignment for M2PA is 3565. The TCP Registered User Port Number 3565 is also assigned to M2PA, in case a specification for M2PA over TCP is created.
M2PAのためのSCTP Registered User Port Number Assignmentは3565です。 また、TCP Registered User Port Number3565はM2PAに割り当てられます、TCPの上のM2PAのための仕様が作成されるといけないので。
The value assigned by IANA for the Payload Protocol Identifier in the SCTP Payload Data chunk is
SCTP有効搭載量Data塊における有効搭載量プロトコルIdentifierのためにIANAによって割り当てられた値はそうです。
M2PA 5
M2PA5
The SCTP Payload Protocol Identifier is included in each SCTP Data chunk, to indicate which protocol the SCTP is carrying. This Payload Protocol Identifier is not directly used by SCTP but may be used by certain network entities to identify the type of information being carried in a Data chunk.
SCTP有効搭載量プロトコルIdentifierは、SCTPがどのプロトコルを運ぶかを示すためにそれぞれのSCTP Data塊に含まれています。 この有効搭載量プロトコルIdentifierはSCTPによって直接使用されませんが、あるネットワーク実体によって使用されて、Data塊で運ばれる情報の種類を特定するかもしれません。
The User Adaptation peer may use the Payload Protocol Identifier as a way of determining additional information about the data being presented to it by SCTP.
User Adaptation同輩はSCTPによってそれに提示されるデータに関する追加情報を決定する方法として有効搭載量プロトコルIdentifierを使用するかもしれません。
George, et al. Standards Track [Page 47] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[47ページ]。
7.2. M2PA Protocol Extensions
7.2. M2PAプロトコル拡張子
This protocol may be extended through IANA in three ways:
このプロトコルはIANAを通して3つの方法で広げられるかもしれません:
- through definition of additional message classes,
- 追加メッセージのクラスの定義で
- through definition of additional message types, and
- そして追加メッセージタイプの定義で。
- through definition of additional message parameters.
- 追加メッセージパラメタの定義で。
The definition and use of new message classes, types, and parameters is an integral part of SIGTRAN adaptation layers. Thus, these extensions are assigned by IANA through an IETF Consensus action as defined in [RFC2434].
新しいメッセージのクラス、タイプ、およびパラメタの定義と使用はSIGTRAN適合層の不可欠の一部です。 したがって、これらの拡大は[RFC2434]で定義されるようにIETF Consensus動作でIANAによって割り当てられます。
The proposed extension must in no way adversely affect the general working of the protocol.
提案された拡大はプロトコルの一般的な運用に決して悪影響を与えてはいけません。
The defined values for the message classes, types, and parameters are listed in the Signaling User Adaptation Layer registry (sigtran-adapt).
メッセージのクラス、タイプ、およびパラメタのための定義された値はSignaling User Adaptation Layer登録に記載されています(sigtran適合してください)。
7.2.1. IETF Defined Message Classes
7.2.1. IETFはメッセージのクラスを定義しました。
The documentation for a new message class MUST include the following information:
新しいメッセージのクラスのためのドキュメンテーションは以下の情報を含まなければなりません:
(a) A long and short name for the message class.
(a) 長くてメッセージのクラスに、短い名前。
(b) A detailed description of the purpose of the message class.
(b) メッセージのクラスの目的の詳述。
7.2.2 IETF Defined Message Types
7.2.2 IETFはメッセージタイプを定義しました。
Documentation of the message type MUST contain the following information:
メッセージタイプのドキュメンテーションは以下の情報を含まなければなりません:
(a) A long and short name for the new message type.
(a) 長くて新しいメッセージタイプに、短い名前。
(b) A detailed description of the structure of the message.
(b) メッセージの構造の詳述。
(c) A detailed definition and description of the intended use of
each field within the message.
(c) メッセージの中の各分野の意図している使用の詳細な定義と記述。
(d) A detailed procedural description of the use of the new
message type within the operation of the protocol.
(d) プロトコルの操作の中の新しいメッセージタイプの使用の詳細な手続き上の記述。
(e) A detailed description of error conditions when receiving this
message type.
(e) このメッセージタイプを受けるときのエラー条件の詳述。
George, et al. Standards Track [Page 48] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[48ページ]。
When an implementation receives a message type that it does not support, it MUST discard the message.
実装がそれがサポートしないメッセージタイプを受けるとき、それはメッセージを捨てなければなりません。
7.2.3. IETF-defined Parameter Extension
7.2.3. IETFによって定義されたパラメタ拡張子
Documentation of the message parameter MUST contain the following information:
メッセージパラメタのドキュメンテーションは以下の情報を含まなければなりません:
(a) Name of the parameter type.
(a) パラメータの型の名前。
(b) Detailed description of the structure of the parameter field.
(b) パラメタ分野の構造の詳述。
(c) Detailed definition of each component of the parameter value.
(c) パラメタ価値のそれぞれのコンポーネントの詳細な定義。
(d) Detailed description of the intended use of this parameter
type, and an indication of whether, and under what
circumstances, multiple instances of this parameter type may
be found within the same message type.
(d)がこのパラメータの型の意図している使用の記述、および指示を詳しく述べた、そして、中では、同じくらいが事情、このパラメタの複数のインスタンスが見つけられるかもしれないのをタイプするものの下でタイプを通信させますか?
7.2.4. Defined Values
7.2.4. 定義された値
This section lists the values defined in this document that should be included in the Signaling User Adaptation Layer registry (sigtran-adapt).
このセクションはSignaling User Adaptation Layer登録に含まれるべきである本書では定義された値を記載します(sigtran適合してください)。
The following values for Message Class are defined in this document:
Message Classのための以下の値は本書では定義されます:
Value
(decimal) Message Class
--------- -------------
11 M2PA Messages
値(10進)のメッセージのクラス--------- ------------- 11 M2PAメッセージ
The following values for Message Type are defined in this document:
Message Typeのための以下の値は本書では定義されます:
Value
(decimal) Message Type
--------- -------------
1 User Data
2 Link Status
値(10進)のメッセージタイプ--------- ------------- 1 ユーザデータ2リンク状態
8. Acknowledgements
8. 承認
The authors would like to thank the following for their valuable comments and suggestions: Brian Tatum, Wayne Davis, Cliff Thomas, Jeff Copley, Monique Bernard, Malleswar Kalla, Ian Rytina, Greg Sidebottom, Al Varney, Jeff Craig, and Andrew Booth.
作者が感謝したがっている、彼らの貴重なコメントと提案のための以下: ブライアン・テイタム、ウェイン・デイヴィス、クリフ・トーマス、ジェフ・コプリー、モニーク・バーナード、Malleswarカッラ、イアンRytina、グレッグSidebottom、アル・ヴァーニー、ジェフ・クレイグ、およびアンドリューBooth。
George, et al. Standards Track [Page 49] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[49ページ]。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[JT-Q703] TTC, "Message Transfer Part Signalling Link," TTC Standard
JT-Q703, Telecommunication Technology Committee (TTC),
version 3 (April 27, 1994).
[JT-Q703]TTC、「メッセージ転送部分の合図リンク」、TTC Standard JT-Q703、情報通信技術委員会(TTC)、バージョン3(1994年4月27日)。
[JT-Q704] TTC, "Message Transfer Part Signalling Network Functions,"
TTC Standard JT-Q704, Telecommunication Technology
Committee (TTC), version 4 (May 30, 2002).
[JT-Q704]TTC、「ネットワーク機能を示すメッセージ転送部分」、TTC Standard JT-Q704、情報通信技術委員会(TTC)、バージョン4(2002年5月30日)。
[Q.703] ITU, "Signalling System No. 7 - Signalling Link," ITU-T
Recommendation Q.703, ITU-T Telecommunication
Standardization Sector of ITU (July 1996).
[Q.703]ITU、ITU-T推薦Q.703、「リンクに合図して、システムNo.7に合図すること」でのITU(1996年7月)のITU-T電気通信標準化セクター。
[Q.704] ITU, "Message Transfer Part - Signalling Network Functions
and Messages," ITU-T Recommendation Q.704, ITU-T
Telecommunication Standardization Sector of ITU (July
1996).
[Q.704]ITU、「メッセージ転送部分--合図して、機能とメッセージをネットワークでつないでください」、ITU-T推薦Q.704、ITU(1996年7月)のITU-T電気通信標準化セクター。
[Q.2140] ITU, "B-ISDN ATM Adaptation Layer - Service Specific
Coordination Function for Signalling at the Network Node
Interface (SSCF at NNI)," ITU-T Recommendation Q.2140,
ITU-T Telecommunication Standardization Sector of ITU
(February 1995).
[Q.2140]ITU、「B-ISDN気圧適合層--ネットワーク・ノードインタフェース(NNIのSSCF)で合図するために特定のコーディネート機能を修理してください」、ITU-T推薦Q.2140、ITU(1995年2月)のITU-T電気通信標準化セクター。
[Q.2210] ITU, "Message Transfer Part Level 3 Functions and Messages
Using the Services of ITU-T Recommendation Q.2140," ITU-T
Recommendation Q.2210, ITU-T Telecommunication
Standardization Sector of ITU (July 1996).
[Q.2210]ITU、「ITU-T推薦Q.2140のサービスを利用して、メッセージ転送はレベル3 機能とメッセージを分けます」、ITU-T推薦Q.2210、ITU(1996年7月)のITU-T電気通信標準化セクター。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[RFC791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2434]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[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月)対パクソン
George, et al. Standards Track [Page 50] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[50ページ]。
[RFC3309] Stone, J., Stewart, R., and D. Otis, "Stream Control
Transmission Protocol (SCTP) Checksum Change", RFC 3309,
September 2002.
[RFC3309] ストーン、J.、スチュワート、R.、およびD.オーティス、「ストリーム制御伝動プロトコル(SCTP)チェックサム変化」、RFC3309、2002年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月。
[T1.111] ANSI, "American National Standard for Telecommunications -
Signaling System Number 7 (SS7) - Message Transfer Part
(MTP)," ANSI T1.111-2001, American National Standards
Institute (February 2001).
[T1.111]ANSI、「テレコミュニケーション--シグナリングシステムNo.7(SS7)--メッセージ転送部分(MTP)への米国標準規格」、ANSI T1.111-2001、American National Standards Institut(2001年2月)。
9.2. Informative References
9.2. 有益な参照
[M2UA] K. Morneault, et. al., "Signaling System 7 (SS7) Message
Transfer Part 2 (MTP2) - User Adaptation Layer," RFC 3331,
Internet Engineering Task Force - Signalling Transport
Working Group (September, 2002).
[M2UA]K.Morneault et(アル)、「システム7(SS7)メッセージに合図して、第2部(MTP2)を移してください--ユーザ適合層」、RFC3331、インターネット・エンジニアリング・タスク・フォース--合図Transport作業部会(2002年9月)。
[Q.700] ITU, "Introduction to CCITT Signalling System No. 7,"
ITU-T Recommendation Q.700, ITU-T Telecommunication
Standardization Sector of ITU (March 1993).
[Q.700]ITU、「CCITT合図システムNo.7への序論」、ITU-T推薦Q.700、ITUのITU-T電気通信標準化セクター(1993年3月)。
[Q.701] ITU, "Functional Description of the Message Transfer Part
(MTP) of Signalling System No. 7," ITU-T Recommendation
Q.701, ITU-T Telecommunication Standardization Sector of
ITU (March 1993).
[Q.701]ITU、「合図システムNo.7のメッセージ転送部分(MTP)の機能的な記述」、ITU-T推薦Q.701(ITU(1993年3月)のITU-T電気通信標準化セクター)。
[Q.702] ITU, "Signalling Data Link," ITU-T Recommendation Q.702,
ITU-T Telecommunication Standardization Sector of ITU
(November 1988).
[Q.702]ITU、「合図データ・リンク」、ITU-T推薦Q.702、ITU(1988年11月)のITU-T電気通信標準化セクター。
[Q.705] ITU, "Signalling System No. 7 - Signalling Network
Structure," ITU-T Recommendation Q.705, ITU-T
Telecommunication Standardization Sector of ITU (March
1993).
[Q.705]ITU、「ネットワーク構造に合図して、システムNo.7に合図すること」でのITU-T推薦Q.705(ITU(1993年3月)のITU-T電気通信標準化セクター)
[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月)。
George, et al. Standards Track [Page 51] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[51ページ]。
Authors' Addresses
作者のアドレス
Tom George Plano, TX USA
トム・ジョージ・テキサスプラノ(米国)
Phone: +1-972-985-4594 EMail: tgeorge_tx@verizon.net
以下に電話をしてください。 +1-972-985-4594 メールしてください: tgeorge_tx@verizon.net
Brian Bidulock OpenSS7 Corporation 1469 Jeffreys Crescent Edmonton, AB T6L 6T1 Canada
ブライアンBidulock OpenSS7社1469のジェフリーズABの三日月形T6L 6T1エドモントン(カナダ)
Phone: +1-780-490-1141 EMail: bidulock@openss7.org
以下に電話をしてください。 +1-780-490-1141 メールしてください: bidulock@openss7.org
Ram Dantu, Ph.D. Assistant Professor Department of Computer Science University of North Texas Denton, TX 76203 USA
牡羊座Dantu、ノーステキサスのテキサス76203デントン(米国)の博士号助教授コンピュータサイエンス学部大学
Phone: +1-940-565-2822 EMail: rdantu@unt.edu
以下に電話をしてください。 +1-940-565-2822 メールしてください: rdantu@unt.edu
Hanns Juergen Schwarzbauer SIEMENS AG Hofmannstr. 51 81359 Munich Germany
ハンスユルゲンSchwarzbauerジーメンス株式会社Hofmannstr。 51 81359ミュンヘンドイツ
Phone: +49-89-722-24236 EMail: HannsJuergen.Schwarzbauer@Siemens.com
以下に電話をしてください。 +49-89-722-24236 メールしてください: HannsJuergen.Schwarzbauer@Siemens.com
Ken Morneault Cisco Systems Inc. 13615 Dulles Technology Drive Herndon, VA 20171 USA
ケンMorneaultシスコシステムズInc.13615ダレス技術Driveヴァージニア20171ハーンドン(米国)
Phone: +1-703-484-3323 EMail: kmorneau@cisco.com
以下に電話をしてください。 +1-703-484-3323 メールしてください: kmorneau@cisco.com
George, et al. Standards Track [Page 52] RFC 4165 SS7 MTP2-User Peer-to-Peer Adaptation Layer September 2005
ジョージ、他 規格はSS7 MTP2-ユーザピアツーピア適合層の2005年9月にRFC4165を追跡します[52ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
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 currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
George, et al. Standards Track [Page 53]
ジョージ、他 標準化過程[53ページ]
一覧
スポンサーリンク
