[要約] RFC 3094は、TekelecのTransport Adapter Layer Interface（TALI）に関する仕様書であり、TALIの目的は、異なるネットワーク要素間の通信を効率的に行うための標準化されたインターフェースを提供することです。
Network Working Group D. Sprague
Request for Comments: 3094 R. Benedyk
Category: Informational D. Brendes
J. Keller
Tekelec
April 2001
Tekelec's Transport Adapter Layer Interface
Tekelecのトランスポートアダプターレイヤーインターフェイス
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
IESG Note:
IESGノート：
Readers should note that this memo presents a vendor's alternative to standards track technology being developed by the IETF SIGTRAN Working Group. The technology presented in this memo has not been reviewed by the IETF for its technical soundness or completeness. Potential users of this type of technology are urged to examine the SIGTRAN work before deciding to use the technology described here.
読者は、このメモがIETF Sigtranワーキンググループによって開発されている標準追跡テクノロジーに代わるベンダーの代替案を提示していることに注意する必要があります。このメモで提示された技術は、IETFによって技術的な健全性や完全性についてレビューされていません。このタイプのテクノロジーの潜在的なユーザーは、ここで説明するテクノロジーを使用することを決定する前に、Sigtranの作業を調べることをお勧めします。
Abstract
概要
This document proposes the interfaces of a Signaling Gateway, which provides interworking between the Switched Circuit Network (SCN) and an IP network. Since the Gateway is the central point of signaling information, not only does it provide transportation of signaling from one network to another, but it can also provide additional functions such as protocol translation, security screening, routing information, and seamless access to Intelligent Network (IN) services on both networks.
このドキュメントでは、Switched Circuit Network（SCN）とIPネットワークの間のインターワーキングを提供する信号ゲートウェイのインターフェイスを提案します。ゲートウェイはシグナリング情報の中心的なポイントであるため、あるネットワークから別のネットワークへのシグナリングの輸送を提供するだけでなく、プロトコル翻訳、セキュリティスクリーニング、ルーティング情報、インテリジェントネットワークへのシームレスなアクセスなどの追加機能を提供することもできます（in）両方のネットワーク上のサービス。
The Transport Adapter Layer Interface (TALI) is the proposed interface, which provides TCAP (Transaction Capability Application Part), ISUP (ISDN User Part), and MTP (Mail Transport Protocol) messaging over TCP/IP. In addition, TALI provides SCCP (Signalling Connection Control Part) Management (SCMG), MTP Primitives, dynamic registration of circuits, and routing of call control messages based on circuit location.
Transport Adapter Layer Interface（TALI）は、TCP/IPを介したTCAP（トランザクション機能アプリケーションパーツ）、ISUP（ISDNユーザーパーツ）、およびMTP（Mail Transport Protocol）メッセージングを提供する提案されたインターフェイスです。さらに、TALIは、SCCP（シグナリング接続制御部品）管理（SCMG）、MTPプリミティブ、回路の動的登録、および回路の場所に基づくコールコントロールメッセージのルーティングを提供します。
Table of Contents
目次
1. Introduction 4 2. Overview of the TALI Protocol 6 2.1 Traditional PSTN SS7 Networks 6 2.2 Converged SS7 Networks 8 2.3 TALI Protocol Stack Overview 10 2.3.1 An Alternate TALI Protocol Stack using the SAAL Layer 13 2.3.2 An Alternate TALI Protocol Stack using SCTP 15 2.4 Inputs to the TALI Version 1.0 State Machine 15 3. TALI Version 1.0 17 3.1 Overview of the TALI Message Structure 17 3.1.1 Types of TALI Fields 19 3.2 Detailed TALI Message Structure 20 3.2.1 TALI Peer to Peer Messages 20 3.2.1.1 Test Message (test) 20 3.2.1.2 Allow Message (allo) 21 3.2.1.3 Prohibit Message (proh) 21 3.2.1.4 Prohibit Acknowledgement Message (proa) 21 3.2.1.5 Monitor Message (moni) 22 3.2.1.6 Monitor Acknowledge Message (mona) 22 3.2.2 Service Messages 23 3.2.2.1 SCCP Service Message (sccp) 23 3.2.2.1.1 SCCP Encapsulation using TALI 25 3.2.2.2 ISUP Service Message (isot) 27 3.2.2.2.1 ISUP Encapsulation using TALI 27 3.2.2.3 MTP3 Service Message (mtp3) 28 3.2.2.3.1 MTP3 Encapsulation using TALI 29 3.2.2.4 SAAL Service Message (saal) 30 3.2.2.4.1 MTP3 and SAAL Peer to Peer Encapsulation using TALI 31 3.3 TALI Timers 34 3.3.1 T1 Timer 34 3.3.2 T2 Timer 34 3.3.3 T3 Timer 34 3.3.4 T4 Timer 34 3.3.5 Recommended Defaults and Ranges for the TALI Timers 35 3.4 TALI User Events 35 3.4.1 Management Open Socket Event 35 3.4.2 Management Close Socket Event 36 3.4.3 Management Allow Traffic Event 36 3.4.4 Management Prohibit Traffic Event 36 3.5 Other Implementation Dependent TALI Events 37 3.6 TALI States 37 3.7 TALI Version 1.0 State Machine 38 3.7.1 State Machine Concepts 38 3.7.1.1 General Protocol Rules 38 3.7.1.2 Graceful Shutdown of a Socket 39 3.7.1.3 TALI Protocol Violations 39 3.7.2 The State Machine 40 3.8 TALI 1.0 Implementation Notes 42 3.8.1 Failure on a TCP/IP Socket 42 3.8.2 Congestion on a TCP/IP Socket 43 3.9 TALI 1.0 Limitations 43 4. TALI Version 2.0 43 4.1 Overview of TALI Version 2.0 Features 45 4.2 TALI Version Identification 47 4.3 Backwards Compatibility 50 4.3.1 Generating Protocol Violations based on Received Messages 53 4.4 Overview of the TALI Message Structure 55 4.4.1 Types of TALI Fields 55 4.5 Detailed TALI Message Structures for New 2.0 Opcodes 58 4.5.1 Management Message (mgmt) 60 4.5.1.1 Routing Key Registration Primitive (rkrp) 61 4.5.1.1.1 RKRP Data Structures 65 4.5.1.1.1.1 Common Fields in all RKRP Messages 65 4.5.1.1.1.2 CIC Based Routing Key Operations 67 4.5.1.1.1.3 SCCP Routing Key Operations 71 4.5.1.1.1.4 DPC-SI, DPC and SI based Routing Key Operations 74 4.5.1.1.1.5 Default Routing Key Operations 76 4.5.1.1.1.6 Support for Multiple RKRP Registration Operations 78 4.5.1.1.1.6.1 Multiple Registrations Support 78 4.5.1.1.1.6.2 Multiple RKRP Operations in a Single Message 80 4.5.1.2 MTP3 Primitive (mtpp) 82 4.5.1.3 Socket Option Registration Primitive (sorp) 87 4.5.2 Extended Service Message (xsrv) 91 4.5.3 Special Message (spcl) 92 4.5.3.1 Special Messages Not Supported (smns) 93 4.5.3.2 Query Message (qury) 93 4.5.3.3 Reply Message (rply) 94 4.5.3.4 Unsolicited Information Message (USIM) 95 4.6 TALI Timers 95 4.7 TALI User Events 95 4.8 TALI States 96 4.9 TALI Version 2.0 State Machine 96 4.9.1 State Machine Concepts 96 4.9.1.1 General Protocol Rules 96 4.9.1.2 Graceful Shutdown of a Socket 97 4.9.1.3 TALI Protocol Violations 97 4.9.2 The State Machine 97 4.10 TALI 2.0 Specification Limitations 101 5. Success/Failure Codes 101 6. Security Considerations 102 7. References 102 8. Acknowledgments 103 9. Authors' Addresses 104 10. Full Copyright Statement 105
1. はじめに4 2. TALIプロトコルの概要6 2.1従来のPSTN SS7ネットワーク6 2.2収束SS7ネットワーク8 2.3 TALIプロトコルスタックの概要10 2.3.1 SAALレイヤーを使用した代替タリプロトコルスタック13 2.3.2代替タリプロトコルスタックを使用した代替タリプロトコルスタック15 TALIバージョンへの入力1.0ステートマシン15 3.タリバージョン1.0 17 3.1タリメッセージ構造の概要17 3.1.1タリフィールドの種類19 3.2詳細なタリメッセージ構造20 3.2.1 Tali Peer to Peerメッセージ20 3.2。1.1テストメッセージ（テスト）20 3.2.1.2許容メッセージ（Allo）21 3.2.1.3を許可するメッセージ（PROH）21 3.2.1.4禁止承認メッセージ（PROA）21 3.2.1.5モニターメッセージ（MONI）22 3.2.1.6モニター確認メッセージ（MONA）22 3.2.2サービスメッセージ23 3.2.2.1 SCCPサービスメッセージ（SCCP）23 3.2.2.1.1 TALIを使用したSCCPカプセル化25 3.2.2.2 ISUPサービスメッセージ（ISOT）27 3.2.2.2.23.2.2.3 MTP3サービスメッセージ（MTP3）28 3.2.2.3.1 TALIを使用したMTP3のカプセル化29 3.2.2.4 Saal Serviceメッセージ（SAAL）30 3.2.2.4.1 MTP3およびSaal Peer to Peerカプセル31 3.3 3.3 Tali Timers 34 3.33 34 3.33.1 T1タイマー34 3.3.2 T2タイマー34 3.3.3 T3タイマー34 3.3.4 T4タイマー34 3.3.5 TALIタイマーの推奨デフォルトと範囲35 3.4 TALIユーザーイベント35 3.4.1管理ソケットイベント35 3.4。2管理閉鎖イベント36 3.4.3管理許可イベント36 3.4.4管理禁止トラフィックイベント36 3.5その他の実装依存タリイベント37 3.6タリステート37 3.7タリバージョン1.0ステートマシン38 3.7.1ステートマシンの概念38 3.7.1.1一般的なプロトコルルール38 3.7.1.2ソケットの優雅なシャットダウン39 3.7.1.3タリプロトコル違反39 3.7.2ステートマシン40 3.8 TALI 1.0実装ノート42 3.8.1 TCP/IPソケットの障害TCP/IPソケット43 3.9 TALI 1.0制限43 4. TALIバージョン2.0 43 4.1 TALIバージョン2.0機能45 4.2 TALIバージョン識別47 4.3後方互換性50 4.3.1受信メッセージに基づくプロトコル違反の生成53 4.4 TALIメッセージの概要構造55 4.4.1タリフィールドの種類55 4.5新しい2.0オプコードの詳細なタリメッセージ構造58 4.5.1管理メッセージ（MGMT）60 4.5.1.1ルーティングキー登録プリミティブ（RKRP）61 4.5.1.1.1 RKRPデータ構造65 4.5.1.1.1.1すべてのRKRPメッセージの共通フィールド65 4.5.1.1.1.2 CICベースのルーティングキー操作67 4.5.1.1.1.1.3 SCCPルーティングキー操作71 4.5.1.1.1.1.4 DPC-SI、DPCおよびSIベースのルーティングキー操作74 4.5 4.5.1.1.1.5デフォルトルーティングキー操作76 4.5.1.1.1.6複数のRKRP登録操作のサポート78 4.5.1.1.1.6.1複数の登録サポート78 4.5.1.1.1.6.2MTP3 Primitive（MTPP）82 4.5.1.3ソケットオプション登録プリミティブ（SORP）87 4.5.2拡張サービスメッセージ（XSRV）91 4.5.3特別なメッセージ（SPCL）92 4.5.3.1特別なメッセージがサポートされていない（SMNS）93 4.5.3.2クエリメッセージ（Qury）93 4.5.3.3返信メッセージ（rply）94 4.5.3.4未承諾情報メッセージ（USIM）95 4.6 Tali Timers 95 4.7 Taliユーザーイベント95 4.8 TALI STASE 96 4.9 TALIバージョン2.0ステートマシン96 4.9.1ステートマシン概念96 4.9.1.1一般的なプロトコルルール96 4.9.1.2ソケットの優雅なシャットダウン97 4.9.1.3タリプロトコル違反97 4.9.2ステートマシン97 4.10 TALI 2.0仕様制限101 5.成功/障害コード101 6.セキュリティ1027.参考文献102 8.謝辞103 9.著者のアドレス104 10.完全な著作権声明105
This document is organized into the following 6 sections:
このドキュメントは、次の6つのセクションに編成されています。
- Introduction to the document - Overview of the TALI Protocol - TALI Version 1.0 - TALI Version 2.0 - Success/Failure Codes - Security Considerations
- ドキュメントの紹介 - タリプロトコルの概要 - タリバージョン1.0-タリバージョン2.0-成功/失敗コード - セキュリティ上の考慮事項
The following terms are used throughout this document.
このドキュメント全体で次の用語が使用されています。
Circuit Identification Code (CIC): A field identifying the circuit being setup or released. Depending on SI and MSU Type, this field can be 12, 14 or 32 bits.
回路識別コード（CIC）：セットアップまたはリリースされている回路を識別するフィールド。SIおよびMSUタイプに応じて、このフィールドは12、14、または32ビットになります。
Changeover/Changeback (co/cb): SS7 MTP3 procedure related to link failure and re-establishment.
変更/チェンジバック（CO/CB）：リンクの障害と再確立に関連するSS7 MTP3手順。
Far End (FE): The remote endpoint of a socket connection.
ファーエンド（FE）：ソケット接続のリモートエンドポイント。
Far End Allowed (FEA): The FE is ready to use the socket for service PDUs.
ファーエンド許可（FEA）：FEは、サービスPDUにソケットを使用する準備ができています。
Far End Prohibited (FEP): The FE is not ready to use the socket for service PDUs.
ファーエンド禁止（FEP）：FEは、サービスPDUにソケットを使用する準備ができていません。
Intelligent Network (IN): A network that allows functionality to be distributed flexibly at a variety of nodes on and off the network and allows the architecture to be modified to control the services.
インテリジェントネットワーク（in）：ネットワークの上および外れのさまざまなノードで機能を柔軟に配布できるネットワークを使用し、アーキテクチャを変更してサービスを制御できるようにします。
Management ATM Adaptation Layer (MAAL): This layer is a component of SAAL. This layer maps requests and indications between the System Management for the SG and the other SAAL layers. MAAL includes interfaces to/from SSCOP, SSCF, and system management. More information can be found in T1.652.
管理ATM適応層（MAAL）：このレイヤーはSAALのコンポーネントです。このレイヤーは、SGのシステム管理と他のSAALレイヤーの間のリクエストと適応症をマップします。Maalには、SSCOP、SSCF、およびシステム管理へのインターフェイスが含まれます。詳細については、T1.652をご覧ください。
Media Gateway (MG): A MG terminates SCN media streams, packetizes the media data, if it is not already packetized, and delivers packetized traffic to the packet network. It performs these functions in reverse order for media streams flowing from the packet network to the SCN.
Media Gateway（MG）：MGは、SCNメディアストリームを終了し、メディアデータがまだパケット化されていない場合にパケット化し、パケット化されたトラフィックをパケットネットワークに配信します。これらの機能をパケットネットワークからSCNに流れるメディアストリームを逆順に実行します。
Media Gateway Controller (MGC): An MGC handles the registration and management of resources at the MG. The MGC may have the ability to authorize resource usage based on local policy. For signaling transport purposes, the MGC serves as a possible termination and origination point for SCN application protocols, such as SS7 ISDN User Part and Q.931/DSS1.
Media Gateway Controller（MGC）：MGCは、MGでのリソースの登録と管理を処理します。MGCは、ローカルポリシーに基づいてリソース使用を承認する機能を備えている場合があります。シグナリング輸送の目的で、MGCは、SS7 ISDNユーザーパーツやQ.931/DSS1などのSCNアプリケーションプロトコルの終了と発信点として機能します。
MTP3 Framing (MTP3F): TALI does not require full MTP3 procedures support but rather uses the MTP3 framing structure (ie: SIO, Routing Label, etc)
MTP3フレーミング（MTP3F）：TALIは完全なMTP3手順サポートを必要とせず、MTP3フレーミング構造（つまり、SIO、ルーティングラベルなど）を使用しています。
Near End (NE): The local endpoint of a socket connection.
近端（NE）：ソケット接続のローカルエンドポイント。
Near End Allowed (NEA): The NE is ready to use the socket for service PDUs.
近端許容（NEA）：NEは、サービスPDUにソケットを使用する準備ができています。
Near End Prohibited (NEP): The NE is not ready to use the socket for service PDUs.
ほぼ終了禁止（NEP）：NEは、サービスPDUにソケットを使用する準備ができていません。
Q.BICC ISUP: An ISUP+ variant that uses 32 bit CIC codes instead of 14/12 bit CIC codes. ISUP+, or Q.BICC ISUP, is based on the Q.765.BICC specification currently being developed in ITU Study Group 11.
Q.BICC ISUP：14/12ビットCICコードの代わりに32ビットCICコードを使用するISUPバリアント。ISUP、またはQ.BICC ISUPは、現在ITU研究グループ11で開発されているQ.765.BICC仕様に基づいています。
Signaling ATM Adaptation Layer (SAAL): This layer is the equivalent of MTP-2 for ATM High Speed Links carrying SS7 Traffic as described in GR-2878-CORE [8]. SAAL includes SSCF, SSCOP and MAAL.
Signaling ATM適応層（SAAL）：このレイヤーは、GR-2878-Core [8]で説明されているように、SS7トラフィックを運ぶATM高速リンクのMTP-2に相当します。SaalにはSSCF、SSCOP、MAALが含まれます。
Signaling Gateway (SG): An SG is a signaling agent that receives/sends SCN native signaling at the edge of the IP network. The SG function may relay, translate or terminate SS7 signaling in an SS7-Internet Gateway. The SG function may also be co-resident with the MGC/MG functions to process SCN signaling associated with line or trunk terminations controlled by the MG (e.g., signaling backhaul).
Signaling Gateway（SG）：SGは、IPネットワークの端でSCNネイティブシグナル伝達を受信/送信するシグナル伝達剤です。SG機能は、SS7インターネットゲートウェイでSS7シグナル伝達を中継、翻訳、または終了する場合があります。SG関数は、MGC/MG関数の共同住宅であり、MGによって制御されるラインまたはトランク終端に関連するSCNシグナル伝達を処理することもできます（たとえば、シグナリングバックホール）。
Service Specific Coordination Function (SSCF): This layer is a component of SAAL. This layer maps the services provided by the lower layers of the SAAL to the needs of a specific higher layer user. In the case of the STP, the higher layer user is the MTP-3 protocol, and the SSCF required is that as defined by T1.645: SSCF for Support of Signaling at the Network Node Interface (SSCF at the NNI). More information can be found in T1.645. SSCF provides the interface between SSCOP and MTP3 and includes the following functions:
サービス固有の調整関数（SSCF）：このレイヤーはSAALのコンポーネントです。このレイヤーは、SAALの下層が特定の高層ユーザーのニーズに合わせて提供するサービスをマッピングします。STPの場合、高層ユーザーはMTP-3プロトコルであり、必要なSSCFは、ネットワークノードインターフェイス（NNIのSSCF）でのシグナリングをサポートするためにT1.645：SSCFで定義されているとおりです。詳細については、T1.645をご覧ください。SSCFは、SSCOPとMTP3の間のインターフェイスを提供し、次の機能を含みます。
- Local Retrieve of messages to support link changeover procedures - Flow control with four levels of congestion
- リンクの切り替え手順をサポートするためのメッセージのローカル取得 - 4つのレベルの輻輳を伴うフロー制御
Switched Circuit Network (SCN): The term SCN is used to refer to a network that carries traffic within channelized bearers of pre-defined sizes. Examples include Public Switched Telephone Networks (PSTNs) and Public Land Mobile Networks (PLMNs). Examples of signaling protocols used in SCN include Q.931, SS7 MTP Level 3 and SS7 Application/User parts.
Switched Circuit Network（SCN）：SCNという用語は、事前に定義されたサイズのチャネル化されたベアラー内にトラフィックを運ぶネットワークを参照するために使用されます。例には、パブリックスイッチ付き電話ネットワーク（PSTN）と公共の土地モバイルネットワーク（PLMNS）が含まれます。SCNで使用されるシグナル伝達プロトコルの例には、Q.931、SS7 MTPレベル3、SS7アプリケーション/ユーザーパーツが含まれます。
Service Specific Connection Oriented Protocol (SSCOP): This layer is a component of SAAL. This layer provides reliable point to point data transfer with sequence integrity and error recovery by selective retransmission. Protocol layer interfaces are described in T1.637. Aspects of the protocol include flow control, connection control, error reporting to layer management, connection maintenance in the prolonged absence of data transfer, local data retrieval by the user of the SSCOP, error detection of protocol control information and status reporting. SSCOP provides the link layer functions that are:
サービス固有の接続指向プロトコル（SSCOP）：このレイヤーはSAALのコンポーネントです。このレイヤーは、選択的な再送信によるシーケンスの整合性とエラー回復を伴う信頼できるポイントデータ転送を提供します。プロトコル層インターフェイスは、T1.637で説明されています。プロトコルの側面には、フロー制御、接続制御、レイヤー管理へのエラーレポート、データ転送の長期にわたる接続メンテナンス、SSCOPのユーザーによるローカルデータ取得、プロトコル制御情報のエラー検出、およびステータスレポートが含まれます。SSCOPは、次のようなリンクレイヤー関数を提供します。
- In-Sequence Delivery - Flow Control - Error Detection/Correction - Keep Alive - Local Data Retrieval - Connection Control - Protocol Error Detection and Recovery
- シーケンス配信 - フロー制御 - エラー検出/修正 - 生存し続ける - ローカルデータの検索 - 接続制御 - プロトコルエラーの検出と回復
Signaling Transfer Point (STP): Packet switches that provide CCS message routing and transport. They are stored programmed switches that use information contained in the message in conjunction with information stored in memory to route the message to the appropriate destination signaling point.
シグナリングトランスファーポイント（STP）：CCSメッセージのルーティングとトランスポートを提供するパケットスイッチ。これらは、メッセージを適切な宛先信号ポイントにルーティングするために、メモリに保存された情報と併せてメッセージに含まれる情報を使用するプログラムされたスイッチを保存します。
The traditional PSTN SS7 network consists of 3 types of devices connected via dedicated SS7 signaling links.
従来のPSTN SS7ネットワークは、専用のSS7シグナリングリンクを介して接続された3種類のデバイスで構成されています。
The 3 primary device types for PSTN networks are:
PSTNネットワークの3つの主要なデバイスタイプは次のとおりです。
* SSP: Signaling Service Point. These nodes act as endpoints in the SS7 network, originating SS7 messages as users attempt to place phone calls. These nodes contain interfaces into the SS7 data network and the SS7 voice network.
* SSP：シグナリングサービスポイント。これらのノードは、SS7ネットワークのエンドポイントとして機能し、ユーザーが電話をかけようとしてSS7メッセージを発信します。これらのノードには、SS7データネットワークとSS7 Voiceネットワークへのインターフェイスが含まれています。
* STP: Signaling Transfer Point. These nodes act primarily as switches, switching SS7 traffic from node to node throughout the network until it reaches another endpoint. An important feature of each STP is to provide SS7 network management functionality that allows messages to be delivered even when links and devices fail. STPs also sometimes provide database type services, such as Global Title Translations and Local Number Portability.
* STP：シグナリング転送点。これらのノードは、主にスイッチとして機能し、ネットワーク全体でノードからノードにSS7トラフィックを切り替えて、別のエンドポイントに到達するまで切り替えます。各STPの重要な機能は、リンクとデバイスが失敗した場合でもメッセージを配信できるSS7ネットワーク管理機能を提供することです。STPSは、グローバルタイトル翻訳やローカル番号の移植などのデータベースタイプサービスも提供する場合があります。
* SCP: Signaling Control Point. These nodes act as databases. These nodes contain stored data that is used to turn SS7 Queries into SS7 Replies.
* SCP：シグナリング制御ポイント。これらのノードはデータベースとして機能します。これらのノードには、SS7クエリをSS7応答に変えるために使用される保存されたデータが含まれています。
There are 3 primary types of dedicated SS7 signaling links:
専用のSS7シグナリングリンクには、3つの主要なタイプがあります。
* 56Kbps SS7 (DS0, V35, OCU) links. These links implement the MTP-1 and MTP-2 protocols as defined in [1].
* 56kbps SS7（DS0、V35、OCU）リンク。これらのリンクは、[1]で定義されているように、MTP-1およびMTP-2プロトコルを実装します。
* DS1 High Speed Links. These links use the SAAL protocol to provide an alternative to 56Kbps SS7 links that is based on newer, faster technology. These links implement the SS7 protocol as defined in [8].
* DS1高速リンク。これらのリンクは、SAALプロトコルを使用して、新しい、より高速なテクノロジーに基づいた56kbps SS7リンクの代替手段を提供します。これらのリンクは、[8]で定義されているようにSS7プロトコルを実装します。
* E1 Links.
* E1リンク。
Figure 1 provides an overview of the traditional PSTN network. In this network, any of the links can be implemented via either 56 Kbps, DS1, or E1 links.
図1に、従来のPSTNネットワークの概要を示します。このネットワークでは、56 kbps、DS1、またはE1リンクのいずれかを介してリンクを実装できます。
^
/ \
/SCP\
/-----\
/ \
/ \
/ \
/ \
/---\ +---+ +---+ /---\
| SSP |-----|STP|----|STP|-----| SSP |
\---/ \ /+-+-+\ /+-+-+ \ / \---/
\/ | \/ | \/
/\ | /\ | /\
/---\ / \+-+-+/ \+-+-+ / \ /---\
| SSP |/----|STP|----|STP|/----| SSP |
\---/ +---+ +---+ \---/
\ /
\ /
\ /
\ ^ /
\/ \/
/SCP\
/-----\
Figure 1: The Traditional PSTN Network
図1：従来のPSTNネットワーク
In the converged SS7 network, SS7 devices will reside on both the traditional PSTN network (with dedicated 56 Kbps and DS1 links) and on the IP network (with Ethernet links based on IP protocol). The services of SSPs, STPs, and SCPs can be provided by new types of devices that reside on IP networks. The IP network is not intended to completely replace the PSTN, rather devices on the 2 types of networks must be able to communicate with one another and convert from 1 lower layer protocol to the other.
収束したSS7ネットワークでは、SS7デバイスは、従来のPSTNネットワーク（専用56 kbpsおよびDS1リンクを使用）とIPネットワーク（IPプロトコルに基づくイーサネットリンクを使用）の両方に存在します。SSP、STP、およびSCPSのサービスは、IPネットワークに存在する新しいタイプのデバイスによって提供できます。IPネットワークはPSTNを完全に交換することを目的としていません。また、2種類のネットワーク上のデバイスは、互いに通信し、1つの下層プロトコルから他方に変換できる必要があります。
Signaling Gateways are new devices that may also function as an STP in the converged network. SGs provide interfaces to:
シグナリングゲートウェイは、収束ネットワークでSTPとしても機能する新しいデバイスです。SGは以下にインターフェイスを提供します
* devices on the SCN (traditional SSPs, STPs, and SCPs)
* SCN上のデバイス（従来のSSP、STP、およびSCPS）
* other SGs
* 他のSG
* new devices on the IP network
* IPネットワーク上の新しいデバイス
SGs also continue to perform STP functions such as SS7 network management and some database services (such as GTT and LNP).
SGSは、SS7ネットワーク管理や一部のデータベースサービス（GTTやLNPなど）などのSTP関数も実行し続けています。
New devices on the IP network include:
IPネットワーク上の新しいデバイスには次のものがあります。
* Media Gateway Controllers. In addition to other functions, these devices control Media Gateways and perform call processing.
* メディアゲートウェイコントローラー。他の機能に加えて、これらのデバイスはメディアゲートウェイを制御し、コール処理を実行します。
* Media Gateways. In addition to other functions, these devices control voice circuits that are used to carry telephone calls. MGs + MGCs combine to provide the functionality of traditional SSPs.
* メディアゲートウェイ。他の機能に加えて、これらのデバイスは、電話を運ぶために使用される音声回路を制御します。MGS MGCは組み合わせて、従来のSSPの機能を提供します。
* IP based SCPs. The database services that are related to SS7 can be moved onto devices on the IP network.
* IPベースのSCPS。SS7に関連するデータベースサービスは、IPネットワーク上のデバイスに移動できます。
Figure 2 provides an overview of the converged SS7 network.
図2に、収束したSS7ネットワークの概要を示します。
----- +----+
/\ / \-------------| SG |
/ \----| SCN | +----+ +----+
/SCP \ \ /------| SG | |
------ ----- +----+ |
| | | |
| | | |
| | -----
| | / \ /\
| | | IP |----/ \
| /---\ \ / /SCP \
| | SSP | ----- ------
| \---/ / \
| | / \
/---\ | / \
| SSP | | +---+ +---+
\---/ +----+ |MGC| |MGC|
| | MG | +---+ +---+
| +----+\ \ /
| \ \ /
| \ -----
| \ / \
+----+ | IP |
| MG |-----------\ /
+----+ -----
Figure 2: The Converged SS7 Network
図2：収束したSS7ネットワーク
In theory, the TALI protocol can be used between 2 nodes to carry SS7 traffic across TCP/IP. Some of the areas that TALI could be used include:
理論的には、TALIプロトコルを2つのノード間で使用して、TCP/IP全体でSS7トラフィックを運ぶことができます。タリを使用できる領域のいくつかは次のとおりです。
- For SG to SG communication across IP - For SG to MGC communication across IP - For SG to IP based SCP communication across IP - For communication between multiple IP based SCPs - For communication between multiple MGCs - For communication between MGCs and MGs - For other IP devices such as DNS, Policy Servers, etc.
- IPを介したSGからSGへの通信 - SGからMGC通信IPを介したMGC通信 - 複数のIPベースのSCP間のSGからIPベースのSCP通信 - 複数のIPベースのSCP間の通信 - 複数のMGC間の通信 - MGCとMGS間の通信 - 他のIPの通信DNS、ポリシーサーバーなどのデバイス
In reality, the communication between MGCs, or between MGC and MG is probably better suited to using other protocols. With respect to the Signaling Gateway implementation, the TALI protocol is used to carry SS7 traffic:
実際には、MGC間、またはMGCとMG間の通信は、おそらく他のプロトコルの使用により適しています。シグナリングゲートウェイの実装に関して、TALIプロトコルはSS7トラフィックを運ぶために使用されます。
- For SG to SG communication - For SG to MGC communication - For SG to IP based SCP communication
- SGからSG通信 - SGからMGC通信 - SGからIPベースのSCP通信
The Transport Adapter Layer Interface is the proposed interface that provides SCCP, ISUP, and MTP messaging encapsulation within a TCP/IP packet between two switching elements. In addition, TALI provides SCCP Management (SCMG), MTP Primitives, dynamic registration of circuits, and routing of call control messages based on circuit location.
トランスポートアダプターレイヤーインターフェイスは、2つのスイッチング要素間のTCP/IPパケット内のSCCP、ISUP、およびMTPメッセージングカプセル化を提供する提案されたインターフェイスです。さらに、Taliは、SCCP管理（SCMG）、MTPプリミティブ、回路の動的登録、および回路の場所に基づいてコールコントロールメッセージのルーティングを提供します。
The major purpose of the TALI protocol is to provide a bridge between the SS7 Signaling Network and applications that reside within an IP network. Figure 3 provides a simple illustration that highlights the protocol stacks used for transport of SS7 MSUs on both the SS7 side and the IP side of the SG.
TALIプロトコルの主な目的は、SS7シグナリングネットワークとIPネットワーク内に存在するアプリケーションとの間にブリッジを提供することです。図3は、SG側とSGのIP側の両方でSS7 MSUSの輸送に使用されるプロトコルスタックを強調した簡単な図を示しています。
SS7 traffic SS7 traffic
via 56Kbps links via TALI
+-----------+ +----+ +--------+
|Traditional| | SG | | IP |
|SS7 Devices|<------>| |<-------->| Devices|
+-----------+ +----+ +--------+
SS7 SS7, TALI, TCP/IP
protocol stack protocol stack
+---------------+ +---------------+
|SS7 application| |SS7 application|
|layer | |layer |
+-------+-------+ +-------+-------+
| TCAP | ISUP | | TCAP | ISUP |
+-------+ | +-------+ |
| SCCP | | | SCCP | |
+-------+-------+ +-------+-------+
| MTP3 | | MTP3 |
+---------------+ +---------------+
| MTP2 | | TALI |
+---------------+ +---------------+
| MTP1 | | TCP |
| (& phy. | +---------------+
| layer) | | IP |
+---------------+ +---------------+
| MAC |
| (& phy. |
| layer) |
+---------------+
Figure 3: TALI Protocol to carry SS7 over TCP/IP
図3：TCP/IPを超えるSS7を運ぶTALIプロトコル
From Figure 3, several observations can be made:
図3から、いくつかの観察を行うことができます。
* The TALI layer is used when transferring SS7 over IP.
* TALI層は、SS7をIPに転送するときに使用されます。
* When SS7 traffic is carried over a IP network, the MTP2 and MTP1 layers of a traditional 56 Kbps link are replaced by the TALI, TCP, IP, and MAC layers
* SS7トラフィックがIPネットワークに搭載されている場合、従来の56 kbpsリンクのMTP2およびMTP1レイヤーがTALI、TCP、IP、およびMACレイヤーに置き換えられます
* The TALI layer sits on top of the TCP layer.
* タリ層は、TCPレイヤーの上にあります。
* The TALI layer sits below the various SS7 layers (MTP3, SCCP/TCAP, ISUP, and applications). The data from these SS7 layers is carried as the data portion of TALI service data packets.
* タリ層は、さまざまなSS7層（MTP3、SCCP/TCAP、ISUP、およびアプリケーション）の下にあります。これらのSS7レイヤーのデータは、TALIサービスデータパケットのデータ部分として運ばれます。
Some of the facts concerning the TALI protocol which are important to understanding how TALI works that are not evident from Figure 3 include the following:
図3から明らかになっていないタリがどのように機能するかを理解するために重要なタリプロトコルに関する事実のいくつかには、以下が含まれます。
* Each TALI connection is provided over a single TCP socket.
* 各TALI接続は、単一のTCPソケットで提供されます。
* The standard Berkeley sockets interface to the TCP is used by the TALI layer to provide connection oriented service from endpoint to peer endpoint.
* TCPへの標準のバークレーソケットインターフェイスは、タリ層によって使用され、エンドポイントからピアエンドポイントまで接続指向サービスを提供します。
* TCP sockets are based on a Client/Server architecture; one end of the TALI connection must be defined as the 'server side', the other end is a 'client'.
* TCPソケットは、クライアント/サーバーアーキテクチャに基づいています。TALI接続の一方の端は「サーバー側」として定義する必要があり、もう1つの端は「クライアント」です。
* The client/server roles are important only in bringing up the TCP connection between the 2 endpoint, once the connection is established both ends use the same Berkeley sockets calls (send, recv) to transfer data.
* クライアント/サーバーの役割は、2つのエンドポイント間のTCP接続を持ち上げる上でのみ重要です。接続が確立されたら、両端が同じバークレーソケットコール（送信、RECV）を使用してデータを転送します。
* The TCP socket must be connected before the 2 TALI endpoints can begin communicating.
* 2つのTALIエンドポイントが通信を開始する前に、TCPソケットを接続する必要があります。
* TALI provides user control over each TALI connection that is defined. This control:
* Taliは、定義されている各TALI接続をユーザー制御します。このコントロール：
* Allows the user to control when each TALI connection will be made
* 各タリ接続がいつ行われるかをユーザーが制御できるようにします
* Allows the user to control when each TALI connection is allowed to carry SS7 traffic
* 各タリ接続がSS7トラフィックを運ぶことが許可されているときにユーザーが制御できるようにします
* Allows the user to control the graceful shutdown of each socket
* ユーザーが各ソケットの優雅なシャットダウンを制御できるようにします
* TALI provides Peer to Peer messages. These messages originate from the TALI layer of one endpoint of the connection and are terminated at the TALI layer of the other endpoint. Peer to Peer messages are used:
* Taliはピアツーピアメッセージを提供します。これらのメッセージは、接続の1つのエンドポイントのタリ層から発生し、もう一方のエンドポイントのタリ層で終了します。ピアツーピアメッセージが使用されます：
* To provide test and watchdog maintenance messages
* テストおよびウォッチドッグメンテナンスメッセージを提供する
* To control the ability of each socket to carry SS7 service messages
* SS7サービスメッセージを伝達する各ソケットの機能を制御する
* TALI provides Service messages. These messages originate from the layer above the TALI layer of one endpoint of the connection and are transferred to and terminated at the layer above the TALI layer of the other endpoint.
* Taliはサービスメッセージを提供します。これらのメッセージは、接続の1つのエンドポイントのタリ層の上のレイヤーから発生し、他のエンドポイントのタリ層の上の層に転送および終了します。
* The service messages provide several different ways to encapsulate the SS7 messages (SCCP/TCAP, ISUP, and other MTP3 layer data) across the TCP/IP connection.
* サービスメッセージは、TCP/IP接続全体でSS7メッセージ（SCCP/TCAP、ISUP、およびその他のMTP3レイヤーデータ）をカプセル化するいくつかの異なる方法を提供します。
* As we will see later, different Service opcodes are used to communicate across the TALI socket exactly how each SS7 message has been encapsulated.
* 後で説明するように、さまざまなサービスオプコードを使用して、各SS7メッセージがカプセル化されている方法を正確にタリソケット間で通信します。
* A set of TALI timers is defined. These timers are used to correctly implement the TALI state machine.
* タリタイマーのセットが定義されています。これらのタイマーは、Tali Stateマシンを正しく実装するために使用されます。
This section presents a different, slightly more complex, TALI protocol stack that can be used in place of the protocol stack in the previous section.
このセクションでは、前のセクションのプロトコルスタックの代わりに使用できる、わずかに複雑なタリプロトコルスタックを紹介します。
Figure 3 in the previous section provided a simple illustration that highlighted the basic TALI protocol stack that can be used to transport SS7 MSUs between 56 Kbps links on the SS7 side of an SG and the IP devices.
前のセクションの図3は、SGのSS7側とIPデバイスの56 kbpsリンク間でSS7 MSUSを輸送するために使用できる基本的なTALIプロトコルスタックを強調した簡単な図を示しました。
Figure 4 below illustrates an alternate TALI protocol stack that includes the SAAL layer as part of the data transferred across the TCP/IP connection.
以下の図4は、TCP/IP接続全体で転送されるデータの一部としてSAAL層を含む代替のTALIプロトコルスタックを示しています。
SS7 traffic SS7 traffic
via DS1 links via TALI
+-----------+ +----+ +--------+
|Traditional| | SG | | IP |
|SS7 Devices|<------>| |<-------->| Devices|
+-----------+ +----+ +--------+
SS7 DS1 SS7, TALI, TCP/IP
protocol stack protocol stack
+-----------------+ +-----------------+
| SS7 application | | SS7 application |
| layer | | layer |
+--------+--------+ +--------+--------+
| TCAP | ISUP | | TCAP | ISUP |
+--------+ | +--------+ |
| SCCP | | | SCCP | |
+--------+--------+ +--------+--------+
| MTP3 | | MTP3 |
+-----------------+ +-----------------+
| SAAL | | SAAL |
|(SSCF,MAAL,SSCOP)| |(SSCF,MAAL,SSCOP)|
+-----------------+ +-----------------+
| AAL5 | | TALI |
+-----------------+ +-----------------+
| ATM | | TCP |
| (& phy. | +-----------------+
| layer) | | IP |
+-----------------+ +-----------------+
| MAC |
| (& phy. |
| layer) |
+-----------------+
Figure 4: An Alternate TALI Protocol Stack with SAAL
図4：Saalとの別のTaliプロトコルスタック
The following bullets provide a discussion regarding the differences between these 2 protocol stacks, the reasons for having 2 protocol stacks, and the advantages of each:
次の弾丸は、これら2つのプロトコルスタックの違い、2つのプロトコルスタックを持っている理由、およびそれぞれの利点に関する議論を提供します。
* When the TALI protocol stack is implemented without the SAAL layer, as in Figure 3, the SEQUENCE NUMBER of the SS7 MSU is NOT part of the data transferred across the TCP/IP connection. In 56 Kbps SS7 links, the MTP2 header contains an 8 bit sequence number for each MSU. The sequence number is used to preserve message sequencing and to support complex SS7 procedures involving MSU retrieval during link changeover and changeback. As indicated in Figure 3, the MTP2 header is NOT part of the data transferred across the TCP/IP connection. The TALI protocol stack without SAAL still guarantees correct sequencing of SS7 data (this sequencing is provided by sequence numbers in the TCP layer), however that protocol stack can not support SS7 changeover and changeback procedures.
* 図3のように、SAAL層なしでTALIプロトコルスタックが実装されると、SS7 MSUのシーケンス番号は、TCP/IP接続全体で転送されるデータの一部ではありません。56 kbps SS7リンクでは、MTP2ヘッダーには、各MSUの8ビットシーケンス番号が含まれています。シーケンス番号は、メッセージシーケンスを保存し、リンクの切り替えとチェンジバック中にMSU検索を含む複雑なSS7手順をサポートするために使用されます。図3に示すように、MTP2ヘッダーは、TCP/IP接続全体で転送されるデータの一部ではありません。SAALのないTALIプロトコルスタックは、SS7データの正しいシーケンスを保証します（このシーケンスはTCPレイヤーのシーケンス番号によって提供されます）が、そのプロトコルスタックはSS7の切り替えおよびチェンジバック手順をサポートできません。
* When the TALI protocol stack is implemented with the SAAL layer, as in Figure 4, the SEQUENCE NUMBER of the SS7 MSU IS part of the data transferred across TCP/IP. In SS7 DS1 links, the SSCOP trailer contains a 24 bit sequence number for each MSU. This 24 bit sequence number serves the same purposes as the 8 bit SS7 sequence number. As indicated in Figure 4, the SSCOP trailer IS part of the data transferred across the TCP/IP connection. The protocol stack in Figure 4 can support SS7 changeover and changeback procedures.
* 図4のように、SAAL層でTALIプロトコルスタックが実装されると、SS7 MSUのシーケンス番号はTCP/IPで転送されるデータの一部です。 SS7 DS1リンクでは、SSCOPトレーラーには、各MSUの24ビットシーケンス番号が含まれています。 この24ビットシーケンス番号は、8ビットSS7シーケンス番号と同じ目的を使用します。 図4に示すように、SSCOPトレーラーはTCP/IP接続全体で転送されるデータの一部です。 図4のプロトコルスタックは、SS7の切り替えとチェンジバックの手順をサポートできます。
* Implementing the TALI protocol with SAAL therefore provides support for SS7 co/cb and data retrieval and can help to minimize MSU loss as SS7 links are deactivated. However, implementing SAAL is not a trivial matter. The SAAL layer consists of 3 sublayers (SSCF, SSCOP, and MAAL), one of which (SSCOP) is quite involved. It is envisioned that most SS7 to TCP/IP applications will NOT choose to implement SAAL.
* したがって、SAALを使用してTALIプロトコルを実装することで、SS7 CO/CBとデータ検索のサポートが提供され、SS7リンクが非アクティブ化されるため、MSUの損失を最小限に抑えることができます。ただし、Saalの実装は些細な問題ではありません。SAAL層は、3つのサブレイヤー（SSCF、SSCOP、およびMAAL）で構成されており、そのうちの1つ（SSCOP）が非常に関与しています。ほとんどのSS7からTCP/IPアプリケーションがSAALの実装を選択しないことを想定しています。
The TALI protocol is dependent on a reliable transport layer below it. At the initial design of TALI, TCP was the only reliable, proven transport layer. Simple Control Transport Protocol (SCTP) is currently being designed as a transport later specifically for signalling. Once SCTP is a proven and accepted transport protocol, SCTP can then be used in place of TCP as shown in Figures 3 and 4.
TALIプロトコルは、その下の信頼できる輸送層に依存しています。タリの初期設計では、TCPが唯一の信頼できる実績のある輸送層でした。Simple Control Transport Protocol（SCTP）は、現在、シグナリングのために後で特に輸送として設計されています。SCTPが実証済みの輸送プロトコルになると、図3および4に示すように、SCTPをTCPの代わりに使用できます。
Figure 5 illustrates the inputs that affect the TALI State Machine. Inputs to the state machine include:
図5は、Tali State Machineに影響を与える入力を示しています。状態マシンへの入力は次のとおりです。
* Management events (ie: requests from the human user of the TALI connection) to control the operation of a particular TALI session.
* 特定のTALIセッションの操作を制御するための管理イベント（つまり、TALI接続の人間ユーザーからのリクエスト）。
* TALI messages received from the Peer. These messages include peer to peer messages as well as service data messages.
* ピアから受け取ったタリメッセージ。これらのメッセージには、ピアツーピアメッセージとサービスデータメッセージが含まれます。
* Events from the User of the TALI layer. The user is the layer above TALI in the protocol stack, either the SS7 or SAAL layer.
* タリ層のユーザーからのイベント。ユーザーは、SS7またはSAALレイヤーのいずれかのプロトコルスタックのタリ上のレイヤーです。
* Implementation Dependent Events. Each implementation must provide inputs into the TALI state machine such as:
* 実装依存イベント。各実装は、次のようなTali Stateマシンに入力を提供する必要があります。
* Socket Events
* ソケットイベント
* TALI protocol violations. The TALI state machine must detect protocol violations and act accordingly.
* タリプロトコル違反。Tali Stateマシンは、プロトコル違反を検出し、それに応じて行動する必要があります。
* Timer events.
* タイマーイベント。
+====+ +============+
| | +---------+ +-------------+ | |
|User| | Service | | Mgmt. Open | | MANAGEMENT |
|Part|<-->| Message | | Mgmt. Close |<-->| |
| | | | | Mgmt. Proh. | | |
| | +---------+ | Mgmt. Allow | +============+
+====+ ^ +-------------+
| ^
| |
v v
+========================================================+
| TALI State Machine |
+========================================================+
^ ^ ^ ^
| | | |
| | | |
v | | |
+---------+ +-----------------+ +-----------+ +------------+
| Received| | Connection est. | | Protocol | | T1 Expired |
| 'test' | | Connection lost | | Violation | | T2 Expired |
| 'allo' | | | | | | T3 Expired |
| 'proh' | +-----------------+ +-----------+ | T4 Expired |
| 'proa' | ^ ^ +------------+
| 'moni' | | | ^
| 'mona' | | | |
| or | | | |
| Service | | | |
| Message | +========================================+
+---------+ | IMPLEMENTATION |
^ | DEPENDENT |
| +========================================+
|
v
+============+
| PEER |
| |
+============+
Figure 5: Overview of Inputs to the TALI 1.0 State Machine
図5：TALI 1.0状態マシンへの入力の概要
This chapter provides the states, messages, message exchange rules and state machine that must be implemented to provide a TALI version 1.0 protocol layer.
この章では、TALIバージョン1.0プロトコルレイヤーを提供するために実装する必要がある州、メッセージ、メッセージ交換ルール、および状態マシンを提供します。
Table 2 provides a summary of the messages and message structure used in TALI version 1.0.
表2に、TALIバージョン1.0で使用されているメッセージとメッセージ構造の概要を示します。
+------------------------------------------------------------------+
| OCTET | DESCRIPTION | SIZE | VALUE | TYPE |
+------------------------------------------------------------------+
| 0..3 | SYNC | 4 Octets | | 4 byte |
| | | | | ASCII |
+------------------------------------------------------------------+
| | TALI | | 'TALI' | |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 4 Octets | | 4 byte |
| | | | | ASCII |
+------------------------------------------------------------------+
| | Test Service | | 'test' | |
| | Allow Service | | 'allo' | |
| | Prohibit Service | | 'proh' | |
| | Prohibit Service Ack | | 'proa' | |
| | Monitor Socket | | 'moni' | |
| | Monitor Socket Ack | | 'mona' | |
| | SCCP Service | | 'sccp' | |
| | ISUP Service over TALI | | 'isot' | |
| | MTP3 Service over TALI | | 'mtp3' | |
| | Service over SAAL | | 'saal' | |
+------------------------------------------------------------------+
| 8..9 | LENGTH | 2 Octets | | integer |
| | (least significant | | | |
| | byte first) non-0 | | | |
| | if Service or | | | |
| | Socket monitor message| | | |
+------------------------------------------------------------------+
| 10..X | DATA PAYLOAD | variable | | variable |
+------------------------------------------------------------------+
Table 2: Message Structure for TALI 1.0
表2：タリ1.0のメッセージ構造
Table 3 indicates the valid values of the LENGTH field for each version 1.0 opcode. The LENGTH field is always an indication of the # of bytes contained in the DATA PAYLOAD portion of a general TALI message.
表3は、各バージョン1.0オペコードの長さフィールドの有効な値を示しています。長さフィールドは、一般的なTALIメッセージのデータペイロード部分に含まれるバイトの＃を常に示しています。
+------------------------------------------------------------------+
| OPCODE | VALID LENGTH VALUES | COMMENTS |
+------------------------------------------------------------------+
| test | 0 bytes | |
+------------------------------------------------------------------+
| allo | 0 bytes | |
+------------------------------------------------------------------+
| proh | 0 bytes | |
+------------------------------------------------------------------+
| proa | 0 bytes | |
+------------------------------------------------------------------+
| moni | 0-200 bytes | A maximum length is provided so |
| | | that the maximum ethernet frame |
| | | size is not exceeded. |
+------------------------------------------------------------------+
| mona | 0-200 bytes | Mona reply length and content must|
| | | match the original moni (with the |
| | | exception of the opcode) |
+------------------------------------------------------------------+
| sccp | 12-265 bytes | These are the valid sizes for the |
| | | SCCP-ONLY portions of SCCP UDT |
| | | MSUs |
+------------------------------------------------------------------+
| isot | 8-273 bytes | The length is the number of octets|
| | | in the MTP3 and higher layer(s) of|
| | | the SS7 MSU. This length includes|
| | | the SIO byte, the MTP3 routing |
| | | label, the CIC code, and the |
| | | ISUP Message Type field, and any |
| | | other bytes that may exist as part|
| | | of the SIF (Service Information |
| | | Field) |
+------------------------------------------------------------------+
| mtp3 | 5-280 bytes | The length is the number of octets|
| | | in the MTP3 and higher layer(s) of|
| | | the SS7 MSU. This length includes|
| | | the SIO byte and the MTP3 routing |
| | | labeld, and any other bytes that |
| | | may exist as part of the SIF |
| | | (Service Information Field) |
+------------------------------------------------------------------+
| saal | 11-280 bytes | The length is the number of octets|
| | | in the MTP3 and higher layer(s) of|
| | | the SS7 MSU. This length includes|
| | | the SIO byte and all bytes in the |
| | | SIF (Service Information Field) |
| | | field. The MTP3 routing label is |
| | | part of the SIF field. Seven (7) |
| | | octets of SSCOP trailer is added |
| | | to the message. The SSCOP trailer|
| | | bytes are also included in the |
| | | length. |
+------------------------------------------------------------------+
Table 3: Valid Length Fields for Each Opcode in TALI 1.0
表3：TALI 1.0の各オペコードの有効な長さフィールド
Several field types are used in the general TALI message structure.
一般的なタリメッセージ構造では、いくつかのフィールドタイプが使用されています。
+------------------------------------------------------------------+
|Field Type | Implementation Notes for that Type |
+------------------------------------------------------------------+
|4 byte | * 4 byte ASCII text strings are used to define the |
|ASCII text | sync code and the opcode of the basic TALI message.|
| | * These fields are case sensitive, the coding for |
| | each sync and opcode literal needs to match the |
| | case specified in Table 2. |
| | * The standard ASCII conversion table is used to |
| | transform each character into a byte. |
| | * The order of the ASCII characters is important. |
| | The first character in the string must be the |
| | first character transmitted across the wire. |
| | * For example, if the string being encoded is 'abCD',|
| | the order of the bytes as they are transferred |
| | over the wire must be: |
| | 1st byte: 0x61 ('a') 3rd byte: 0x43 ('C') |
| | 2nd byte: 0x62 ('b') 4th byte: 0x44 ('D') |
| | * The software for each implementation should be |
| | written in a manner that accounts for the required |
| | byte order of transmission (ie: the Big Endian/ |
| | Little Endian characteristics of the processor |
| | need to be dealt with in the software. |
+------------------------------------------------------------------+
|Integer | * A 1, 2 or 4 byte field to be treated as an integer |
| | value. Integer fields should be transmitted Least |
| | Significant Byte first across the wire. |
| | * The software for each implementation should be |
| | written in a manner that accounts for the required |
| | byte order of transmission (ie: the Big Endian/ |
| | Little Endian characteristics of the processor |
| | need to be dealt with in the software. |
+------------------------------------------------------------------+
|Variable | * The definition of the message structure for this |
| | field is governed by other specifications. |
| | * For example, when transferring MTP3 service data |
| | via a 'mtp3' opcode, the DATA PAYLOAD begins with |
| | the SIO byte of the MTP3 routing label. The |
| | structure for the entire DATA PAYLOAD is governed |
| | by the MTP3 message structure defined in [1]. |
+------------------------------------------------------------------+
|X byte | * ASCII text fields of sizes other than 4 bytes |
|ASCII text | should be supported according to the same rules |
| | presented for the 4 byte ASCII text fields. For |
| | instance, an 8 byte string such as 'ab01cd23' could|
| | be used, where the 'a' would be the first byte of |
| | the field transmitted out the wire. |
+------------------------------------------------------------------+
Table 4: Implementation Notes for each Type of TALI field
表4：タリフィールドの各タイプの実装ノート
The following subsections provide more information regarding the TALI Peer to Peer messages that are implemented in version 1.0. The TALI peer to peer messages originate at the TALI layer of 1 end of the socket connection (the near end) and are terminated at the TALI layer of the far end of the connection.
次のサブセクションは、バージョン1.0で実装されているTali Peer to Peerメッセージに関する詳細情報を提供します。Tali Peer to Peerメッセージは、ソケット接続の1つの端（近端）のタリ層で発生し、接続の遠端のタリ層で終了します。
The 'test' message is used by a TALI implementation to query the remote end of the TALI connection with respect to the willingness of the remote end to carry SS7 service data. This message asks the other end: are you ready to carry service data? This message is sent periodically by each TALI implementation based on a T1 timer interval. Upon receiving 'test', a TALI implementation must reply with either 'proh' or 'allo' to indicate the nodes willingness to carry SS7 service data over that TALI connection.
「テスト」メッセージは、TALIの実装によって使用され、SS7サービスデータを運ぶリモートエンドの意欲に関するTALI接続のリモートエンドを照会します。このメッセージはもう一方の端を尋ねます：あなたはサービスデータを携帯する準備ができていますか？このメッセージは、T1タイマー間隔に基づいて各TALI実装によって定期的に送信されます。「テスト」を受信すると、TALIの実装は、「Proh」または「Allo」のいずれかで返信する必要があり、そのTALI接続を介してSS7サービスデータを運ぶノードを示す必要があります。
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'test' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length = 0 |
+------------------------------------------------------------------+
The 'allo' message is sent in reply to a 'test' query, or in response to some internal implementation event, to indicate that a TALI implementation IS willing to carry SS7 service data over the TALI session. This message informs the far end that SS7 traffic can be transmitted on the socket. 'allo' is one of the 2 possible replies to a 'test' message. Before SS7 traffic can be carried over a socket, both ends of the connection need to send 'allo' messages.
「Allo」メッセージは、「テスト」クエリへの返信、またはいくつかの内部実装イベントに応じて送信され、TALIの実装がTALIセッションでSS7サービスデータを喜んで伝えることを望んでいることを示します。このメッセージは、SS7トラフィックをソケットに送信できることを遠くに通知します。「Allo」は、「テスト」メッセージに対する2つの可能な返信の1つです。SS7トラフィックをソケットに渡す前に、接続の両端が「Allo」メッセージを送信する必要があります。
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'allo' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length = 0 |
+------------------------------------------------------------------+
The 'proh' message is sent in reply to a 'test' query, or in response to some internal implementation event, to indicate that a TALI implementation is NOT willing to carry SS7 service data over the TALI session. This message informs the far end that SS7 traffic can not be transmitted on the socket. 'proh' is one of the 2 possible replies to a 'test' message. As long as 1 end of the connection remains in the 'prohibited' state, SS7 traffic can not be carried over the socket.
「プロ」メッセージは、「テスト」クエリへの返信、またはいくつかの内部実装イベントに応じて送信され、TALIの実装がTALIセッションでSS7サービスデータを運ぶことをいとわないことを示します。このメッセージは、SS7トラフィックをソケットに送信できないことを遠くに通知します。「Proh」は、「テスト」メッセージに対する2つの可能な返信の1つです。接続の1つの端が「禁止」状態にある限り、SS7トラフィックをソケットに渡すことはできません。
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'proh' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length = 0 |
+------------------------------------------------------------------+
The 'proa' message is sent by a TALI implementation each time a 'proh' is received from the far end. This message is sent to indicate to the far end that his 'prohibit' message was received correctly and will be acted on accordingly.
「proa」メッセージは、「proh」が遠端から受信されるたびにTaliの実装によって送信されます。このメッセージは、彼の「禁止」メッセージが正しく受信され、それに応じて行動されることを遠端に示すために送信されます。
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'proa' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length = 0 |
+------------------------------------------------------------------+
The 'moni' message provides a generic ECHO capability that can be used by each TALI implementation as that implementation sees fit. A TALI version 1.0 implementation does not have to originate a 'moni' message to be compliant with the 1.0 specification. The primary intent of this message is to provide a way for the TALI layer to test the round-trip message transfer time on a socket. A 'mona' message must be sent in reply to each received 'moni' message. The DATA portion of a 'moni' message is vendor implementation dependent. The DATA portion of each 'mona' reply must exactly match the DATA portion of the 'moni' that is replied to. Regardless of whether an implementation chooses to send 'moni' or not, 'mona' must be sent in response to each 'moni' in order to remain compliant with the TALI protocol.
「モニ」メッセージは、実装が適切と見えるため、各タリの実装で使用できる一般的なエコー機能を提供します。TALIバージョン1.0の実装では、1.0仕様に準拠するために「モニ」メッセージを発信する必要はありません。このメッセージの主な意図は、タリ層がソケットで往復メッセージ転送時間をテストする方法を提供することです。「モナ」メッセージは、受信した各「モニ」メッセージに返信して送信する必要があります。「モニ」メッセージのデータ部分は、ベンダーの実装依存です。各「モナ」返信のデータ部分は、返信される「モニ」のデータ部分と正確に一致する必要があります。実装が「モニ」を送信することを選択したかどうかに関係なく、タリプロトコルに準拠したままでいるために、各「モニ」に応じて「モナ」を送信する必要があります。
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'moni' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length |
+------------------------------------------------------------------+
| 10..X | DATA PAYLOAD| Vendor Dependent |
+------------------------------------------------------------------+
As mentioned above, the 'mona' must be sent in reply to each received 'moni'. The contents of the 'mona' DATA area must match the DATA area of the received 'moni' message.
上記のように、「モナ」は、受け取った各「モニ」に返信して送信する必要があります。「モナ」データ領域の内容は、受信した「モニ」メッセージのデータ領域と一致する必要があります。
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'mona' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length |
+------------------------------------------------------------------+
| 10..X | DATA PAYLOAD| Vendor Dependent |
+------------------------------------------------------------------+
The following subsections provide more information regarding the TALI Service messages that are implemented in version 1.0. TALI Service messages are used to carry SS7 MSUs across the IP network. The information in this section includes details with respect to how to encapsulate SS7 MSUs into TCP/IP frames using each of the TALI service opcodes. The TALI service messages originate at the layer above TALI, are transported across the IP network via a TALI service message, and are delivered to the layer above TALI at the far end of the TALI connection.
次のサブセクションは、バージョン1.0に実装されているTALIサービスメッセージに関する詳細情報を提供します。TALIサービスメッセージは、IPネットワーク全体でSS7 MSUSを運ぶために使用されます。このセクションの情報には、各TALIサービスオプコードを使用してSS7 MSUSをTCP/IPフレームにカプセル化する方法に関する詳細が含まれています。TALIサービスメッセージは、TALIの上のレイヤーで発生し、TALIサービスメッセージを介してIPネットワークを介して輸送され、Tali接続の遠端にあるTaliの上のレイヤーに配信されます。
The 'sccp' opcode is used to deliver SS7 MSUs with a Service Indicator of 3 (SCCP) over a TALI connection. This opcode is only used on TALI protocol stacks that are implemented without SAAL. The MTP3 layer of the SS7 MSU is NOT part of the data transferred across TCP/IP for this opcode; the data portion of the TALI 'sccp' message begins with the first byte of the SCCP data area in the SS7 MSU (after the MTP3 routing label). The first byte in the SCCP data area is an SCCP message type field.
「SCCP」オペコードは、TALI接続を介して3（SCCP）のサービスインジケーターを備えたSS7 MSUSを配信するために使用されます。このオペコードは、SAALなしで実装されたTALIプロトコルスタックでのみ使用されます。SS7 MSUのMTP3層は、このオプコードのTCP/IPを越えて転送されるデータの一部ではありません。Tali 'SCCP'メッセージのデータ部分は、SS7 MSUのSCCPデータ領域の最初のバイトから始まります（MTP3ルーティングラベルの後）。SCCPデータ領域の最初のバイトは、SCCPメッセージタイプフィールドです。
Several restrictions on the SCCP messages that this TALI opcode can carry exist. These restrictions are as follows:
このTALIオプコードが存在できるSCCPメッセージに関するいくつかの制限。これらの制限は次のとおりです。
* SCCP messages contain an SCCP message type field. The SCCP messages that are supported by TALI 1.0 implementations are limited to Class 0 and Class 1 SCCP messages with a message type field of either:
* SCCPメッセージには、SCCPメッセージタイプフィールドが含まれています。TALI 1.0の実装でサポートされているSCCPメッセージは、次のいずれかのメッセージタイプフィールドを使用して、クラス0およびクラス1 SCCPメッセージに限定されています。
* UDT
* UDTS
* XUDT
* XUDTS
* udt
* udts
* xudt
* xudts
* SCCP messages must contain a Point Code in the 'calling party' area in order to be transferred across the TCP/IP connection as a 'sccp' message. An implementation may choose to modify the original SCCP MSU to add an appropriate calling party point code before transmission across TALI if desired.
* SCCPメッセージは、TCP/IP接続全体で「SCCP」メッセージとして転送されるために、「呼び出しパーティー」領域にポイントコードを含める必要があります。 実装では、元のSCCP MSUを変更して、必要に応じてTALI全体に送信する前に、適切な呼び出しパーティーポイントコードを追加することを選択できます。
* SCCP messages must contain a Point Code in the 'called party' area in order to be transferred across the TCP/IP connection as a 'sccp' message. An implementation may choose to modify the original SCCP MSU to add an appropriate called party point code before transmission across TALI if desired.
* SCCPメッセージは、TCP/IP接続全体に「SCCP」メッセージとして転送されるために、「パーティ」領域に「呼び出された」領域にポイントコードを含める必要があります。実装では、元のSCCP MSUを変更して、必要に応じてTALI全体に送信する前に、適切な呼び出されたパーティポイントコードを追加することを選択できます。
* The encoding of the SS7 SCCP MSUs, as they are transmitted across TALI via 'sccp', should remain compliant with the ANSI specifications (T1.112 and T1.114) that apply to the SCCP and TCAP portions of the message respectively.
* 「SCCP」を介してTALIを介して送信されるSS7 SCCP MSUSのエンコードは、それぞれメッセージのSCCPおよびTCAP部分に適用されるANSI仕様（T1.112およびT1.114）に準拠したままでなければなりません。
NOTE 1: SCCP Subsystem Management for the IP based SCP's is supported via this 'sccp' opcode. SS7 SCCP Management messages are controlled by an SCMG SS7 process. SCMG sends the management messages via SCCP UNITDATA (UDT) messages. Therefore, the SCMG messages can be sent across the TALI connection.
注1：IPベースのSCPのSCCPサブシステム管理は、この「SCCP」オペコードを介してサポートされています。SS7 SCCP管理メッセージは、SCMG SS7プロセスによって制御されます。SCMGは、SCCP UnitData（UDT）メッセージを介して管理メッセージを送信します。したがって、SCMGメッセージはTALI接続全体に送信できます。
NOTE 2: 'sccp' TALI messages will not include the MTP3 header and therefore will not retain the original DPC/OPC of the SS7 MSU. Each TALI implementation needs to consider if/how to provide this DPC/OPC information in the SCCP portion of the message. For example the DPC can be replicated to the point code in the SCCP Called Party Address area and the OPC can be replicated to the point code in the SCCP Calling Party Address area.
注2：「SCCP」TALIメッセージにはMTP3ヘッダーが含まれていないため、SS7 MSUの元のDPC/OPCを保持しません。各TALIの実装は、メッセージのSCCP部分でこのDPC/OPC情報を提供するかどうか/方法を考慮する必要があります。たとえば、DPCは、パーティアドレスエリアと呼ばれるSCCPのポイントコードに複製でき、OPCはSCCP通話パーティーアドレスエリアのポイントコードに複製できます。
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'sccp' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length |
+------------------------------------------------------------------+
| 10..X | SCCP Data | SCCP data starting at the first byte after|
| | | the Layer 3 Routing Label (data does not |
| | | include the SIO or Routing Label) |
+------------------------------------------------------------------+
When an SCCP MSU arrives at an SG from a 56 Kbps or DS1 link and is routed within the SG for transmission to an IP device, the SG performs the following processing on the SS7 MSU:
SCCP MSUが56 kbpsまたはDS1リンクからSGに到着し、IPデバイスへの送信のためにSG内でルーティングされると、SGはSS7 MSUで次の処理を実行します。
* discards the MTP Layer 2 information, CRC and flags
* MTPレイヤー2情報、CRC、フラグを破棄する
* places the DPC from MTP Layer 3 into the Called Party Address field of the SCCP layer; the Calling Party Address field is created if it does not exist and then filled
* MTPレイヤー3からDPCをSCCPレイヤーの呼び出したパーティアドレスフィールドに配置します。発話パーティーアドレスフィールドは、存在しない場合に作成され、その後入力されます
* places the OPC from MTP Layer 3 into the Calling Party Address field of the SCCP layer if there is no Calling Party Point Code
* 通話党ポイントコードがない場合、MTPレイヤー3からSCCPレイヤーの呼び出しパーティーアドレスフィールドにOPCを配置します
* places the modified SCCP and unchanged TCAP data in the service payload area of the TALI packet
* TALIパケットのサービスペイロード領域に変更されたSCCPと変更されていないTCAPデータを配置します
* The SYNC field is set
* 同期フィールドが設定されています
* The OPCODE is set to 'sccp'
* オペコードは「SCCP」に設定されています
* The LENGTH is set to the number of octets in the SERVICE field
* 長さは、サービスフィールドのオクテットの数に設定されます
Once the fully formed 'sccp' TALI packet is created, it is handed to the TCP socket layer and transmitted. The transmission process will add TCP, IP and MAC header information.
完全に形成された「SCCP」TALIパケットが作成されると、TCPソケットレイヤーに渡されて送信されます。送信プロセスには、TCP、IP、およびMacヘッダー情報が追加されます。
Since the routing information from MTP Layer 3 is placed in the SCCP part of the outgoing message, no routing information needs to be saved by the SG.
MTPレイヤー3からのルーティング情報は、発信メッセージのSCCP部分に配置されるため、SGによってルーティング情報を保存する必要はありません。
SS7 MSU
SS7 MSU
| Layer 3 | Layer 2 |
| | |
+----+---+-----+-----+-------+---+--+---+---+---+---+----+
|Flag|FCS|TCAP |SCCP |Routing|SIO|LI|FIB|FSN|BIB|BSN|Flag|
| | |Layer|Layer| Label | | | | | | | |
+----+---+-----+-----+-------+---+--+---+---+---+---+----+
| |
| |
| |
TALI +-----------+---+------+----+
Packet | Service |LEN|Opcode|SYNC|
+-----------+---+------+----+
| |
| |
| |
+---------------------------+------+------+------+
IP | TALI Packet |TCP | IP | MAC |
Packet | |Header|Header|Header|
+---------------------------+------+------+------+
Figure 6: Encapsulation of SCCP MSUs using the TALI 'sccp' opcode
図6：tali 'sccp' opcodeを使用したSCCP MSUSのカプセル化
When an 'sccp' TALI packet is received on by an SG from an IP device, the SG performs the following processing on the 'sccp' packet:
「SCCP」TALIパケットがIPデバイスからSGによって受信されると、SGは「SCCP」パケットで次の処理を実行します。
* validates the TALI header
* タリヘッダーを検証します
* Allocates space for a new SS7 message
* 新しいSS7メッセージのスペースを割り当てます
* Regenerates the SIO with the Sub-Service Field set to National Network, priority of zero (0), Service Indicator set to SCCP
* National Networkに設定されたサブサービスフィールド、ゼロ（0）の優先度、SCCPに設定されたサービスインジケーターでSIOを再生します
* extracts the SCCP/TCAP data from the SERVICE area and places it in the new SS7 message
* サービスエリアからSCCP/TCAPデータを抽出し、新しいSS7メッセージに配置します
* sets the DPC to the SCCP Called Party Point Code
* DPCをParty Pointコードと呼ばれるSCCPに設定します
* sets the OPC to the SCCP Calling Party Point Code
* OPCをSCCP通話パーティポイントコードに設定します
* randomly generates the SLS
* SLSをランダムに生成します
Once the 'sccp' packet is transformed back into a normal SS7 MSU, the MSU is routed within the SG according to the normal SS7 routing procedures.
「SCCP」パケットが通常のSS7 MSUに戻されると、MSUは通常のSS7ルーティング手順に従ってSG内にルーティングされます。
The 'isot' opcode is used to deliver SS7 MSUs with a Service Indicator of 5 (ISUP) over a TALI connection. This opcode is only used on TALI protocol stacks that are implemented without SAAL. The MTP3 layer of the SS7 MSU IS part of the data transferred across TCP/IP for this opcode; the data portion of the TALI 'isot' message begins with the SIO byte of the MTP3 header in the SS7 MSU.
「ISOT」オペコードは、TALI接続を介して5（ISUP）のサービスインジケーターを備えたSS7 MSUSを配信するために使用されます。このオペコードは、SAALなしで実装されたTALIプロトコルスタックでのみ使用されます。SS7 MSUのMTP3層は、このオペコードのTCP/IPを越えて転送されるデータの一部です。Tali 'Isot'メッセージのデータ部分は、SS7 MSUのMTP3ヘッダーのSIOバイトから始まります。
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'isot' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length |
+------------------------------------------------------------------+
| 10..X | ISUP Data | Raw ISUP data starting at the Layer 3 SIO |
| | | field. |
+------------------------------------------------------------------+
When an ISUP MSU arrives at an SG from a 56 Kbps or DS1 link and is routed within the SG to a IP device, the SG performs the following processing on the SS7 MSU:
ISUPが56 kbpsまたはDS1リンクからSGに到着し、SG内でIPデバイスにルーティングされると、SGはSS7 MSUで次の処理を実行します。
* discards the MTP Layer 2 information, CRC and flags
* MTPレイヤー2情報、CRC、フラグを破棄する
* places MTP Layer 3 into the SERVICE payload area of the TALI packet
* MTPレイヤー3をタリパケットのサービスペイロードエリアに配置します
* The SYNC field is set
* 同期フィールドが設定されています
* The OPCODE is set to 'isot'
* オペコードは「asot」に設定されています
* The LENGTH is set to the number of octets in the SERVICE field
* 長さは、サービスフィールドのオクテットの数に設定されます
Once the fully formed 'isot' TALI packet is created, it is handed to the TCP socket layer and transmitted. The transmission process will add TCP, IP and MAC header information.
完全に形成された「asot」タリパケットが作成されると、TCPソケットレイヤーに渡されて送信されます。送信プロセスには、TCP、IP、およびMacヘッダー情報が追加されます。
Since the routing information is placed in the TALI Packet, no routing information needs to be saved by the SG.
ルーティング情報はTALIパケットに配置されるため、SGによってルーティング情報を保存する必要はありません。
SS7 MSU
SS7 MSU
| Layer 3 | Layer 2 |
| | |
+----+---+----+----+---+-------+---+--+---+---+---+---+----+
|Flag|FCS|ISUP|Msg.|CIC|Routing|SIO|LI|FIB|FSN|BIB|BSN|Flag|
| | |Part|Type| |Label | | | | | | | |
+----+---+----+----+---+-------+---+--+---+---+---+---+----+
| /
| /
| |
TALI +-----------------------+---+------+----+
Packet | Service |LEN|Opcode|SYNC|
+-----------------------+---+------+----+
| /
| ---------
| /
+----------------------------+------+------+------+
IP | TALI Packet |TCP | IP | MAC |
Packet | |Header|Header|Header|
+----------------------------+------+------+------+
Figure 7: Encapsulation of ISUP MSUs using the TALI 'isot' opcode
図7：tali 'isot' opcodeを使用したisup msusのカプセル化
When an 'isot' TALI packet is received on an SG from an IP device, the SG performs the following processing on the 'isot' packet:
「ISOT」TALIパケットがIPデバイスからSGで受信されると、SGは「ISOT」パケットで次の処理を実行します。
* validates the TALI header
* タリヘッダーを検証します
* Allocates space for a new SS7 message
* 新しいSS7メッセージのスペースを割り当てます
* extracts the MTP Layer 3 data from the SERVICE area and places it in the new SS7 message
* サービス領域からMTPレイヤー3データを抽出し、新しいSS7メッセージに配置します
Once the 'isot' packet is transformed back into a normal SS7 MSU, the MSU is routed within the SG according to the normal SS7 routing procedures.
「ISOT」パケットが通常のSS7 MSUに戻されると、MSUは通常のSS7ルーティング手順に従ってSG内にルーティングされます。
The 'mtp3' opcode is used to deliver SS7 MSUs with a Service Indicator of 0-2, 4, 6-15 (non-SCCP, non-ISUP) over a TALI connection. This opcode is only used on TALI protocol stacks that are implemented without SAAL. The MTP3 layer of the SS7 MSU IS part of the data transferred across TCP/IP for this opcode; the data portion of the TALI 'mtp3' message begins with the SIO byte of the MTP3 header in the SS7 MSU.
'mtp3'オペコードは、タリ接続上で0-2、4、6-15（非SCCP、非ISUP）のサービスインジケーターを備えたSS7 MSUSを配信するために使用されます。このオペコードは、SAALなしで実装されたTALIプロトコルスタックでのみ使用されます。SS7 MSUのMTP3層は、このオペコードのTCP/IPを越えて転送されるデータの一部です。Tali 'MTP3'メッセージのデータ部分は、SS7 MSUのMTP3ヘッダーのSIOバイトから始まります。
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'mtp3' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length |
+------------------------------------------------------------------+
| 10..X | Layer 3 MSU | Raw MSU data starting at the Layer 3 SIO |
| | Data | field. |
+------------------------------------------------------------------+
When an SS7 MSU with SI=0-2,4,6-15 arrives at an SG from a 56 Kbps or DS1 link and is routed within the SG to an IP device, the SG performs the following processing on the SS7 MSU:
SI = 0-2,4,6-15のSS7 MSUが56 kbpsまたはDS1リンクからSGに到着し、SG内でIPデバイスにルーティングされると、SGはSS7 MSUで次の処理を実行します。
* discards the MTP Layer 2 information, CRC and flags
* MTPレイヤー2情報、CRC、フラグを破棄する
* places MTP Layer 3 into the SERVICE payload area of TALI packet
* MTPレイヤー3をタリパケットのサービスペイロードエリアに配置します
* The SYNC field is set
* 同期フィールドが設定されています
* The OPCODE is set to 'mtp3'
* オペコードは「mtp3」に設定されています
* The LENGTH is set to the number of octets in the SERVICE field
* 長さは、サービスフィールドのオクテットの数に設定されます
Once the fully formed 'mtp3' TALI packet is created, it is handed to the TCP socket layer and transmitted. The transmission process will add TCP, IP and MAC header information.
完全に形成された「MTP3」TALIパケットが作成されると、TCPソケットレイヤーに渡されて送信されます。 送信プロセスには、TCP、IP、およびMacヘッダー情報が追加されます。
SS7 MSU
SS7 MSU
| Layer 3 | Layer 2 |
| | |
+----+---+-----------+-------+---+--+---+---+---+---+----+
|Flag|FCS|Other Layer|Routing|SIO|LI|FIB|FSN|BIB|BSN|Flag|
| | |3 Data |Label | | | | | | | |
+----+---+-----------+-------+---+--+---+---+---+---+----+
| /
| ------
| /
TALI +----------------+---+------+----+
Packet | Service |LEN|Opcode|SYNC|
+----------------+---+------+----+
| /
| --
| /
+----------------------------+------+------+------+
IP | TALI Packet |TCP | IP | MAC |
Packet | |Header|Header|Header|
+----------------------------+------+------+------+
Figure 8: Encapsulation of SS7 MSUs with SI!=3,5,13 using 'mtp3'
When an 'mtp3' TALI packet is received by an SG from an IP device, the SG performs the following processing on the 'mtp3' packet:
「MTP3」TALIパケットがIPデバイスからSGによって受信されると、SGは「MTP3」パケットで次の処理を実行します。
* validates the TALI header
* タリヘッダーを検証します
* Allocates space for a new SS7 message
* 新しいSS7メッセージのスペースを割り当てます
* extracts the MTP Layer 3 data from the SERVICE area and places it in the new SS7 message
* サービス領域からMTPレイヤー3データを抽出し、新しいSS7メッセージに配置します
Once the 'mtp3' packet is transformed back into a normal SS7 MSU, the MSU is routed within the SG according to the normal SS7 routing procedures.
「MTP3」パケットが通常のSS7 MSUに戻されると、MSUは通常のSS7ルーティング手順に従ってSG内にルーティングされます。
The 'saal' opcode is used to deliver SS7 MSUs with any Service Indicator over a TALI connection. This opcode is only used on TALI protocol stacks that are implemented with SAAL. The 'saal' opcode is also used to transmit SAAL peer to peer packets (SSCF peer to peer packets and SSCOP peer to peer packets other than SS7 service data) over a TALI connection.
「SAAL」オペコードは、TALI接続を介してSS7 MSUSを任意のサービスインジケーターとともに配信するために使用されます。このオペコードは、SAALで実装されたTALIプロトコルスタックでのみ使用されます。「SAAL」オペコードは、TALI接続を介してSAALピア（SSCFピアからピアパケットとSS7サービスデータ以外のSSCOPトゥピアパケット）を送信するためにも使用されます。
When used to transfer SS7 MSUs, the MTP3 layer of the SS7 MSU IS part of the data transferred across TCP/IP for this opcode; the data portion of the TALI 'saal' message begins with the SIO byte of the MTP3 header in the SS7 MSU and ends with the last byte of the SSCOP trailer.
SS7 MSUSを転送するために使用すると、SS7 MSUのMTP3層は、このオペコードのTCP/IPで転送されるデータの一部です。Tali 'Saal'メッセージのデータ部分は、SS7 MSUのMTP3ヘッダーのSIOバイトから始まり、SSCOPトレーラーの最後のバイトで終わります。
When used to transfer SSCF/SSCOP peer to peer messages the data portion of the TALI 'saal' message includes the entire SSCOP PDU.
SSCF/SSCOPピアをピアに転送するために使用される場合、Tali 'Saal'メッセージのデータ部分にはSSCOP PDU全体が含まれます。
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'saal' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length |
+------------------------------------------------------------------+
| 10..X | Layer 3 | Raw MSU data starting at the Layer 3 SIO |
| | Data | field. |
+------------------------------------------------------------------+
| (X+1) | SSCOP | Zero (0) to three (3) octets of padding |
| ..Y | Trailer | plus 4 octets for the trailer data. The |
| | | total length of the Layer 3 Data and the |
| | | SSCOP trailer must be a multiple of 4. |
+------------------------------------------------------------------+
or
または又はそれとも若しくは乃至或るいは
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'saal' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length |
+------------------------------------------------------------------+
| 10..X | SAAL Peer | Raw SSCF/SSCOP peer to peer packets are |
| | to Peer | also transferred over the TALI connection |
| | message | using this 'saal' opcode. |
+------------------------------------------------------------------+
When an SS7 MSU (with any SI) arrives at an SG from a 56 Kbps or DS1 link and is routed within the SG for transmission to an IP device, the SG performs the following processing on the SS7 MSU:
SS7 MSU（任意のSIを使用）が56 kbpsまたはDS1リンクからSGに到着し、IPデバイスへの伝送のためにSG内でルーティングされると、SGはSS7 MSUで以下の処理を実行します。
* discards the MTP Layer 2 information, CRC and flags
* MTPレイヤー2情報、CRC、フラグを破棄する
* the MSU is passed from an MTP3 processing software layer to the SSCF and SSCOP layers (the SAAL layers). These layers convert the SS7 MSU into an SSCOP PDU. Part of this conversion includes adding an SSCOP trailer.
* MSUは、MTP3処理ソフトウェアレイヤーからSSCFおよびSSCOPレイヤー（SAALレイヤー）に渡されます。 これらの層は、SS7 MSUをSSCOP PDUに変換します。 この変換の一部には、SSCOPトレーラーの追加が含まれます。
* the SSCOP PDU (whether it is a peer to peer SAAL message or SS7 MSU in an SSCOP PDU) is copied into the SERVICE payload area of the TALI packet
* SSCOP PDU（SSCOP PDUのPeer to Peer SaalメッセージまたはSS7 MSU）がTALIパケットのサービスペイロードエリアにコピーされます
* The SYNC field is set
* 同期フィールドが設定されています
* The OPCODE is set to 'saal'
* オペコードは「saal」に設定されています
* The LENGTH is set to the number of octets in the SERVICE field
* 長さは、サービスフィールドのオクテットの数に設定されます
Once the fully formed 'saal' TALI packet is created, it is handed to the TCP socket layer and transmitted. The transmission process will add TCP, IP and MAC header information.
完全に形成された「Saal」タリパケットが作成されると、TCPソケットレイヤーに渡されて送信されます。送信プロセスには、TCP、IP、およびMacヘッダー情報が追加されます。
Since the routing information is placed in the TALI Packet, no routing information needs to be saved by the SG.
ルーティング情報はTALIパケットに配置されるため、SGによってルーティング情報を保存する必要はありません。
SS7 MSU
SS7 MSU
| Layer 3 | Layer 2 |
| | |
+----+---+-----------+-------+---+--+---+---+---+---+----+
|Flag|FCS|Other Layer|Routing|SIO|LI|FIB|FSN|BIB|BSN|Flag|
| | |3 Data |Label | | | | | | | |
+----+---+-----------+-------+---+--+---+---+---+---+----+
| |
| |
| |
+-------+-----------------------+
|SSCOP | Service |
|Trailer| |
+-------+-----------------------+
| |
+-------+-----------------------+---+------+----+
|Service with SSCOP Trailer |LEN|Opcode|SYNC|
+-------+-----------------------+---+------+----+
| /
| -----------------
| /
+----------------------------+------+------+------+
| TALI Packet |TCP | IP | MAC |
| |Header|Header|Header|
+----------------------------+------+------+------+
Figure 9: Encapsulation of SAAL PDUs using the TALI 'saal' opcode
図9：Tali 'Saal' Opcodeを使用したSaal PDUのカプセル化
When an 'saal' TALI packet is received at the SG from an IP device, the SG performs the following processing on the 'saal' packet:
IPデバイスからSGで「Saal」タリパケットが受信されると、SGは「Saal」パケットで次の処理を実行します。
* validates the TALI header
* タリヘッダーを検証します
* Allocates space for a new SSCOP PDU message
* 新しいSSCOP PDUメッセージのスペースを割り当てます
* extracts the SSCOP PDU data from the SERVICE area and places it in the new SSCOP PDU message
* サービスエリアからSSCOP PDUデータを抽出し、新しいSSCOP PDUメッセージに配置します
Once the 'saal' packet is transformed back into a normal DS1 SSCOP PDU, the SSCOP PDU is passed to the SAAL layer for receive processing. If the SSCOP PDU is a peer to peer pdu, it is processed completely in the appropriate SAAL layer. If the SSCOP PDU is an SS7 MSU, the MSU is transformed back to a normal SS7 MSU and is routed within the SG according to the normal SS7 routing procedures.
「SAAL」パケットが通常のDS1 SSCOP PDUに戻されると、SSCOP PDUは受信処理のためにSAAL層に渡されます。 SSCOP PDUがピアツーピアPDUである場合、適切なSAAL層で完全に処理されます。 SSCOP PDUがSS7 MSUの場合、MSUは通常のSS7 MSUに戻され、通常のSS7ルーティング手順に従ってSG内にルーティングされます。
Version 1.0 of the TALI specification defined 4 TALI timers that are used as part of the TALI state machine. These timers are generically named 'T1' through 'T4'. Brief descriptions of each timer are provided in the following subsections. Timer expiration events for each of the T1-T4 timers appear as inputs to the TALI state machine. For exact processing of each timer (when to start/stop, how to process timer expirations), refer to the TALI state machine.
Tali仕様のバージョン1.0は、Tali State Machineの一部として使用される4つのTaliタイマーを定義しました。これらのタイマーは、一般的に「T1」を介して「T4」と呼ばれます。各タイマーの簡単な説明は、次のサブセクションで提供されています。T1-T4タイマーのそれぞれのタイマーの有効期限イベントは、Tali Stateマシンへの入力として表示されます。各タイマーの正確な処理（いつ開始/停止するか、タイマーの有効期限を処理する方法）については、Tali Stateマシンを参照してください。
Both ends of the TALI connection have there own T1-T4 timers. The T1-T4 timer values can be set on each end of the connection independent of the settings on the far end. For each timer, a default value and range is recommended in the following sections.
タリ接続の両端には、独自のT1-T4タイマーがあります。T1-T4タイマーの値は、遠端の設定とは無関係に接続の両端に設定できます。各タイマーについて、デフォルト値と範囲が次のセクションで推奨されます。
The T1 timer represents the time interval between the origination of a 'test' message at each TALI implementation. Each time T1 expires, the TALI implementation should send a 'test'.
T1タイマーは、各TALI実装での「テスト」メッセージの起源間の時間間隔を表します。T1が切れるたびに、TALIの実装は「テスト」を送信する必要があります。
The T2 timer represents the amount of time that the Peer has to return an 'allo' or a 'proh' in response to a 'test'. If the far end fails to reply with 'allo' or 'proh' before T2 expires, the sender of the 'test' treats the T2 expiration as a protocol violation. Note that T2 must be < T1 in order for these timers to work as designed.
T2タイマーは、ピアが「テスト」に応じて「アロ」または「プロ」を返しなければならない時間を表します。T2が失効する前に「Allo」または「Proh」で遠端が返信できない場合、「テスト」の送信者はT2の有効期限をプロトコル違反として扱います。これらのタイマーが設計どおりに機能するためには、T2が<T1でなければならないことに注意してください。
The T3 timer controls how long the near end should continue to process Service Data that is received from the far end after a Management Prohibit Traffic Event has occurred (at the near end). This timer is used when a transition from NEA-FEA (both ends allowed to send service data) to NEP-FEA (only far end willing to send service data) occurs. On that transition, it is reasonable to expect that the far end needs some amount of time to adjust its TALI state machine and divert service data traffic away from this socket. The T3 timer controls the amount of time the far end has to divert traffic.
T3タイマーは、経営陣がトラフィックイベントが発生した後（近端で）禁止された後、遠端から受信されるサービスデータを処理し続ける期間を制御します。このタイマーは、NEA-FEA（両端がサービスデータを送信することを許可されている）からNEP-FEA（サービスデータの送信を希望する遠端のみ）に移行するときに使用されます。その移行では、ファーエンドがタリ州のマシンを調整し、このソケットからサービスのトラフィックをそらすのにある程度の時間が必要であると期待するのが合理的です。T3タイマーは、遠端がトラフィックを迂回しなければならない時間を制御します。
The T4 timer represents the time interval between the origination of a 'moni' message at each TALI implementation. Each time T4 expires, the TALI implementation should send a 'moni'.
T4タイマーは、各TALI実装での「モニ」メッセージの起源間の時間間隔を表します。T4が切れるたびに、Taliの実装は「Moni」を送信する必要があります。
The following table provides the recommended default and configurable range for each TALI timer.
次の表は、各タリタイマーに推奨されるデフォルトと構成可能な範囲を示します。
+------------------------------------------------------------------+
|Name| Min | Max |Default| Description |
+------------------------------------------------------------------+
| T1 | 100ms | 60sec | 4 sec | Send test PDU timer |
+------------------------------------------------------------------+
| T2 | 100ms | 60sec | 3 sec | Response timer for an allo or proh |
| | | | | response to test message. |
+------------------------------------------------------------------+
| T3 | 100ms | 60sec | 5 sec | Timer controls how long to process |
| | | | | rcvd serv data after an NE |
| | | | | transition from NEA to NEP. System |
| | | | | is waiting for a proa response to |
| | | | | the first proh send when NE |
| | | | | transitions from NEA to NEP. |
+------------------------------------------------------------------+
| T4 | 100ms | 60sec |10 sec | Send moni PDU timer |
+------------------------------------------------------------------+
Table 5: Timers
表5：タイマー
NOTE: The value of T1 must be at least one (1) millisecond greater than T2. This is to prevent the system from a lockup in the T1 expired condition. If T1 is equal or less than T2, it will expire and restart T2 and not enforce responses to the test message.
注：T1の値は、T2より少なくとも1ミリ秒大きくなければなりません。これは、T1の有効期限が切れた状態でシステムがロックアップされないようにするためです。T1がT2の場合、またはT2未満の場合、T2の有効期限が切れて再起動し、テストメッセージへの応答を実施しません。
Enforcement of minimum and maximum timer values is implementation dependent.
最小および最大タイマー値の実施は実装に依存します。
Each TALI implementation must provide several user event controls over the behavior of the TALI state machine for each TALI connection. The user interface to provide these capabilities is implementation specific.
各TALIの実装は、各TALI接続のTALI Stateマシンの動作に対するいくつかのユーザーイベントコントロールを提供する必要があります。これらの機能を提供するユーザーインターフェイスは、実装固有です。
The 'mgmt open socket' event, together with the 'mgmt close socket' event, allows the user to control when each defined TALI connection will form a TCP socket connection. When 'open socket' for a particular TALI connection occurs, the TALI connection should begin trying to form a TCP socket connection to the peer.
「MGMT Open Socket」イベントと「MGMT Close Socket」イベントとともに、各定義されたTALI接続がTCPソケット接続を形成するときにユーザーが制御できます。特定のTALI接続の「オープンソケット」が発生すると、TALI接続がピアへのTCPソケット接続を形成しようとする必要があります。
The steps that are taken to connect are dependent on the client/server role of that end of the TALI connection. The exact steps to perform these tasks are implementation dependent and may differ based on the TCP stack being used.
接続するために取られる手順は、TALI接続のその端のクライアント/サーバーの役割に依存します。これらのタスクを実行するための正確な手順は実装依存であり、使用されているTCPスタックに基づいて異なる場合があります。
In general, TALI clients form socket connections by using the BSD sockets calls:
一般に、TALIクライアントはBSDソケット呼び出しを使用してソケット接続を形成します。
Socket() Bind() Connect()
socket（）bind（）connect（）
In general, TALI servers form socket connections by using the BSD sockets calls:
一般に、TALIサーバーはBSDソケット呼び出しを使用してソケット接続を形成します。
Socket() Bind() Listen() Accept()
socket（）bind（）聞きます（）accept（）
The 'mgmt close socket' event can be issued by the user when it is desired that the TCP socket for a TALI socket, be closed immediately, or discontinue its attempts to connect to the peer. After acting on 'close socket', the TALI connection will not be established until 'mgmt open socket' is issued.
「MGMT Close Socket」イベントは、TALIソケットのTCPソケットをすぐに閉じる、またはピアへの接続の試みを中止することが望まれる場合に、ユーザーが発行できます。「Close Socket」に作用した後、Tali接続は「MGMT Open Socket」が発行されるまで確立されません。
The 'mgmt allow traffic' event, together with the 'mgmt prohibit traffic' event, allows the user to control when each defined TALI connection will be willing to carry SS7 service data over that particular TALI connection. When 'mgmt allow traffic' is issued, the TALI implementation becomes willing to carry service data. The TALI state for the near end should transition to NEA (near end allowed) if the connection is already established.
「MGMT許可」イベントは、「MGMT禁止トラフィック」イベントとともに、ユーザーが定義された各TALI接続がその特定のTALI接続にSS7サービスデータを運ぶことをいとわないときに制御できるようにします。「MGMT許可トラフィック」が発行されると、TALIの実装はサービスデータを喜んで運ぶようになります。接続が既に確立されている場合は、近端のタリ州はNEA（近端で許可されている）に移行する必要があります。
The 'mgmt prohibit traffic' event is the opposite of 'allow traffic'. When 'mgmt prohibit traffic' is issued, the TALI implementation becomes un-willing to carry SS7 service data over that particular TALI connection. The TALI state for the near end should transition to NEP (near end prohibited) if the connection is already established.
「MGMTがトラフィックを禁止する」イベントは、「トラフィックを許可する」の反対です。「MGMTがトラフィックを禁止する」が発行されると、TALIの実装は、その特定のTALI接続の上にSS7サービスデータを運ぶようになりません。接続が既に確立されている場合、端末のタリ州はNEP（ほぼ終了禁止）に移行する必要があります。
In addition to timers, each TALI implementation needs to be able to detect, and react accordingly, for the following events:
タイマーに加えて、各タリの実装は、次のイベントで検出し、それに応じて対応できる必要があります。
* Connection Established. When the TCP socket connection is initially established the TALI state machine must be notified.
* 接続が確立されました。TCPソケット接続が最初に確立される場合、Tali Stateマシンに通知する必要があります。
* Connection Lost. When the TCP socket connection is lost, due to socket errors during reads/writes, the TALI state machine must be notified.
* 接続切断。読み取り/書き込み中のソケットエラーにより、TCPソケット接続が失われた場合、Tali Stateマシンに通知する必要があります。
* Protocol Violations. Any violation of the TALI protocol as discussed in 3.7.1.3.
* プロトコル違反。3.7.1.3で説明したタリプロトコルの違反。
The TALI version 1.0 specification is based on a state machine that considers 6 TALI states. Each end of the TALI connection maintains its own TALI state.
TALIバージョン1.0仕様は、6つのタリ州を考慮する状態マシンに基づいています。タリ接続の各端は、独自のタリ州を維持しています。
+------------------------------------------------------------------+
| Name | Description |
+------------------------------------------------------------------+
| OOS | The TALI connection is out of service. This usually|
| | corresponds to a user event to 'close' the socket, |
| | or a user event to 'deactivate the SS7 link'. |
+------------------------------------------------------------------+
| Connecting | The TALI layer is attempting to establish a TCP |
| | socket connection to the peer. Servers are |
| | 'accepting', clients are 'connecting'. |
+------------------------------------------------------------------+
| NEP-FEP | The TCP socket connection is established. Neither |
| | side of the connection is ready to use the socket |
| | for service PDUs. |
+------------------------------------------------------------------+
| NEP-FEA | The TCP socket connection is established. The NE is|
| | not ready to use the socket for service PDUs. The |
| | FE is ready to use the socket for service PDUs. |
+------------------------------------------------------------------+
| NEA-FEP | The TCP socket connection is established. The NE is|
| | ready to use the socket for service PDUs. The FE is|
| | not ready to use the socket for service PDUs. |
+------------------------------------------------------------------+
| NEA-FEA | The TCP socket connection is established. Both |
| | sides are ready to use the socket for service PDUs. |
| | This is the only state where normal bi-directional |
| | SS7 data transfer occurs. |
+------------------------------------------------------------------+
Table 6: TALI States
表6：タリ州
This section provides the state machine that must be followed by each TALI implementation in order to be compliant with this specification.
このセクションでは、この仕様に準拠するためには、各タリ実装が続く必要がある状態マシンを提供します。
Before presenting the actual state machine, several concepts are discussed.
実際の状態マシンを提示する前に、いくつかの概念について説明します。
1. Neither side can send service data unless both sides are allowed.
1. どちらの側も、両側が許可されない限り、サービスデータを送信することはできません。
2. Each side initializes to the prohibited state for both near end and far end.
2. それぞれの側は、ほぼ端と遠端の両方で禁止状態に初期化します。
3. State changes between the NEx-FEx states are signaled with either an 'allo' or 'proh'.
3. NEX-FEX状態間の状態の変化は、「Allo」または「Proh」のいずれかで通知されます。
4. Each side can poll the far end's state with a 'test'. Upon sending 'test', T1 and T2 should always be restarted.
4. それぞれの側は、「テスト」でファーエンドの状態を投票できます。 「テスト」を送信すると、T1とT2を常に再起動する必要があります。
5. Each side polls the far end with a 'test' every T1 expiration.
5. それぞれの側は、T1の有効期限ごとに「テスト」で遠端を投票します。
6. The reply to a 'test' is based on the state of the near end only.
6. 「テスト」への返信は、近端のみの状態に基づいています。
7. The reply to a 'test' is either 'allo' or 'proh'.
7. 「テスト」への返信は、「Allo」または「Proh」のいずれかです。
8. A far end signals the last service PDU has been transmitted with either a 'proh' or a 'proa'.
8. ファーエンドは、最後のサービスPDUに「proh」または「proa」のいずれかが送信されていることを示しています。
9. Upon receiving a 'proh', the receiver must always reply with 'proa'.
9. 「proh」を受け取ると、受信者は常に「proa」で返信する必要があります。
10. The NE cannot gracefully close a socket unless a 'proh' is sent and 'proa' is received.
10. NEは、「プロ」が送信され、「プロ」が受信されない限り、ソケットを優雅に閉じることはできません。
11. On the transition from NEA to NEP, after sending a 'proh', the near end must continue to process received service data until a 'proa' is received or until a T3 timer expires.
11. NEAからNEPへの移行では、「プロ」を送信した後、「PROA」が受信されるまで、またはT3タイマーが切れるまで、端末は受信したサービスデータを処理し続ける必要があります。
The state table treats a management request to close the socket as a 'hard' shutdown. That is, it will close the socket immediately regardless of the current state. Therefore, the correct steps to ensure a graceful shutdown of a socket (from the NEA_FEP or NEA_FEA states) is:
ステートテーブルは、ソケットを「ハード」シャットダウンとして閉じるための管理リクエストを扱います。つまり、現在の状態に関係なく、すぐにソケットを閉じます。したがって、ソケットの優雅なシャットダウンを確保するための正しい手順（NEA_FEPまたはNEA_FEA状態から）は次のとおりです。
1. Management issues a Management Prohibit Traffic Event on the socket.
1. 経営陣は、ソケットのトラフィックイベントを禁止する経営陣が発行します。
2. Management will wait for T3 to expire.
2. 経営陣はT3が期限切れになるのを待ちます。
3. Management can then issue a Close Socket Event on the socket.
3. その後、経営陣はソケットで緊密なソケットイベントを発行できます。
Each TALI implementation must detect when violations of the TALI protocol have occurred and react accordingly. Protocol violations include:
各タリの実装は、タリプロトコルの違反が発生したときに検出し、それに応じて反応する必要があります。プロトコル違反は次のとおりです。
* Invalid sync code in a received message
* 受信したメッセージ内の無効な同期コード
* Invalid opcode in a received message
* 受信したメッセージ内のOpCodeが無効です
* Invalid length field in a received message
* 受信したメッセージ内の無効な長さフィールド
* Not receiving an 'allo' or 'proh', in response to the origination of a 'test' , before the T2 timer expires
* T2タイマーが期限切れになる前に、「テスト」の起源に応じて、「Allo」または「Proh」を受け取っていない
* Receiving Service Messages on a prohibited socket.
* 禁止されているソケットでサービスメッセージを受信します。
* TCP Socket errors - Connection Lost
* TCPソケットエラー - 接続が失われました
In the state machine that follows, State/Event combinations that should be treated as protocol violations are indicated via a 'PV' in the state/event cell. All of the 'PV' events are then processed as per the 'Protocol Violation' row in the table.
次の状態マシンでは、プロトコル違反として扱う必要がある状態/イベントの組み合わせは、州/イベントセルの「PV」を介して示されています。すべての「PV」イベントは、テーブルの「プロトコル違反」行に従って処理されます。
Internal Data required for State Machine:
状態マシンに必要な内部データ：
boolean sock_allowed. This flag indicates whether the NE is allowed to carry Service Messages.
boolean sock_allowed。このフラグは、NEがサービスメッセージを伝達することを許可されているかどうかを示します。
Initial Conditions: sock_allowed = FALSE state = OOS no timers running
初期条件：sock_allowed = false state = oosタイマーは実行されていません
+------------------------------------------------------------------+
| State| OOS |Connecting| NEP-FEP | NEP-FEA | NEA-FEP | NEA-FEA |
|Event | | | | | | |
+------------------------------------------------------------------+
|T1 Exp. | | |Send test|Send test|Send test|Send test|
| | | |Start T1 |Start T1 |Start T1 |Start T1 |
| | | |Start T2 |Start T2 |Start T2 |Start T2 |
+------------------------------------------------------------------+
|T2 Exp. | | | PV | PV | PV | PV |
+------------------------------------------------------------------+
|T3 Exp. | | | PV | PV | | |
+------------------------------------------------------------------+
|T4 Exp. | | |Send moni|Send moni|Send moni|Send moni|
| | | |Start T4 |Start T4 |Start T4 |Start T4 |
+------------------------------------------------------------------+
|Rcv test| | |Send proh|Send proh|Send allo|Send allo|
+------------------------------------------------------------------+
|Rcv allo| | | Stop T2 | Stop T2 | Stop T2 | Stop T2 |
| | | | NEP-FEA | | NEA-FEA | |
+------------------------------------------------------------------+
|Rcv proh| | | Stop T2 | Stop T2 | Stop T2 | Stop T2 |
| | | |Send proa|Send proa|Send proa|Flush or |
| | | | | NEP-FEP | | reroute |
| | | | | | |Send proa|
| | | | | | | NEA-FEP |
+------------------------------------------------------------------+
|Rcv proa| | | Stop T3 | Stop T3 | | |
+------------------------------------------------------------------+
|Rcv moni| | |Convert |Convert |Convert |Convert |
| | | | to mona | to mona | to mona | to mona |
| | | |Send mona|Send mona|Send mona|Send mona|
+------------------------------------------------------------------+
|Rcv mona| | |Implemen-|Implemen-|Implemen-|Implemen-|
| | | |tation |tation |tation |tation |
| | | |dependent|dependent|dependent|dependent|
+------------------------------------------------------------------+
|Rcv | | | PV |If T3 run| PV |Process |
| Service| | | | Process | | |
| | | | |Else PV | | |
+------------------------------------------------------------------+
|Connect.| | Start T1 | | | | |
|Estab. | | Start T2 | | | | |
| | | Start T4 | | | | |
| | |(if non-0)| | | | |
| | |if sock_ | | | | |
| | | allowed | | | | |
| | | = TRUE | | | | |
| | | send allo| | | | |
| | | send test| | | | |
| | | NEA-FEP | | | | |
| | |else | | | | |
| | | send proh| | | | |
| | | send test| | | | |
| | | NEP-FEP | | | | |
+------------------------------------------------------------------+
|Connect.| | | PV | PV | PV | PV |
|Lost | | | | | | |
+------------------------------------------------------------------+
|Protocol| | |Stop all |Stop all |Stop all |Stop all |
|Violat. | | | timers | timers | timers | timers |
| | | |Close the|Close the|Close the|Close the|
| | | | socket | socket | socket | socket |
| | | |Connect- |Connect- |Connect- |Connect- |
| | | | ing | ing | ing | ing |
+------------------------------------------------------------------+
|Mgmt. |Open | | | | | |
|Open |socket| | | | | |
|Socket |Conne-| | | | | |
| | cting| | | | | |
+------------------------------------------------------------------+
|Mgmt. | |Close the |Stop all |Stop all |Stop all |Stop all |
|Close | | socket | timers | timers | timers | timers |
|Socket | |OOS |Close the|Close the|Close the|Close the|
| | | | socket | socket | socket | socket |
| | | |OOS |OOS |OOS |OOS |
+------------------------------------------------------------------+
|Mgmt. |sock_ |sock_allo-|sock_all-|sock_all-|sock_all-|sock_all-|
|Prohibit|allow-| wed=FALSE| owed= | owed= | owed= | owed= |
|Socket |ed = | | FALSE | FALSE | FALSE | FALSE |
| |FALSE | | | |send proh|send proh|
| | | | | |start t3 |start t3 |
| | | | | | NEP-FEP | NEP-FEA |
| | | | | | | |
+------------------------------------------------------------------+
|Mgmt. |sock_ |sock_allo-|sock_all-|sock_all-|sock_all-|sock_all-|
|Allow |allow-| wed=TRUE | owed= | owed= | owed= | owed= |
|Traffic |ed = | | TRUE | FALSE | TRUE | TRUE |
| |TRUE | |send allo|send allo| | |
| | | | NEA-FEP | NEA-FEA | | |
+------------------------------------------------------------------+
|User |reject| reject | reject | reject | reject | send |
|Part |data | data | data | data | data | data |
|Msgs. | | | | | | |
+------------------------------------------------------------------+
Table 7: TALI 1.0 State Machine
表7：TALI 1.0状態マシン
Several aspects of the expected TALI 1.0 implementation have not been specifically addressed in the state machine or previous text (or else they were presented but will be reiterated here). These implementation notes in some cases have to do with the expected behavior of the software layer above the TALI layer.
予想されるTALI 1.0の実装のいくつかの側面は、州のマシンや以前のテキストで特別に対処されていません（または、提示されましたが、ここで繰り返されます）。これらの実装ノートでは、場合によっては、タリ層の上のソフトウェア層の予想される動作に関係しています。
* The failure to read or write from a TCP socket shall be detected and generate a connection lost event.
* TCPソケットからの読み取りまたは書き込みの失敗を検出し、接続の失われたイベントを生成するものとします。
* Message streams can be monitored for congestion via implementation dependent methods.
* メッセージストリームは、実装に依存する方法を介して混雑を監視できます。
* One possible definition of congestion for the previous requirement might be when a TCP socket is blocked.
* 以前の要件の輻輳の可能な定義の1つは、TCPソケットがブロックされている場合になる可能性があります。
Several limitations with the TALI 1.0 specification and implementation are identified:
TALI 1.0の仕様と実装に関するいくつかの制限が特定されています。
* For SCCP traffic, only UDT and XUDT Class 0 and Class 1 traffic should be managed by this protocol.
* SCCPトラフィックの場合、UDTおよびXUDTクラス0およびクラス1トラフィックのみをこのプロトコルで管理する必要があります。
* When the MTP3 Routing Label is not part of the data transmitted across the wire, priority zero (0) traffic is used for all traffic when the SIO is regenerated.
* MTP3ルーティングラベルがワイヤ間で送信されるデータの一部ではない場合、SIOが再生されると、すべてのトラフィックに優先ゼロ（0）トラフィックが使用されます。
Version 2.0 of the TALI specification provides several additions to the Version 1.0 specification. The 2.0 additions are provided by introducing three new TALI opcodes. The basic functionality and most of the details of the TALI 1.0 implementation are NOT changed by the 2.0 additions.
TALI仕様のバージョン2.0は、バージョン1.0仕様にいくつかの追加を提供します。2.0の追加は、3つの新しいTali Opcodesを導入することにより提供されます。Tali 1.0の実装の基本機能と詳細のほとんどは、2.0の追加によって変更されません。
The table below provides a summary of the messages and message structure used in TALI version 2.0.
以下の表は、Taliバージョン2.0で使用されているメッセージとメッセージ構造の概要を示しています。
+------------------------------------------------------------------+
| OCTET | DESCRIPTION | SIZE | VALUE | TYPE |
+------------------------------------------------------------------+
| 0..3 | SYNC | 4 Octets | | 4 byte ASCII |
+------------------------------------------------------------------+
| | TALI | | 'TALI' | |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 4 Octets | | 4 byte ASCII |
+------------------------------------------------------------------+
| | Test Service | | 'test' | |
| | Allow Service | | 'allo' | |
| | Prohibit Service | | 'proh' | |
| | Prohibit Service Ack| | 'proa' | |
| | Monitor Socket | | 'moni' | |
| | Monitor Socket Ack | | 'mona' | |
| | SCCP Service | | 'sccp' | |
| | ISUP Service o/TALI | | 'isot' | |
| | MTP3 Service o/TALI | | 'mtp3' | |
| | Service o/SAAL | | 'saal' | |
| | Management Message | | 'mgmt' | |
| | Extended Service Msg| | 'xsrv' | |
| | Special Message | | 'spcl' | |
+------------------------------------------------------------------+
| 8..9 | LENGTH | 2 Octets | | integer |
| | (least significant | | | |
| | byte first) non-0 | | | |
| | if Service or | | | |
| | Socket monitor msg | | | |
+------------------------------------------------------------------+
| 10..X | DATA PAYLOAD | variable | | variable |
+------------------------------------------------------------------+
Due to the minimal amount of change from 1.0, this chapter will only provide:
1.0からの変化の量が最小限であるため、この章は次のようにしか提供しません。
* Detailed information regarding how a TALI implementation can identify itself as a 2.0 vs. a 1.0 implementation
* タリの実装がどのように自分自身を2.0と1.0の実装として識別できるかに関する詳細情報
* Detailed information regarding how to provide backward compatibility for a connection to a far end that is only TALI 1.0 capable
* Tali 1.0のみであるファーエンドへの接続のための後方互換性を提供する方法に関する詳細情報
* Detailed information regarding the new 2.0 opcodes
* 新しい2.0オプコードに関する詳細情報
* Detailed information regarding any other changes to the information presented in previous sections that need to be implemented in order to be 2.0 compatible.
* 2.0に互換性があるために実装する必要がある以前のセクションで提示された情報に対するその他の変更に関する詳細情報。
Therefore, readers of this chapter should read this from the point of view of modifying an existing TALI 1.0 implementation to support the new 2.0 features.
したがって、この章の読者は、新しい2.0機能をサポートするために既存のTALI 1.0実装を変更するという観点からこれを読む必要があります。
A small number of changes to a 1.0 TALI implementation are required to support 2.0. Figure 10 illustrates the inputs that affect the 2.0 TALI State Machine. The reader may notice that the only differences from the inputs for 1.0 are as follows:
2.0をサポートするには、1.0 TALI実装の少数の変更が必要です。図10は、2.0 Tali Stateマシンに影響を与える入力を示しています。読者は、1.0の入力との唯一の違いが次のとおりであることに気付くかもしれません。
Three new TALI opcodes can be sent/received between a TALI node and its peer. The new opcodes are:
Taliノードとそのピアの間に3つの新しいTali Opcodesを送信/受信できます。新しいオプコードは次のとおりです。
* 'mgmt' * 'xsrv' * 'spcl'
* 'mgmt' * 'xsrv' * 'spcl'
Three new User Part capabilities need to be supported by the layer of code above the TALI layer in each implementation. The user part needs to provide support for 'mgmt', 'xsrv', and 'spcl' data.
3つの新しいユーザーパーツ機能は、各実装のタリ層の上のコードのレイヤーによってサポートする必要があります。ユーザーパーツは、「MGMT」、「XSRV」、および「SPCL」データのサポートを提供する必要があります。
More information about the 3 new opcodes is provided in individual sections in this chapter. However, a brief description of the purpose of each of these opcodes is as follows:
この章の個々のセクションには、3つの新しいオプコードの詳細について説明します。ただし、これらの各オペコードの目的の簡単な説明は次のとおりです。
* 'mgmt' - This opcode is intended to allow MANAGEMENT data, or data that will manage the operation of the device, to pass between the TALI endpoints. Examples of this management data include:
* 'mgmt' - このオペコードは、管理データ、またはデバイスの動作を管理するデータを、タリのエンドポイント間を通過させることを目的としています。この管理データの例は次のとおりです。
* configuration data, such as which SS7 traffic streams a peer would like to receive over a specific socket
* ピアが特定のソケットで受信したいSS7トラフィックストリームなどの構成データ
* SS7 Network Management data, such as information regarding point code (un)availability and congestion.
* SS7ネットワーク管理データ、ポイントコード（UN）の可用性や混雑に関する情報など。
* Enabling/disabling various socket options, such as options regarding which messages are supported, or how to format data.
* どのメッセージがサポートされているか、データのフォーマット方法に関するオプションなど、さまざまなソケットオプションを有効/無効にします。
* 'xsrv' - Extended Service Opcodes. It is envisioned that the TALI protocol could be extended to carry other types of traffic that are not covered by the 1.0 service data opcodes ('sccp', 'isot', 'mtp3', or 'saal'). By defining a new 'xsrv' service opcode, the TALI protocol is opened up to the possibility of being used for other types of data transport.
* 「XSRV」 - 拡張サービスオプコード。TALIプロトコルを拡張して、1.0 Service Data Opcodes（ 'sccp'、 'isot'、 'mtp3'、または 'saal'）でカバーされていない他のタイプのトラフィックを運ぶことができると想定されています。新しい「XSRV」サービスオペコードを定義することにより、TALIプロトコルは、他のタイプのデータトランスポートに使用される可能性に開かれています。
* 'spcl' - Special services. It is envisioned that vendors may want to build special services into their TALI implementations that are only activated when the implementation is connected to other equipment implementing the same special services. This opcode is intended to provide a general means to discover more information regarding who the TALI session is connected to, and a means to enable special features based on the vendor/implementation on the far end.
* 「SPCL」 - 特別なサービス。ベンダーは、同じ特別なサービスを実装する他の機器に実装が接続されている場合にのみアクティブ化されるタリ実装に特別なサービスを構築したいと考えています。このオペコードは、タリセッションが誰に接続されているかに関するより多くの情報を発見するための一般的な手段と、遠端のベンダー/実装に基づいて特別な機能を有効にする手段を提供することを目的としています。
+====+ +---------+ +============+
| | | Service | +-------------+ | |
|User| | Message,| | Mgmt. Open | | MANAGEMENT |
|Part|<-->| MGMT, | | Mgmt. Close |<-->| |
| | | XSRV, | | Mgmt. Proh. | | |
| | | SPCL | | Mgmt. Allow | +============+
+====+ +---------+ +-------------+
^ ^
| |
v v
+========================================================+
| TALI State Machine |
+========================================================+
^ ^ ^ ^
| | | |
v | | |
+---------+ | | |
| Received| +-----------------+ +-----------+ +------------+
| 'test', | | Connection est. | | Protocol | | T1 Expired |
| 'allo', | | Connection lost | | Violation | | T2 Expired |
| 'proh', | | | | | | T3 Expired |
| 'proa', | +-----------------+ +-----------+ | T4 Expired |
| 'moni', | ^ ^ +------------+
| 'mona', | | | ^
| 'mgmt', | | | |
| 'xsrv', | | | |
| 'spcl', | | | |
| or | +========================================+
| Service | | IMPLEMENTATION |
| Message | | DEPENDENT |
+---------+ +========================================+
^
|
v
+============+
| PEER |
| |
+============+
Figure 10: Overview of Inputs to the TALI 2.0 State Machine
図10：TALI 2.0状態マシンへの入力の概要
The TALI 1.0 specification did not provide a simple means to perform TALI version identification. However, the general purpose 'moni' message from 1.0 can be used to solve this problem in 2.0.
TALI 1.0仕様は、TALIバージョンの識別を実行する簡単な手段を提供しませんでした。ただし、1.0からの汎用「Moni」メッセージを使用して、この問題を2.0で解決できます。
Recall from 1.0 that the 'moni' message was very loosely defined in the 1.0 spec:
1.0のメッセージが1.0仕様で非常にゆるく定義されていたことを1.0から思い出してください。
* The primary purpose of the 'moni' message was to provide a general purpose ECHO capability. It was envisioned that an important task that the ECHO capability could provide would be to measure Round Trip TALI/TALI processing time.
* 「モニ」メッセージの主な目的は、汎用エコー能力を提供することでした。エコー機能が提供できる重要なタスクは、タリ/タリの処理時間を往復することであると想定されていました。
* The data portion of the 'moni' message could be from 0-200 bytes long. The use of the data area was completely implementation specific.
* 「モニ」メッセージのデータ部分の長さは0〜200バイトです。データ領域の使用は完全に実装固有でした。
* There were no requirements that an implementation ever send a 'moni'.
* 実装が「モニ」を送信する要件はありませんでした。
* If an implementation did send 'moni', it should use the T4 timer to control the frequency of the outgoing 'moni'.
* 実装が「モニ」を送信した場合、T4タイマーを使用して、発信「モニ」の頻度を制御する必要があります。
* The receiver of the 'moni' should not make any assumptions as to the data portion of the 'moni'. The receiver should simply convert the 'moni' into a 'mona' and return the message with the same data portion.
* 「モニ」の受信者は、「モニ」のデータ部分について仮定を立てるべきではありません。受信者は、単に「モニ」を「モナ」に変換し、同じデータ部分でメッセージを返す必要があります。
TALI 2.0 implementations should use the 'moni' message to provide version identification as per the following bullets:
Tali 2.0の実装は、「Moni」メッセージを使用して、次の箇条書きに従ってバージョン識別を提供する必要があります。
* The primary purpose of the 'moni' message is now twofold:
* 「モニ」メッセージの主な目的は今では2つあります。
* To provide version identification
* バージョン識別を提供します
* To continue to provide a general purpose ECHO capability that can be used to measure Round Trip time or perform other implementation specific tasks.
* 総目的のエコー機能を提供し続けるには、往復時間を測定したり、他の実装固有のタスクを実行したりするために使用できます。
* The data portion of the 'moni' message is now divided into 2 portions
* 「モニ」メッセージのデータ部分は2つの部分に分割されます
* A portion dedicated to version identification, 12 bytes long, with a specific format that must be followed
* バージョンの識別に特化した部分、12バイトの長さ、従う必要がある特定の形式を備えた
* Followed by a free format section that can be used in a completely implementation specific manner.
* その後、完全に実装された方法で使用できる無料のフォーマットセクションが続きます。
* The overall length of the data portion for a 'moni' should still not exceed 200 bytes. This is required to maintain backward compatibility with 1.0 implementations that may check for a maximum length of 200 bytes on the 'moni' opcode.
* 「モニ」のデータ部分の全長は、まだ200バイトを超えてはなりません。これは、「MONI」オペコードで最大200バイトの長さをチェックする可能性のある1.0の実装での逆方向の互換性を維持するために必要です。
* If a TALI implementation wants to identify itself as a version 2.0 node, it must send a 'moni' encoded as per Table 8. Every 'moni' it sends should conform to the encoding in Table 8. The version label should not change from 'moni' to 'moni'. The data following the version label can change from 'moni' to 'moni' and can continue to be used for RTT calculations, or other purposes.
* TALIの実装がバージョン2.0ノードとして自分自身を識別したい場合、表8に従ってエンコードされた「モニ」を送信する必要があります。モニ 'から「モニ」。バージョンラベルに続くデータは、「モニ」から「モニ」に変更でき、RTT計算またはその他の目的に引き続き使用できます。
* If a TALI implementation is trying to determine if the far end of the TALI connection has implemented version 2.0, the implementation must examine any received 'moni' messages that arrive from the far end and see if they conform to the new stricter 'moni' encoding in Table 8. On receiving 'moni', a TALI 2.0 node will compare the 12 bytes of data in the VER LABEL field with a list of predetermined strings to determine the functionality of the TALI node it is connected to. If the data doesn't match any of the predetermined strings, the Far End is assumed to be a TALI 1.0 node.
* TALIの実装がTALI接続の遠端がバージョン2.0を実装しているかどうかを判断しようとしている場合、実装は遠端から到着した受信した「モニ」メッセージを調べ、新しいより厳しい「モニ」エンコードに準拠するかどうかを確認する必要があります。表8では、「Moni」を受信すると、Tali 2.0ノードは、Verラベルフィールドの12バイトのデータを所定の文字列のリストと比較して、接続されているTaliノードの機能を決定します。データが所定の文字列のいずれかと一致しない場合、遠端はTALI 1.0ノードであると想定されます。
* Each TALI implementation must assume that the far end of the connection is a 1.0 implementation until an arriving 'moni' announces that the far end supports TALI version 2.0. If a 'moni' never arrives, the implementation knows the far end has implemented version 1.0 of the specification.
* 各タリの実装は、到着する「モニ」がファーエンドがタリバージョン2.0をサポートすることを発表するまで、接続の遠端が1.0の実装であると想定する必要があります。「モニ」が到着しない場合、実装は、ファーエンドが仕様のバージョン1.0を実装していることを知っています。
* TALI 1.0 implementations can receive newly encoded 'moni' messages and simply ignore the data. The 1.0 implementations will continue to operate as if the far end is always a 1.0 node (ignore the data portion of the 'moni', convert 'moni' to 'mona', and return the 'mona').
* TALI 1.0の実装は、新しくエンコードされた「モニ」メッセージを受信し、データを単純に無視できます。1.0の実装は、遠端が常に1.0ノードであるかのように動作し続けます（「モニ」のデータ部分を無視し、「モニ」に「モナ」に変換し、「モナ」を返します）。
* The next section provides more information regarding backwards compatibility (2.0 implementations connected to devices that implemented version 1.0 of the specification).
* 次のセクションでは、逆方向の互換性（仕様のバージョン1.0を実装したデバイスに接続された2.0実装）に関する詳細情報を提供します。
+------------------------------------------------------------------+
| Octets | Field Name | Description | Field Type |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |4 byte ASCII|
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'moni' |4 byte ASCII|
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length (includes the version | Integer |
| | | label and data fields) | |
+------------------------------------------------------------------+
| 10..21 | Ver. Label | 'vers xxx.yyy' | 12 byte |
| | See note | | ASCII |
+------------------------------------------------------------------+
| 22..X | DATA | Vendor Dependent | Variable |
| | | Maximum length of this | |
| | | message (as coded in octets 8| |
| | | -9, and stored in bytes 10-X)| |
| | | should not exceed 200 bytes. | |
+------------------------------------------------------------------+
Table 8: Version Control 'moni' Message
表8：バージョン制御「モニ」メッセージ
NOTE: xxx.yyy = provides the Major and Minor release number of the TALI specification being implemented. 001.000 = Tali version 1.0 002.000 = Tali version 2.0 // this specification. 002.001 = Tali version 2.1 // a minor change to 2.0 003.000 = Tali version 3.0 and so on.
注：xxx.yyy =実装されているTALI仕様の主要なリリース番号とマイナーリリース番号を提供します。001.000 = TALIバージョン1.0 002.000 = TALIバージョン2.0 //この仕様。002.001 = TALIバージョン2.1 // 2.0 003.000へのマイナーな変更= TALIバージョン3.0など。
The 'vers 002.000' field is an 12 byte field of field type 'ascii text'. As such, 'v' should be the first byte of the field that is transmitted out the wire.
「Vers 002.000」フィールドは、フィールドタイプ「ASCIIテキスト」の12バイトフィールドです。そのため、「V」は、ワイヤーから送信されるフィールドの最初のバイトである必要があります。
As part of adding new functionality to the TALI specification, backwards compatibility from TALI version 2.0 to version 1.0 is required. Backwards compatibility is important since TALI 2.0 nodes may be connected to far ends that only support version 1.0; it is important that these 2 implementations continue to inter-operate, and that the 2.0 node falls back to supporting only 1.0 opcodes in this situation.
TALI仕様に新しい機能を追加する一環として、TALIバージョン2.0からバージョン1.0への逆方向の互換性が必要です。TALI 2.0ノードは、バージョン1.0のみをサポートするFAR ENDORに接続される可能性があるため、逆方向の互換性が重要です。これらの2つの実装が操作を続け、2.0ノードがこの状況では1.0オプコードのみをサポートすることに戻ることが重要です。
The previous section described how a TALI 2.0 implementation can use the 'moni' it sends to identify itself as a 2.0 node and how it can use the 'moni' it receives to determine if the far end is also a 2.0 node. In addition to the discussion in the previous section, the following bullets provide details regarding how backwards compatibility must be achieved:
前のセクションでは、TALI 2.0の実装がどのように送信される「モニ」を使用して2.0ノードとして識別し、「モニ」を使用する方法を受信して、遠端が2.0ノードであるかどうかを判断する方法について説明しました。前のセクションの議論に加えて、次の弾丸は、後方互換性をどのように達成しなければならないかに関する詳細を提供します。
* As documented in the version 1.0 specification, TALI 1.0 implementations that receive TALI messages with 'mgmt', 'xsrv', and 'spcl' opcodes will treat the message as a Protocol Violation (invalid opcode received). The Protocol Violation will cause the socket to be dropped immediately.
* バージョン1.0仕様で文書化されているように、「MGMT」、「XSRV」、および「SPCL」オペコードを使用してTALIメッセージを受信するTALI 1.0の実装は、メッセージをプロトコル違反として扱います（無効なOpCodeが受信）。プロトコル違反により、ソケットはすぐにドロップされます。
* It is therefore required that a 2.0 implementation only send 'mgmt', 'xsrv', and 'spcl' opcodes, after it has used a received 'moni' message to determine that the far end is a 2.0 (or later) implementation and has identified itself as a 2.0 (or later) implementation.
* したがって、2.0の実装は、「MGMT」、「XSRV」、および「SPCL」オプコードのみを送信する必要があります。2.0（またはそれ以降の）実装として自分自身を特定しました。
* Each TALI 2.0 implementations must use the 'moni' as described in the previous section to identify themselves as 2.0, and to learn if the far end is 2.0.
* 各TALI 2.0の実装は、前のセクションで説明されているように「MONI」を使用して2.0と識別し、遠端が2.0であるかどうかを知る必要があります。
* Each TALI 2.0 implementation should maintain a variable as part of its state machine, 'far_end_version'. The 'far_end_version' should be initialized to 1.0 when the socket is established. Each time a 2.0 implementation receives 'moni', it should update the 'far_end_version' variable. If the 'moni' did not contain a version label, the 'far_end_version' should be reset to 1.0. If the 'moni' did contain a version label for 2.0 (or a later version), the 'far_end_version' should be set accordingly.
* 各TALI 2.0の実装は、状態マシン「FAR_END_VERSION」の一部として変数を維持する必要があります。ソケットが確立されている場合、「FAR_END_Version」は1.0に初期化する必要があります。2.0実装が「MONI」を受信するたびに、「FAR_END_Version」変数を更新する必要があります。「モニ」にバージョンラベルが含まれていない場合、「FAR_END_Version」を1.0にリセットする必要があります。「モニ」に2.0（または後のバージョン）のバージョンラベルが含まれていた場合、それに応じて「FAR_END_Version」を設定する必要があります。
* Each time a 2.0 implementation receives a new 2.0 opcode ('mgmt', 'xsrv', and 'spcl') from the far end, it should examine the ' far_end_version'. If the 'far_end_version' indicates the far end is a 1.0 implementation, the received TALI message should be treated as a Protocol Violation (invalid opcode). If the 'far_end_version' is 2.0 (or later), the 2.0 implementation should process the received 'mgmt/xsrv/spcl' according to that nodes capabilities for that opcode.
* 2.0実装が新しい2.0オペコード（ 'mgmt'、 'xsrv'、および 'spcl'）を遠端から受信するたびに、「far_end_version」を調べる必要があります。「FAR_END_Version」が遠端が1.0の実装であることを示す場合、受信したTALIメッセージはプロトコル違反（無効なOPCODE）として扱う必要があります。「far_end_version」が2.0（またはそれ以降）の場合、2.0の実装は、そのオプコードのノード機能に従って受信した「mgmt/xsrv/spcl」を処理する必要があります。
* Each time a 2.0 implementation receives a request to send a TALI message with a 2.0 opcode ('mgmt/xsrv/spcl') from a higher layer of software, it should examine the 'far_end_version'. If the 'far_end_version' indicates the far end is a 1.0 implementation, the request to send the 2.0 opcode should be denied or ignored (an implementation decision) and the 2.0 opcode must NOT be sent to the far end. If the 'far_end_version' indicates the far end is 2.0 (or later), the request can be satisfied and the TALI message with the 2.0 opcode can be sent to the far end.
* 2.0の実装が、より高いレイヤーのソフトウェアから2.0オペコード（ 'mgmt/xsrv/spcl'）でtaliメッセージを送信するリクエストを受信するたびに、「far_end_version」を調べる必要があります。「far_end_version」がファーエンドが1.0の実装であることを示す場合、2.0オペコードを送信するリクエストは拒否または無視され（実装決定）、2.0オペコードを遠端まで送信してはなりません。「far_end_version」が遠端が2.0（またはそれ以降）であることを示す場合、リクエストを満たすことができ、2.0オペコードを使用したタリメッセージを遠端まで送信できます。
* Each TALI 2.0 implementation can provide a varying level of support for each of the three new 2.0 opcodes ('mgmt/xsrv/spcl'). In other words, an implementation may wish to only support SOME OF the primitives within the new opcodes. The level of support for each 2.0 opcode ('mgmt/xsrv/spcl') is independent of the other two 2.0 opcodes.
* 各TALI 2.0の実装は、3つの新しい2.0オプコード（ 'MGMT/XSRV/SPCL'）のそれぞれにさまざまなレベルのサポートを提供できます。言い換えれば、実装は、新しいオペコード内のいくつかのプリミティブのみをサポートしたい場合があります。各2.0オペコード（ 'MGMT/XSRV/SPCL'）のサポートレベルは、他の2つの2.0オプコードとは無関係です。
* The basic message structure for TALI messages using the new 2.0 opcodes is presented in Table 9.
* 新しい2.0オプコードを使用したTALIメッセージの基本メッセージ構造を表9に示します。
* The minimal level of support that is required for each of the 2.0 opcodes (mgmt/xsrv/spcl) is to be able to receive TALI messages with these opcodes, recognize the new opcode, and ignore the message without affecting the state machine. The TALI state should not change. The socket connection should stay up. In other words, a 2.0 implementation can elect to ignore any received 'mgmt/xsrv/spcl' messages, if that implementation does not care to support the capability intended by that particular opcode.
* 2.0オペコード（MGMT/XSRV/SPCL）のそれぞれに必要な最小レベルのサポートは、これらのオペコードでTALIメッセージを受信し、新しいオプコードを認識し、状態マシンに影響を与えることなくメッセージを無視できるようにすることです。タリ州は変わってはなりません。ソケット接続は上昇しておく必要があります。言い換えれば、2.0の実装では、その特定のOPCodeが意図した機能をサポートすることを気にしない場合、受信した「MGMT/XSRV/SPCL」メッセージを無視することを選択できます。
* A partial level of support for a 2.0 opcode could be implemented. Partial support may consist of understanding the data structure for the 2.0 opcode, but only supporting some of the variants of the opcode. The message structure for each of the new 2.0 opcodes consists of an extra 'Primitive' field that follows the TALI opcode and message length fields. Each 'Primitive' is used to differentiate a variant of the opcode. It is envisioned that each new 2.0 opcode can be extended by adding new 'Primitives', as more capabilities are defined for the opcode, without having to add new TALI opcodes. A 2.0 implementation may understand and be willing to act on some of the 'Primitives' for an opcode, but not others. Receiving variants of a 2.0 opcode that an implementation does not understand need to be ignored and not affect the 2.0 state machine.
* 2.0オペコードの部分レベルのサポートを実装できます。部分的なサポートは、2.0オペコードのデータ構造を理解することで構成されている場合がありますが、オペコードのバリアントの一部のみをサポートしています。新しい2.0オペコードのそれぞれのメッセージ構造は、Tali Opcodeとメッセージの長さフィールドに続く追加の「プリミティブ」フィールドで構成されています。各「プリミティブ」は、オペコードのバリアントを区別するために使用されます。新しい2.0オペコードは、新しい「プリミティブ」を追加することで拡張できることを想定しています。これは、新しいTaliオプコードを追加することなく、オペコードの機能がより多く定義されているためです。2.0の実装は、オペコードの「プリミティブ」の一部に理解し、喜んで行動することをいとわないが、他のものではないかもしれない。実装が理解していない2.0オペコードのバリエーションを無視する必要があり、2.0状態マシンに影響を与えないようにします。
* The full level of support for a 2.0 opcode could be implemented. This support would consist of understanding and fully supporting every 'Primitive' within the 2.0 opcode.
* 2.0オペコードの完全なレベルのサポートを実装できます。 このサポートは、2.0オペコード内のすべての「プリミティブ」を理解し、完全にサポートすることで構成されます。
+------------------------------------------------------------------+
| Octets | Field Name | Description | Field Type |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |4 byte ASCII|
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'mgmt', 'xsrv' or 'spcl' |4 byte ASCII|
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length (length of the rest | Integer |
| | | of this packet) | |
+------------------------------------------------------------------+
| 10..13 | Primitive | 'wxyz', or a 4 byte text | 4 byte |
| | See note | that is appropriate for the | ASCII |
| | | given opcode | |
+------------------------------------------------------------------+
| 14..X | DATA | The content of the data area | Variable |
| | | is dependent on the opcode/ | |
| | | primitive combination | |
+------------------------------------------------------------------+
Table 9: Basic Message Structure for New 2.0 TALI Opcodes
表9：新しい2.0タリオプコードの基本メッセージ構造
NOTE: The Primitive field acts as a modifier for each opcode. Within an opcode, different operations or groups of operations can be defined and supported. The Primitive identifies each different operation or set of operations.
注：プリミティブフィールドは、各オペコードの修飾子として機能します。オペコード内では、異なる操作または操作グループを定義およびサポートできます。プリミティブは、それぞれの異なる操作または一連の操作を識別します。
As implied by some of the bullets before Table 9, it is a goal of the 2.0 TALI specification to relax some of the error checking associated with the processing of received TALI messages.
表9の前にいくつかの弾丸で暗示されているように、これは2.0 TALI仕様の目標であり、受信したTALIメッセージの処理に関連するエラーチェックの一部を緩和します。
Version 1.0 of this specification was very strict in detailing the fields that were checked for each received message. As each received message was processed, the SYNC code, opcode and length field of the message was checked; if any of these fields were invalid an internal protocol violation was generated. The processing of the protocol violation caused the socket to go down. In addition to the 3 specific checks (sync, opcode, length), the overall philosophy of version 1.0 was to treat any received data that the receiver did not understand, or which the receiver deemed to contain incorrectly coded fields as protocol violations.
この仕様のバージョン1.0は、受信したメッセージごとにチェックされたフィールドを詳細に詳しく説明していました。受信した各メッセージが処理されたため、メッセージの同期コード、オペコード、および長さフィールドがチェックされました。これらのフィールドのいずれかが無効な場合、内部プロトコル違反が生成されました。プロトコル違反の処理により、ソケットがダウンしました。3つの特定のチェック（同期、オペコード、長さ）に加えて、バージョン1.0の全体的な哲学は、受信者が理解していなかった、または受信者がプロトコル違反として誤ってコーディングされたフィールドを含むとみなされるデータを扱うことでした。
Version 2.0 introduces the possibility of partial support for opcodes, partial support for primitives, and partial support for various fields (such as support for ANSI Pt Codes, but not ITU Pt Codes). Thus, the overall philosophy of how to treat received data that the receiver does not support needs to be relaxed from the strict treatment in version 1.0. Version 2.0 implementations should be more tolerant when they receive messages they do not support (or which they believe contain incorrectly coded fields). This tolerance should include NOT treating these receives as protocol violations.
バージョン2.0では、オペコードの部分的なサポート、プリミティブの部分的なサポート、およびさまざまな分野の部分的なサポート（ANSI PTコードのサポートなど）の可能性を紹介します。したがって、受信者がサポートしていない受信データを治療する方法の全体的な哲学は、バージョン1.0の厳格な治療からリラックスする必要があります。バージョン2.0の実装は、サポートしていないメッセージを受信する場合（または誤ってコーディングされたフィールドが含まれていると思われる）場合、より寛容にする必要があります。この寛容には、これらの受信をプロトコル違反として扱わないことを含める必要があります。
Version 2.0 implementations should perform the following level of strict/loose checks on the received messages:
バージョン2.0の実装は、受信したメッセージで次のレベルの厳格/ルーズチェックを実行する必要があります。
* Checks against the sync codes, opcodes and lengths for version 1.0 and version 2.0 opcodes should be performed (against Table 3 and Table 11). Invalid data in these fields should be treated as cause for protocol violations.
* バージョン1.0およびバージョン2.0オプコードの同期コード、オペコード、および長さに対してチェックする必要があります（表3および表11に対して）。これらのフィールドの無効なデータは、プロトコル違反の原因として扱う必要があります。
* Checks against the opcode field for messages with new 2.0 opcodes (mgmt/xsrv/spcl) should be performed to determine whether the message can be processed by the implementation. If an implementation chooses to NOT support a particular 2.0 opcode, the received message should be discarded, internal data (such as measurements, logs of messages, user notifications) could record the event, and the TALI state should NOT be affected.
* 新しい2.0オプコード（MGMT/XSRV/SPCL）を使用したメッセージのOpCodeフィールドに対してチェックする必要があります。メッセージを実装によって処理できるかどうかを判断する必要があります。実装が特定の2.0オペコードをサポートしないことを選択した場合、受信したメッセージを破棄する必要があります。内部データ（測定、メッセージのログ、ユーザー通知など）はイベントを記録でき、TALI Stateは影響を受けるべきではありません。
* Checks against the primitive field for messages with new 2.0 opcodes (mgmt/xsrv/spcl) should be performed to determine whether the message can be processed by the implementation. If an implementation does not understand a particular primitive, or has chosen NOT to implement the features for a particular primitive, the received message should be discarded, internal data (such as measurements, logs of messages, user notifications) could record the event, and the TALI state should NOT be affected.
* 新しい2.0オプコード（MGMT/XSRV/SPCL）を使用したメッセージのプリミティブフィールドに対するチェックを実行して、実装によってメッセージを処理できるかどうかを判断する必要があります。実装が特定のプリミティブを理解していない場合、または特定のプリミティブの機能を実装しないことを選択した場合、受信したメッセージを破棄する必要があります。内部データ（測定、メッセージのログ、ユーザー通知など）はイベントを記録でき、タリ州は影響を受けるべきではありません。
* Checks against other field types in messages with new 2.0 opcodes (such as checking the encoding of a Point Code field for a valid Pt Code type) should also be performed in a 'soft' manner. Errors found in individual fields should cause the received message to be discarded, internal data (such as measurements, logs of messages, user notifications) could record the event, and the TALI state should NOT be affected.
* 新しい2.0オペコードを使用したメッセージの他のフィールドタイプに対するチェック（有効なPTコードタイプのポイントコードフィールドのエンコードのチェックなど）も「ソフト」な方法で実行する必要があります。個々のフィールドで見つかったエラーは、受信したメッセージの破棄を引き起こす必要があり、内部データ（測定、メッセージのログ、ユーザー通知など）がイベントを記録する可能性があり、Tali Stateに影響を受けるべきではありません。
The goals behind introducing this gentler treatment of errors in received data are as follows:
受信したデータにこのエラーのこの穏やかな扱いを導入する背後にある目標は次のとおりです。
* To keep the socket up in order to perform the primary purpose of the connection (ie: to continue to transport SS7 data) in spite of improperly formatted/unsupported TALI messages related to other features/extensions/etc.
* 接続の主要な目的を実行するためにソケットを上げ続けるには（つまり、SS7データを輸送し続けるため）、他の機能/拡張機能/などに関連する/サポートされていないTALIメッセージを不適切にフォーマットしています。
* To allow applications to support and use some of the features for a particular TALI revision without requiring the application to implement all of the functionality for the TALI revision.
* アプリケーションがTALIリビジョンのすべての機能を実装するためにアプリケーションを要求することなく、アプリケーションが特定のTALIリビジョンのいくつかの機能をサポートおよび使用できるようにするため。
* To increase the extensibility of the protocol. Looser receive checks are preferred in order to be able to add new primitives and new primitive operations as they are defined.
* プロトコルの拡張性を高めるため。LOOSER受信チェックは、新しいプリミティブと新しいプリミティブ操作を定義するために追加できるようにするために推奨されます。
The basic message structure for all TALI messages is unchanged with the addition of new 2.0 opcodes. The base TALI header still consists of SYNC + OPCODE + LENGTH, as described in Table 2.
すべてのTALIメッセージの基本的なメッセージ構造は、新しい2.0オプコードの追加と変わらない。ベースタリヘッダーは、表2に記載されているように、同期オペコード長で構成されています。
The message structure for the new 2.0 opcodes was shown in Table 9. These messages define an extra required field, PRIMITIVE, that follows the LENGTH field of Table 2.
新しい2.0オプコードのメッセージ構造を表9に示しました。これらのメッセージは、表2の長さフィールドに従う必要のある特別なフィールドを定義します。
Table 4 in the version 1.0 specification provided implementation notes for all the 'types of fields' found in the 1.0 specification. Version 2.0 of TALI continues to use all of the types provided in Table 4, and also defines some new fields that are used in TALI messages that use the new 2.0 opcodes. The following table introduces the new field types that are introduced with version 2.0. The types in Table 10 are used in addition to the types in Table 4 to implement the 2.0 TALI protocol.
バージョン1.0仕様の表4は、1.0仕様で見つかったすべての「フィールドのタイプ」の実装ノートを提供しました。 TALIのバージョン2.0は、表4に記載されているすべてのタイプを引き続き使用しており、新しい2.0オプコードを使用するTALIメッセージで使用されるいくつかの新しいフィールドも定義しています。 次の表では、バージョン2.0で導入された新しいフィールドタイプを紹介します。 表10のタイプは、2.0 TALIプロトコルを実装するために表4のタイプに加えて使用されます。
+-----------+------------------------------------------------------+
|Field Type | Implementation Notes for that Type |
+------------------------------------------------------------------+
|SS7 Point | Used to transmit point code information for ANSI or |
|Code | ITU variants of point codes across the TALI interface|
| | * The point code structure is 4 bytes. Byte 3 is used|
| | to identify the TYPE of point code. The actual |
| | point code is then encoded in bytes 0-2 (w/byte 0 |
| | being the least significant byte and the first byte|
| | transmitted across the wire) |
| | * Byte 3: encoding of the type of point code (PC) |
| | 0 = an ANSI Full PC |
| | 1 = an ITU International Full PC w/ a 3/8/3 coding |
| | scheme for zone/area/identifier |
| | 2 = an ITU National Full PC w/ a raw 14 bit PC |
| | 3 = unused |
| | 4 = an ANSI Cluster PC |
| | * For ANSI Full PC w/byte 3=0. These point codes are|
| | 24 bit point codes as follows: |
| | Byte 2 = Network |
| | Byte 1 = Cluster |
| | Byte 0 = Member |
| | * For ITU International Full PC (3/8/3) w/byte 3=1. |
| | These point codes use 14 bits (stored in the 14 |
| | least significant bits in bytes 0&1). Byte 2 is |
| | unused. The 14 bits should be interpreted as 3 |
| | bits of zone, 8 bits of area and 3 bits of |
| | signaling point identifier. The 3 bits of |
| | signaling point identifier are the 3 least |
| | significant bits. |
| | * For ITU National Full PC w/byte 3=2. These point |
| | codes use 14 bits (stored in the 14 least |
| | significant bits in bytes 0&1). Byte 2 is unused. |
| | The 14 bits represent a single 14-bit quantity that|
| | constitutes the point code. |
| | * For unused w/byte 3=3. Bytes 0 through 2 are |
| | undefined. |
| | * For ANSI Cluster PC, w/byte 3=4. These point codes|
| | are 24 bit point codes as follows: |
| | Byte 2 = Network |
| | Byte 1 = Cluster |
| | Byte 0 = 0. This field is ignored and should be |
| | coded as 0...all members of the cluster are implied|
| | * Byte 0 is the first byte that is transmitted across|
| | the wire, followed by byte 1, byte 2, then byte 3. |
+------------------------------------------------------------------+
|Bit-Field | * Field containing an array of N bits, where N is a |
| | multiple of 8. Bit-Field types should be |
| | transmitted such that the byte containing bits 0 |
| | through 7 is transmitted across the wire first, |
| | followed by the byte containing bits 8 through 15, |
| | etc. |
| | * The software for each implementation should be |
| | written in a manner that accounts for the required |
| | byte order of transmission (ie: the Big Endian/ |
| | Little Endian characteristics of the processor need|
| | to be dealt with in the software). |
+------------------------------------------------------------------+
|Version |A TALI version label is a 12 byte ASCII text field. |
|Label |The label is of a format 'vers xxx.yyy', where xxx.yyy|
| |are used to identify the version such as 002.000. As |
| |with other ASCII text fields, the first byte of the |
| |text field (the 'v') should be the first byte |
| |transmitted out the wire. |
+------------------------------------------------------------------+
|Primitive |Messages that use the new TALI 2.0 opcodes all have a |
| |4 byte text ASCII field referred to as a Primitive. |
| |The Primitive acts as a modifier for the opcode. This |
| |allows a single opcode to be used to perform multiple |
| |actions. |
+------------------------------------------------------------------+
|Primitive |A Primitive can be used to specify either a specific |
|Operation |action or a set of actions. When the Primitive field |
| |is used to specify a set of actions, an operation |
| |field is used to pick a specific operation within that|
| |group of actions. Operation fields are 4 byte integers|
+------------------------------------------------------------------+
|Private |Various RFC documents have detailed a set of assigned |
|Enterprise |numbers (RFC 1700, Assigned Numbers) and defined data |
|Code |structures (RFC 1155, Structure and Identification of |
|(PEC) |Management Information for IP-based Internets) |
| |that are used on IP networks to provide network |
| |management information. |
| |Network Management Object Identifiers (OID) are used |
| |to recognize specific organizations, companies, |
| |protocols, and so on, in a manner that all vendors can|
| |agree on. |
| |An Object Identifier exists which uniquely describes |
| |each company that does business in the data/telecomm |
| |industry. That OID is referred to as an 'SMI Network |
| |Management Private Enterprise Code', which we are |
| |shortening to Private Enterprise Code of PEC in this |
| |document for simplicity. Each PEC is assumed to have |
| |a defined prefix of |
| |'iso.org.dod.internet.private.enterprise' or |
| |(1.3.6.1.4.1). |
| | |
| |The PEC for each company can be found via a file at: |
| |ftp://ftp.isi.edu/in-notes/iana/assignments/ |
| | enterprise-numbers |
| | |
| |To encode the PEC for a vendor in each implementation |
| |of TALI, a 2 byte integer field is used. The contents|
| |of the integer field should match the PEC code for |
| |that company in the file mentioned above. |
| | |
| |For example, Tekelec, which has a PEC of 323, will |
| |code this 2 byte field as '0x0143'. |
| | |
| |Like other integer fields, the PEC value is |
| |transmitted Least Significant Byte first across the |
| |ethernet wire. |
+------------------------------------------------------------------+
Table 10: Implementation for new field types introduced in TALI 2.0
表10：TALI 2.0で導入された新しいフィールドタイプの実装
The message structures for opcodes defined in version 1.0 of TALI are unchanged from the information presented earlier, with the exception of the 'moni' message. The 2.0 format for the 'moni' message was described earlier.
Taliのバージョン1.0で定義されているOpcodesのメッセージ構造は、「Moni」メッセージを除き、前述の情報から変更されません。「モニ」メッセージの2.0形式については、前述のことです。
Detailed message structures, and discussion of the capabilities, for each of the new 2.0 opcodes is provided in the following sections. Before discussing each opcode individually, Table 11 provides the minimum and maximum value of the LENGTH field that should be supported for each new opcode (as well as 'moni/mona'). Table 11 additionally shows the impact of ITU support that was added in 2.0. The routing label for ITU point codes only uses 4 octets instead of 7 octets as ANSI requires.
新しい2.0オプコードのそれぞれについて、詳細なメッセージ構造と機能の説明は、次のセクションに記載されています。各オペコードを個別に説明する前に、表11は、新しいオペコード（および「モニ/モナ」）に対してサポートする必要がある長さフィールドの最小値と最大値を示します。表11は、2.0に追加されたITUサポートの影響をさらに示しています。ITUポイントコードのルーティングラベルは、ANSIが必要とするように7オクテットの代わりに4オクテットのみを使用します。
+------------------------------------------------------------------+
| Opcode | Valid Length | Comments |
| | Field Values | |
+------------------------------------------------------------------+
| moni | 0-200 bytes | The overall length of the data portion |
| | | for 'moni' on TALI 2.0 implementations |
| | | is unchanged from version 1.0 of the |
| | | specification and remains at 200 bytes |
| | | to provide backwards compatibility. |
+------------------------------------------------------------------+
| mona | 0-200 bytes | The overall length of the data portion |
| | | for 'mona' on TALI 2.0 implementations |
| | | is unchanged from version 1.0 of the |
| | | specification and remains at 200 bytes |
| | | to provide backwards compatibility. |
+------------------------------------------------------------------+
| mgmt | 4-4096 bytes | The minimum length of 4 bytes is required|
| | | to provide space for the Primitive field.|
| | | The maximum length allows large TCP |
| | | packets to be supported if desired. |
+------------------------------------------------------------------+
| xsrv | 4-4096 bytes | The minimum length of 4 bytes is required|
| | | to provide space for the Primitive field.|
| | | The maximum length allows large TCP |
| | | packets to be supported if desired. |
+------------------------------------------------------------------+
| spcl | 4-4096 bytes | The minimum length of 4 bytes is required|
| | | to provide space for the Primitive field.|
| | | The maximum length allows large TCP |
| | | packets to be supported if desired. |
+------------------------------------------------------------------+
| sccp | 9-265 bytes | These are the valid sizes for the |
| | | SCCP-ONLY portions of SCCP UDT MSUs. |
+------------------------------------------------------------------+
| isot | 8-273 bytes | The length is the number of octets that |
| | | in the MTP3 and higher layer(s) of the |
| | | SS7 MSU. This length includes the SIO |
| | | byte and all bytes in the SIF (Service |
| | | Information Field) field. The MTP3 |
| | | routing label is part of the SIF field. |
+------------------------------------------------------------------+
| mtp3 | 8-280 bytes | The length is the number of octets that |
| | | in the MTP3 and higher layer(s) of the |
| | | SS7 MSU. This length includes the SIO |
| | | byte and all bytes in the SIF (Service |
| | | Information Field) field. The MTP3 |
| | | routing label is part of the SIF field. |
+------------------------------------------------------------------+
| saal | 8-280 bytes | The length is the number of octets that |
| | | in the MTP3 and higher layer(s) of the |
| | | SS7 MSU. This length includes the SIO |
| | | byte and all bytes in the SIF (Service |
| | | Information Field) field. The MTP3 |
| | | routing label is part of the SIF field. |
| | | Seven (7) octets of SSCOP trailer is |
| | | added to the message. The SSCOP trailer |
| | | bytes are also included in the length. |
+------------------------------------------------------------------+
Table 11: Valid Length Fields for Opcodes Affected by TALI 2.0
表11：タリ2.0の影響を受けるオプコードの有効な長さフィールド
The 'mgmt' opcode is intended to allow Management data, or data that will manage the operation of the device, to pass between the TALI endpoints over the socket connection. 'mgmt' messages can be received and processed in any of the TALI NEx-FEx states. Three PRIMITIVES are defined for use with this opcode:
「MGMT」オペコードは、管理データ、またはデバイスの動作を管理するデータを許可し、ソケット接続を介してTALIエンドポイント間を通過することを目的としています。「MGMT」メッセージは、Tali Nex-Fex州のいずれかで受信および処理できます。このオペコードで使用するために3つのプリミティブが定義されています。
* 'rkrp' - Routing Key Registration Primitive. This primitive allows the nodes to configure the SS7 traffic streams that they wish to receive over each socket. This 'routing key registration' is performed in-band, via TALI messages.
* 「RKRP」 - キー登録のプリミティブをルーティングします。このプリミティブにより、ノードは、各ソケットで受け取るSS7トラフィックストリームを構成できます。この「ルーティングキー登録」は、タリメッセージを介して帯域内で実行されます。
* 'mtpp' - MTP3 Primitives. This primitive allows SS7 MTP3 network management messages regarding the (un)availability and congestion states of SS7 devices to be passed to the IP devices SG.
* 'mtpp' -MTP3プリミティブ。このプリミティブにより、SS7デバイスの（UN）可用性および輻輳状態に関するSS7 MTP3ネットワーク管理メッセージをIPデバイスSGに渡すことができます。
* 'sorp' - Socket Options Registration Primitive. This primitive allows various socket options to be enabled/disabled by each TALI device.
* 「SORP」 - ソケットオプション登録プリミティブ。このプリミティブにより、各TALIデバイスによってさまざまなソケットオプションを有効/無効にすることができます。
As of version 2.0, the only defined primitives for the 'mgmt' opcode are 'rkrp', 'mtpp', and 'sorp'. In the future, more primitives can be added to this opcode to extend the Management capabilities of the SG or IP devices. The basic message structure for the 2.0 'mgmt' messages for all 3 of these primitives is as follows:
バージョン2.0の時点で、「MGMT」オペコードの唯一の定義されたプリミティブは、「RKRP」、「MTPP」、および「SORP」です。将来的には、このオプコードにさらにプリミティブを追加して、SGまたはIPデバイスの管理機能を拡張できます。これら3つのプリミティブすべての2.0 'mgmt'メッセージの基本的なメッセージ構造は次のとおりです。
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'mgmt' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length |
+------------------------------------------------------------------+
| 10..13 | Primitive | 'rkrp', 'mtpp' or 'sorp' Each of these |
| | | primitives specify a group of applicable |
| | | management operations. |
+------------------------------------------------------------------+
| 14..17 | Primitive | The operation field specifies the one |
| | Operation | operation within the group of operations |
| | | identified by the primitive. |
+------------------------------------------------------------------+
| 18.. | Message | The content of the message data area is |
| | Data | dependent on the combination of opcode/ |
| | | primitive/operation fields. Each of those|
| | | combinations could use a different message|
| | | data structure. |
+------------------------------------------------------------------+
Table 12: Message Structure for 'mgmt' opcode
表12： 'mgmt' opcodeのメッセージ構造
The 'rkrp' primitive allows IP nodes to modify the application routing key table in the SG by sending TALI messages to configure the SS7 traffic streams that they wish to receive over each socket. This 'routing key registration' is performed in-band, via TALI messages, as an alternative to using the SG user interface to configure the routing keys.
「RKRP」プリミティブにより、IPノードは、各ソケットで受信したいSS7トラフィックストリームを構成するためにTALIメッセージを送信することにより、SGのアプリケーションルーティングキーテーブルを変更できます。 この「ルーティングキー登録」は、SGユーザーインターフェイスを使用してルーティングキーを構成するための代替として、TALIメッセージを介してバンド内で実行されます。
Recall from earlier discussion in this document that the specification supports five (5) types of fully specified routing keys:
このドキュメントの以前の議論から、仕様が完全に指定された5種類のルーティングキーをサポートしていることを思い出してください。
* A key for SCCP traffic, where key = DPC-SI-SSN, where SI=3.
* key = dpc-si-ssn、si = 3では、sccpトラフィックのキー。
* A key for ISUP traffic, where key = DPC-SI-OPC-CIC Range, where SI=5. The CIC values for traditional ISUP are 14 bit quantities in ANSI networks and 12 bit quantities in ITU networks.
* isUpトラフィックのキー。キー= dpc-si-opc-cic範囲、si = 5。従来のISUPのCIC値は、ANSIネットワークでは14ビットの量であり、ITUネットワークでは12ビット量です。
* A key for TUP traffic, where key = DPC-SI-OPC-CIC Range, where SI=4. This key is only supported for ITU networks. The CIC values for TUP keys are 12 bit quantities in ITU networks.
* key = dpc-si-opc-cic範囲、si = 4のtupトラフィックのキー。このキーは、ITUネットワークでのみサポートされています。TUPキーのCIC値は、ITUネットワークで12ビットの量です。
* A key for QBICC traffic (an extension of ISUP which uses 32 bit CIC codes), where key = DPC-SI-OPC-CIC, where SI=13. The CIC values for QBICC keys are 32 bit quantities for ANSI and ITU networks.
* QBICCトラフィックのキー（32ビットCICコードを使用するISUPの拡張）。ここで、key = dpc-si-opc-cic、si = 13。QBICCキーのCIC値は、ANSIおよびITUネットワークの32ビット量です。
* A key for OTHER-MTP3-SI (non-SCCP, non-ISUP, non-QBICC for ANSI and non-SCCP, non-ISUP, non-QBICC, non-TUP for ITU) traffic, where key = DPC-SI
* 他のMTP3-SIのキー（非SCCP、非ISUP、ANSIおよび非SCCPの非QBICC、非ISUP、非QBICC、ITUの非tup）トラフィック、key = dpc-si
Each of these keys is fully specified key where the exact content of the MSU to be routed must match the data in the routing key.
これらの各キーは、ルーティングされるMSUの正確なコンテンツがルーティングキーのデータと一致する必要がある場合、完全に指定されたキーです。
Extensions to the routing keys have been added that will support 'partial match' or 'default' routing keys. The purpose of these extensions is to improve the handling of MSU traffic when no fully specified routing key exists that matches the MSU. Partial match and default routing keys are used when the SG can not find a fully specified routing key that can be used to route an MSU. Partial match keys can be used to provide closest-match routing such as 'ignore the CIC' for ISUP/QBICC/TUP traffic, or 'ignore the SSN' for SCCP traffic. Default keys are used when no full or partial routing key has been found as a last resort destination to route the MSU to.
「部分的な一致」または「デフォルト」ルーティングキーをサポートするルーティングキーへの拡張が追加されています。これらの拡張機能の目的は、MSUに一致する完全に指定されたルーティングキーが存在しない場合、MSUトラフィックの取り扱いを改善することです。SGがMSUをルーティングするために使用できる完全に指定されたルーティングキーを見つけることができない場合、部分一致およびデフォルトのルーティングキーが使用されます。部分マッチキーを使用して、ISUP/QBICC/TUPトラフィックの「CICを無視する」、SCCPトラフィックの「SSNを無視する」などの最も近い試合ルーティングを提供できます。完全なルーティングキーまたは部分的なルーティングキーが、MSUをルーティングする最後のリゾートの目的地として見つかっていない場合、デフォルトキーが使用されます。
The types of partial and default keys defined by the protocol are discussed in the following table. The 4th column in the table indicates the data structure that is used in the TALI rkrp message to perform operations on each partial/default key type. Note: The order of the keys in the table (from top to bottom) matches the hierarchical search order that an SG will use to attempt to find a routing key to use for an MSU. The partial and default keys are only used after attempting to find a fully specified key that matches the MSU.
プロトコルによって定義された部分的およびデフォルトキーのタイプについては、次の表で説明します。テーブルの4番目の列は、各部分/デフォルトのキータイプで操作を実行するためにTali RKRPメッセージで使用されるデータ構造を示しています。注：テーブル内のキーの順序（上から下まで）は、SGがMSUに使用するルーティングキーを見つけるために使用する階層検索順序と一致します。部分的なキーとデフォルトのキーは、MSUに一致する完全に指定されたキーを見つけようとした後にのみ使用されます。
+--------+------------+--------------------------------+-----------+
|Key | Key | Comments | Cross |
|Type | Attributes | | Reference |
+--------+------------+--------------------------------+-----------+
|Partial | DPC-SI-OPC |Used as backup routes for CIC | 4.5.1.1.2 |
| | |based traffic (but ignoring the | |
| | |CIC field). | |
+--------+------------+--------------------------------+-----------+
|Partial | DPC-SI |Used as backup routes for CIC | 4.5.1.1.4 |
| | |based or SCCP traffic (but | |
| | |ignoring the OPC-CIC or SSN). | |
| | |Routes traffic based solely on | |
| | |DPC and SI of the MSU. | |
+--------+------------+--------------------------------+-----------+
|Partial | DPC |Used as a backup route for any | 4.5.1.1.4 |
| | |MSU type. Routes traffic based | |
| | |solely on the DPC field. | |
+--------+------------+--------------------------------+-----------+
|Partial | SI |Used as a backup route for any | 4.5.1.1.4 |
| | |MSU type. Routes traffic based | |
| | |solely on the SI field. | |
+--------+------------+--------------------------------+-----------+
|Default | - |If no other type of routing key | 4.5.1.1.5 |
| | |for an MSU can be found, use | |
| | |this one. | |
+--------+------------+--------------------------------+-----------+
Table 13: Partial and Default Routing Keys (in hierarchical order)
表13：部分的およびデフォルトのルーティングキー（階層順）
The specific capability requested in each 'rkrp' message is indicated via an 'RKRP Operation' field. These capabilities include:
各「RKRP」メッセージで要求される特定の機能は、「RKRP操作」フィールドを介して示されています。これらの機能には次のものが含まれます。
* ENTER: The ENTER operation creates an association between a specific socket and a specific application routing key. The socket of the association is always the socket that the 'rkrp' was received on. The application routing key identifies an SS7 traffic stream that should be carried over that socket. Multiple sockets can be associated with the same application routing key, if so, they all receive traffic in a 'load sharing' mode. An override field can be used to remove any other socket associations for a particular routing key and add a single socket association. The ENTER operation is applicable for fully specified SCCP keys, CIC based keys (ISUP, Q.BICC, and TUP), OTHER-MTP3-SI keys, and all types of partial keys and to the default routing key.
* ENTER：ENTER操作は、特定のソケットと特定のアプリケーションルーティングキーとの間に関連性を作成します。協会のソケットは、常に「RKRP」が受信されたソケットです。アプリケーションルーティングキーは、そのソケットに掲載する必要があるSS7トラフィックストリームを識別します。複数のソケットを同じアプリケーションルーティングキーに関連付けることができます。もしそうなら、それらはすべて「負荷共有」モードでトラフィックを受け取ります。オーバーライドフィールドを使用して、特定のルーティングキーの他のソケット関連を削除し、単一のソケット関連を追加できます。ENTER操作は、完全に指定されたSCCPキー、CICベースのキー（ISUP、Q.BICC、およびTUP）、他のMTP3-SIキー、およびすべてのタイプの部分キー、およびデフォルトのルーティングキーに適用されます。
* DELETE: The DELETE operation deletes an association between a specific socket and a specific application routing key. The socket of the association is always the socket that the 'rkrp' was received on. Other socket associations for the same application routing key are NOT affected by the deletion. When the last socket association for a routing key is deleted, the entire routing key entry is removed from the database. The DELETE operation operation is applicable for fully specified SCCP keys, CIC based keys (ISUP, Q.BICC, and TUP), OTHER-MTP3-SI keys, and all types of partial keys and to the default routing key.
* 削除：削除操作は、特定のソケットと特定のアプリケーションルーティングキーとの間の関連付けを削除します。 協会のソケットは、常に「RKRP」が受信されたソケットです。 同じアプリケーションルーティングキーの他のソケット関連は、削除の影響を受けません。 ルーティングキーの最後のソケット関連が削除されると、ルーティングキーエントリ全体がデータベースから削除されます。 削除操作は、完全に指定されたSCCPキー、CICベースのキー（ISUP、Q.BICC、およびTUP）、他のMTP3-SIキー、およびすべてのタイプの部分キーおよびデフォルトルーティングキーに適用されます。
* SPLIT: The SPLIT operation is used to convert a single application routing key into 2 application routing keys that together cover the same SS7 traffic stream as the original key. Immediately after a split is performed, both of the resulting entries retain the same socket associations as the original routing key. When the split is completed, the socket associations can be modified for each of the 2 resulting ranges independent of the other range. The split operation is only applicable to fully specified CIC based keys (ISUP, QBICC, and TUP). Each fully specified CIC based key is uniquely identified by the combination of DPC/SI/OPC/CIC range. The CIC range is a continuous set of numbers from CICS(start) to CICE(end); the CIC range in the application routing key corresponds to the CIC value in a CIC based MSU.
* スプリット：分割操作は、単一のアプリケーションルーティングキーを2つのアプリケーションルーティングキーに変換するために使用されます。分割が実行された直後、結果の両方のエントリは、元のルーティングキーと同じソケット関連を保持します。分割が完了すると、他の範囲とは無関係に、結果の2つの範囲のそれぞれについてソケット関連を変更できます。分割操作は、完全に指定されたCICベースのキー（ISUP、QBICC、およびTUP）にのみ適用されます。完全に指定された各CICベースのキーは、DPC/SI/OPC/CIC範囲の組み合わせによって一意に識別されます。CIC範囲は、CICS（Start）からCICE（END）までの数値の連続セットです。アプリケーションルーティングキーのCIC範囲は、CICベースのMSUのCIC値に対応しています。
* RESIZE: The RESIZE operation is used to modify the CIC range in for a single application routing key. The resize operation is only applicable to fully specified CIC based routing keys. The resize operation replaces the CICS/CICE values for a routing key with a new CIC range (NCICS/NCICE). A wide variety of NCICS/NCICE ranges can be supported based on the existing CICS/CICE; just about the only restriction is that the new range can not already exist in the database and can not overlap any other entry in the database. The socket associations for the routing key are NOT affected by the change in CICS/CICE. The SPLIT operation is applicable only to fully specified CIC based keys (ISUP, Q.BICC, and TUP).
* サイズ：サイズ操作は、単一のアプリケーションルーティングキーのCIC範囲を変更するために使用されます。サイズ操作は、完全に指定されたCICベースのルーティングキーにのみ適用されます。サイズ変更操作は、ルーティングキーのCICS/CICE値を新しいCIC範囲（NCICS/NCICE）に置き換えます。既存のCICS/CICEに基づいて、さまざまなNCICS/NCICE範囲をサポートできます。ほぼ唯一の制限は、新しい範囲がデータベースにまだ存在せず、データベース内の他のエントリを重複させることができないことです。ルーティングキーのソケット関連は、CICS/CICEの変化の影響を受けません。分割操作は、完全に指定されたCICベースのキー（ISUP、Q.BICC、およびTUP）にのみ適用されます。
The list of RKRP Operations (and their encodings) that are supported for TALI version 2.0 is as follows:
TALIバージョン2.0でサポートされているRKRP操作（およびそのエンコーディング）のリストは次のとおりです。
0x0001 - ENTER ISUP KEY 0x0002 - DELETE ISUP KEY 0x0003 - SPLIT ISUP KEY 0x0004 - RESIZE ISUP KEY 0x0005 - ENTER Q.BICC ISUP KEY 0x0006 - DELETE Q.BICC ISUP KEY 0x0007 - SPLIT Q.BICC ISUP KEY 0x0008 - RESIZE Q.BICC ISUP KEY 0x0009 - ENTER SCCP KEY 0x000A - DELETE SCCP KEY 0x000B - ENTER OTHER-MTP3-SI KEY 0x000C - DELETE OTHER-MTP3-SI KEY 0x000D - ENTER TUP KEY (ITU only) 0x000E - DELETE TUP KEY (ITU only) 0x000F - SPLIT TUP KEY (ITU only) 0x0010 - RESIZE TUP KEY (ITU only) 0x0011 - ENTER DPC-SI-OPC PARTIAL KEY 0x0012 - DELETE DPC-SI-OPC PARTIAL KEY 0x0013 - ENTER DPC-SI PARTIAL KEY 0x0014 - DELETE DPC-SI PARTIAL KEY 0x0015 - ENTER DPC PARTIAL KEY 0x0016 - DELETE DPC PARTIAL KEY 0x0017 - ENTER SI PARTIAL KEY 0x0018 - DELETE SI PARTIAL KEY 0x0019 - ENTER DEFAULT 0x001A - DELETE DEFAULT KEY 0x001B - MULTIPLE REGISTRATION SUPPORT
0x0001-ISUPキー0x0002を入力 - 削除ISUPキー0x0003-分割ISUPキー0x0004 -ResizeISUPキー0x0005 -Enter Q.BICCISUP ISUP ISUPキー0x0006 -DELETE Q.BICC ISUPキー0x0007-分割Q.BICC ISUPキー0x0008 -Resize Q.BICCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCYISUPキー0x0009 -SCCPキー0x000Aを入力 - SCCPキー0x000Bを削除 - その他-MTP3 -SIキー0x000Cを入力 - 他のMTP3 -SIキー0x000Dを削除-TUPキー（ITUのみ）0x000E -DELETE TUPキー（ITUのみ）0x000F-分割tupキー（ITUのみ）0x0010-変更するtupキー（ITUのみ）0x0011 -dpc-si-opc partial key 0x0012を入力します。部分キー0x0015 -DPC Partial Key 0x0016を入力 - DPC Partial Key 0x0017を削除 - Si Partial Key 0x0018を入力 - Delete Si Partial Key 0x0019-デフォルト0x001aを入力 - デフォルトキー0x001bを削除します - 複数の登録サポート
The message data area of the 'rkrp' messages will differ based on which RKRP Operation is specified. Several different structures are used, the correct structure can be identified by the RKRP Operation field.
「RKRP」メッセージのメッセージデータ領域は、どのRKRP操作が指定されているかによって異なります。いくつかの異なる構造が使用され、RKRP操作フィールドによって正しい構造を識別できます。
In order to simplify the implementation, each of these structures will define a structure that will support all of the operations required for the key type. This means that based on the rkrp operation, some of the fields will be required, and some of the fields will not be applicable for each RKRP message. Unused fields should be initialized to 0 by the sender and ignored by the receiver.
実装を簡素化するために、これらの各構造は、キータイプに必要なすべての操作をサポートする構造を定義します。これは、RKRP操作に基づいて、一部のフィールドが必要であり、一部のフィールドは各RKRPメッセージに適用できないことを意味します。未使用のフィールドは、送信者によって0に初期化され、受信機によって無視される必要があります。
In the following subsections several different data structures to be used for various RKRP operations are presented. It should be noted that each of these data structures has the following fields in common. The data structure below should begin at byte 14 of the TALI message as shown in Table 12.
以下のサブセクションでは、さまざまなRKRP操作に使用されるいくつかの異なるデータ構造が提示されています。これらのデータ構造のそれぞれには、共通のフィールドがあることに注意する必要があります。以下のデータ構造は、表12に示すように、TALIメッセージのBYTE 14で開始する必要があります。
+------------------------------------------------------------------+
| Octets | Field Name | Description | Field Type |
+------------------------------------------------------------------+
| 2 | RKRP | Identifies which 'rkrp' | Integer |
| | Operation | operation is desired. | |
+------------------------------------------------------------------+
| 2 | Request/ | Identifies whether the 'rkrp'| Integer |
| | Reply | message is a request (from an| |
| | | IP node to SG) for some type | |
| | | of 'rkrp' action, or a reply | |
| | | to a previous request (from | |
| | | the SG back to the IP node). | |
| | | This integer field uses the | |
| | | following encodings: | |
| | | 0x0000=Request | |
| | | 0x0001=Reply. See Success/ | |
| | | Failure code for more info. | |
+------------------------------------------------------------------+
| 2 | Success/ | Provides a success/failure | Integer |
| | Failure | indication as part of the | |
| | Code | reply back to the IP node | |
| | | for each processed request. | |
| | | This field is only used when | |
| | | the Request/Reply field is | |
| | | 0x0001. This field uses the | |
| | | encodings from in section 5. | |
+------------------------------------------------------------------+
Table 14: Common Fields in ALL 'rkrp' Data Structures
表14：すべての「RKRP」データ構造の一般的なフィールド
The primary purpose of requiring the data structures for all RKRP operations to begin with these same fields, is to provide a means for a receiver to reply to unknown RKRP messages in a consistent manner. When an implementation receives an RKRP request message it does not understand, it should turn the request into a reply and use the success/failure code to indicate that the operation is not supported (with an RKRP Reply Code of Unsupported rkrp Operation).
すべてのRKRP操作がこれらの同じフィールドから開始するためにデータ構造を要求する主な目的は、レシーバーが不明なRKRPメッセージに一貫した方法で返信する手段を提供することです。実装がRKRPリクエストメッセージを受信した場合、それは理解できません。リクエストを返信に変え、成功/失敗コードを使用して操作がサポートされていないことを示します（サポートされていないRKRP操作のRKRP返信コードを使用）。
It is a requirement that these common fields continue to be used as new RKRP operations are added to this specification. This will ensure that the capability described in the previous paragraph will always exist.
これらの一般的なフィールドは、新しいRKRP操作がこの仕様に追加されるため、引き続き使用され続けることが要件です。これにより、前の段落で説明されている機能が常に存在することが保証されます。
The data structure used for 'rkrp' messages related to MSUs which are CIC based (ISUP, Q.BICC ISUP, and TUP (ITU only)) is as presented in the next table. The data structure below should begin at byte 14 of the TALI message as shown in Table 12.
CICベースのMSUSに関連する「RKRP」メッセージ（ISUP、Q.BICC ISUP、およびTUP（ITUのみ））に使用されるデータ構造は、次の表に示されているとおりです。以下のデータ構造は、表12に示すように、TALIメッセージのBYTE 14で開始する必要があります。
Note 1: The number of bits used in each CIC field will vary based on the SI and network type.
注1：各CICフィールドで使用されるビット数は、SIとネットワークタイプに基づいて異なります。
* ISUP operations (0x0001 - 0x0004) are assumed to use 14 bit CIC values from the corresponding fields in the structure when DPC/OPC indicate an ANSI network (12 bits used in ITU networks). Only the 14(12) least significant bits of the 32 bit CIC field will be used.
* ISUP操作（0x0001-0x0004）は、DPC/OPCがANSIネットワーク（ITUネットワークで使用される12ビット）を示す場合、構造内の対応するフィールドから14ビットCIC値を使用すると想定されています。32ビットCICフィールドの14（12）の最小ビットのみが使用されます。
* Q.BICC ISUP operations (0x0005 - 0x0008) are assumed to use 32 bit CIC values from the corresponding fields in the structure.
* Q.BICC ISUP操作（0x0005-0x0008）は、構造内の対応するフィールドから32ビットCIC値を使用すると想定されています。
* TUP operations (0x000d - 0x0010) are assumed to use 12 bit CIC values from the corresponding fields in the structure when DPC/OPC indicate an ITU network. Only the 12 least significant bits of the 32 bit CIC field will be used. TUP operations are not supported for ANSI networks.
* TUP操作（0x000D -0x0010）は、DPC/OPCがITUネットワークを示している場合、構造内の対応するフィールドから12ビットCIC値を使用すると想定されています。32ビットCICフィールドの12個の最小ビットのみが使用されます。TUP操作は、ANSIネットワークではサポートされていません。
Note 2: This same structure should be used to specify the partial key = DPC-SI-OPC(ignoreCIC). When specifying a DPC-SI-OPC partial key, the CIC fields in this structure should be set to 0 by the sender.
注2：この同じ構造を使用して、部分キー= DPC-SI-OPC（Ingrecic）を指定する必要があります。 DPC-SI-OPC部分キーを指定する場合、この構造のCICフィールドは、送信者によって0に設定する必要があります。
+------------------------------------------------------------------+
| Octets | Field Name | Description | Field Type |
+------------------------------------------------------------------+
| 2 | RKRP | Identifies which 'rkrp' | Integer |
| | Operation | operation is desired. | |
+------------------------------------------------------------------+
| 2 | Request/ | Identifies whether the 'rkrp'| Integer |
| | Reply | message is a request (from an| |
| | | IP node to SG) for some type | |
| | | of 'rkrp' action, or a reply | |
| | | to a previous request (from | |
| | | the SG back to the IP node). | |
| | | This integer field uses the | |
| | | following encodings: | |
| | | 0x0000=Request | |
| | | 0x0001=Reply. See Success/ | |
| | | Failure code for more info. | |
+------------------------------------------------------------------+
| 2 | Success/ | Provides a success/failure | Integer |
| | Failure | indication as part of the | |
| | Code | reply back to the IP node | |
| | | for each processed request. | |
| | | This field is only used when | |
| | | the Request/Reply field is | |
| | | 0x0001. This field uses the | |
| | | encodings listed in section | |
| | | 5. | |
+------------------------------------------------------------------+
| 2 | RKRP flags | This is a 2 byte bit-field | Bit-field |
| | | that provides 16 possible | |
| | | flags that can control | |
| | | various aspects of the | |
| | | operation. | |
| | | Bit 0 - An Override bit is | |
| | | used on the ENTER operation | |
| | | to control how the socket | |
| | | associations for a routing | |
| | | key should be manipulated. | |
| | | This flag determines if the | |
| | | ENTER is to add the given | |
| | | socket association in a | |
| | | 'load-sharing' mode or if | |
| | | the new association should | |
| | | replace (Override) all | |
| | | existing associations. This | |
| | | flag is only examined on | |
| | | ENTER operations. | |
| | | Bit 0=0, Load Sharing Mode | |
| | | Bit 0=1, Override Mode | |
| | | Bits 1-15, currently | |
| | | undefined | |
+------------------------------------------------------------------+
| 1 | SI | Service Indicator. The SI | Integer |
| | | field in an SS7 MSU | |
| | | identifies the type of | |
| | | traffic being carried by the | |
| | | MSU (0=SNM, 3=SCCP, 5=ISUP, | |
| | | etc). Each application | |
| | | routing key must specify a | |
| | | specific SI value that it | |
| | | relates to. | |
| | | SI should be 5 for ISUP keys.| |
| | | SI should be 13 for Q.BICC | |
| | | ISUP keys. | |
| | | SI should be 4 for TUP keys. | |
+------------------------------------------------------------------+
| 4 | DPC | Destination Point Code. Each| SS7 Point |
| | | SS7 MSU contains a DPC that | Code |
| | | identifies the destination | |
| | | for the MSU. Each | |
| | | application routing key must | |
| | | specify a specific DPC value | |
| | | that it relates to. | |
+------------------------------------------------------------------+
| 4 | OPC | Origination Point Code. Each| SS7 Point |
| | | SS7 MSU contains a OPC that | Code |
| | | identifies the source of the | |
| | | MSU. ISUP routing keys must | |
| | | each specify a single OPC | |
| | | that the application routing | |
| | | key relates to. | |
+------------------------------------------------------------------+
| 4 | CICS | Circuit Identification Code | Integer |
| | | Start. Each SS7 ISUP MSU | |
| | | contains a CIC code. Each | |
| | | ISUP/QBICC/TUP routing key | |
| | | identifies a range of CIC | |
| | | values that are applicable | |
| | | for the routing key. The | |
| | | CICS value is the low end of | |
| | | the CIC range. | |
+------------------------------------------------------------------+
| 4 | CICE | Circuit Identification Code | Integer |
| | | End. Each SS7 ISUP MSU | |
| | | contains a CIC code. Each | |
| | | ISUP/QBICC/TUP routing key | |
| | | identifies a range of CIC | |
| | | values that are applicable | |
| | | for the routing key. The | |
| | | CICE value is the high end | |
| | | of the CIC range. | |
+------------------------------------------------------------------+
| 4 | SPLIT CIC | The SPLIT field is used on | Integer |
| | | the SPLIT operation to | |
| | | specify where in the existing| |
| | | CIC range (given by CICS/ | |
| | | CICE) an existing routing key| |
| | | should be split into 2 | |
| | | routing keys. To be valid, | |
| | | the following relationship | |
| | | must be true before the SPLIT| |
| | | is performed: | |
| | | CICS < SPLIT <= CICE. | |
| | | After the SPLIT is performed,| |
| | | the 2 routing keys are as | |
| | | follows: | |
| | | CICS to SPLIT-1 | |
| | | SPLIT to CICE | |
+------------------------------------------------------------------+
| 4 | NCICS | The NCICS and NCICE fields | Integer |
| | | are used on the RESIZE | |
| | | operation to specify how the | |
| | | CIC range for existing | |
| | | routing key should be | |
| | | modified. NCICS specifies | |
| | | the new value that should | |
| | | replace the existing CICS | |
| | | value in the routing key. | |
+------------------------------------------------------------------+
| 4 | NCICE | The NCICS and NCICE fields | Integer |
| | | are used on the RESIZE | |
| | | operation to specify how the | |
| | | CIC range for existing | |
| | | routing key should be | |
| | | modified. NCICE specifies | |
| | | the new value that should | |
| | | replace the existing CICE | |
| | | value in the routing key. | |
+------------------------------------------------------------------+
Table 15: Message Data Structure CIC based Routing Key Operations
表15：メッセージデータ構造CICベースのルーティングキー操作
The following table indicates the Required (R), or Not Applicable (NA) status for each field of the message data structure in Table 15 based on the RKRP Operation field. As mentioned previously, unused fields (those marked NA) should be initialized to 0 by the sender and ignored by the receiver.
次の表は、RKRP操作フィールドに基づいて、表15のメッセージデータ構造の各フィールドに必要な（R）、または適用されない（NA）ステータスを示しています。前述のように、未使用のフィールド（マークされたNA）は、送信者によって0に初期化され、受信機によって無視される必要があります。
+------------------------------------------------------------------+
| Operation | ENTER | DELETE | SPLIT | RESIZE | ENTER/DELETE |
| | (ISUP,| (ISUP, | (ISUP,| (ISUP, | PARTIAL DPC |
| | QBICC,| QBICC, | QBICC,| QBICC, | SI OPC KEY |
| Field | TUP) | TUP) | TUP) | TUP) | |
+------------------------------------------------------------------+
| Request/Reply | R | R | R | R | R |
+------------------------------------------------------------------+
| Success/Failure | R | R | R | R | R |
+------------------------------------------------------------------+
| RKRP Flags | R | R | R | R | R |
+------------------------------------------------------------------+
| SI | R | R | R | R | R |
+------------------------------------------------------------------+
| DPC | R | R | R | R | R |
+------------------------------------------------------------------+
| OPC | R | R | R | R | R |
+------------------------------------------------------------------+
| CICS | R | R | R | R | NA |
+------------------------------------------------------------------+
| CICE | R | R | R | R | NA |
+------------------------------------------------------------------+
| SPLIT CIC | NA | NA | R | NA | NA |
+------------------------------------------------------------------+
| NCICS | NA | NA | NA | R | NA |
+------------------------------------------------------------------+
| NCICE | NA | NA | NA | R | NA |
+------------------------------------------------------------------+
Table 16: Required/Not Applicable Fields for CIC based Routing Keys
表16：CICベースのルーティングキーに必須/該当しないフィールド
The data structure used for 'rkrp' messages related to SCCP routing keys is presented in the next table. The data structure below should begin at byte 14 of the TALI message as shown in Table 12.
SCCPルーティングキーに関連する「RKRP」メッセージに使用されるデータ構造は、次の表に表示されます。以下のデータ構造は、表12に示すように、TALIメッセージのBYTE 14で開始する必要があります。
+------------------------------------------------------------------+
| Octets | Field Name | Description | Field Type |
+------------------------------------------------------------------+
| 2 | RKRP | Identifies which 'rkrp' | Integer |
| | Operation | operation is desired. | |
+------------------------------------------------------------------+
| 2 | Request/ | Identifies whether the 'rkrp'| Integer |
| | Reply | message is a request (from an| |
| | | IP node to SG) for some type | |
| | | of 'rkrp' action, or a reply | |
| | | to a previous request (from | |
| | | the SG back to the IP node). | |
| | | This integer field uses the | |
| | | following encodings: | |
| | | 0x0000=Request | |
| | | 0x0001=Reply. See Success/ | |
| | | Failure code for more info. | |
+------------------------------------------------------------------+
| 2 | Success/ | Provides a success/failure | Integer |
| | Failure | indication as part of the | |
| | Code | reply back to the IP node | |
| | | for each processed request. | |
| | | This field is only used when | |
| | | the Request/Reply field is | |
| | | 0x0001. This field uses the | |
| | | encodings listed in section | |
| | | 5. | |
+------------------------------------------------------------------+
| 2 | RKRP flags | This is a 2 byte bit-field | Bit-field |
| | | that provides 16 possible | |
| | | flags that can control | |
| | | various aspects of the | |
| | | operation. | |
| | | Bit 0 - An Override bit is | |
| | | used on the ENTER operation | |
| | | to control how the socket | |
| | | associations for a routing | |
| | | key should be manipulated. | |
| | | This flag determines if the | |
| | | ENTER is to add the given | |
| | | socket association in a | |
| | | 'load-sharing' mode or if | |
| | | the new association should | |
| | | replace (Override) all | |
| | | existing associations. This | |
| | | flag is only examined on | |
| | | ENTER operations. | |
| | | Bit 0=0, Load Sharing Mode | |
| | | Bit 0=1, Override Mode | |
| | | Bits 1-15, currently | |
| | | undefined | |
+------------------------------------------------------------------+
| 1 | SI | Service Indicator. The SI | Integer |
| | | field in an SS7 MSU | |
| | | identifies the type of | |
| | | traffic being carried by the | |
| | | MSU (0=SNM, 3=SCCP, 5=ISUP, | |
| | | etc). Each application | |
| | | routing key must specify a | |
| | | specific SI value that it | |
| | | relates to. | |
| | | SI should be 3 for SCCP keys.| |
+------------------------------------------------------------------+
| 4 | DPC | Destination Point Code. Each| SS7 Point |
| | | SS7 MSU contains a DPC that | Code |
| | | identifies the destination | |
| | | for the MSU. Each | |
| | | application routing key must | |
| | | specify a specific DPC value | |
| | | that it relates to. | |
+------------------------------------------------------------------+
| 1 | SSN | SubSystem Number. Each SCCP | Integer |
| | | MSU contains a subsystem | |
| | | number that identifies the | |
| | | SCCP subsystem that should | |
| | | process the MSU. SCCP | |
| | | routing keys must each | |
| | | specify a single SSN that | |
| | | the application routing key | |
| | | relates to. | |
+------------------------------------------------------------------+
Table 17: Message Data Structure SCCP Routing Key Operations
表17：メッセージデータ構造SCCPルーティングキー操作
The following table indicates the Required (R), or Not Applicable (NA) status for each field of the message data structure in Table 17 based on the RKRP Operation field. As mentioned previously, unused fields (those marked NA) should be initialized to 0 by the sender and ignored by the receiver.
次の表は、RKRP操作フィールドに基づいて、メッセージデータ構造の各フィールドに必要な（R）、または適用されない（NA）ステータスを示しています。前述のように、未使用のフィールド（マークされたNA）は、送信者によって0に初期化され、受信機によって無視される必要があります。
+--------------------------------------------+
| Operation | ENTER SCCP | DELETE SCCP |
| Field | | |
+--------------------------------------------+
| Request/Reply | R | R |
+--------------------------------------------+
| Success/Failure | R | R |
+--------------------------------------------+
| RKRP Flags | R | R |
+--------------------------------------------+
| SI | R | R |
+--------------------------------------------+
| DPC | R | R |
+--------------------------------------------+
| SSN | R | R |
+--------------------------------------------+
Table 18: Required/Not Applicable Fields for SCCP Routing Keys
表18：SCCPルーティングキーに必須/適用されないフィールド
The data structure used for 'rkrp' messages related to DPC-SI based (either full keys for non-sccp, non-cic based traffic, or partial keys for CIC based or SCCP), DPC based (partial key), and SI based (partial key) operations is as presented in the next table. The data structure below should begin at byte 14 of the TALI message as shown in Table 12.
DPC-SIベースに関連する「RKRP」メッセージに使用されるデータ構造（非SCCPの完全なキー、非CICベースのトラフィック、またはCICベースまたはSCCPの部分キー）、DPCベース（部分キー）、およびSIベース（部分キー）操作は、次の表に示されているとおりです。以下のデータ構造は、表12に示すように、TALIメッセージのBYTE 14で開始する必要があります。
+------------------------------------------------------------------+
| Octets | Field Name | Description | Field Type |
+------------------------------------------------------------------+
| 2 | RKRP | Identifies which 'rkrp' | Integer |
| | Operation | operation is desired. | |
+------------------------------------------------------------------+
| 2 | Request/ | Identifies whether the 'rkrp'| Integer |
| | Reply | message is a request (from an| |
| | | IP node to SG) for some type | |
| | | of 'rkrp' action, or a reply | |
| | | to a previous request (from | |
| | | the SG back to the IP node). | |
| | | This integer field uses the | |
| | | following encodings: | |
| | | 0x0000=Request | |
| | | 0x0001=Reply. See Success/ | |
| | | Failure code for more info. | |
+------------------------------------------------------------------+
| 2 | Success/ | Provides a success/failure | Integer |
| | Failure | indication as part of the | |
| | Code | reply back to the IP node | |
| | | for each processed request. | |
| | | This field is only used when | |
| | | the Request/Reply field is | |
| | | 0x0001. This field uses the | |
| | | encodings from section 5. | |
+------------------------------------------------------------------+
| 2 | RKRP flags | This is a 2 byte bit-field | Bit-field |
| | | that provides 16 possible | |
| | | flags that can control | |
| | | various aspects of the | |
| | | operation. | |
| | | Bit 0 - An Override bit is | |
| | | used on the ENTER operation | |
| | | to control how the socket | |
| | | associations for a routing | |
| | | key should be manipulated. | |
| | | This flag determines if the | |
| | | ENTER is to add the given | |
| | | socket association in a | |
| | | 'load-sharing' mode or if | |
| | | the new association should | |
| | | replace (Override) all | |
| | | existing associations. This | |
| | | flag is only examined on | |
| | | ENTER operations. | |
| | | Bit 0=0, Load Sharing Mode | |
| | | Bit 0=1, Override Mode | |
| | | Bits 1-15, currently | |
| | | undefined | |
+------------------------------------------------------------------+
| 1 | SI | Service Indicator. The SI | Integer |
| | | field in an SS7 MSU | |
| | | identifies the type of | |
| | | traffic being carried by the | |
| | | MSU (0=SNM, 3=SCCP, 5=ISUP, | |
| | | etc). Each application | |
| | | routing key must specify a | |
| | | specific SI value that it | |
| | | relates to. | |
+------------------------------------------------------------------+
| 4 | DPC | Destination Point Code. Each| SS7 Point |
| | | SS7 MSU contains a DPC that | Code |
| | | identifies the destination | |
| | | for the MSU. Each | |
| | | application routing key must | |
| | | specify a specific DPC value | |
| | | that it relates to. | |
+------------------------------------------------------------------+
Table 19: Message Data Structure DPC/SI, DPC and SI based Routing
Key Operations
The following table indicates the Required (R), or Not Applicable (NA) status for each field of the message data structure in Table 19 based on the RKRP Operation field. As mentioned previously, unused fields (those marked NA) should be initialized to 0 by the sender and ignored by the receiver.
次の表は、RKRP操作フィールドに基づいて、メッセージデータ構造の各フィールドに必要な（R）、または適用されない（NA）ステータスを示しています。前述のように、未使用のフィールド（マークされたNA）は、送信者によって0に初期化され、受信機によって無視される必要があります。
+-------------------------------------------------------+
| Operation | ENTER/ | ENTER/ | ENTER/ | ENTER/ |
| | DELETE | DELETE | DELETE | DELETE |
| | OTHER | DPC-SI | DPC | SI |
| Field | MTP3 SI | PARTIAL | ONLY | ONLY |
+-------------------------------------------------------+
| Request/Reply | R | R | R | R |
+-------------------------------------------------------+
| Success/Failure | R | R | R | R |
+-------------------------------------------------------+
| RKRP Flags | R | R | R | R |
+-------------------------------------------------------+
| SI | R | R | NA | R |
+-------------------------------------------------------+
| DPC | R | R | R | NA |
+-------------------------------------------------------+
Table 20: Required/Not Applicable Fields for DPC/SI, DPC and SI based Routing Keys
表20：DPC/SI、DPCおよびSIベースのルーティングキーに必要/該当しないフィールド
The data structure used for 'rkrp' messages related to entering and deleting a default routing key is as presented in the next table. The data structure below should begin at byte 14 of the TALI message as shown in Table 12.
デフォルトのルーティングキーの入力と削除に関連する「RKRP」メッセージに使用されるデータ構造は、次の表に示されているとおりです。以下のデータ構造は、表12に示すように、TALIメッセージのBYTE 14で開始する必要があります。
+------------------------------------------------------------------+
| Octets | Field Name | Description | Field Type |
+------------------------------------------------------------------+
| 2 | RKRP | Identifies which 'rkrp' | Integer |
| | Operation | operation is desired. | |
+------------------------------------------------------------------+
| 2 | Request/ | Identifies whether the 'rkrp'| Integer |
| | Reply | message is a request (from an| |
| | | IP node to SG) for some type | |
| | | of 'rkrp' action, or a reply | |
| | | to a previous request (from | |
| | | the SG back to the IP node). | |
| | | This integer field uses the | |
| | | following encodings: | |
| | | 0x0000=Request | |
| | | 0x0001=Reply. See Success/ | |
| | | Failure code for more info. | |
+------------------------------------------------------------------+
| 2 | Success/ | Provides a success/failure | Integer |
| | Failure | indication as part of the | |
| | Code | reply back to the IP node | |
| | | for each processed request. | |
| | | This field is only used when | |
| | | the Request/Reply field is | |
| | | 0x0001. This field uses the | |
| | | encodings listed in section | |
| | | 5. | |
+------------------------------------------------------------------+
| 2 | RKRP flags | This is a 2 byte bit-field | Bit-field |
| | | that provides 16 possible | |
| | | flags that can control | |
| | | various aspects of the | |
| | | operation. | |
| | | Bit 0 - An Override bit is | |
| | | used on the ENTER operation | |
| | | to control how the socket | |
| | | associations for a routing | |
| | | key should be manipulated. | |
| | | This flag determines if the | |
| | | ENTER is to add the given | |
| | | socket association in a | |
| | | 'load-sharing' mode or if | |
| | | the new association should | |
| | | replace (Override) all | |
| | | existing associations. This | |
| | | flag is only examined on | |
| | | ENTER operations. | |
| | | Bit 0=0, Load Sharing Mode | |
| | | Bit 0=1, Override Mode | |
| | | Bits 1-15, currently | |
| | | undefined | |
+------------------------------------------------------------------+
Table 21: Message Data Structure for Default Routing Keys
表21：デフォルトのルーティングキーのメッセージデータ構造
The following table indicates the Required (R), or Not Applicable (NA) status for each field of the message data structure in Table 21 based on the RKRP Operation field. As mentioned previously, unused fields (those marked NA) should be initialized to 0 by the sender and ignored by the receiver.
次の表は、RKRP操作フィールドに基づいて、表21のメッセージデータ構造の各フィールドに必要な（R）、または適用されない（NA）ステータスを示しています。前述のように、未使用のフィールド（マークされたNA）は、送信者によって0に初期化され、受信機によって無視される必要があります。
+-------------------------------------+
| Operation | ENTER | DELETE |
| Field | DEFAULT | DEFAULT |
+-------------------------------------+
| Request/Reply | R | R |
+-------------------------------------+
| Success/Failure | R | R |
+-------------------------------------+
| RKRP Flags | R | R |
+-------------------------------------+
Table 22: Required/Not Applicable Fields for Default Routing Keys
表22：デフォルトのルーティングキーに必須/該当なしフィールド
The intent of support for multiple RKRP operations within a single TALI message (opcode = 'mgmt', primitive = 'rkrp') is to decrease the message count and byte overhead on network transmission when performing massive registration sequences.
単一のTALIメッセージ（OPCODE = 'MGMT'、Primitive = 'RKRP'）内の複数のRKRP操作のサポートの意図は、大規模な登録シーケンスを実行するときにネットワーク伝送でメッセージ数とバイトオーバーヘッドを減らすことです。
This functionality is added by 2 mechanisms:
この機能は、2つのメカニズムによって追加されます。
* a new RKRP operation (0X001B, MULTIPLE REGISTRATIONS SUPPORT) is defined. This operation is meant to be used in a query/reply manner to determine if the far end supports multiple RKRP registrations per TALI message before using such capability.
* 新しいRKRP操作（0x001B、複数の登録サポート）が定義されています。この操作は、クエリ/返信方法で使用され、そのような機能を使用する前に、ファーエンドがTALIメッセージごとに複数のRKRP登録をサポートするかどうかを判断することを目的としています。
* The basic 'rkrp' message structure is extended to allow multiple rkrp operations to follow one another in a tali message.
* 基本的な「RKRP」メッセージ構造は、複数のRKRP操作がTALIメッセージで互いに従うことができるように拡張されています。
A new RKRP operation and accompanying data structure are defined to determine if a far end device supports multiple RKRP registration operations per TALI message.
新しいRKRP操作と付随するデータ構造が定義され、ファーエンドデバイスがTALIメッセージごとに複数のRKRP登録操作をサポートするかどうかを判断します。
The data structure used for the 'multiple registrations support' operation is as presented in the next table. The data structure below should begin at byte 14 of the TALI message as shown in Table 12.
「複数の登録サポート」操作に使用されるデータ構造は、次の表に示されているとおりです。以下のデータ構造は、表12に示すように、TALIメッセージのBYTE 14で開始する必要があります。
+------------------------------------------------------------------+
| Octets | Field Name | Description | Field Type |
+------------------------------------------------------------------+
| 2 | RKRP | Identifies which 'rkrp' | Integer |
| | Operation | operation is desired. | |
+------------------------------------------------------------------+
| 2 | Request/ | Identifies whether the 'rkrp'| Integer |
| | Reply | message is a request (from an| |
| | | IP node to SG) for some type | |
| | | of 'rkrp' action, or a reply | |
| | | to a previous request (from | |
| | | the SG back to the IP node). | |
| | | This integer field uses the | |
| | | following encodings: | |
| | | 0x0000=Request | |
| | | 0x0001=Reply. See Success/ | |
| | | Failure code for more info. | |
+------------------------------------------------------------------+
| 2 | Success/ | Provides a success/failure | Integer |
| | Failure | indication as part of the | |
| | Code | reply back to the IP node | |
| | | for each processed request. | |
| | | This field is only used when | |
| | | the Request/Reply field is | |
| | | 0x0001. This field uses the | |
| | | encodings listed in section | |
| | | 5. | |
+------------------------------------------------------------------+
| 4 | Operations | This field is used by the | Integer |
| | Per Message | reply to tell the requester | |
| | | the maximum # of RKRP | |
| | | registration operations per | |
| | | TALI message that are | |
| | | supported by the | |
| | | implementation. | |
| | | * This field should be set | |
| | | to 0 when the request/ | |
| | | reply field is set to | |
| | | Request. | |
| | | * This field should be set to| |
| | | the Maximum # of operations| |
| | | per TALI message that a | |
| | | TALI implementation is | |
| | | willing to support when the| |
| | | request/reply field is set | |
| | | to Reply. | |
+------------------------------------------------------------------+
Table 23: Message Data Structure for Multiple Registrations Support
Operation
The following table indicates the Required (R), or Not Applicable (NA) status for each field of the message data structure above. As mentioned previously, unused fields (those marked NA) should be initialized to 0 by the sender and ignored by the receiver.
次の表は、上記のメッセージデータ構造の各フィールドに必要な（R）、または適用されない（NA）ステータスを示しています。前述のように、未使用のフィールド（マークされたNA）は、送信者によって0に初期化され、受信機によって無視される必要があります。
+-------------------------------------------------+
| Operation | MULTIPLE | MULTIPLE |
| | REGISTRATIONS | REGISTRATIONS |
| | SUPPORT | SUPPORT |
| Field | REQUEST | REPLY |
+-------------------------------------------------+
| Request/Reply | R | R |
+-------------------------------------------------+
| Success/Failure | R | R |
+-------------------------------------------------+
| Operations Per | R | R |
| Message | | |
+-------------------------------------------------+
Table 24: Required/Not Applicable Fields for Multiple Registrations Support Operation
表24：複数の登録に必要な/該当しないフィールドサポート操作
After using the MULTIPLE REGISTRATIONS SUPPORT operation to determine that the far end supports multiple RKRP operations per TALI message, a device wishing to use this functionality can begin sending more than 1 registration request/reply per message. To do so, the basic message structure for an 'mgmt' opcode (presented in Table 12) can be extended so that each operation directly follows the previous operation in the TALI message. An example showing a TALI message with 3 RKRP operations in it would look as follows:
複数の登録サポート操作を使用して、ファーエンドがTALIメッセージごとに複数のRKRP操作をサポートしていると判断した後、この機能を使用したいデバイスは、メッセージごとに複数の登録リクエスト/返信を送信し始めることができます。そのために、「MGMT」オペコード（表12に示す）の基本的なメッセージ構造を拡張できるように、各操作はTALIメッセージの以前の操作に直接従うようにすることができます。3つのRKRP操作を含むタリメッセージを示す例は、次のように見えます。
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'mgmt' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length. The length should be set such that|
| | | all (3 in this example) operations are |
| | | accounted for. |
+------------------------------------------------------------------+
| 10..13 | Primitive | 'rkrp' |
+------------------------------------------------------------------+
| 14..17 | Primitive | The fisrt operation field identifies a |
| | Operation | specific rkrp operation to be performed. |
| | #1 | |
+------------------------------------------------------------------+
| 18..x | Message | The length of the message data (and the |
| | Data for | interpretation of those bytes) for |
| | Operation | operation #1 depends on the message data |
| | #1 | required for rkrp operation #1 |
+------------------------------------------------------------------+
| x+1.. | Primitive | The fisrt operation field identifies a |
| x+4 | Operation | specific rkrp operation to be performed. |
| | #2 | |
+------------------------------------------------------------------+
| x+5..y | Message | The length of the message data (and the |
| | Data for | interpretation of those bytes) for |
| | Operation | operation #2 depends on the message data |
| | #2 | required for rkrp operation #2 |
+------------------------------------------------------------------+
| y+1.. | Primitive | The fisrt operation field identifies a |
| y+4 | Operation | specific rkrp operation to be performed. |
| | #3 | |
+------------------------------------------------------------------+
| y+5..z | Message | The length of the message data (and the |
| | Data for | interpretation of those bytes) for |
| | Operation | operation #3 depends on the message data |
| | #3 | required for rkrp operation #3 |
+------------------------------------------------------------------+
Table 25: Message Structure for 'mgmt' opcode with multiple 'rkrp' operations in 1 TALI Message
表25：1 Taliメッセージに複数の「RKRP」操作を備えた「MGMT」オペコードのメッセージ構造
It should be reiterated that in order to avoid unpredictable behavior, a node using the 'multiple registrations per TALI msg' capability must be sure the far end device supports the capability. The only way to be sure of this is to successfully send a MULTIPLE REGISTRATION SUPPORT request and receive a MULTIPLE REGISTRATION SUPPORT reply.
予測不可能な動作を避けるために、「TALI MSGごとの複数の登録」機能を使用するノードは、ファーエンドデバイスが機能をサポートすることを確認する必要があることを繰り返します。これを確実にする唯一の方法は、複数の登録サポートリクエストを正常に送信し、複数の登録サポートの返信を受信することです。
The 'mtpp' primitive allows IP nodes to receive status regarding point code (un)availability and congestion levels. These messages provide information similar to the TFP/TFA (TransFer Prohibited and TransFer Allowed), TFC (TransFer Congested) and RCT (Route Congestion Test) messages that are encoded as SS7 SNM (Signaling Network Management) MSUs in traditional SS7 networks. The 'mtp3 primitives' allow this status information to be transferred in-band, via TALI messages, to the IP nodes.
「MTPP」プリミティブにより、IPノードはポイントコード（UN）の可用性と輻輳レベルに関するステータスを受信できます。これらのメッセージは、従来のSS7ネットワークでSS7 SNM（シグナル伝達ネットワーク管理）MSUSとしてエンコードされたTFP/TFA（転送禁止および転送許可）、TFC（転送混合）、およびRCT（ルート渋滞テスト）メッセージに類似した情報を提供します。「MTP3 Primitives」により、このステータス情報は、TALIメッセージを介してIPノードにバンド内で転送されます。
The specific information provided in each 'mtpp' message is indicated via an 'MTPP Operation' field. These capabilities provided by the various MTPP Operation fields include:
各「MTPP」メッセージで提供される特定の情報は、「MTPP操作」フィールドを介して示されています。さまざまなMTPP操作フィールドが提供するこれらの機能には、以下が含まれます。
* POINT CODE UNAVAILABLE: This primitive operation announces that an SS7 Point Code is Unavailable (ie: the SG has NO route available to send traffic for the destination). The PT CODE field indicates which SS7 Pt Code this operation is concerned with.
* ポイントコードは利用できません：このプリミティブ操作は、SS7ポイントコードが利用できないことを発表します（つまり、SGには目的地のトラフィックを送信するルートがありません）。PTコードフィールドは、この操作が関係しているSS7 PTコードを示します。
* POINT CODE AVAILABLE: This primitive operation announces that an SS7 Point Code is Available (ie: the SG has SOME route available to send traffic for the destination). The PT CODE field indicates which SS7 Pt Code this operation is concerned with.
* 利用可能なポイントコード：このプリミティブ操作は、SS7ポイントコードが利用可能であることを発表します（つまり、SGには目的地のトラフィックを送信するためのルートがあります）。PTコードフィールドは、この操作が関係しているSS7 PTコードを示します。
* REQUEST FOR POINT CODE STATUS: This primitive operation provides a way for one end of the connection to poll the other end for the available/unavailable status of a specific SS7 pt code. For instance, the IP node can poll the SG - Can you send traffic successfully for the destination indicated? The receiver of the request will reply to the request with either a point code available or pt code unavailable primitive respectively.
* ポイントコードステータスのリクエスト：このプリミティブ操作は、特定のSS7 PTコードの利用可能/利用できないステータスについて、接続の一方の端がもう一方の端を投票する方法を提供します。たとえば、IPノードはSGを投票できます - 指定された目的地のトラフィックを正常に送信できますか？リクエストの受信者は、利用可能なポイントコードまたはPTコードのいずれかをそれぞれ利用できないプリミティブでリクエストに返信します。
* CLUSTER UNAVAILABLE: This primitive operation announces that an entire Cluster of SS7 Point Codes (ex: 10-10-*) are Unavailable (ie: the SG has NO route available to send traffic for any of the destinations in that cluster). The PT CODE field indicates which SS7 Cluster Pt Code this operation is concerned with.
* クラスターは利用できません：このプリミティブ操作は、SS7ポイントコード（例：10-10-*）のクラスター全体が利用できないことを発表します（つまり、SGにはそのクラスター内の宛先のいずれかのトラフィックを送信するルートがありません）。PTコードフィールドは、この操作が関係しているSS7クラスターPTコードを示します。
* CLUSTER AVAILABLE: This primitive operation announces that at least 1 SS7 Point Code within a cluster is Available (ie: the SG has SOME route available to send traffic for at least 1 of the destinations in that cluster). The PT CODE field indicates which SS7 Cluster Pt Code this operation is concerned with.
* 利用可能なクラスター：このプリミティブ操作は、クラスター内の少なくとも1つのSS7ポイントコードが利用可能であることを発表します（つまり、SGには、そのクラスター内の少なくとも1つの宛先のトラフィックを送信するためのルートがあります）。PTコードフィールドは、この操作が関係しているSS7クラスターPTコードを示します。
* REQUEST FOR CLUSTER STATUS: This primitive operation provides a way for one end of the connection to poll the other end for the available/unavailable status of a cluster of SS7 pt codes. For instance, the IP node can poll the SG - Can you send traffic successfully for any of the destinations in the cluster? The receiver of the request will reply to the request with either a cluster available or cluster unavailable primitive respectively.
* クラスターステータスのリクエスト：このプリミティブ操作は、SS7 PTコードのクラスターの利用可能/利用できないステータスのために、接続の一方の端がもう一方の端を投票する方法を提供します。 たとえば、IPノードはSGを投票できます - クラスター内の宛先のいずれかのトラフィックを正常に送信できますか？ リクエストの受信者は、それぞれ利用可能なクラスターまたはクラスターのいずれかを使用して、リクエストにそれぞれ返信します。
* CONGESTED DESTINATION: This primitive operation announces that the path towards an SS7 Point Code is Congested. The PT CODE field indicates which SS7 Pt Code this operation is concerned with. The CONGESTION LEVEL field indicates the severity of the congestion.
* 混雑した目的地：この原始操作は、SS7ポイントコードへのパスが混雑していることを発表します。PTコードフィールドは、この操作が関係しているSS7 PTコードを示します。輻輳レベルのフィールドは、輻輳の重症度を示しています。
* REQUEST FOR CONGESTION STATUS: This primitive operation provides a way for one end of the connection to poll the other end for the congestion status of an SS7 pt code. For instance, the IP node can poll the SG - Is the path to the specified destination still congested? This request is used to abate congestion towards an SS7 destination.
* 輻輳状態のリクエスト：このプリミティブ操作は、SS7 PTコードの輻輳状態について、接続の一方の端がもう一方の端を投票する方法を提供します。たとえば、IPノードはSGを投票できます - 指定された宛先へのパスはまだ混雑していますか？このリクエストは、SS7の宛先に向かって混雑を軽減するために使用されます。
* As an implementation note: Upon receiving this request, the SG will generate and send a Route Congestion Test (RCT), SS7 Network Management Message with a priority set to match the congestion level in the request. The RCT is sent towards the SS7 destination. If the SS7 destination is still congested, the RCT will result an SS7 Transfer Controlled (TFC) arriving back at the SG, which will be converted into a CONGESTED DESTINATION primitive and sent on to the IP node.
* 実装として：このリクエストを受信すると、SGは、リクエストの輻輳レベルと一致する優先度セットを備えたSS7ネットワーク管理メッセージのルート渋滞テスト（RCT）を生成および送信します。RCTはSS7宛先に向かって送信されます。SS7の宛先がまだ混雑している場合、RCTはSGに到着するSS7転送制御（TFC）が吸引される宛先の原始に変換され、IPノードに送られます。
* USER PART UNAVAILABLE: SS7 nodes send User Part Unavailable messages when a user part that is mounted on a node is no longer available for service. This primitive operation provides a way for an IP Node to receive the same information as the SS7 UPU message.
* ユーザーパーツは利用できません：SS7ノードは、ノードにマウントされているユーザーパーツがサービスに利用できなくなった場合、ユーザーパーツを利用できないメッセージを送信します。このプリミティブ操作は、IPノードがSS7 UPUメッセージと同じ情報を受信する方法を提供します。
In order to simplify the implementation, a single data structure is defined to be used for all of the 'mtpp' operations. Depending on the 'mtpp operation', some of the fields will be required, and some of the fields will not be applicable for each MTPP message. Unused fields should be initialized to 0 by the sender and ignored by the receiver. The data structure used for 'mtpp' messages is as presented in the next table. The data structure below should begin at byte 14 of the TALI message as shown in Table 12.
実装を簡素化するために、すべての「MTPP」操作に使用されるように単一のデータ構造が定義されています。「MTPP操作」に応じて、一部のフィールドが必要になり、一部のフィールドは各MTPPメッセージに適用できません。未使用のフィールドは、送信者によって0に初期化され、受信機によって無視される必要があります。「MTPP」メッセージに使用されるデータ構造は、次の表に示されているとおりです。以下のデータ構造は、表12に示すように、TALIメッセージのBYTE 14で開始する必要があります。
+------------------------------------------------------------------+
| Octets | Field Name | Description | Field Type |
+------------------------------------------------------------------+
| 2 | MTPP | Identifies which 'mtpp' | Integer |
| | Operation | operation/capability is | |
| | | provided in this message. | |
| | | This integer field uses the | |
| | | following encodings: | |
| | | 0x0001 = PC Unavailable | |
| | | 0x0002 = PC Available | |
| | | 0x0003 = Request for PC | |
| | | Status | |
| | | 0x0004 = Cluster Unavailable | |
| | | 0x0005 = Cluster Available | |
| | | 0x0006 = Request for Cluster | |
| | | Status | |
| | | 0x0007 = Congested | |
| | | Destination, w/Cong | |
| | | Level | |
| | | 0x0008 = Request for | |
| | | Congestion Status | |
| | | 0x0009 = User Part | |
| | | Unavailable | |
+------------------------------------------------------------------+
| 4 | Concerned | Identifies the SS7 Point Code| SS7 Point |
| | Point | that is relevant to the mtpp | Code |
| | Code | operation. The mtpp | |
| | | operation is concerning this | |
| | | point code (or cluster). | |
+------------------------------------------------------------------+
| 4 | Source | This field is only used on | SS7 Point |
| | Point | the 'Congested Destination' | Code |
| | Code | and 'Request for Congestion | |
| | | Status' operations. | |
| | | * When used in an 'Congestion| |
| | | Destination' operation, | |
| | | this field contains the Pt | |
| | | Code of the Source of the | |
| | | traffic that was | |
| | | experiencing congestion as | |
| | | it made its way to the | |
| | | Concerned Pt Code. In | |
| | | terms of the original SS7 | |
| | | MSUs (the TransFer | |
| | | Controlled MSU) that | |
| | | provided congestion | |
| | | information, the CPC of the| |
| | | TFC is the 'Concerned Point| |
| | | Code' of the resulting MTPP| |
| | | primitive and the DPC of | |
| | | the TFC is the 'Source | |
| | | Point Code' of the | |
| | | resulting MTPP primitive. | |
| | | * When used in an 'Request | |
| | | for Congestion Status' | |
| | | operation, this field | |
| | | indicates which Source Pt | |
| | | Code is trying to abate the| |
| | | congestion of the concerned| |
| | | Pt Code. In terms of the | |
| | | original SS7 MSUs (the | |
| | | Route Congestion Test MSU) | |
| | | that is used to poll for | |
| | | congestion, the DPC of the | |
| | | RCT is the 'Concerned Point| |
| | | Code' of the MTPP primitive| |
| | | and the OPC of the RCT is | |
| | | the 'Source Point Code' of | |
| | | the MTPP primitive. | |
+------------------------------------------------------------------+
| 2 | Congestion | This field is used on the | Integer |
| | Level | 'Congested Destination' and | |
| | | 'Request for Congestion | |
| | | Status' operations to | |
| | | indicate the congestion level| |
| | | of the destination. This | |
| | | integer field uses the | |
| | | following encodings: | |
| | | 0x0000 = Congestion Level 0 | |
| | | 0x0001 = Congestion Level 1 | |
| | | 0x0002 = Congestion Level 2 | |
| | | 0x0003 = Congestion Level 3 | |
+------------------------------------------------------------------+
| 2 | Cause Code | This field is used on the | Integer |
| | | 'User Part Unavailable' | |
| | | operation to indicate the | |
| | | Cause Code for why the UPU is| |
| | | being sent. This integer | |
| | | field uses the following | |
| | | encodings: | |
| | | 0x0000 = Cause Unknown | |
| | | 0x0001 = User Part Unequipped| |
| | | 0x0002 = User Part | |
| | | Inaccessible | |
+------------------------------------------------------------------+
| 2 | User ID | This field is used on the | Integer |
| | | 'User Part Unavailable' | |
| | | operation to indicate which | |
| | | user part is unavailable. The| |
| | | User ID field identifies the | |
| | | type of traffic that was | |
| | | unavailable (0=SNM, 3=SCCP, | |
| | | 5=ISUP, etc). | |
+------------------------------------------------------------------+
Table 26: Message Data Structure for use with the 'mtpp' Primitive
表26：「MTPP」プリミティブで使用するメッセージデータ構造
The following table indicates the Required (R), or Not Applicable (NA) status for each field of the message data structure in Table 26 based on the MTPP Operation field. As mentioned previously, unused fields (those marked NA) should be initialized to 0 by the sender and ignored by the receiver.
次の表は、MTPP操作フィールドに基づいて、メッセージデータ構造の各フィールドの必要な（R）、または適用されない（NA）ステータスを示しています。前述のように、未使用のフィールド（マークされたNA）は、送信者によって0に初期化され、受信機によって無視される必要があります。
+------------------------------------------------------------------+
| Field | Concerned | Source | Congestion | Cause | User |
| | Point | Point | Level | Code | ID |
| Operation | Code | Code | | | |
+------------------------------------------------------------------+
| PC Unavailable | R | NA | NA | NA | NA |
+------------------------------------------------------------------+
| PC Available | R | NA | NA | NA | NA |
+------------------------------------------------------------------+
| Request for PC | R | NA | NA | NA | NA |
| Status | | | | | |
+------------------------------------------------------------------+
| Cluster | R | NA | NA | NA | NA |
| Unavailable | | | | | |
+------------------------------------------------------------------+
| Cluster | R | NA | NA | NA | NA |
| Available | | | | | |
+------------------------------------------------------------------+
| Request for | R | NA | NA | NA | NA |
| Cluster Status | | | | | |
+------------------------------------------------------------------+
| Congested | | | | | |
| Destination w/ | R | R | R | NA | NA |
| Cong. Level | | | | | |
+------------------------------------------------------------------+
| Request for | | | | | |
| Congestion | R | R | R | NA | NA |
| Status | | | | | |
+------------------------------------------------------------------+
| User Part | R | NA | NA | R | R |
| Unavailable | | | | | |
+------------------------------------------------------------------+
Table 27: Required/Not Applicable Fields for MTPP Operations
表27：MTPP操作に必須/適用されないフィールド
The 'sorp' primitive allows IP nodes to set various options on a socket by socket basis. This allows the IP node some control over the communication that will occur across the TALI connection. The 'sorp' primitives allows this socket option control to be transferred in-band, via TALI messages, to the IP nodes.
「SORP」プリミティブにより、IPノードはソケットごとにさまざまなオプションをソケットに設定できます。これにより、IPノードは、TALI接続全体で発生する通信をある程度制御できます。「SORP」プリミティブにより、このソケットオプションコントロールは、タリメッセージを介してIPノードにバンド内で転送できます。
The SORP primitives capabilities that are available to the IP device in SG are as follows:
SGのIPデバイスが利用できるSORPプリミティブ機能は次のとおりです。
* Set SORP Flags: Used to set the flags bit field. The receiver of this message should store the bit settings indicated in the SORP Flag field.
* SORPフラグの設定：フラグビットフィールドを設定するために使用されます。このメッセージの受信者は、SORPフラグフィールドに示されているビット設定を保存する必要があります。
* Request Current SORP Flags Settings: Used to poll for the status of the bit field options. The receiver of this message should send a Reply w/ Current SORP Flag settings.
* 現在のSORPフラグの設定をリクエスト：ビットフィールドオプションのステータスのポーリングに使用します。このメッセージの受信者は、現在のSORPフラグ設定を備えた返信を送信する必要があります。
* Reply w/ Current SORP Flag Settings: Used to reply to a poll, indicating the current bit field settings to the far end.
* 現在のSORPフラグ設定付きの返信：投票に返信するために使用され、遠端までの現在のビットフィールド設定を示します。
As of TALI 2.0, each socket option is stored as a bit in a 32 bit bit-field. Each bit in the field indicates the setting for 1 option. A bit field with a 0 value indicates the option is DISABLED. A bit field with a 1 value indicates the option is ENABLED. The following options are currently supported:
TALI 2.0の時点で、各ソケットオプションは32ビットフィールドに少し保存されます。フィールド内の各ビットは、1オプションの設定を示します。0の値を持つビットフィールドは、オプションが無効になっていることを示します。1つの値を持つビットフィールドは、オプションが有効になっていることを示します。現在、次のオプションがサポートされています。
* ENABLE/DISABLE BROADCAST PHASE MTPP PRIMITIVES: Traditional STPs send Broadcast Phase TFPs and TFAs to all adjacent nodes when the point code availability changes for destinations in the STP's SS7 routing table. These Broadcast Phase TFA/TFP SS7 messages are converted into TALI mtpp primitives by SG nodes such as the SG. The ENABLE/DISABLE BROADCAST PHASE MTPP PRIMITIVES options allow each IP node to tell the remote end whether the IP node wants to receive the mtpp primitives that result from SS7 broadcast phase messages.
* ブロードキャストフェーズMTPPプリミティブを有効/無効にする：従来のSTPSは、STPのSS7ルーティングテーブルの宛先のポイントコードの可用性が変更されたときに、すべての隣接ノードにブロードキャストフェーズTFPとTFAを送信します。これらのブロードキャストフェーズTFA/TFP SS7メッセージは、SGなどのSGノードによってTali MTPPプリミティブに変換されます。ブロードキャストフェーズMTPP Primitivesオプションを有効/無効にすると、各IPノードは、IPノードがSS7ブロードキャストフェーズメッセージに起因するMTPPプリミティブを受信したいかどうかをリモートエンドに伝えることができます。
* As an implementation note: In the SG, each defined socket has a flag, 'enable_broadcast_phase_primitives', which is initialized to FALSE each time the socket connects. The IP node should send the ENABLE BROADCAST PHASE MESSAGES operation to the SG to announce that it wants to receive unsolicited status changes for a particular socket. As the SG is determining where to send broadcast phase TFAs/TFPs, it will interrogate the 'enable_broadcast_phase_primitives' flag for each socket on that socket.
* 実装として：SGには、定義された各ソケットにはフラグ「Enable_broadcast_phase_primitives」があり、ソケットが接続するたびにfalseに初期化されます。IPノードは、有効なブロードキャストフェーズメッセージ操作をSGに送信して、特定のソケットの未承諾ステータスの変更を受信したいことを発表する必要があります。SGはブロードキャストフェーズTFAS/TFPSの送信先を決定しているため、そのソケットの各ソケットの「enable_broadcast_phase_primitives」フラグを尋問します。
* ENABLE/DISABLE RESPONSE METHOD MTPP PRIMITIVES: Traditional STPs send Response Method TFPs to adjacent nodes when the adjacent nodes continue to send MSUs to the STP that can not be delivered (ie: the STP has told the adjacent node that a destination is Unavailable, but the adjacent node continues to send traffic destined for that unavailable DPC to the STP). These Response Method messages are sent in response to MSUs that are received at the STP. These Response Method TFP messages are converted into TALI mtpp primitives by SG nodes such as the SG. The ENABLE/DISABLE RESPONSE METHOD MTPP PRIMITIVES options allow each IP node to tell the remote end whether the IP node wants to receive the mtpp primitives that result from SS7 response method messages. In addition to response method TFPs, 2 other SS7 Network Management messages, namely TFCs (transfer controlled) and UPUs (user part unavailable), fall into this RESPONSE METHOD grouping. TFCs and UPUs are similar to response method TFPs due to the fact that a previous action by the IP Node (sending traffic toward some destination) has caused a response method event back to the IP Node. The primary difference between response method TFPs versus response method TFCs/UPUs is that the response method TFP is converted to an MTPP primitive and sent back to only the original socket, while response method TFCs/UPUs may need to be replicated to multiple sockets (after being converted to mtpp primitives) since there is no way to tell which socket caused the response method event.
* 対応方法を有効/無効にするMTPPプリミティブ：従来のSTPSは、隣接するノードが配信できないSTPにMSUSを送信し続けている場合、隣接するノードに応答方法TFPを送信します（つまり、STPは隣接ノードに宛先が利用できないことを伝えましたが、隣接するノードは、その利用できないDPCのためのトラフィックをSTPに送信し続けます）。これらの応答メソッドメッセージは、STPで受信されるMSUSに応じて送信されます。これらの応答方法TFPメッセージは、SGなどのSGノードによってTali MTPPプリミティブに変換されます。Enable/Disable ResponseメソッドMTPP Primitivesオプションにより、各IPノードは、IPノードがSS7応答メソッドメッセージに起因するMTPPプリミティブを受信したいかどうかをリモートエンドに伝えることができます。応答方法TFPSに加えて、他の2つのSS7ネットワーク管理メッセージ、すなわちTFC（転送制御）およびUPUS（ユーザーパーツは利用できません）は、この応答メソッドグループに分類されます。TFCSとUPUSは、IPノードによる以前のアクション（一部の宛先にトラフィックを送信）がIPノードに戻って回答方法イベントを引き起こしたため、応答方法TFPに似ています。応答方法TFPと応答方法TFCS/UPUSの主要な違いは、応答方法TFPがMTPPプリミティブに変換され、元のソケットのみに送られ、応答方法TFCS/UPUSを複数のソケットに複製する必要があることです（後）どのソケットが応答方法イベントを引き起こしたかを判断する方法がないため、MTPPプリミティブに変換されます）。
* As an implementation node: In the SG, each defined socket has a flag, 'enable_response_method_primitives', which is initialized to FALSE each time the socket connects. The IP node should send the ENABLE RESPONSE METHOD MTPP PRIMITIVES operation to the SG to announce that it wants to receive response method TFPs when appropriate for a particular socket. Before the SG sends a response method TFP (converted to a mtpp primitive) back to an IP node, the SG will interrogate the 'enable_response_method_primitives' flag for that socket and only perform the send if the flag allows it.
* 実装ノードとして：SGでは、定義された各ソケットにはフラグ「Enable_response_method_primitives」があり、ソケットが接続するたびにfalseに初期化されます。IPノードは、Enable Response Method MTPP Primitives操作をSGに送信して、特定のソケットに適切な場合に応答方法TFPを受信したいことを発表する必要があります。SGが応答方法TFP（MTPPプリミティブに変換）をIPノードに送信する前に、SGはそのソケットの「enable_response_method_primitives」フラグを尋問し、フラグが許可されている場合にのみ送信を実行します。
* ENABLE/DISABLE NORMALIZED SCCP: Version 1.0 of TALI specified that the 'sccp' TALI opcode must be used on point to multipoint connections in order to transmit SCCP MSUs between the SG and IP nodes. When using the 'sccp' opcode, the MTP3 header portion of the original SS7 MSU was stripped from the MSU and was NOT part of the data transmitted across the TALI connection. The sender of the 'sccp' TALI message was responsible for duplicating the DPC/OPC fields from the MTP3 header into appropriate fields in the SCCP portion of the message (into the Called/Calling Party Address Pt Code fields) before sending as a 'sccp' opcode. This option provides a way to send SCCP MSUs across TALI point to multipoint connections that includes the MTP3 header as part of the data transmitted, and does NOT involve any modification to the original SS7 SCCP MSU. When the ENABLE NORMALIZED SCCP primitive is received, SCCP MSUs should be sent across the TALI interface using the 'mtp3' opcode. This transmission should include the entire MTP3 header + the sccp portion of the original MSU. No modification of the original SS7 MSU should occur. When the DISABLE NORMALIZED SCCP primitive is received, SCCP MSUs should be sent across the TALI interface using the 'sccp' opcode as specified in version 1.0 of TALI.
* 正規化/無効化SCCP：TALIのバージョン1.0は、SGノードとIPノード間でSCCP MSUSを送信するために、「SCCP」TALI OPCODEをマルチポイント接続に使用する必要があることを指定しました。「SCCP」オペコードを使用すると、元のSS7 MSUのMTP3ヘッダー部分がMSUから剥がされ、TALI接続全体に送信されるデータの一部ではありませんでした。「SCCP」TALIメッセージの送信者は、MTP3ヘッダーからDPC/OPCフィールドをメッセージのSCCP部分の適切なフィールドに複製する責任がありました（呼び出し/通話党アドレスPTコードフィールドに） 'SCCPとして送信'オペコード。このオプションは、TALIポイントを越えてSCCP MSUSを送信するマルチポイント接続に送信する方法を提供します。これは、送信されたデータの一部としてMTP3ヘッダーを含み、元のSS7 SCCP MSUの変更は含まれません。正規化されたSCCPプリミティブを受信する場合、「MTP3」オペコードを使用してSCCP MSUSをTALIインターフェイス全体に送信する必要があります。このトランスミッションには、元のMSUのSCCP部分にMTP3ヘッダー全体を含める必要があります。元のSS7 MSUの変更は発生しません。無効化された正規化されたSCCPプリミティブを受信する場合、TALIのバージョン1.0で指定されている「SCCP」オペコードを使用して、SCCP MSUSをTALIインターフェイス全体に送信する必要があります。
* ENABLE/DISABLE NORMALIZED ISUP: Version 1.0 of TALI specified that the 'isot' TALI opcode must be used on point to multipoint connections in order to transmit ISUP MSUs between the SG and IP nodes. When using the 'isot' opcode, the original SS7 MSU, including the MTP3 header portion, was transmitted in a 'isot' TALI message. This option indicates that the far end would prefer to receive ISUP MSUs using the 'mtp3' TALI opcode as opposed to the 'isot' opcode. When the option is ENABLED, the 'mtp3' opcode is used to transmit ISUP MSUs, including the MTP3 header, across the TALI connection. When the option is DISABLED, the 'isot' opcode is used as in TALI Release 1.0.
* 正規化されたISUPを有効/無効にする：TALIのバージョン1.0は、SGノードとIPノード間のISUP MSUSを送信するために、「ISOT」TALI OPCODEをマルチポイント接続に使用する必要があることを指定しました。 「ISOT」オペコードを使用すると、MTP3ヘッダー部分を含む元のSS7 MSUが「ISOT」タリメッセージに送信されました。 このオプションは、「ISOT」オペコードとは対照的に、「MTP3」TALI OPCODEを使用してISUP MSUSを受信することを好むことを示しています。 オプションが有効になっている場合、「MTP3」オペコードを使用して、MTP3ヘッダーを含むISUP MSUSをTALI接続全体に送信します。 オプションが無効になっている場合、Taliリリース1.0のように「ISOT」オペコードが使用されます。
The data structure used for 'sorp' messages is as presented in the next table. The data structure below should begin at byte 14 of the TALI message as shown in Table 12.
「SORP」メッセージに使用されるデータ構造は、次の表に示されているとおりです。以下のデータ構造は、表12に示すように、TALIメッセージのBYTE 14で開始する必要があります。
+------------------------------------------------------------------+
| Octets | Field Name | Description | Field Type |
+------------------------------------------------------------------+
| 2 | SORP | Identifies which 'sorp' | Integer |
| | Operation | operation/capability is | |
| | | provided in this message. | |
| | | This integer field uses the | |
| | | following encodings: | |
| | | 0x0001 = Set SORP Flags | |
| | | 0x0002 = Request Current | |
| | | SORP Flags Settings | |
| | | 0x0003 = Reply w/ Current | |
| | | SORP Flag Settings | |
+------------------------------------------------------------------+
| 2 | SORP Flags | A 4 byte bit-field that uses | Bit-Field |
| | | each bit as an enabled/ | |
| | | disabled flag for a | |
| | | particular socket option. | |
| | | Bit x = 0 indicates the | |
| | | option is DISABLED. | |
| | | Bit x = 1 indicates the | |
| | | option is ENABLED. | |
| | | The assignments for each BIT | |
| | | are as follows: | |
| | | Bit 0 = Broadcast Phase MTPP | |
| | | Primitives | |
| | | Bit 1 = Response Method MTPP | |
| | | Primitives | |
| | | Bit 2 = Normalized SCCP | |
| | | Bit 3 = Normalized ISUP | |
+------------------------------------------------------------------+
Table 28: Message Data Structure to be used for 'sorp' Primitive
表28：「sorp」プリミティブに使用されるメッセージデータ構造
The Extended Service, 'xsrv', opcode is added to the TALI 2.0 protocol to lay the groundwork for providing a means to transport other types of service traffic (beyond 'sccp', 'isot', 'mtp3', and 'saal') in future revisions of this protocol without having to define a new opcode as each new service type is identified and added. The PRIMITIVE field will uniquely identify each new service type as they are added. It is envisioned that some 'xsrv' messages can be received and processed in any of the TALI NEx-FEx state, while some other 'xsrv' messages can only be received and processed in the NEA-FEA state (such as Service data in version 1.0 of TALI).
拡張サービス「XSRV」、OpCodeがTALI 2.0プロトコルに追加され、他の種類のサービストラフィックを輸送する手段を提供するための基礎を築きます（「SCCP」、「ISOT」、「MTP3」、および「SAAL」）新しいサービスタイプが識別されて追加されるたびに、新しいオペコードを定義することなく、このプロトコルの将来の改訂で。プリミティブフィールドは、追加された各新しいサービスタイプを一意に識別します。一部の「XSRV」メッセージはTali Nex-Fex状態のいずれかで受信および処理できることを想定していますが、他の「XSRV」メッセージはNEA-FEA州でのみ受信および処理できます（バージョンのサービスデータなどタリの1.0）。
There are no specific PRIMITIVES defined for this opcode in this release. It is expected that some new service messages will be added in the future. This opcode provides for grouping of the new service data types.
このリリースでは、このオプコードに対して定義された特定のプリミティブはありません。いくつかの新しいサービスメッセージが将来追加されることが期待されています。このオペコードは、新しいサービスデータ型のグループ化を提供します。
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'xsrv' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length |
+------------------------------------------------------------------+
| 10..13 | Primitive | To be determined |
+------------------------------------------------------------------+
| 14.. | Message | To be determined |
| 2000 | Data | |
+------------------------------------------------------------------+
The Special Message, 'spcl', opcode is added to the TALI 2.0 protocol to provide a way for vendors to build special services into their TALI implementations that are only activated when the implementation is connected to other equipment implementing the same special services. 'spcl' messages can be received and processed in any of the TALI NEx-FEx states. This opcode is intended to provide a general means to discover more information regarding who the TALI session is connected to, and to provide means to enable special features based on the vendor/implementation on the far end.
特別なメッセージ「SPCL」、OpcodeがTALI 2.0プロトコルに追加され、ベンダーが同じ特別なサービスを実装する他の機器に接続されている場合にのみアクティブ化されるTALI実装に特別なサービスを構築する方法を提供します。「SPCL」メッセージは、TALI NEX-FEX状態のいずれかで受信および処理できます。このオペコードは、タリセッションが誰に接続されているかに関する詳細情報を発見し、遠端のベンダー/実装に基づいて特別な機能を有効にする手段を提供する一般的な手段を提供することを目的としています。
As part of the 2.0 specification, 4 primitives are initially defined for this opcode:
2.0仕様の一部として、このオペコードに対して4つのプリミティブが最初に定義されています。
* 'smns' - Special Messages Not Supported. * 'qury' - Query. * 'rply' - Reply. * 'usim' - UnSolicited Information Message.
* 「SMNS」 - 特別なメッセージはサポートされていません。* 'qury' - クエリ。* 'rply' - 返信。* 'usim' - 未承諾の情報メッセージ。
Additional primitives can be added in future versions of the TALI protocol.
タリプロトコルの将来のバージョンに追加のプリミティブを追加できます。
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'spcl' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length |
+------------------------------------------------------------------+
| 10..13 | Primitive | 'smns' - special messages not supported |
| | | 'qury' - query |
| | | 'rply' - reply |
| | | 'usim' - UIM (unsolicited information msg)|
+------------------------------------------------------------------+
| 14..X | Data | Vendor dependent |
+------------------------------------------------------------------+
This message is sent as a response to a 'spcl' message with a 'qury' PRIMITIVE. A node may send out this message when it wants the Far End to know that it does not support 'spcl' messages and wishes not to receive them in the future.
このメッセージは、「qury」プリミティブを備えた「spcl」メッセージへの応答として送信されます。ノードは、「SPCL」メッセージをサポートしておらず、将来それらを受け取らないことを望んでいることを知ってもらいたい場合、このメッセージを送信する場合があります。
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'spcl' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length |
+------------------------------------------------------------------+
| 10..13 | Primitive | 'smns' |
+------------------------------------------------------------------+
This message can be sent to Query the far end of the connection (ie: try to find out more information about the VENDOR, TALI version, or other features). It is expected that each 2.0 implementation would respond to a 'qury' with a 'rply'.
このメッセージは、接続の遠端を照会するために送信できます（つまり、ベンダー、タリ版、またはその他の機能の詳細を確認してみてください）。各2.0の実装は、「rply」で「quury」に応答すると予想されます。
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'spcl' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length |
+------------------------------------------------------------------+
| 10..13 | Primitive | 'qury' |
+------------------------------------------------------------------+
The 'rply' message provides a way for a TALI 2.0 implementation to identify itself in more detail. The information included in the reply includes:
「rply」メッセージは、TALI 2.0の実装がより詳細に識別する方法を提供します。返信に含まれる情報には以下が含まれます。
* PEC - a 2 byte field that identifies the vendor for the TALI implemenation.
* PEC -TALI実装のベンダーを識別する2バイトフィールド。
* Version Number - a 12 byte field that identifies the TALI version of the implementation.
* バージョン番号 - 実装のTALIバージョンを識別する12バイトフィールド。
* Other Vendor Specific Data - the format of any remaining data that a particular vendor wants to provide is specific to each vendor.
* その他のベンダー固有のデータ - 特定のベンダーが提供したい残りのデータの形式は、各ベンダーに固有です。
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'spcl' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length |
+------------------------------------------------------------------+
| 10..13 | Primitive | 'rply' |
+------------------------------------------------------------------+
| 14..15 | PEC | Private Enterprise Code * |
| | | (Vendor ID Number, Integer Field) |
+------------------------------------------------------------------+
| 16..27 | Version | 'vers xxx.yyy' |
| | Label | |
+------------------------------------------------------------------+
| 28..? | Other Vendor| Free Format data area, specific to each |
| | Specific | vendor |
| | Data | |
+------------------------------------------------------------------+
*See Table 4 for details on the PEC field.
*PECフィールドの詳細については、表4を参照してください。
A 'usim' provides the same information as the 'rply' primitive. The 'usim' can be sent at any time by a 2.0 implementation (whereas the 'rply' should only be sent in reply to a 'qury').
「usim」は、「rply」原始と同じ情報を提供します。「USIM」は、2.0の実装でいつでも送信できます（「rply」は「quury」への返信でのみ送信する必要があります）。
+------------------------------------------------------------------+
| Octets | Field Name | Description |
+------------------------------------------------------------------+
| 0..3 | SYNC | 'TALI' |
+------------------------------------------------------------------+
| 4..7 | OPCODE | 'spcl' |
+------------------------------------------------------------------+
| 8..9 | LENGTH | Length |
+------------------------------------------------------------------+
| 10..13 | Primitive | 'usim' |
+------------------------------------------------------------------+
| 14..15 | PEC | Private Enterprise Code * |
| | | (Vendor ID Number, Integer Field) |
+------------------------------------------------------------------+
| 16..27 | Version | 'vers xxx.yyy' |
| | Label | |
+------------------------------------------------------------------+
| 28..? | Other Vendor| Free Format data area, specific to each |
| | Specific | vendor |
| | Data | |
+------------------------------------------------------------------+
Version 2.0 of the TALI specification does not introduce any new timers. The T1-T4 timers defined previously remain in effect.
TALI仕様のバージョン2.0では、新しいタイマーは導入されていません。以前に定義されたT1-T4タイマーは有効です。
While, it is expected that most implementations wishing to identify themselves as 2.0 (or later) would use a non-zero value for T4 - this is a not a hard requirement. The only requirement for identifying yourself as 2.0 is to send at least 1 'moni' as per the 2.0 format upon connection establishment.
一方、自分自身を2.0（またはそれ以降）として識別したいほとんどの実装は、T4にゼロ以外の値を使用することが期待されています - これは難しい要件ではありません。2.0として自分自身を識別するための唯一の要件は、接続確立時の2.0形式に従って少なくとも1つの「MONI」を送信することです。
Version 2.0 of the TALI specification does not introduce any new user events. The user events defined in Section 3.4 (mgmt open, mgmt close, mgmt allow, mgmt proh, connection established, connection lost) remain in effect.
TALI仕様のバージョン2.0では、新しいユーザーイベントは紹介されていません。セクション3.4で定義されているユーザーイベント（mgmt open、mgmt close、mgmt lock、mgmt proh、connectionの確立、接続が失われた）で定義されています。
Version 2.0 of the TALI specification does not introduce any new TALI states. The TALI states defined in Section 3.6 remain in effect.
TALI仕様のバージョン2.0では、新しいタリ州は紹介されていません。セクション3.6で定義されているタリ状態は引き続き有効です。
This section provides the state machine that must be followed by each TALI 2.0 implementation in order to be compliant with this specification. As mentioned throughout this document, a 2.0 implementation is based on several small additions to a 1.0 implementation and each 2.0 implementation must be willing to inter-operate in a backwards compatible mode (a 2.0 implementation connected to a 1.0 implementation must fall back to 1.0 features only).
このセクションでは、この仕様に準拠するためには、各TALI 2.0の実装が続く必要がある状態マシンを提供します。 このドキュメント全体で述べたように、2.0の実装は1.0実装へのいくつかの小さな追加に基づいており、各2.0実装は後方互換モード（1.0の実装に接続された2.0実装が1.0機能に戻る必要があります） のみ）。
Before presenting the actual state machine, several concepts are discussed.
実際の状態マシンを提示する前に、いくつかの概念について説明します。
A set of general protocol rules was presented in the 1.0 specification, in section 3.7.1.1; those rules are still applicable to 2.0 implementations. In addition to those earlier rules, the following rules are also applicable to 2.0 nodes:
一連の一般的なプロトコルルールは、セクション3.7.1.1の1.0仕様で提示されました。これらのルールは、2.0の実装にまだ適用されます。これらの以前のルールに加えて、次のルールは2.0ノードにも適用できます。
* A 2.0 implementation should identify the TALI version it has implemented via the 'moni' message
* 2.0実装は、「モニ」メッセージを介して実装したタリバージョンを識別する必要があります
* A 2.0 implementation should process any received 'moni' messages, attempting to determine the TALI version of the far end. A 2.0 implementation must use an internal flag, such as 'far_end_version', to track the TALI version that the far end of the connection has implemented. The 'far_end_version' flag should be initialized to version 1.0.
* 2.0の実装では、受信した「モニ」メッセージを処理し、ファーエンドのタリバージョンを決定しようとする必要があります。2.0の実装では、「FAR_END_Version」などの内部フラグを使用して、接続の遠端が実装したTALIバージョンを追跡する必要があります。'far_end_version'フラグは、バージョン1.0に初期化する必要があります。
* A 2.0 implementation should reject/ignore internal requests (from software layers in it's own product, or requests from the management interface for the device) to send TALI messages that require 2.0 opcodes when the far end is a 1.0 implementation. A 2.0 implementation should only send TALI messages that require new 2.0 opcodes (mgmt, xsrv, spcl) when it knows the far end is capable of processing those opcodes (when 'far_end_version' is 2.0 or greater).
* 2.0の実装では、内部要求（独自の製品のソフトウェアレイヤー、またはデバイスの管理インターフェイスからの要求から）を拒否/無視する必要があります。2.0の実装では、遠端がそれらのオペコードを処理できることがわかっている場合（ 'far_end_version'が2.0以上）ことを知っている場合、新しい2.0オプコード（MGMT、XSRV、SPCL）を必要とするTALIメッセージのみを送信する必要があります。
* Upon receiving a TALI message with a 2.0 opcode, a 2.0 implementation should interrogate its 'far_end_flag'; if the far end is not 2.0 or greater, the arrival of the message should be treated as a Protocol Violation. If the far end is 2.0 or greater, the message should be processed according to the nodes 2.0 capabilities, or ignored (if the node has chosen not to implement any 2.0 functionalities).
* 2.0オプコードでTALIメッセージを受信すると、2.0の実装は「FAR_END_FLAG」を尋問する必要があります。遠端が2.0以上でない場合、メッセージの到着はプロトコル違反として扱う必要があります。遠端が2.0以上の場合、メッセージをノード2.0機能に従って処理するか、無視する必要があります（ノードが2.0機能を実装しないことを選択した場合）。
The steps to perform a graceful shutdown of each socket were presented in the 1.0 specification, in section 3.7.1.2. Those steps are not changed for 2.0 implementations.
各ソケットの優雅なシャットダウンを実行する手順は、セクション3.7.1.2の1.0仕様で提示されました。これらの手順は、2.0の実装では変更されません。
Each TALI implementation must detect when violations of the TALI protocol have occurred and react accordingly. Protocol violations include:
各タリの実装は、タリプロトコルの違反が発生したときに検出し、それに応じて反応する必要があります。プロトコル違反は次のとおりです。
* Invalid sync code in a received message
* 受信したメッセージ内の無効な同期コード
* Invalid opcode in a received message
* 受信したメッセージ内のOpCodeが無効です
* Invalid length field in a received message
* 受信したメッセージ内の無効な長さフィールド
* Not receiving an 'allo' or 'proh', in response to the origination of a 'test' , before the T2 timer expires
* T2タイマーが期限切れになる前に、「テスト」の起源に応じて、「Allo」または「Proh」を受け取っていない
* Receiving Service Messages on a prohibited socket.
* 禁止されているソケットでサービスメッセージを受信します。
* TCP Socket errors - Connection Lost
* TCPソケットエラー - 接続が失われました
* Receiving a TALI message with a 2.0 opcode ('mgmt', 'xsrv', ' spcl') from a far end that has not identified itself as a 2.0 implementation.
* 2.0の実装とは識別されていない遠端から2.0オペコード（ 'mgmt'、 'xsrv'、 'spcl'）でタリメッセージを受信します。
In the state machine that follows, State/Event combinations that should be treated as protocol violations are indicated via a 'PV' in the state/event cell. All of the 'PV' events are then processed as per the 'Protocol Violation' row in the table.
次の状態マシンでは、プロトコル違反として扱う必要がある状態/イベントの組み合わせは、州/イベントセルの「PV」を介して示されています。すべての「PV」イベントは、テーブルの「プロトコル違反」行に従って処理されます。
Internal Data required for State Machine:
状態マシンに必要な内部データ：
* boolean sock_allowed. This flag indicate whether the NE is allowed to carry Service Messages.
* boolean sock_allowed。このフラグは、NEがサービスメッセージを伝達することを許可されているかどうかを示します。
* Far_end_version. This enumeration should track the TALI version of the far end of the socket.
* far_end_version。この列挙は、ソケットの遠端のタリ版を追跡する必要があります。
Initial Conditions: sock_allowed = FALSE far_end_version = 1.0 state = OOS no timers running
初期条件：sock_allowed = fals far_end_version = 1.0 state = oosタイマーなし実行
+------------------------------------------------------------------+
| State| OOS |Connecting| NEP-FEP | NEP-FEA | NEA-FEP | NEA-FEA |
|Event | | | | | | |
+------------------------------------------------------------------+
|T1 Exp. | | |Send test|Send test|Send test|Send test|
| | | |Start T1 |Start T1 |Start T1 |Start T1 |
| | | |Start T2 |Start T2 |Start T2 |Start T2 |
+------------------------------------------------------------------+
|T2 Exp. | | | PV | PV | PV | PV |
+------------------------------------------------------------------+
|T3 Exp. | | | PV | PV | | |
+------------------------------------------------------------------+
|T4 Exp. | | |Send moni|Send moni|Send moni|Send moni|
| | | |Start T4 |Start T4 |Start T4 |Start T4 |
+------------------------------------------------------------------+
|Rcv test| | |Send proh|Send proh|Send allo|Send allo|
+------------------------------------------------------------------+
|Rcv allo| | | Stop T2 | Stop T2 | Stop T2 | Stop T2 |
| | | | NEP-FEA | | NEA-FEA | |
+------------------------------------------------------------------+
|Rcv proh| | | Stop T2 | Stop T2 | Stop T2 | Stop T2 |
| | | |Send proa|Send proa|Send proa|Flush or |
| | | | | NEP-FEP | | reroute |
| | | | | | |Send proa|
| | | | | | | NEA-FEP |
+------------------------------------------------------------------+
|Rcv proa| | | Stop T3 | Stop T3 | | |
+------------------------------------------------------------------+
|Rcv moni| | |Update |Update |Update |Update |
| | | |'far end |'far end |'far end |'far end |
| | | |version' |version' |version' |version' |
| | | |based on |based on |based on |based on |
| | | |moni |moni |moni |moni |
| | | |Convert |Convert |Convert |Convert |
| | | | to mona | to mona | to mona | to mona |
| | | |Send mona|Send mona|Send mona|Send mona|
+------------------------------------------------------------------+
|Rcv mona| | |Implemen-|Implemen-|Implemen-|Implemen-|
| | | |tation |tation |tation |tation |
| | | |dependent|dependent|dependent|dependent|
+------------------------------------------------------------------+
|Rcv | | | PV |If T3 run| PV |Process |
| Service| | | | Process | | |
| | | | |Else PV | | |
+------------------------------------------------------------------+
|Rcv mgmt| | |If FE< |If FE< |If FE< |If FE< |
| | | | 2.0 PV | 2.0 PV | 2.0 PV | 2.0 PV |
| | | |Else |Else |Else |Else |
| | | | Process | Process | Process | Process |
+------------------------------------------------------------------+
|Rcv xsrv| | |If FE< |If FE< |If FE< |If FE< |
| | | | 2.0 PV | 2.0 PV | 2.0 PV | 2.0 PV |
| | | |Else |Else |Else |Else |
| | | | Process | Process | Process | Process |
+------------------------------------------------------------------+
|Rcv spcl| | |If FE< |If FE< |If FE< |If FE< |
| | | | 2.0 PV | 2.0 PV | 2.0 PV | 2.0 PV |
| | | |Else |Else |Else |Else |
| | | | Process | Process | Process | Process |
+------------------------------------------------------------------+
|Connect.| | Start T1 | | | | |
|Estab. | | Start T2 | | | | |
| | | Start T4 | | | | |
| | |(if non-0)| | | | |
| | |if sock_ | | | | |
| | | allowed | | | | |
| | | = TRUE | | | | |
| | | send allo| | | | |
| | | send test| | | | |
| | | NEA-FEP | | | | |
| | |else | | | | |
| | | send proh| | | | |
| | | send test| | | | |
| | | NEP-FEP | | | | |
+------------------------------------------------------------------+
|Connect.| | | PV | PV | PV | PV |
|Lost | | | | | | |
+------------------------------------------------------------------+
|Protocol| | |Stop all |Stop all |Stop all |Stop all |
|Violat. | | | timers | timers | timers | timers |
| | | |Close the|Close the|Close the|Close the|
| | | | socket | socket | socket | socket |
| | | |Connect- |Connect- |Connect- |Connect- |
| | | | ing | ing | ing | ing |
+------------------------------------------------------------------+
|Mgmt. |Open | | | | | |
|Open |socket| | | | | |
|Socket |Conne-| | | | | |
| | cting| | | | | |
+------------------------------------------------------------------+
|Mgmt. | |Close the |Stop all |Stop all |Stop all |Stop all |
|Close | | socket | timers | timers | timers | timers |
|Socket | |OOS |Close the|Close the|Close the|Close the|
| | | | socket | socket | socket | socket |
| | | |OOS |OOS |OOS |OOS |
+------------------------------------------------------------------+
|Mgmt. |sock_ |sock_allo-|sock_all-|sock_all-|sock_all-|sock_all-|
|Prohibit|allow-| wed=FALSE| owed= | owed= | owed= | owed= |
|Socket |ed = | | FALSE | FALSE | FALSE | FALSE |
| |FALSE | | | |send proh|send proh|
| | | | | |start t3 |start t3 |
| | | | | | NEP-FEP | NEP-FEA |
| | | | | | | |
+------------------------------------------------------------------+
|Mgmt. |sock_ |sock_allo-|sock_all-|sock_all-|sock_all-|sock_all-|
|Allow |allow-| wed=TRUE | owed= | owed= | owed= | owed= |
|Traffic |ed = | | TRUE | FALSE | TRUE | TRUE |
| |TRUE | |send allo|send allo| | |
| | | | NEA-FEP | NEA-FEA | | |
+------------------------------------------------------------------+
|User |reject| reject | reject | reject | reject | send |
|Part |data | data | data | data | data | data |
|Msgs. | | | | | | |
+------------------------------------------------------------------+
|Request | | |If FE<2.0|If FE<2.0|If FE<2.0|If FE<2.0|
|to Tx | | | Ignore | Ignore | Ignore | Ignore |
|mgmt | | |Else |Else |Else |Else |
| | | | Process | Process | Process | Process |
+------------------------------------------------------------------+
|Request | | |If FE<2.0|If FE<2.0|If FE<2.0|If FE<2.0|
|to Tx | | | Ignore | Ignore | Ignore | Ignore |
|xsrv | | |Else |Else |Else |Else |
| | | | Process | Process | Process | Process |
+------------------------------------------------------------------+
|Request | | |If FE<2.0|If FE<2.0|If FE<2.0|If FE<2.0|
|to Tx | | | Ignore | Ignore | Ignore | Ignore |
|spcl | | |Else |Else |Else |Else |
| | | | Process | Process | Process | Process |
+------------------------------------------------------------------+
Table 29: TALI 2.0 State Machine
表29：TALI 2.0状態マシン
Several limitations with the TALI 2.0 specification are identified. These are considered possible areas for expansion of the protocol in the future:
TALI 2.0仕様のいくつかの制限が特定されています。これらは、将来のプロトコルの拡張のための可能な領域と見なされます。
* Support for different types of routing keys is limited. It is envisioned that new routing key types will need to be added and supported as new applications are identified.
* さまざまなタイプのルーティングキーのサポートは限られています。新しいルーティングキータイプを追加してサポートする必要があると想定されています。新しいアプリケーションが特定されているため、サポートする必要があります。
* An opcode, or new primitive within an existing opcode, could be added as a means of returning unknown or unsupported data to the sender. In addition to discarding and storing internal debug data, an implementation may want to return the original TALI message to the sender when the receiver of the message deems the message to be unknown, unsupported, or incorrectly formatted.
* 既存のオペコード内のオペコード、または新しいプリミティブは、未知のデータまたはサポートされていないデータを送信者に返す手段として追加できます。内部デバッグデータの破棄と保存に加えて、実装は、メッセージの受信者がメッセージを不明、サポートなし、または誤ってフォーマットしていると見なす場合に、元のTALIメッセージを送信者に返すことをお勧めします。
The following list provides all the known success/failure codes that are being used for the rkrp feature. New defines will be added to the end of the list as they are identified.
次のリストは、RKRP機能に使用されているすべての既知の成功/失敗コードを提供します。新しい定義は、識別されるようにリストの最後に追加されます。
Error # Meaning
1 Transaction successfully completed.
2 Length of TALI msg is insufficient to contain all
required information for rkrp operation
3 Unsupported 'rkrp' operation
4 Invalid SI. SI must be in range 0..15
5 Invalid SI/operation combination. Split and resize only
supported for SI=4,5,13. Enter, delete and override
supported for all SI.
6 Invalid DPC. Point code cannot be zero, and must be full
point code.
7 Invalid SSN. SSN must be in range 0..255.
8 Invalid OPC. Point code cannot be zero, and must be full
point code.
9 Invalid CICS. Must be in range appropriate for SI and PC
type.
10 Invalid CICE. Must be in range appropriate for SI and PC
type.
11 Invalid CIC range. CICS must be less than or equal to
CICE. On a split operation, CICS must be strictly less
than than CICE (cannot split an range with only one
entry).
12 Invalid NCICS. Must be in range appropriate for SI and
PC type.
13 Invalid NCICE. Must be in range appropriate for SI and PC type. 14 Invalid new CIC range. NCICS must be less than or equal to NCICE. 15 Invalid SPLIT value. Must be in range appropriate for SI and PC type. Must be greater than CICS and less than or equal to CICE. 16 No free entries in table. 17 CIC range overlaps but does not match existing entry. 18 Entry already has 16 associations. 19 Entry to be changed not found in table. 20 New entry would overlap another entry (allowed to overlap the entry being changed, but no others). 21 Entry to be deleted not found in table. 22 TUP routing keys are not supported for ANSI networks
13無効なNCICE。 SIおよびPCタイプに適した範囲でなければなりません。 14無効な新しいCIC範囲。 NCICSはNCICE以下でなければなりません。 15無効な分割値。 SIおよびPCタイプに適した範囲でなければなりません。 CICよりも大きく、CICE以下でなければなりません。 16表に無料のエントリはありません。 17 CIC範囲が重なりますが、既存のエントリと一致しません。 18エントリにはすでに16の関連付けがあります。 19変更されるエントリは、表にありません。 20新しいエントリは別のエントリを重複させます（変更中のエントリと重複することは許可されますが、他のエントリはありません）。 21削除されるエントリは表にありません。 22 TupルーティングキーはANSIネットワークにはサポートされていません
TALI is an interface for the transport of SS7 traffic and management messages across an IP network. As with traditional PSTN networks, the IP networks using TALI are expected to well engineered systems. The use of virtual private networks and firewalls is to be expected. In addition, the use of IPSEC will bring added security benefit to the network.
Taliは、IPネットワーク全体でSS7トラフィックと管理メッセージを輸送するためのインターフェイスです。従来のPSTNネットワークと同様に、TALIを使用したIPネットワークは、十分に設計されたシステムが予想されます。仮想プライベートネットワークとファイアウォールの使用が予想されます。さらに、IPSECを使用すると、ネットワークに追加のセキュリティ便益がもたらされます。
[1] Bell Communications Research, Specification of Signaling System Number 7, GT-246-CORE, Bellcore, Issue 1, December 1994.
[1] Bell Communications Research、Signaling System Number 7、GT-246-Core、Bellcore、Issue 1、1994年12月。
[2] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[2] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[3] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[3] Postel、J。、「インターネットコントロールメッセージプロトコル」、STD 5、RFC 792、1981年9月。
[4] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[4] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[5] Logical Link Control, IEEE 802.2 and ISO 8802.2
[5] 論理リンク制御、IEEE 802.2およびISO 8802.2
[6] Carrier Sense Multiple Access with Collision Detection (Ethernet), IEEE 802.3 and ISO 8802-3 CSMA/CD.
[6] キャリアには、衝突検出（イーサネット）、IEEE 802.3およびISO 8802-3 CSMA/CDによる複数のアクセスが検出されます。
[7] Virtual LAN, IEEE 802.1 Q and ISO 8802-1Q CSMA/CD.
[7] 仮想LAN、IEEE 802.1 QおよびISO 8802-1Q CSMA/CD。
[8] Bell Communications Research, Generic Requirements for CCS Nodes Supporting ATM High-Speed Signaling Links (HSLs), GR-2878-CORE, Issue 1, Bellcore, November 1995.
[8] Bell Communications Research、ATM高速シグナリングリンク（HSLS）、GR-2878-CORE、Issue 1、Bellcore、1995年11月をサポートするCCSノードの一般的な要件。
[9] Bell Communications Research, Asynchronous Transfer Mode (ATM) and ATM Adaptation Layer (AAL) Protocols, GR-1113-CORE, Bellcore.
[9] Bell Communications Research、非同期転送モード（ATM）およびATM適応層（AAL）プロトコル、GR-1113コア、ベルコア。
[10] American National Standards Institute, B-ISDN Signaling ATM Adaptation Layer - Service Specific Connection Oriented Protocol (SSCOP), T1.637.
[10] American National Standards Institute、B -ISDNシグナル伝達ATM適応層 - サービス固有の接続指向プロトコル（SSCOP）、T1.637。
[11] American National Standards Institute, B-ISDN Signaling ATM Adaptation Layer - Service Specific Coordination Function for Support of Signaling at the Network Node Interface (SSCF at the NNI), T1.645.
[11] American National Standards Institute、B -ISDNシグナル伝達ATM適応層 - ネットワークノードインターフェイス（NNIのSSCF）でのシグナリングのサポートのためのサービス固有の調整機能、T1.645。
[12] American National Standards Institute, B-ISDN Signaling ATM Adaptation Layer - Layer Management for the SAAL at the NNI, T1.652.
[12] American National Standards Institute、B -ISDN Signaling ATM適応層 - NNIのSAALのレイヤー管理、T1.652。
The authors would like to thank Ken Morneault for his comments and contributions to the document.
著者は、Ken Morneaultのコメントと文書への貢献について感謝したいと思います。
David Sprague Tekelec 5200 Paramount Pkwy. Morrisville, NC 27560 Phone: +1 919-460-5563 EMail: david.sprague@tekelec.com
David Sprague Tekelec 5200 Paramount Pkwy。ノースカロライナ州モリスビル27560電話：1 919-460-5563メール：David.sprague@tekelec.com
Dan Brendes Tekelec 5200 Paramount Pkwy. Morrisville, NC 27560 Phone: +1 919-460-2162 EMail: dan.brendes@tekelec.com
Dan Brendes Tekelec 5200 Paramount Pkwy。 ノースカロライナ州モリスビル27560電話：1 919-460-2162メール：dan.brendes@tekelec.com
Robby Benedyk Tekelec 5200 Paramount Pkwy. Morrisville, NC 27560 Phone: +1 919-460-5533 EMail: robby.benedyk@tekelec.com
Robby Benedyk Tekelec 5200 Paramount Pkwy。 ノースカロライナ州モリスビル27560電話：1 919-460-5533メール：robby.benedyk@tekelec.com
Joe Keller Tekelec 5200 Paramount Pkwy. Morrisville, NC 27560 Phone: +1 919-460-5549 EMail: joe.keller@tekelec.com
Joe Keller Tekelec 5200 Paramount Pkwy。ノースカロライナ州モリスビル27560電話：1 919-460-5549メール：joe.keller@tekelec.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。