[要約] RFC 4165は、SS7のMTP2のユーザーピア間適応層（M2PA）に関する仕様です。M2PAは、SS7ネットワークでの信号伝送を効率化するために使用されます。このRFCの目的は、M2PAの機能と動作を定義し、SS7ネットワークの信頼性とパフォーマンスを向上させることです。
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
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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状況については、「Internet Official Protocol Standards」（STD 1）の現在の版を参照してください。このメモの分布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（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.
この文書は、Stream Control Transmission Protocol（SCTP）のサービスを使用して、シグナリングシステム番号7（SS7）メッセージ転送部（MTP）レベル3シグナリングメッセージのトランスポートをサポートするプロトコルを定義しています。このプロトコルは、MTPレベル3プロトコルを使用してSS7シグナリングポイント間で使用されます。SS7シグナリングポイントは、SS7 MTPレベル2を使用して標準のSS7リンクを使用してMTPレベル3のシグナリングメッセージのトランスポートを提供することもできます。このプロトコルは、SS7エンドポイント間でピアツーピア通信を提供するために、MTPレベル2と同様の方法で動作する。
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
There is a need for Switched Circuit Network (SCN) signaling protocol delivery over an IP network. This includes message transfer between the following:
IPネットワーク上でのスイッチド回線ネットワーク（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シグナリングノードは、SS7シグナリングリンクを使用しないIPネットワークドメイン内のデータベースやその他のデバイスにアクセスできます。同様に、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シグナリングポイント（IPSP）と呼びます。IPSPSは、SS7リンクの代わりにIPネットワークを使用して従来のSS7ノードとして機能します。
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レベル2 / MTPレベル3インターフェイス境界をサポートします。
- Support management of SCTP transport associations and traffic instead of MTP2 Links.
- MTP2リンクの代わりにSCTPトランスポートアソシエーションとトラフィックの管理をサポートします。
- Support asynchronous reporting of status changes to management.
- 管理へのステータス変更の非同期レポートをサポートします。
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.701] [Q.702] [Q.704] [Q.705] [Q.705] [T1.111]。
MTP2 - MTP Level 2, the MTP signaling link layer.
MTP2 - MTPレベル2、MTPシグナリングリンク層。
MTP3 - MTP Level 3, the MTP signaling network layer.
MTP3 - MTPレベル3、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-user - 通常MTPレベル2のサービスを使用するプロトコル。唯一のMTP2ユーザーはMTP3です。MTP2ユーザーはM2PAユーザーと同じです。
Signaling End Point (SEP) - An SS7 Signaling Point that originates or terminates signaling messages. One example is a central office switch. [RFC2719]
シグナリングエンドポイント（SEP） - シグナリングメッセージを発信または終了するSS7シグナリングポイント。一例は中央局スイッチです。[RFC2719]
IP Signaling Point (IPSP) - An SS7 Signaling Point with an IP network connection used for SS7 over IP.
IPシグナリングポイント（IPSP） - IPを介してSS7に使用されるIPネットワーク接続を持つSS7シグナリングポイント。
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は、IP経由でSS7に使用されるIPネットワーク接続とSS7ネットワークへの従来の（IP）リンクの両方を持つSS7シグナリングポイントです。
Signal Transfer Point (STP) - A Signal Transfer Point as defined by MTP standards, e.g., [Q.700].
信号転送点（STP） - MTP規格で定義される信号転送点、例えば[Q.700]。
Signaling Point (STP) - A Signaling Point as defined by MTP standards, e.g., [Q.700].
シグナリングポイント（STP） - MTP規格で定義されているシグナリング点、例えば[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".
ネットワークバイトオーダー - 「ビッグエンディアン」とも呼ばれる最上位バイト[RFC791]、付録B「データ伝送順」を参照してください。
Stream - A stream refers to an SCTP stream [RFC2960].
ストリーム - ストリームはSCTPストリームを参照します[RFC2960]。
BSNT - Backward Sequence Number to be Transmitted
BSNT - 送信されるべき後方シーケンス番号
FSNC - Forward Sequence Number of last message accepted by remote level 2
FSNC - リモートレベル2で受け入れられた最後のメッセージの転送シーケンス番号
LI - Length Indicator
LI - 長さインジケータ
MSU - Message Signal Unit
MSU - メッセージ信号ユニット
SCCP - Signaling Connection Control Part
SCCP - シグナリング接続制御部
SCN - Switched Circuit Network SCTP - Stream Control Transmission Protocol
SCN - スイッチ回路ネットワークSCTP - ストリーム制御伝送プロトコル
SIF - Signaling Information Field
SIF - シグナリング情報フィールド
SIO - Service Information Octet
SIO - サービス情報オクテット
SLC - Signaling Link Code
SLC - シグナリングリンクコード
SS7 - Signaling System Number 7
SS7 - シグナリングシステム番号7
SSN - Stream Sequence Number
SSN - ストリームシーケンス番号
STP - Signal Transfer Point
STP - 信号転送点
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].
「必須」、「必須」、「必要ではない」、「しない」、「推奨する」、「推奨する」、「5月」、および「オプション」、「オプション」、「オプション」、「オプション」、「オプション」、「オプション」、[RFC2119]に記載されているように解釈されること。
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.
スイッチ付き回路ネットワーク（SCN）のシグナリングトランスポートのためのシグナリングトランスポートのためのRFC2719は、IPトランスポートプロトコル、ストリーム制御伝送プロトコル（SCTP）、およびが予想されるサービスをサポートするための適応モジュールを含む複数のコンポーネントを使用しています。その基礎となるプロトコル層からの特定のSCNシグナリングプロトコル。
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ユーザピアツーピア適応層（M2PA）として知られる適応層は、MTP3とMTP2と同様のインターフェースおよびサービスを提供する。実際には、従来の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ユーザピアツーピア適応レイヤ（M2PA）を使用してSCTPレイヤに適合されています。MTP3とMTP2の間のすべてのプリミティブはM2PAによって支持されています。SCTPアソシエーションは、IPSP間の1つのSS7リンクとして機能します。IPSPは、MTP3より上のシグナリング接続制御部（SCCP）および他のSS7層を有することができる。
******** IP ********
* IPSP *--------* IPSP *
******** ********
+------+ +------+
| 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.
シグナリングゲートウェイ（SG）で使用されるM2PAの例を図2に示す。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.
SEPとSGは従来のSS7リンクを介して通信します。これは[Q.702]などのプロトコルに従います。SGとIPSPは、M2PAプロトコルを使用してIPリンクを介して通信します。SEPから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レイヤーを持つことができます。シグナリングゲートウェイは信号転送点（STP）として機能する。SEPとSGとの間のSS7経路に他のSTPが存在してもよい。
******** SS7 *************** IP ********
* SEP *--------* SG *--------* IPSP *
******** *************** ********
+------+ +------+
| TCAP | | TCAP |
+------+ +------+
| SCCP | | SCCP |
+------+ +-------------+ +------+
| MTP3 | | MTP3 | | MTP3 |
+------+ +------+------+ +------+
| MTP2 | | MTP2 | M2PA | | M2PA |
| | | +------+ +------+
| | | | SCTP | | SCTP |
+------+ +------+------+ +------+
| MTP1 | | MTP1 | IP | | IP |
+------+ +------+------+ +------+
SEP - SS7 Signaling Endpoint
SEP - 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はSCTPアソシエーションをSS7リンクとして使用します。M2PA / SCTP / IPスタックは、MTP2 / MTP1スタックの代わりに使用できます。
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には独自のSS7ポイントコードが必要です。
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-USER）インタフェースはIPSPに保持されています。M2PAプロトコルレイヤは、MTPレベル2からMTPレベル3に提供されるものと同等のサービスのセットを提供する必要があります。
These services are described in the following subsections.
これらのサービスは以下のサブセクションで説明されています。
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].
このインタフェースは、該当するSS7規格[Q.703] [Q.704] [T1.111] [Q.2140]で説明されているMTP2 / MTPTP3インターフェイスと同じです。[T1.111]と[Q.2210]。
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の切り替え手順は[Q.2210]と[T1.111]に記載されている拡張切替順序と拡張切替確認メッセージを使用する必要があります。
Also, the following MTP3/MTP2 primitives must use the larger sequence numbers:
また、次のMTP3 / MTP2プリミティブは、より大きなシーケンス番号を使用する必要があります。
- BSNT Confirmation
- BSNT確認
- Retrieval Request and FSNC
- 取得要求とFSNC
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レベル2は、信号単位として知られる3種類のメッセージを送信します。メッセージ信号単位（MSU）、リンクステータス信号単位（LSSUS）、およびフィルイン信号単位（FISU）。
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のユーザーデータメッセージと呼ばれます。
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には類似のメッセージが必要です。リンクステータスメッセージはこの目的に役立ちます。
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.
他の信号ユニットが送信されているのを待っていない場合、FISUは連続的に送信されます。FISUはまたメッセージの確認応答を行います。IPネットワークは共有リソースであるため、FISUSの場合のように継続的に送信されるメッセージタイプを持つことは望ましくありません。さらに、SCTPはその上位層を継続的に送信する必要はありません。したがって、M2PAはFISUのようなプロトコルデータユニットを提供しない。M2PAのユーザーデータメッセージは、メッセージの確認応答を継承するために使用されます。M2PAがメッセージを確認する必要がある場合、それ自身のMTP3メッセージがない場合は、空のユーザーデータメッセージを送信できます。
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
- リンクアライメント手順
The M2PA layer must maintain a map of each of its SS7 links to the corresponding SCTP association.
M2PAレイヤーは、対応するSCTPアソシエーションへの各SS7リンクのマップを維持しなければなりません。
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はリンクステータスメッセージのために指定されています。ストリーム1は、ユーザデータメッセージとともに、ユーザデータメッセージと順番に順番に残る必要があるリンクステータスメッセージのために指定される。リンクステータスおよびユーザデータメッセージを別々のストリームに分離することにより、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から受信した通知はM2PAによって処理されるか、または上位層MTP3に送信される適切な通知に変換される。
M2PA allows MTP3 to perform all of its Message Handling and Network Management functions with IPSPs as it does with other SS7 nodes.
M2PAにより、MTP3は他のSS7ノードとの間でIPSPSを使用してすべてのメッセージ処理とネットワーク管理機能を実行できるようにします。
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] [T1.111] [Q.2140]に記載されています。
The upper layer primitives provided by SCTP are described in [RFC2960] Section 10 "Interface with Upper Layer".
SCTPによって提供される上位層のプリミティブは、[RFC2960]セクション10「上位層とのインターフェース」に記載されています。
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ユーザ適応レイヤ（M2UA）[M2UA]は、MTP3レイヤをSCTP / IPスタックに適合させる。バックホールアーキテクチャ[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を使用しています。2つのレイヤ間の通信MTP3 / M2PAは、SS7 MTP3 / MTP2と同じプリミティブによって定義されています。M2PAはMTP2と同様の機能を実行します。
******** SS7 *************** IP ********
* SEP *--------* SG *--------* IPSP *
******** *************** ********
+------+ +-------------+ +------+
| 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, 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.
M2UAの同等のアーキテクチャを図4に示します.M2UAでは、MGCのMTP3はSGのMTP2をSS7層として使用します。同様に、SGのMTP2はMGCのMTP3をその上限SS7層として使用します。SS7では、MTP3レイヤとMTP2レイヤ間の通信はプリミティブによって定義されています。M2UAでは、MTP3 / MTP2通信はM2UAメッセージとして定義され、IP接続を介して送信されます。
******** SS7 *************** IP ********
* SEP *--------* SG *--------* MGC *
******** *************** ********
+------+ +------+
| 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への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：SGはMTP3がないため、上限SS7層を持たない。
e. M2PA: relies on MTP3 for management procedures. M2UA: uses M2UA management procedures.
e. M2PA：管理手順にはMTP3に依存しています。M2UA：M2UA管理手順を使用します。
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.
M2PAとM2UAの潜在的なユーザーは、IPネットワークを介したSS7シグナリングトランスポートに使用する方法を決定するときにこれらの違いを認識する必要があります。
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メッセージ内のすべてのフィールドは、ネットワークバイト順、すなわち最上位バイトで送信されなければならない。
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のプロトコルメッセージには、バージョン、メッセージクラス、メッセージタイプ、およびメッセージ長を含むメッセージヘッダー構造が必要です。ヘッダ構造を図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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5. Common Message Header
図5.一般的なメッセージヘッダー
The version field contains the version of M2PA. The supported versions are:
バージョンフィールドにはM2PAのバージョンが含まれています。サポートされているバージョンは次のとおりです。
Value
(decimal) Version
--------- -------
1 Release 1.0 of M2PA protocol
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.
スペアフィールドは、送信者によってすべてのゼロ（0]）に設定され、受信者によって無視されるべきです。予備フィールドは独自の情報には使用しないでください。
The following List contains the valid Message Classes:
次のリストには、有効なメッセージクラスが含まれています。
Value
(decimal) Message Class
--------- -------------
11 M2PA Messages
Other values are invalid for M2PA.
M2PAには他の値が無効です。
The following list contains the message types for the defined messages.
次のリストには、定義されたメッセージのメッセージタイプが含まれています。
Value
(decimal) Message Type
--------- -------------
1 User Data
2 Link Status
Other values are invalid.
他の値は無効です。
The Message Length defines the length of the message in octets, including the Common Header.
メッセージ長は、共通のヘッダーを含むオクテット内のメッセージの長さを定義します。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6. M2PA-specific Message Header
図6. M2PA固有のメッセージヘッダ
This is the FSN of the message last received from the peer.
これは、ピアから最後に受信したメッセージのFSNです。
This is the M2PA sequence number of the User Data message being sent.
これは、送信されているユーザーデータメッセージのM2PAシーケンス番号です。
The FSN and BSN values range from 0 to 16,777,215.
FSN値とBSN値は0から16,777,215の範囲です。
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メッセージは、共通のメッセージヘッダーとM2PAヘッダーと、その後にメッセージに適したデータで構成されています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ 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)
- ユーザーデータメッセージ（セクション2.3.1）、またはリンク状態メッセージ（セクション2.3.2）
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.
ユーザーデータはMTP3から送信されたデータです。ユーザーデータはオプションのフィールドです。確認応答のみのメッセージに含める必要はありません。
The format of the User Data message is as follows:
ユーザーデータメッセージのフォーマットは次のとおりです。
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 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Data field contains the following fields of the MTP Message
Signal Unit (MSU):
- the Message Priority field (PRI) - Service Information Octet (SIO) - Signaling Information Field (SIF)
- メッセージ優先フィールド（PRI） - サービス情報オクテット（SIO） - シグナリング情報フィールド（SIF）
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規格は、PRIフィールドをMTP3メッセージ優先欄JT-Q703] [JT-Q704]として使用しています。これら2ビットを使用しないMTPのバージョンの場合、データフィールドの最初のオクテット全体がスペアである。
The format of the first octet of the Data field is:
データフィールドの最初のオクテットのフォーマットは次のとおりです。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|PRI| spare | (followed by 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:
データフィールドには、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)
- フラグ - 後方シーケンス番号（BSN） - 後方インジケータビット（BIB） - フォワードシーケンス番号（FSN） - 前方インジケータビット（FIB） - 長さインジケータ（LI） - チェックビット（CK）
The Data field SHALL be transmitted in the byte order as defined by MTP3.
データフィールドは、MTP3によって定義されているようにバイト順で送信されなければならない。
M2PA SHALL NOT add padding to the MTP3 message.
M2PAは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の推奨事項では、メッセージ内のメッセージとフィールドのフォーマットはビット伝送順序に基づいています。これらの推奨事項では、各フィールドの最下位ビット（LSB）は右側に位置しています。以下に示すように、受信したSS7フィールドには、4オクテットワードに受信されたオクテットによって取り付けられます。
As an example, in the ANSI MTP protocol, the Data field format is shown below:
例として、ANSI MTPプロトコルでは、データフィールドフォーマットを以下に示します。
|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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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).
各オクテット内では、SS7推奨に従って最下位ビット（LSB）は右（例えば、SIOのビット15はLSB）になる。
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:
リンクステータスを示すために、MTP2リンクステータスメッセージをM2PAピア間で送信できます。このメッセージは、MTP2のリンクステータス信号ユニットと同様の機能を実行します。リンクステータスメッセージのフォーマットは次のとおりです。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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)
The Link Status Proving message may optionally carry additional bytes. If the optional bytes are used, the format of the message is as follows.
リンクステータス証明メッセージは、オプションで追加のバイトを運ぶことができる。オプションのバイトが使用されている場合、メッセージのフォーマットは次のとおりです。
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 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
リンクステータス証明メッセージの長さは、リンク上で搬送されるユーザーデータメッセージのサイズと似ていることをお勧めします。
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.
フィラーフィールドには、リンクステータス証明メッセージ間で変化する数字パターンが含まれており、SCTPチェックサム[RFC3309]を使用して送信精度を検証することをお勧めします。
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アソシエーション状態とそれぞれの説明のリストです。
IDLE - State of the association during power-up initialization.
アイドル - 電源投入初期化中の関連付けの状態。
ASSOCIATING - M2PA is attempting to establish an SCTP association.
関連付け - M2PAはSCTPアソシエーションを確立しようとしています。
ESTABLISHED - SCTP association is established.
確立された - SCTP協会が確立されています。
+-----------+
| 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
Figure 7. M2PA Association State Transition Diagram
図7. 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リンクがある状態から別の状態に移動します。状態の変更を引き起こす可能性があるイベントは次のとおりです。
- 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リンク状態に影響します。
Because M2PA provides MTP3 with an interface and functionality like MTP2, its internal functioning is similar to that of MTP2.
M2PAはMTP3をMTP2に提供するMTP3をMTP2に提供するため、その内部機能は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は該当する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]の要件に従うべき要件に従うべきであることを意味しません。
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は、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はメッセージの配信を提供するので、MTP2で行われるように、M2PAがフラグを持つメッセージを区切る必要はありません。さらに、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はチェックサムを使用して送信エラーを検出するので、MTP2で必要なようにM2PAチェックサムを必要としません。これにより、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からのメッセージの受信を成功させることによって示されます。
This section describes how M2PA relates MTP and SCTP entities.
このセクションでは、M2PAと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アドレス（またはマルチホーミングが使用されている場合は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登録ポートである必要があります。
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.
これら2つのIPアドレスの間に1つの関連付けを確立する場合は、関連付けられている各エンドポイントで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登録されたポート番号は、各関連付けの一端に使用されるべきです。
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アドレス/ポートの各組み合わせ（すなわち、各関連）は、各エンドポイントで同じシグナリングリンクコード（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.
図8は、2つのIPSPSの場合、それぞれ2つのIPアドレスを示しています。2つの関連付けは、2つのIPSPを接続するリンクです。これらのリンクは同じリンクセットにあるため、異なるSLCを持つ必要があります。
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アソシエーションをSLCにマッピングするための実際の方法は実装に依存しています。
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 |
| | | |
| | | |
+-------------+ +-------------+
IPx = IP address PW = Registered port number for M2PA
IPX = IPアドレスPW = M2PAの登録ポート番号
Figure 8. Two IPSPs with Two IP Addresses Each
図8. 2つのIPアドレスを持つ2つのIPSP
+-------------+---------------------------------------+-----+
| Association | IPSP X | IPSP Y | SLC |
| +------------+------+------------+------+ |
| | IP address | Port | IP address | Port | |
+=============+============+======+============+======+=====+
| 1 | IPA | PW | IPB | PW | a |
+-------------+------------+------+------------+------+-----+
| 2 | IPC | PW | IPD | PW | b |
+-------------+------------+------+------------+------+-----+
Table 1. Two IPSPs with Two IP Addresses Each
表1. 2つのIPアドレスを持つ2つのIPSP
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および表2は、3つのIPSPを用いた例を示している。この例では、2つのリンクは異なるリンクセットにあります。したがって、SLC値A、Bが等しい可能性がある。
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 |
| |
| |
| |
| |
| |
| |
| |
| |
+-------------+
IPx = IP address PW = Registered port number for M2PA
IPX = IPアドレスPW = M2PAの登録ポート番号
Figure 9. One IPSP Connected to Two IPSPs
図9. 2つのIPSPSに接続されている1つのIPSP
+-------------+---------------------------------------+-----+
| 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 |
+-------------+------------+------+------------+------+-----+
Table 2. One IPSP Connected to Two IPSPs
表2. 1つのIPSPが2つのIPSPSに接続されています
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および表3は、同じ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 |
| | | |
| | | |
+-------------+ +-------------+
IPx = IP address P1 = Pre-selected port number PW = Registered port number for M2PA
IPX = IPアドレスP1 =事前選択ポート番号PW = M2PAの登録ポート番号
Figure 10. Multiple Associations Between Two IP Addresses
図10. 2つのIPアドレス間の複数の関連付け
+-------------+---------------------------------------+-----+
| Association | IPSP X | IPSP Y | SLC |
| +------------+------+------------+------+ |
| | IP address | Port | IP address | Port | |
+=============+============+======+============+======+=====+
| 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.
関連付けには、各方向に2つのストリームが含まれていなければならない。ストリーム0はリンクステータスメッセージのために指定されています。ストリーム1は、ユーザデータメッセージとともに、ユーザデータメッセージと順番に順番に残る必要があるリンクステータスメッセージのために指定される。
The following Link Status messages SHALL be sent on the Link Status stream (stream 0):
次のリンクステータスメッセージは、リンクステータスストリーム（Stream 0）で送信されます。
- Alignment - Proving Normal - Proving Emergency - Ready (when sent during alignment) - Busy - Busy Ended - Out of Service
- 整列 - 緊急証明 - 緊急証明 - 準備完了（整合中に送信されたとき） - ビジー - 忙しい - サービス不足
The following Link Status messages SHALL be sent on the User Data stream (stream 1):
次のリンクステータスメッセージは、ユーザーデータストリーム（Stream 1）で送信されます。
- Processor Outage - Processor Recovered - Ready (when sent at the end of processor outage)
- プロセッサの停止 - プロセッサが回復 - 準備完了（プロセッサの停止の最後に送信されたとき）
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.
(1) 両方のエンドポイントがSS7トラフィックを送信する準備ができているように、ハンドシェイク手順を提供するために、もう一方のエンドの準備ができてトラフィックが送信されるのを防ぐために。
(2) To verify that the SCTP association is suitable for use as an SS7 link.
(2) SCTPアソシエーションがSS7リンクとしての使用に適していることを確認するため。
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から開始要求を受信した場合、M2PAはリンクが不足していることを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.
サービスステータスOUTサービスのメッセージがMTP2のSIOSメッセージを置き換えます。MTP2とは異なり、メッセージは継続的に送信されるべきではありません。協会が確立された後、M2PAはそのピアにリンク状況を除外するリンクステータスを送信しなければならない。整列の開始前に、M2PAは追加のリンクステータスをサービスのメッセージから送信することがあります。
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.
リンクステータスアライメントメッセージは、MTP2のSIOメッセージを置き換えます。このメッセージは、アライメント手順の先頭にシグナルに送信されます。リンクステータスアライメントメッセージは継続的に送信されないでください。M2PAは、リンクステータムの整列を受信するまで追加のリンクステータスアラインメントを送信することができます。
The Link Status Proving Normal message replaces the SIN message of MTP2. The Link Status Proving Emergency message replaces the SIE message of MTP2.
NORMALメッセージを証明するリンクステータスがMTP2のSINメッセージを置き換えます。緊急メッセージを証明するリンクステータスは、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は、プロトコルパラメータPRESVENT_INTERVALによって定義された間隔でリンクステータス証明メッセージをそのピアに送信するものとします。証明期間中にリンクステータス証明メッセージで生成されたトラフィック負荷が、リンクが稼働しているときに予想される通常のトラフィック負荷に匹敵するように証明されていることをお勧めします。
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.
リンクステータスREADYメッセージは、証明期間の最後に送信されるMTP2のFISUを置き換えます。リンクステータスレディメッセージは、両端が証明を完了したことを確認するために使用されます。M2PAがタイマT1を起動すると、MTP2が完了した後にMTP2がFISUを送信する場合は、リンクステータスレディメッセージをそのピアに送信します。リンクステータスREADEメッセージが送信された場合、M2PAはタイマT1が実行されている間に追加のリンクステータスレディメッセージを送信することがあります。これらのリンクステータスレディメッセージはリンクステータスストリームで送信されます。
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は（それぞれ）ユーザデータまたはリンクステータスプロセッサの停止メッセージを送信するものとします。
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.
リンクステータスプロセッサの停止メッセージは、MTP2のSIPOメッセージを置き換えます。MTP2とは異なり、メッセージは継続的に送信されるべきではありません。M2PAは、MTP2がSIPOを送信するプロセッサの停止条件の開始時に、リンクステータスプロセッサの停止メッセージをそのピアに送信します。M2PAは、その状態が持続する限り、追加のリンクステータスプロセッサの停止メッセージを送信することができます。リンクステータスプロセッサの停止メッセージは、ユーザーデータストリームで送信されます。
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) ピアから受信したユーザデータメッセージは承認されてはならず、バッファリングされていなければならない。
(b) M2PA SHOULD continue to acknowledge User Data messages received and accepted by MTP3 before the local processor outage.
(b) M2PAは、ローカルプロセッサの停止前にMTP3によって受信および受け入れられたユーザーデータメッセージを承認し続けるべきです。
(c) M2PA SHOULD continue to transmit messages that have been sent by its upper layer MTP3.
(c) M2PAは、その上位層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は、リモートプロセッサの停止に関係なく、MTP3によって受信および受け入れられたユーザーデータメッセージを承認し続けるべきです。
(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) リンクステータスプロセッサの停止後にピアから受信したユーザーデータメッセージをMTP3に配信できない場合は、これらのメッセージを確認してはならず、バッファリングされていなければなりません。
If M2PA receives a Flush command from MTP3,
M2PAがMTP3からFlushコマンドを受信した場合、
(a) M2PA SHALL discard any incoming messages that were queued and unacknowledged during the processor outage condition.
(a) M2PAは、プロセッサの停止条件の間にキューに入れられ、未確認の着信メッセージを破棄します。
(b) M2PA SHALL discard messages in the transmit and retransmit queues as required by MTP2.
(b) M2PAは、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は、プロセッサの停止条件でキューに入れられ、未確認の着信メッセージの処理を開始します。
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 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).
ローカルプロセッサ停止条件が終了すると、M2PAはリンクステータスプロセッサ回復メッセージをユーザデータストリームのそのピアに送信するものとする。このメッセージは、MTP2で使用されるように、MSUまたはFISUの代わりにプロセッサの停止条件の終わりを通知するために使用されます。リンクステータスプロセッサの回復されたメッセージのBSNは、ピアM2PAから受信された最後のユーザデータメッセージのFSN（廃棄されていない）に設定される。M2PAは、リンクステータスレディメッセージを受信するまで、リンクステータスプロセッサ回復メッセージを送信した後にユーザデータメッセージの送信を中止する（下記参照）。
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.
リンクステータスプロセッサを回復したメッセージを受信すると、RPOのM2PAは、ユーザデータストリーム上のリンクステータスレディメッセージで応答するものとします。リンクステータスレディメッセージ内のBSNは、ピアM2PAから受信された最後のユーザデータメッセージの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.
リンクステータスレディメッセージを受信すると、以前はLPOのM2PAは、ユーザデータストリーム上のリンクステータスレディメッセージで応答するものとします。リンクステータスレディメッセージ内のBSNは、ピアM2PAから受信された最後のユーザデータメッセージの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端末の両方で）は、MTP2で必要な場合は、受信したリンクステータスREADYメッセージのBSN値を使用して、そのシーケンス番号を再同期します。M2PAは、リンクステータスレディメッセージを送信するまで送信ユーザデータメッセージの送信を再開してはならない。
During resynchronization, M2PA SHALL NOT discard any received User Data messages that were sent after the processor outage ended.
再同期中、M2PAは、プロセッサの停止が終了した後に送信された受信したユーザーデータメッセージを破棄してはなりません。
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がローカルプロセッサの停止を経験すると、これが該当するMTP2規格（例えば[Q.2140]）によって許可されている場合、リンク状況をサービスの中から送信することによってリンク外にリンクを取り除かせることができる。
In other respects, M2PA SHOULD follow the same procedures as MTP2 in processor outage.
他の点では、M2PAはプロセッサの停止のMTP2と同じ手順に従うべきです。
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.
リンクステータスビジーメッセージは、MTP2のSIBメッセージを置き換えます。メッセージは継続的に送信されないでください。M2PAは、MTP2がSIBを送信する受信輻輳状態の開始時にリンクステータスビジーメッセージをそのピアに送信します。その条件が持続する限り、M2PAは追加のリンクステータスビジーメッセージを送信することができます。条件が終了すると、M2PAはリンクステータスビジーの終了メッセージをそのピアに送信します。
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は、受信渋滞にある間にメッセージを送信し続けるものとしますが、リンクステータスビジーメッセージの送信をトリガーしたメッセージも承認してはいけません。
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が第1のリンクステータスビジーメッセージを受信すると、確認応答待ち（すなわち、T7が実行されている）再送バッファにメッセージがある場合、リモート輻輳タイマT6を起動する。M2PAが実行中の場合はT7タイマーを停止します。T6が実行されている間に受信された追加のリンクステータスビジーメッセージは、T6をリセットさせず、T7を起動させないでください。T6が実行されている間、T7は開始されません。
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がリンクステータスビジー終了メッセージを受信し、T6は期限切れになっていないため、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は、もう一方の端がビジーである間にメッセージを受信して確認し続ける必要がありますが、リンクステータスのビジーを受信した後、およびリンクステータスのビジーを受信する前にユーザーデータメッセージを送信してはなりません。
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.
サービスステータスOUTサービスのメッセージがMTP2のSIOSメッセージを置き換えます。MTP2とは異なり、メッセージは継続的に送信されるべきではありません。M2PAは、MTP2がSIOSを送信する条件の始めに、そのピアにリンク状況をそのピアに送信しなければならない。M2PAは、その条件が持続する限り、追加のリンクステータスをサービスに送信することができます。
When M2PA places a link in the OUT OF SERVICE state, M2PA SHOULD NOT terminate the SCTP association.
M2PAがサービス不足状態にリンクを配置すると、M2PAはSCTPアソシエーションを終了しないでください。
The SCTP association for a link may become unusable, such as when one of the following occurs:
次のいずれかが発生した場合など、リンクのSCTPの関連付けは使用できなくなる可能性があります。
- SCTP sends a Send Failure notification to M2PA.
- SCTPは送信失敗通知をM2PAに送信します。
- SCTP sends a Communication Lost notification to M2PA.
- SCTPは通信損失通知をM2PAに送信します。
- SCTP sends a Communication Error notification to M2PA.
- SCTPは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はリンクが不正になっていてサービスの状態状態を入力したことをMTP3に報告します。
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では、リンクステータスメッセージに優先順位があります（[Q.703]、セクション11.2）。これを実現するために、M2PAは、リンクステータスメッセージとユーザデータメッセージのためにSCTP関連のあるセキュリティで別々のストリームを使用します。
M2PA SHALL send all messages using the ordered delivery option of SCTP.
M2PAは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.
M2PAは、SCTPにメッセージを送信するときに、ユーザデータストリームで送信されたメッセージよりも、リンクステータスストリームで送信されたメッセージを優先させる必要があります。
M2PA SHOULD give higher priority to reading the Link Status stream than to reading the User Data stream.
M2PAは、ユーザデータストリームの読み取りよりもリンクステータスストリームを読み取ることを優先する必要があります。
M2PA SHOULD give higher priority to receiving notifications from SCTP than to reading either the Link Status stream or the User Data stream.
M2PAは、リンクステータスストリームまたはユーザデータストリームのいずれかを読み取るためよりもSCTPからの通知を受信するのを高めるべきです。
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にアップグレードされたノードは、通信中の他のノードで使用されている古いバージョンをサポートする必要があります。そうであれば、アライメントは正常に進行できます。
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.
- 新しいバージョンは、古いバージョンからメッセージを処理できるはずです。
- 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メッセージへのメッセージの送信を控えてください。
- If an older version of M2PA receives a message that it cannot process, it SHOULD discard the message.
- 古いバージョンのM2PAが処理できないメッセージを受信した場合は、メッセージを破棄する必要があります。
- 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つのバージョンで異なる処理が行われた場合、新しいバージョンにはこれを認識して適切に処理するための手順を含める必要があります。
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 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が古いバージョンと互換性がない場合、新しいバージョンはこれを認識し、リンクの位置合わせを防ぐ必要があります。サポートされていないバージョンでのリンクステータスアラインメントメッセージが新しいバージョンによって受信された場合、受信側のM2PAはリンクステータスを使用して返信メッセージが表示され、アライメント手順を完了する必要があります。
When MTP3 sends a message for transmission to M2PA, M2PA passes the corresponding M2PA message to SCTP using the SEND primitive.
MTP3がM2PAに送信するメッセージを送信すると、M2PAは、送信プリミティブを使用して対応するM2PAメッセージをSCTPに渡します。
User Data messages SHALL be sent via the User Data stream (stream 1) of the association.
ユーザーデータメッセージは、関連付けのユーザーデータストリーム（Stream 1）を介して送信されなければならない。
M2PA Link Status messages are passed to SCTP using the SEND primitive.
M2PAリンクステータスメッセージは、Send Primitiveを使用してSCTPに渡されます。
The following Link Status messages SHALL be sent on the Link Status stream (stream 0):
次のリンクステータスメッセージは、リンクステータスストリーム（Stream 0）で送信されます。
- Alignment - Proving Normal - Proving Emergency - Ready (when sent during alignment) - Busy - Busy Ended - Out of Service
- 整列 - 緊急証明 - 緊急証明 - 準備完了（整合中に送信されたとき） - ビジー - 忙しい - サービス不足
The following Link Status messages SHALL be sent on the User Data stream (stream 1):
次のリンクステータスメッセージは、ユーザーデータストリーム（Stream 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が無効なメッセージクラスまたは共通メッセージヘッダー内の無効なメッセージ・メッセージ・タイプを使用してSCTPからメッセージを受信した場合、M2PAはメッセージを破棄します。
For message types other than User Data, the Forward Sequence Number is set to the FSN of the last User Data message sent.
ユーザデータ以外のメッセージタイプの場合、転送シーケンス番号は送信された最後のユーザデータメッセージのFSNに設定されます。
If M2PA receives a User Data message with an FSN that is out of order, M2PA SHALL discard the message.
M2PAが故障しているFSNでユーザーデータメッセージを受信した場合、M2PAはメッセージを破棄する。
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に折り返されていることに注意する必要があります。
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は次のユーザーデータメッセージを送信してメッセージを確認する必要があります。確認するメッセージがある場合に送信できるユーザーデータメッセージがない場合、M2PAは遅延なしでデータペイロードなしでユーザーデータメッセージを生成して送信する必要があります。（言い換えれば、MTP2がFISUでメッセージを確認する場合、M2PAは空のユーザーデータメッセージを使用してメッセージを確認する必要があります。）この空のユーザーデータメッセージのFSNはインクリメントされません。データを含む最後に送信されたユーザーデータメッセージと同じFSNを含める必要があります。確認応答を遅らせると、SS7の性能が低下する可能性があります。
If M2PA receives an empty User Data message, it SHALL NOT send an acknowledgement of that message.
M2PAが空のユーザデータメッセージを受信した場合、そのメッセージの確認応答を送信してはなりません。
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.
これらのメッセージは切り替えのために取得されず、タイマT7がそれらに適用されないので、リンクステータスメッセージまたは空のユーザデータメッセージをM2PA RESTRASSMITバッファに配置する理由はないことに注意してください。
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は、確認されるまで、送信されたユーザデータメッセージを再送信キューに保持するものとする。これらのメッセージは、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ネットワークよりも変動しているため、MTP2のように単一のT7タイマ（承認の過度の遅延）が不十分です。T7値に等しい期間の後にメッセージが未確知されていない場合は、T7タイマーが期限切れになります。
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は、MTP3、例えばQ.704 [Q.704]、Section 3.8のシグナリングリンク送信輻輳の要件に従って、そのバッファ内の送信輻輳を検出するものとします。
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:
切り替えの目的は、メッセージ損失、複製、または誤シーケンスを回避しながら、使用不可のシグナリングリンクによって運ばれるシグナリングトラフィックができるだけ早く代替シグナリングリンクに転送されるようにすることです。この目的のために、切替手順はデータ検索を含み、これはデータ検索を含み、これは転送されたトラフィックへの代替シグナリングリンクを開く前に実行される。データ検索はこれらのステップで構成されています。
(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によって受信されていない未送受信されたシグナリングリンクの再送信バッファ、ならびに未転送メッセージの再送信バッファ内のすべてのユーザデータメッセージを識別する。
(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.
データを含むユーザーデータメッセージのみが取得され、代替リンクを介して送信されることに注意してください。リンクステータスメッセージと空のユーザデータメッセージは、代替リンクを検索して送信してはならない。
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のシーケンス番号は24ビット長です。MTP2の前方および後方シーケンス番号はわずか7ビットの長さです。したがって、MTP3がより大きなシーケンス番号を収容することが必要である。これは、切り替え順序（COO）および切り替え確認応答（COA）メッセージの代わりに、拡張切替順序（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からの検索要求とFSNC要求を受信した場合、M2PAはそのバッファから取得し、MTP3に順次配信します。
(a) any transmitted User Data messages beginning with the first unacknowledged message with FSN greater than FSNC.
(a) FSNCよりも大きいFSNを持つ最初の未確認メッセージで始まる送信されたユーザーデータメッセージ。
(b) any untransmitted User Data messages.
(b) 翻訳されていないユーザーデータメッセージ。
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は代替リンクで送信するための未送信メッセージのみを取得します。M2PAがFSNC値のない検索要求とFSNC要求を受け取った場合、または無効なFSNCを使用して、M2PAはそのバッファから取得し、MTP3に順番に配信されます。
(a) any untransmitted User Data messages.
(a) 翻訳されていないユーザーデータメッセージ。
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バージョンは、検索要求（検索要求とFSNC）を持っています。検索により、MTP3は、代替リンク上の送信のために未送信のメッセージと未確認の両方のメッセージの両方を検索することができます。このバージョンのMTPでは、M2PAが検索要求を受信した場合、M2PAはそのバッファから取得し、MTP3に順番に配信します。
(a) any transmitted but unacknowledged User Data messages.
(a) 送信されていないユーザーデータメッセージ。
(b) any untransmitted User Data messages.
(b) 翻訳されていないユーザーデータメッセージ。
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がリンクの一方向に複数のユーザデータストリームを持つことが問題になります。バッファの更新は、重複またはメッセージの損失を回避するために、各ユーザデータストリームに対して別々に行われなければならないであろう。しかし、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レイヤでのユーザデータメッセージのシーケンス番号付けでも、各ストリームでバッファ更新を実行する必要がある。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.
複数のユーザーデータストリームとのM2PAリンクはMTP3で複数のBSNT XCO / XCAメッセージが定義されている場合、またはMTP3が切り替え中に複数のXCO / XCAメッセージ（各ユーザーデータストリームに対して1つ）を送信できる場合に可能です。これはこの文書の範囲を超えています。
Some M2PA procedures may be affected by the use of SCTP as a transport layer. These considerations are discussed in this section.
いくつかのM2PA手順は、輸送層としての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再送タイマーによって検出された損失を修復した後に、アソシエーションから始まるとき。
It is possible that transmission of M2PA messages MAY be delayed by SCTP slow start under certain conditions, including the following:
次の条件を含む特定の条件下でSCTPスロースタートによってM2PAメッセージの送信が遅れる可能性がある可能性があります。
(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のパフォーマンスにどのように影響するかに気づくべきです。場合によっては、遅い開始の悪影響を回避することが可能かもしれません。たとえば、証明期間中に送信されたリンクステータス証明メッセージを使用して、リンクがサービス内に配置される前にスロースタートを完了できます。
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.705]。M2PAとSCTP間の通信は、SCTPの用語を使用して名前が付けられています。
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が初期化されていると想定されます。
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 . . .
. . . . . .
Proving period begins.
証明期間が始まります。
Figure 11. Example: Link Initialization - Alignment
図11.例：リンクの初期化 - 位置合わせ
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 . . .
. . . . . .
Send Link Status Ready (one or more) and wait for the remote end to complete its proving period.
リンクステータスの準備ができて（1つ以上）、リモートエンドが証明期間を完了するのを待ちます。
. . . . . .
. Start timer T1 . . .
. . . . . .
. Link Status Ready . . .
. ------------------------------------> .
. . . . . .
. . . . . .
. . . Link Status Ready .
. <------------------------------------ .
. . . . . .
. Stop timer T1 . . .
. . . . . .
In Service . . In Service
<------------ . . ------------>
. . . . . .
MTP3 MAY begin sending data messages.
MTP3はデータメッセージの送信を開始することがあります。
Figure 12. Example: Link Initialization - Proving
図12.例：リンクの初期化 - 証明されています
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へのデータ要求プリミティブを使用して送信されます。図13は、リンクがサービス内の場合を示しています。メッセージは、送信元のMTP3から宛先のMTP3に渡されます。
MTP3 M2PA SCTP SCTP M2PA MTP3
---- ---- ---- ---- ---- ----
. . . . . .
Message for . . . .
transmission . . . .
------------> . . . .
. . . . . .
. Send . . . .
. (Data Message) . . .
. ------------> . . .
. . . . . .
. . (SCTP sends message) . .
. . . . . .
. . . Receive .
. . . ------------> .
. . . . . .
. . . . Received message
. . . . ------------>
. . . . . .
Figure 13. Example: Link Initialization - In Service
図13.例：リンク初期化 - サービス内
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.
リンクステータス表示の例を図14に示します.SCTPがM2PAへの通信損失プリミティブを送信する場合、M2PAはMTP3にリンクが不足していることを通知します。MTP3は通常の方法で応答します。
MTP3 M2PA SCTP SCTP M2PA MTP3
---- ---- ---- ---- ---- ----
. . . . . .
. Communication Lost . . .
. <------------ . . .
. . . . . .
Out of Service . . . .
<------------ . . . .
. . . . . .
Figure 14. Example: Link Status Indication
図14.例：リンクステータス表示
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はリンクステータスメッセージをそのピアに送信します。ピア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 . . .
. ------------------------------------> .
. . . . . .
Figure 15. Example: Link Status Message - Processor Outage
図15.例：リンクステータスメッセージ - プロセッサの停止
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は、プロセッサの停止の例をより詳細に示しています。この例のすべてのM2PAメッセージはデータストリーム（Stream 1）で送信されます。
A 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 .
. <------------------------------------ .
Side A detects LPO.
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 .
. . . . ------------>
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.
LPOでは、それらを認めずにメッセージ14-16をバッファする必要があります。Aは、MTP3からメッセージを送信し、LPOの前に受信されたメッセージを確認し続けることができる。
. . . . . .
. User Data FSN=4 BSN=13 . . .
. ------------------------------------> .
. User Data FSN=5 BSN=13 . . .
. ------------------------------------> .
. User Data 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.
RPOでは、Bはメッセージを承認し続けることがあります。Bがメッセージ4および5を受信したが、まだ処理されていないと仮定する。
. . . . . .
. (empty) User Data FSN=16 BSN=4
. <------------------------------------ .
. (empty) User Data FSN=16 BSN=5
. <------------------------------------ .
LPO ends at A. A flushes 14-16 (the messages that were buffered without acknowledgement).
LPOはAで終わります.16（肯定応答なしにバッファされていたメッセージ）。
. . . . . .
. LS PR FSN=6 BSN=13 . . .
. ------------------------------------> .
. . . . Remote Processor
. . . . Outage Ceases
. . . . ------------>
. . . . . .
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リンクステータスレディメッセージ設定BSN = 5、Bで処理された最後のメッセージを使用して、これをAに通知します。
. . . . . .
. . . . . .
. . . LS Ready 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準備完了を送信しているので、この時点でデータの送信データを新しいシーケンス番号（FSN = 14から始めて）再開することができます。
. . . . . .
. . . . . Message for
. . . . transmission
. . . . <------------
. . . User Data 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は、次のユーザデータメッセージで、そのシーケンス番号を再同期するためにリンクステータスレディ情報を使用して、そのシーケンス番号を再同期することができる。
. . . . . .
. LS Ready 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はシーケンス番号の同期を完了し、READERを受信して送信しているので、この時点でデータの送信を新しいシーケンス番号で再開し、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) . .
. ------------------------------------> .
. . . . . .
. . . . . .
. . . . . .
Figure 16. Example: Processor Outage and Recovery
図16.例：プロセッサの停止と回復
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は、レベル2の流れ制御手順を示す。図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 .
. . . . . .
Figure 17. Example: Level 2 Flow Control - Congestion Ceases
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
. . . . ------------>
. . . . . .
Figure 18. Example: Level 2 Flow Control - Timer T6 Expires
図18.例：レベル2フロー制御 - タイマT6期限切れ
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の輻輳発症と減除を通知します。輻輳レベルが定義されている場合は、通知に輻輳レベルが含まれています。
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) . . . . .
<------------ . . . .
. . . . . .
Figure 19. Example: MTP3 Signaling Link Congestion
図19.例：MTP3シグナリングリンク輻輳
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 . . . .
<------------ . . . .
. . . . . .
Figure 20. Example: Link Deactivation
図20.例：リンク無効化
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では、未確認のメッセージと未送信のメッセージを再送信するための別のリンクを選択します。
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.
Figure 21. Example: Link Changeover
図21.例：リンクの切り替え
M2PA is designed to carry signaling messages for telephony services. As such, M2PA MUST involve the security needs of several parties:
M2PAは、テレフォニーサービスのシグナリングメッセージを運ぶように設計されています。そのように、M2PAはいくつかの締約国のセキュリティニーズを含みなければなりません：
- 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.
これらの当事者はいくつかの重複するセキュリティニーズを持つかもしれませんが、それらのニーズは同一ではないかもしれません。セキュリティソリューションはすべての異なる当事者のニーズを満たすべきです。
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の実装者は[RFC3788]のガイドラインに従う必要があります。
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登録ユーザポート番号割り当ては3565です.TCP登録ユーザーポート番号3565は、M2PA over TCPの指定が作成された場合には、M2PAに割り当てられています。
The value assigned by IANA for the Payload Protocol Identifier in the SCTP Payload Data chunk is
SCTPペイロードデータチャンク内のペイロードプロトコルIDのIANAによって割り当てられた値は
M2PA 5
M2PA 5.
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ペイロードプロトコル識別子は各SCTPデータチャンクに含まれています。このペイロードプロトコル識別子はSCTPによって直接使用されていませんが、データチャンクで運ばれる情報の種類を識別するために特定のネットワークエンティティによって使用されることがあります。
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.
ユーザ適応ピアは、SCTPによってそれに提示されているデータに関する追加情報を決定する方法としてペイロードプロトコル識別子を使用することができる。
This protocol may be extended through IANA in three ways:
このプロトコルは、3つの方法でIANAを通じて拡張することができます。
- 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コンセンサスアクションを介して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).
メッセージクラス、タイプ、およびパラメータの定義された値は、シグナリングユーザー適応レイヤレジストリ（Sigtran-Appation）にリストされています。
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) メッセージクラスの目的の詳細な説明。
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) このメッセージタイプを受信したときのエラー状態の詳細な説明。
When an implementation receives a message type that it does not support, it MUST discard the message.
実装がサポートされていないメッセージタイプを受信すると、メッセージを破棄する必要があります。
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) このパラメータタイプの意図された使用、およびどのような状況でもかかわらず、このパラメータタイプの複数のインスタンスが同じメッセージタイプ内に見つかる可能性があります。
This section lists the values defined in this document that should be included in the Signaling User Adaptation Layer registry (sigtran-adapt).
このセクションでは、シグナリングユーザー適応レイヤレジストリ（Sigtran-Adapt）に含める必要があるこのドキュメントで定義されている値をリストします。
The following values for Message Class are defined in this document:
このドキュメントでは、メッセージクラスの次の値が定義されています。
Value
(decimal) Message Class
--------- -------------
11 M2PA Messages
The following values for Message Type are defined in this document:
このドキュメントには、メッセージタイプの次の値が定義されています。
Value
(decimal) Message Type
--------- -------------
1 User Data
2 Link Status
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.
著者らは、彼らの貴重なコメントや提案のために次のように感謝したいと思います：Brian Tatum、Wayne Davis、Cliff Thomas、Jeff Copley、Monique Bernard、Malleswar Kalla、Ian Rytina、Greg SideBottom、Al Varney、Jeff Craig、およびAndrewブース。
[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規格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規格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、「シグナリングシステム番号7 - シグナリングリンク」、ITU-T勧告Q.703、ITUのITU-T電気通信標準化部門（1996年7月）。
[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のITUの電気通信標準化部門（1996年7月）。
[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 ATM適応層 - ネットワークノードインタフェース（NNIのSSCFでシグナリングするためのサービス固有の調整機能）」、ITUのITU - T電気通信標準化部門（ITU - T勧告Q.214）1995年2月）。
[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.214」、「ITU-T勧告Q.2210、ITU-T電気通信標準化部門（1996年7月）。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791] Postel、J.、「インターネットプロトコル」、STD 5、RFC 791、9月1981日。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S、「RFCで使用するためのキーワード」、BCP 14、RFC 2119、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.Lavestrand、「RFCSのIANAに関する考察のためのガイドライン」、BCP 26、RFC 2434、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] Stewart、R。、XIE、Q.、MorneAlt、K.、Sharp、C.、Schwarzbauer、H.、Taylor、T.、Rytina、I。、Kalla、M.、Zhang、L.、およびV。Paxson、「ストリーム制御伝送プロトコル」、RFC 2960、2000年10月。
[RFC3309] Stone, J., Stewart, R., and D. Otis, "Stream Control Transmission Protocol (SCTP) Checksum Change", RFC 3309, September 2002.
[RFC3309] Stone、J.、Stewart、R.およびD. OTIS、「ストリーム制御伝送プロトコル（SCTP）チェックサム変更」、2002年9月、RFC 3309。
[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.Pastor-Balbas、「シグナル伝達輸送（Sigtran）プロトコルのセキュリティ上の考察」、RFC 3788、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、「電気通信のためのアメリカ国家規格 - シグナリングシステム7（SS7） - メッセージ転送部（MTP）、ANSI T1.111-2001、Analive National Standards Institute（2001年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. MorneAltら。「シグナリングシステム7（SS7）メッセージ転送部2（MTP2） - ユーザ適応層、RFC 3331、インターネットエンジニアリングタスクフォース - シグナリングトランスポートワーキンググループ（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シグナリングシステム第7号の概要」、ITU-T勧告Q.700、ITUの電気通信標準化部門（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、「シグナリングシステム第7号のメッセージ転送部（MTP）の機能説明、ITU - T勧告Q.701、ITUのITU - T電気通信標準化部門（1993年3月）。
[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のITUの電気通信標準化部門（1988年11月）。
[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のITU通信標準化部門（1993年3月）。
[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] ON、L.、RyTina、I.、Garcia、M.、Schwarzbauer、H.、Coene、L.、Lin、H.、Juhasz、I.、Holdrege、M.、C. Sharp、 "Framework1999年10月、RFC 2719、Signaling Transportのアーキテクチャ。
Authors' Addresses
著者の住所
Tom George Plano, TX USA
トムジョージプラノ、TX USA
Phone: +1-972-985-4594
EMail: tgeorge_tx@verizon.net
Brian Bidulock OpenSS7 Corporation 1469 Jeffreys Crescent Edmonton, AB T6L 6T1 Canada
Brian Bidulock OpenSS7 Corporation 1469 Jeffreys Crescent Edmonton、AB T6L 6T1カナダ
Phone: +1-780-490-1141
EMail: bidulock@openss7.org
Ram Dantu, Ph.D. Assistant Professor Department of Computer Science University of North Texas Denton, TX 76203 USA
Ram Dantu、Ph.D。アシスタント教授北テキサス州大学Denton、TX 76203 USA
Phone: +1-940-565-2822
EMail: rdantu@unt.edu
Hanns Juergen Schwarzbauer SIEMENS AG Hofmannstr. 51 81359 Munich Germany
Hanns Juergen Schwarzbauer Siemens Ag Hofmannstr。51 81359ミュンヘンドイツ
Phone: +49-89-722-24236
EMail: HannsJuergen.Schwarzbauer@Siemens.com
Ken Morneault Cisco Systems Inc. 13615 Dulles Technology Drive Herndon, VA 20171 USA
Ken MorneAlt Cisco Systems Inc. 13615 Dulles Technology Drive Herndon、VA 20171 USA
Phone: +1-703-484-3323
EMail: kmorneau@cisco.com
Full Copyright Statement
完全著作権宣言
Copyright (C) The Internet Society (2005).
著作権（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.
この文書は、BCP 78に含まれている権利、ライセンス、制限の対象となり、その中に述べた場合を除き、著者らはすべての権利を保持しています。
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.
この文書と本明細書に含まれる情報は、「現状のまま」基準で提供されており、投稿者、または（いずれかの場合）、インターネット社会とインターネットエンジニアリングのタスクフォースがすべての保証を損なう、または本明細書における情報の使用が、特定の目的のためのあらゆる権利または黙示の保証を侵害しないことを含むがこれらに限定されないが、これに限定されない。
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は、IETFを取りません。利用可能です。そのような権利を特定するためにそれが独立した努力をしたことを表していません。RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79にあります。
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.
IETF事務局へのIETF事務局と利用可能なライセンスの保証のコピー、またはこの仕様書の実装者や利用者による一般的なライセンスまたは許可を得るための試みの結果を得ることができます。IETFオンラインIPRリポジトリからhttp://www.ietf.org/ipr。
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エディタ機能のための資金は、現在インターネット社会によって提供されています。