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
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.
著作権（C）インターネット協会（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.
この文書では、回線交換ネットワーク（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.
交通アダプター層インタフェース（TALI）は、TCP / IP上でTCAP（トランザクション機能アプリケーションパート）、ISUP（ISDNユーザ部）、およびMTP（メール転送プロトコル）メッセージングを提供して提唱しているインタフェースです。また、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
SAAL層13 2.3.2アン代替TALIプロトコルスタックを使用してTALIプロトコル1.はじめに4 2.概要6つの2.1伝統的なPSTN SS7ネットワーク6つの2.2コンバージドSS7ネットワーク8 2.3 TALIプロトコルスタックの概要10 2.3.1アン代替TALIプロトコルスタックSCTPを使用してTALIバージョンへ15の2.4インプット1.0ステートマシン15 3. TALIバージョン1.0 17 3.1 TALIメッセージ構造の概要TALIフィールズの17 3.1.1タイプ19 3.2詳細なTALIメッセージ構造20 3.2.1 TALIはメッセージ20をピアツーピア3.2.1.1テスト・メッセージ（テスト）20 3.2.1.2メッセージ（アロ）21 3.2.1.3メッセージ（PrOH中）を禁止21 3.2.1.4確認応答メッセージ（のProA）21 3.2.1.5モニタメッセージ（MONI）22 3.2.1.6モニタを禁止許可（モナ）22の3.2.2サービスメッセージメッセージをアクノリッジ23 3.2.2.1 SCCPメッセージサービス（SCCP）23 3.2.2.1.1 SCCP封入使用TALI 25 3.2.2.2 ISUPサービスメッセージ（ISOT）27 3.2.2.2.1 ISUPカプセル化使用TALI 27 3.2.2.3 MTP3サービスメッセージ（MTP3）TALI 29 3.2を使用して28 3.2.2.3.1 MTP3カプセル化.2.4（SAAL）30 3.2.2.4.1 MTP3とSAALピアSAALサービスメッセージTALI 31 3.3 TALIタイマ34 3.3.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その他の実装に依存TALIのイベント37 3.6 TALI州37件の3.7 TALIバージョン1.0ステートマシン38の3.7.1ステートマシンの概念38 3.7.1.1一般的なプロトコルルールソケットの38 3.7.1.2正常なシャットダウン39 3.7.1.3 TALIプロトコル違反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
3.7.2ステートマシン40 3.8 TALI 1.0実装では、TCP上でTCP上/ IPソケット42 3.8.2混雑/ IPソケットTALIの43 3.9 TALI 1.0制限事項43 4. TALIバージョン2.0 43 4.1概要42 3.8.1失敗ノートバージョン2.0の特長45 4.2 TALIバージョンの識別47の4.3後方互換性50 4.3.1受信したメッセージに基づいて生成プロトコル違反TALIメッセージ構造の53 4.4概要TALIフィールドの55 4.4.1タイプ55の4.5詳細なTALIメッセージ構造の新しい2.0オペコード58 4.5.1マネジメントメッセージ（MGMT）60 4.5.1.1ルーティングキー登録プリミティブ（rkrp）すべてrKRPメッセージ65 4.5.1.1.1.2 CICベースルーティングキーで61の4.5.1.1.1 rKRPデータ構造65の4.5.1.1.1.1共通のフィールド複数のRKRP登録操作のための操作67 4.5.1.1.1.3 SCCPのルーティングのキー操作71 4.5.1.1.1.4 DPC-SI、DPCおよびSIルーティングキー操作ベース74 4.5.1.1.1.5デフォルトルーティングキー操作76 4.5.1.1.1.6サポート78件の4.5.1.1.1.6.1複数の登録は78 4.5.1.1.1.6をサポートしていますシングルメッセージ80 4.5.1.2 MTP3プリミティブ（MTPP）82 4.5.1.3ソケットオプション登録プリミティブ（SORP）87 4.5.2拡張サービスメッセージ（xsrv）で0.2複数RKRP運用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タイマ95 4.7 TALIユーザーイベント95の4.8 TALI州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 TALIプロトコル違反97 4.9.2ステートマシン97 4.10 TALI 2.0仕様の制限101 5.成功/失敗コード101の6.セキュリティ上の考慮事項102 7.参考文献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
- 文書の紹介 - TALIプロトコルの概要 - TALIバージョン1.0 - TALIバージョン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）可END：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.
メディアゲートウェイ（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.
メディアゲートウェイコントローラ（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：32ビットCICコードの代わりに14/12ビット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.
シグナリングATMアダプテーションレイヤ（SAAL）：GR-2878-COREに記載されているように、この層は、SS7トラフィックを運ぶATM高速リンクのMTP-2のと等価である[8]。 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).
ゲートウェイ（SG）をシグナリング：SGは、受信シグナリングエージェントである/ IPネットワークのエッジでSCNネイティブシグナリングを送信します。 SG機能は、リレー翻訳又はSS7-インターネットゲートウェイにSS7シグナリングを終了することができます。 SG機能は、MGによって制御されるラインまたはトランク終端に関連付けられたSCNシグナリング（例えば、バックホールシグナリング）を処理するためにMGC / MG機能と共存してもよいです。
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であることT1.645によって定義される：ネットワークノードインタフェース（NNIでSSCF）でシグナリングをサポートするための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.
回線交換ネットワーク（SCN）：用語SCNは、事前定義されたサイズのチャネル化ベアラ内のトラフィックを搬送するネットワークを指すために使用されます。例としては、公衆交換電話網（のPSTN）と公衆陸上モバイルネットワーク（PLMNのを）スイッチがあります。 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
- インシーケンス配信 - フロー制御 - エラー検出/訂正 - Keep Aliveを - ローカルデータ取得 - 接続制御 - プロトコルエラー検出と回復
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音声ネットワークへのインターフェースを含みます。
* 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ネットワーク管理機能を提供することです。 STPはまた時々、このようなグローバルタイトル翻訳とローカルナンバーポータビリティなどのデータベースタイプのサービスを提供します。
* 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の高速リンク。これらのリンクは、新しい、より高速な技術に基づいて56KbpsのSS7リンクの代替を提供するために、SAALプロトコルを使用しています。 [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デバイスは、と（IPプロトコルに基づいてイーサネットリンクとの）IPネットワーク上で（56 KbpsのとDS1リンク専用有する）従来のPSTNネットワークの両方に存在するであろう。 SSP、STPを、とのSCPのサービスは、IPネットワーク上に存在するデバイスの新しいタイプによって提供することができます。ネットワークの2つのタイプのデバイスが互いに通信し、他の1つの下位層プロトコルへ変換することができなければならない、むしろIPネットワークは、完全にPSTNを交換することを意図していません。
Signaling Gateways are new devices that may also function as an STP in the converged network. SGs provide interfaces to:
シグナリングゲートウェイはまた、統合ネットワークにおけるSTPとして機能することができる新しいデバイスです。 SGSがへのインタフェースを提供します。
* devices on the SCN (traditional SSPs, STPs, and SCPs)
* SCN上のデバイス（伝統のSSP、STPを、とのSCP）
* 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.
*メディアゲートウェイ。他の機能に加えて、これらのデバイスは、電話コールを運ぶために使用される音声回路を制御します。 MGの+のMGCは、従来のSSPの機能性を提供するために組み合わせます。
* IP based SCPs. The database services that are related to SS7 can be moved onto devices on the IP network.
* IPベースのSCP。 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プロトコルはTCP / IPを越えSS7トラフィックを運ぶために2つのノード間で使用することができます。 TALIを使用することができる領域の一部を以下に示します。
- 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横切るMGCの通信にSGについて - - その他の場合 - 複数のMGCとの間の通信のための - - のMGCとMGの間の通信のための複数のIPベースのSCPとの間の通信のために - IP横切ってIPベースのSCPへの通信SGについてIP横切るSG通信にSGについてなどDNS、ポリシーサーバ、などのIPデバイス
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
- MGCへの通信のためにSG - - IPベースのSCPへの通信のためにSG SG通信にSGについて
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は、SS7側とSGのIP側の両方にSS7 MSUの輸送に使用されるプロトコルスタックを強調簡単図を提供します。
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：TALIプロトコルTCP / IP上でSS7を運ぶために
From Figure 3, several observations can be made:
図3からは、いくつかの観察を行うことができます。
* The TALI layer is used when transferring SS7 over IP.
IP上でSS7を転送するとき* TALI層が使用されています。
* 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.
* TALI層は、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.
* TALI層は、種々の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:
TALIは、図3から明らかでないことどのように機能するかを理解するのに重要なTALIプロトコルに関する事実の一部は、次のものがあります。
* 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標準バークレーソケットインタフェースは、エンドポイントをピア・ツーエンドポイントから接続指向サービスを提供するために、TALI層で使用されます。
* 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接続の一端は、「サーバー側」として定義されている必要があり、もう一方の端には、「クライアント」です。
* 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
*各TALI接続が行われる際に、ユーザが制御できます
* Allows the user to control when each TALI connection is allowed to carry SS7 traffic
*各TALI接続は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メッセージをピアツーピア提供します。これらのメッセージは、接続の一方のエンドポイントのTALI層に由来し、他のエンドポイントのTALI層で終端されています。メッセージをピアツーピア使用されます。
* 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は、サービスのメッセージを提供します。これらのメッセージは、接続の一方のエンドポイントのTALI層以上の層を起源とに転送され、他の終点のTALI層以上の層で終端されています。
* 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メッセージがカプセル化された正確にどのようにTALIソケットを介して通信するために使用されています。
* A set of TALI timers is defined. These timers are used to correctly implement the TALI state machine.
* TALIタイマーのセットが定義されます。これらのタイマーは正しくTALIのステートマシンを実装するために使用されています。
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.
このセクションでは、前のセクションで、プロトコルスタックの代わりに使用することができます異なる、少し複雑な、TALIプロトコルスタックを示しています。
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は、56のSGのSS7側KbpsのリンクとIPデバイスとの間のSS7のMSUを輸送するために使用することができる基本的な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.
TALIプロトコルスタックは、図3のように、SAAL層なしで実施された場合*、SS7 MSUのシーケンス番号は、TCP / IP接続を介して転送されるデータの一部ではありません。 56 KbpsのSS7リンクでは、MTP2ヘッダーは各MSUのための8ビットのシーケンス番号を含みます。シーケンス番号は、メッセージの順序付けを維持するために、リンクの切り替えと切戻MSU中の検索を含む複雑なSS7手順をサポートするために使用されます。図3に示すように、MTP2ヘッダはTCP / IP接続を介して転送されるデータの一部ではありません。 SAAL無しTALIプロトコルスタックは、まだ（この配列決定は、TCP層においてシーケンス番号により提供される）SS7データの正しい順序付けを保証し、しかしそのプロトコルスタックは、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.
TALIプロトコルスタックは、図4のように、SAAL層で実装されている場合*、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.
*したがって、SS7 CO / CBおよびデータ検索のためのサポートを提供し、SS7リンクが非アクティブ化されるMSUの損失を最小限に抑えるのを助けることができるSAALとTALIプロトコルを実装します。しかし、実装SAALは些細な問題ではありません。 SAAL層3つの副層（SSCF、SSCOP、およびMAAL）から成り、（SSCOP）の一つは、非常に複雑です。 TCP / IPアプリケーションに最もSS7は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プロトコルは、その下に信頼性の高いトランスポート層に依存しています。 TALIの初期設計では、TCPは信頼性の高い、実績のあるトランスポート層でした。単純な制御転送プロトコル（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ステートマシンに影響を与えるの入力を示しています。ステートマシンへの入力は、次のとおりです。
* 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.
* TALIメッセージがピアから受信しました。これらのメッセージは、メッセージをピア・ツー・ピアだけでなく、サービス・データ・メッセージが含まれます。
* 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.
* TALI層のユーザーからのイベント。ユーザは、SS7またはSAAL層のいずれかのプロトコルスタックのTALI上の層です。
* Implementation Dependent Events. Each implementation must provide inputs into the TALI state machine such as:
*実装依存のイベント。各実装は、このようなTALI州のマシンへの入力を提供する必要があります。
* Socket Events
*ソケットのイベント
* TALI protocol violations. The TALI state machine must detect protocol violations and act accordingly.
* TALIプロトコル違反。 TALI州のマシンは、プロトコル違反を検出し、それに応じて行動しなければなりません。
* 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：TALI 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オペコードのためのLENGTHフィールドの有効な値を示します。 LENGTHフィールドは、常に一般的な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.
いくつかのフィールドタイプは、一般的なTALIメッセージ構造で使用されています。
+------------------------------------------------------------------+
|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：TALIフィールドの各タイプの実装ノート
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ピアに関するより多くの情報を提供しています。 TALIメッセージはソケット接続の1つの端（近端）のTALI層で発生し、接続の遠端のTALI層で終端されているピアツーピア。
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.
「試験」メッセージは、SS7サービスデータを運ぶためにリモートエンドの意欲に対するTALI接続の遠隔端を照会するTALI実装によって使用されます。このメッセージは、もう一方の端を尋ねる：あなたは、サービス・データを伝送する準備ができていますか？このメッセージは、T1タイマー間隔に基づいて、各TALI実装によって定期的に送信されます。 「テスト」を受信すると、TALI実装は、TALI接続を介してSS7サービスデータを搬送するノードの意思を示すために「PrOH中」または「同種」のいずれかで応答しなければなりません。
+------------------------------------------------------------------+
| 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.
「アロ」というメッセージをTALI実装がTALIセッションを介してSS7サービスデータを運ぶために喜んでであることを示すために、または、いくつかの内部実装のイベントに応答して「試験」のクエリへの応答で送信されます。このメッセージは、SS7トラフィックがソケット上で送信することができる遠端に通知します。 「アロ」「テスト」メッセージに2つの可能な応答の一つです。 SS7トラフィックがソケット上で行うことができる前に、接続の両端には、「アロ」メッセージを送信する必要があります。
+------------------------------------------------------------------+
| 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.
「prohで」メッセージがTALI実装がTALIセッションを介してSS7サービスデータを運ぶことを望んでいないことを示すために、または、いくつかの内部実装のイベントに応答して「試験」のクエリへの応答で送信されます。このメッセージは、SS7トラフィックがソケット上で送信することができない遠端に通知します。 「PrOHでは、「テスト」メッセージに2つの可能な応答の一つです。限り接続の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」メッセージは、TALI実装によって「PrOHを」が遠端から受信されるたびに送信されます。このメッセージは、彼の「禁止」のメッセージが正しく受信されたし、それに応じて作用を受けることになる遠端に示すために送信されます。
+------------------------------------------------------------------+
| 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.
「MONI」というメッセージは、その実装が適していると決めるよう各TALI実装で使用できる汎用のECHO機能を提供します。 TALIバージョン1.0の実装は、1.0仕様に準拠している「MONI」というメッセージを発信する必要はありません。このメッセージの主な目的は、TALI層がソケットに往復メッセージ転送時間をテストするための方法を提供することです。 「モナ」メッセージが受信された各「MONI」メッセージへの応答で送信されなければなりません。 「MONI」メッセージのデータ部分は、ベンダの実装依存です。各「モナ」の回答のデータ部分は、正確に答えている「MONI」のデータ部分を一致させる必要があります。かかわらず、実装が「MONI」か、「モナ」を送信することを選択したかどうかのTALIプロトコルに準拠したままにするために、各「MONI」に応答して送信されなければなりません。
+------------------------------------------------------------------+
| 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.
上述したように、「モナ」は、それぞれ受信「MONI」に応答して送信されなければなりません。 「モナ」データ領域の内容は、受け取った「MONI」というメッセージのデータ領域と一致する必要があります。
+------------------------------------------------------------------+
| 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のMSUを運ぶために使用されています。このセクションの情報は、TCP / IPにSS7のMSUをカプセル化する方法に関する詳細を含むTALIサービスオペコードの各々を使用してフレーム。 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のMSUを送達するために使用されます。このオペコードは、唯一のSAALせずに実装されているTALIプロトコルスタック上で使用されています。 SS7 MSUのMTP3層は、このオペコードのためにTCP / IPを介して転送されるデータの一部ではありません。 TALI「SCCP」メッセージのデータ部分（MTP3ルーティングラベル後）SS7 MSUでSCCPデータ領域の最初のバイトから始まります。 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メッセージは、「SCCP」というメッセージとしてTCP / IP接続を介して転送されるためには「発信者」エリアでポイントコードが含まれている必要があります。実装は、必要に応じて、TALI間で伝送する前に、適切な発信者ポイントコードを追加して、元のSCCP MSUを変更することもできます。
* 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メッセージは、「SCCP」というメッセージとしてTCP / IP接続を介して転送されるために 'と呼ばれるパーティーエリアでポイントコードが含まれている必要があります。実装は、必要に応じて、TALI渡って、送信する前に適切な着信側のポイントコードを追加して、元のSCCP MSUを変更することもできます。
* 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.
* SS7 SCCP MSUの符号化に、それらはTALIを介して「SCCP」を介して送信されるように、それぞれのメッセージの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：SCCPサブシステムの管理IPベースのSCPのがこの「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
* SCCP層の被呼者アドレスフィールドに、MTPレイヤ3からDPCを配置します。コーリングパーティアドレスフィールドが存在しない場合は作成され、満たされています
* 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
何のコーリングパーティポイントコードが存在しない場合* SCCP層のコーリングパーティアドレスフィールドに、MTPレイヤ3から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
* SYNCフィールドが設定されています
* The OPCODE is set to 'sccp'
* OPCODEは、「SCCP」に設定されています
* The LENGTH is set to the number of octets in the SERVICE field
* LENGTHはSERVICEフィールドのオクテット数に設定されています
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」を使用してSCCP MSUのカプセル化オペコード
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
* TALIヘッダを検証
* 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
*サービスインジケータSCCPに設定し、全国ネットワーク、ゼロ（0）の優先順位を設定サブサービス分野で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
*パーティーポイントコードと呼ばSCCPにDPCを設定し、
* sets the OPC to the SCCP Calling Party Point Code
*パーティーポイントコードを呼び出すSCCPにOPCを設定します
* 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のMSUを配信するために使用されます。このオペコードは、唯一の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 MSUが56 Kbps以上DS1リンクからSGに到達するとIPデバイスにSG内でルーティングされた場合、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
* TALIパケットのSERVICEペイロード領域にMTPレイヤ3を配置
* The SYNC field is set
* SYNCフィールドが設定されています
* The OPCODE is set to 'isot'
* OPCODEを「ISOT」に設定されています
* The LENGTH is set to the number of octets in the SERVICE field
* LENGTHはSERVICEフィールドのオクテット数に設定されています
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.
完全に形成された「ISOT」TALIパケットが作成されると、それは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」を使用してISUP MSUのカプセル化オペコード
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
* TALIヘッダを検証
* 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」オペコードは、TALI接続を介して0-2のサービスインジケータ、4、6-15（非SCCP、非ISUP）とSS7のMSUを送達するために使用されます。このオペコードは、唯一の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とSS7 MSU = 0-2,4,6-15 56 Kbps以上DS1リンクからSGに到達するとIPデバイスにSG内でルーティングされた場合、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
* TALIパケットのSERVICEペイロード領域にMTPレイヤ3を配置
* The SYNC field is set
* SYNCフィールドが設定されています
* The OPCODE is set to 'mtp3'
* OPCODEを「MTP3」に設定されています
* The LENGTH is set to the number of octets in the SERVICE field
* LENGTHはSERVICEフィールドのオクテット数に設定されています
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'
図8：SIとのSS7 MSUのカプセル化= 3,5,13 '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
* TALIヘッダを検証
* 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のMSUを配信するために使用されます。このオペコードは、唯一のSAALで実装されているTALIプロトコルスタック上で使用されています。 「SAAL」オペコードもTALI接続を介して（SSCFはSS7サービスデータ以外のパケットをピアにパケットとSSCOPピアのピアツーピア）パケットをピア・ツーSAALピアを送信するために使用されます。
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のMSUを転送するために使用される場合、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:
（任意のSIを有する）SS7 MSUが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はSSCFとSSCOP層（SAAL層）にMTP3処理ソフトウェアレイヤから渡されます。これらの層は、SSCOP PDUにSS7 MSUに変換します。この変換の一部は、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にSAALメッセージまたはSS7 MSUピア・ツー・ピアであるか否か）TALIパケットのSERVICEペイロード領域にコピーされます
* The SYNC field is set
* SYNCフィールドが設定されています
* The OPCODE is set to 'saal'
* OPCODEを「SAAL」に設定されています
* The LENGTH is set to the number of octets in the SERVICE field
* LENGTHはSERVICEフィールドのオクテット数に設定されています
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」TALIパケットが作成されると、それは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」オペコードを使用して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:
「SAAL」TALIパケットがIP装置からSGで受信されると、SG「はSAAL」パケットに以下の処理を行います。
* validates the TALI header
* TALIヘッダを検証
* 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状態機械の一部として使用される4つのTALIタイマーを定義しました。これらのタイマーを総称して「T4」から「T1」と命名されています。各タイマの簡単な説明は以下のサブセクションで提供されています。 T1-T4タイマーのそれぞれについてタイマ満了イベントは、TALI状態マシンへの入力として現れます。各タイマの正確な処理のために（起動するときに/タイマーの満了を処理する方法、停止）、TALI状態機械を指します。
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.
TALI接続の両端が自身の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タイマは、ピアが「テスト」に応じて「同種」または「PrOHを」を返却しなければならない時間の量を表します。遠端がT2の有効期限が切れる前に「アロ」または「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への遷移は、（のみ遠いサービスデータを送信するために喜んで終了）が発生したときにこのタイマーが使用されます。その移行で、遠端がそのTALI州のマシンを調整し、離れてこのソケットからのサービスデータトラフィックをそらすためにある程度の時間が必要であることを期待するのは合理的です。 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実装における「MONI」メッセージの発信元との間の時間間隔を表します。 T4の有効期限が切れるたびに、TALI実装は、「MONI」を送信する必要があります。
The following table provides the recommended default and configurable range for each TALI timer.
次の表は、各TALIタイマの推奨デフォルトと設定可能な範囲を提供します。
+------------------------------------------------------------------+
|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の値は、少なくとも一つ（1）T2より大きくをミリ秒でなければなりません。これは、T1期限切れの状態でロックアップからシステムを防ぐためです。 T1は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州のマシンの挙動に比べていくつかのユーザイベント制御を提供する必要があります。これらの機能を提供するためのユーザーインターフェイスは実装固有のものです。
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近いソケット」イベントに「MGMTオープンソケット」イベントは、それぞれがTCPソケット接続を形成するTALI接続を定義したとき、ユーザが制御することを可能にします。特定の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()
In general, TALI servers form socket connections by using the BSD sockets calls:
一般的には、TALIサーバは、BSDソケット呼び出しを使用してソケット接続を形成します：
Socket()
Bind()
Listen()
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.
TALIソケットのTCPソケットは、直ちに閉じ、またはピアに接続するための試行を中止することが望まれる場合「MGMT近いソケット」イベントは、ユーザによって発行することができます。 「MGMTオープンソケット」が発行されるまで「近いソケット」に作用した後、TALI接続が確立されることはありません。
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.
各々がTALI接続がその特定のTALI接続を介してSS7サービスデータを運ぶために喜んであろう定義されたときに一緒に「MGMTトラフィックを禁止する」イベントと、イベント「MGMTトラフィックを許可」、ユーザが制御することを可能にします。発行された「MGMTトラフィックを許可する」とき、TALI実装は、サービスデータを運ぶために喜んでなります。接続がすでに確立されている場合は近端のための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サービスデータを運ぶために非喜んでなり。接続がすでに確立されている場合は近端のためのTALI状態は、（端部近傍禁止）NEPに移行すべきです。
In addition to timers, each TALI implementation needs to be able to detect, and react accordingly, for the following events:
タイマーに加えて、各TALI実装は、以下のイベントのために、検出し、それに応じて反応することができる必要があります。
* Connection Established. When the TCP socket connection is initially established the TALI state machine must be notified.
* 接続が確立されました。 TCPソケット接続が最初に確立されるとTALI州のマシンに通知しなければなりません。
* 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州のマシンに通知しなければなりません。
* Protocol Violations. Any violation of the TALI protocol as discussed in 3.7.1.3.
*プロトコル違反。 3.7.1.3で論じたようにTALIプロトコルのいずれかの違反。
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つのTALI状態を考慮したステートマシンに基づいています。 TALI接続の各端部は、独自のTALI状態を維持します。
+------------------------------------------------------------------+
| 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：TALI州
This section provides the state machine that must be followed by each TALI implementation in order to be compliant with this specification.
このセクションでは、この仕様に準拠するために、各TALI実装が続かなければならない状態マシンを提供します。
Before presenting the actual state machine, several concepts are discussed.
実際のステートマシンを提示する前に、いくつかの概念が議論されています。
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'.
NEX-FEX状態間の3状態の変化は、「同種」または「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は、必ず再起動する必要があります。
8. A far end signals the last service PDU has been transmitted with either a 'proh' or a 'proa'.
8. A遠端はPDUが「prohで」または「のProA」のいずれかで送信された最後のサービスを知らせます。
9. Upon receiving a 'proh', the receiver must always reply with 'proa'.
「prohで」を受信すると9は、受信機は常に「のProA」で返信する必要があります。
10. The NE cannot gracefully close a socket unless a 'proh' is sent and 'proa' is received.
「prohで」が送信されると「のProA」が受信されない限り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.
NEAからNEPへの移行11.は、「prohで」を送信した後、近端は「の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.管理は管理がソケット上のトラフィックのイベントを禁止発行します。
Each TALI implementation must detect when violations of the TALI protocol have occurred and react accordingly. Protocol violations include:
各TALI実装はTALIプロトコルの違反が発生したときを検出し、それに応じて反応しなければなりません。プロトコル違反は、次のとおりです。
* Invalid sync code in a received message
*受信したメッセージに無効な同期コード
* Invalid opcode in a received message
*受信したメッセージに無効なオペコード
* 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タイマが満了する前に*、「試験」の発信に応じて、「アロ」または「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.
ブールsock_allowed。このフラグは、NEは、サービス・メッセージを運ぶために許可されているかどうかを示します。
Initial Conditions: sock_allowed = FALSE state = OOS no timers running
初期条件：sock_allowed = FALSE状態= 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実装のいくつかの態様は、具体的ステートマシンまたは前のテキストで扱われていない（または他のそれらが発表されましたが、ここでは繰り返されます）。いくつかのケースでは、これらの実装ノートはTALI層上のソフトウェア層の正常な動作を行う必要があります。
* 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.
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のオペコードを導入することにより、提供されています。基本的な機能と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
* TALI実装が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:
1.0 TALI実装に対する変更の小さな数は2.0をサポートするために必要とされます。図10は、2.0 TALIステートマシンに影響を与えるの入力を示しています。読者は、次のように1.0の入力との相違点であることに気づくことができます。
Three new TALI opcodes can be sent/received between a TALI node and its peer. The new opcodes are:
三の新しいTALIオペコードは、TALIノードとそのピアとの間で受信/送信することができます。新しいオペコードは以下のとおりです。
* '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.
三つの新しいユーザ部の機能は、各実装でTALI層上記のコードの層によってサポートされる必要があります。ユーザ部分は、「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」 - このオペコードは、デバイスの動作を管理します管理データ、またはデータが、TALIエンドポイント間を通過できるように意図されます。この管理データの例としては、
* 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.
このようなポイントコード（UN）の可用性と渋滞に関する情報など* SS7ネットワーク管理データ、。
* 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サービスデータオペコード（「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' - 特別なサービスを提供しています。ベンダーが実装は同じ特別なサービスを実装する他の機器に接続されている場合にのみ起動される彼らのTALI実装に特別なサービスを構築したい得ることが想定されます。このオペコードは、TALIセッションが接続されている方に関するより多くの情報を発見するための一般的な手段、および遠端でのベンダー/実装に基づいて特別な機能を有効にするための手段を提供することを意図しています。
+====+ +---------+ +============+
| | | 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:
「MONI」というメッセージが非常に緩く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.
*「MONI」というメッセージの主な目的は、汎用のECHO機能を提供することでした。これは、ECHO能力が提供できる重要なタスクは、ラウンドトリップTALI / TALI処理時間を測定することであろうと想定されました。
* The data portion of the 'moni' message could be from 0-200 bytes long. The use of the data area was completely implementation specific.
*「MONI」メッセージのデータ部分は、0~200バイト長であってもよいです。データ領域の使用が完全に実装特異的でした。
* There were no requirements that an implementation ever send a 'moni'.
*実装は、これまで「MONI」を送って何の要件はありませんでした。
* If an implementation did send 'moni', it should use the T4 timer to control the frequency of the outgoing 'moni'.
*実装は「MONI」を送っていた場合、それは、発信「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.
*「MONI」の受信機は、「MONI」のデータ部分についてどのような仮定を行うべきではありません。受信機は、単に「モナ」に「MONI」を変換し、同一のデータ部分とメッセージを返すべきです。
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:
*「MONI」というメッセージの主な目的は、今二つあります。
* 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.
*往復時間を測定したり、他の実装特定のタスクを実行するために使用することができる汎用のECHO機能を提供し続けること。
* The data portion of the 'moni' message is now divided into 2 portions
*「MONI」メッセージのデータ部分は、現在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.
*「MONI」のデータ部の全体の長さは依然として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すべての「MONI」は、表8から変更しないでくださいバージョンラベルにエンコーディングに従わなければならない送信ごとにエンコードされた「MONI」を送信する必要があります'MONI' から 'MONI'。バージョンラベルを以下のデータは「MONI」から「MONI」から変更することができますし、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を実装している場合、実装は任意の遠端から到着「MONI」メッセージを受信調べる必要があり、彼らは新しい、より厳しい「MONI」に準拠するかどうかを決定しようとしている場合「MONI」を受信すると、表8にエンコード、TALI 2.0ノードは、それが接続されているTALIノードの機能性を決定するために、予め定められた文字列のリストをVERラベルフィールド内のデータの12のバイトを比較します。データが所定の文字列のいずれかに一致しない場合は、遠端は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.
*各TALI実装は、到着した「MONI」は遠端がTALIバージョン2.0をサポートしていることを発表するまで、接続の遠端が1.0実装であることを前提としなければなりません。 「MONI」は決して到着しない場合、実装は、遠端が仕様のバージョン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の実装は、新たにエンコードされた「MONI」メッセージを受信し、単にデータを無視することができます。 1.0実装では、遠端が常に1.0ノード（「MONI」のデータ部分を無視する「モナ」に「MONI」を変換し、「モナ」を返す）であるかのように動作し続けます。
* 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：バージョン管理「MONI」メッセージ
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 = 002.000タリバージョン1.0 =タリバージョン2.0 //この仕様。 002.001 =タリバージョン2.1 2.0 003.000に//マイナーチェンジ=タリバージョン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.
バージョン1.0にTALIバージョン2.0から互換性後方、TALI仕様に新しい機能を追加することの一部として必要とされます。 TALI 2.0ノードははるかのみバージョン1.0をサポートしている端部に接続することができるので、後方互換性が重要です。これらの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実装が「MONI」は2.0ノードとして自身を識別するために送信し、それはMONI」を使用する方法が遠端も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」でTALIメッセージを受信TALI 1.0実装、および「SPCL」オペコードは、（無効オペコードを受信）プロトコル違反としてメッセージを扱います。プロトコル違反は、ソケットがすぐにドロップされることになります。
* 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（またはそれ以降）であることを決定するために、受信した「MONI」メッセージを使用した後に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の実装は、前のセクションで説明したように2.0として自分自身を識別するために、「MONI」を使用しなければならない、と遠端が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 '変数を更新する必要があります。 「MONI」はバージョンラベルが含まれていなかった場合は、「far_end_versionは」1.0にリセットする必要があります。 「MONI」は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メッセージは、プロトコル違反（無効オペコード）として扱われるべきです。 「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オペコードとTALIメッセージは、遠端に送信することができます。
* 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メッセージを受信し、新しいオペコードを認識し、状態マシンに影響を与えることなく、メッセージを無視することができることです。 TALI状態は変更しないでください。ソケット接続は存続すべきです。言い換えると、2.0の実装は、その実装がその特定のオペコードが意図した機能をサポートするために気にしない場合は、任意の受信「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オペコードとメッセージの長さフィールドの後に続く余分な「プリミティブ」フィールドで構成されています。各「プリミティブは」オペコードの変種を区別するために使用されます。より多くの機能がオペコードのために定義されているように、それぞれの新しい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 TALIオペコードのための基本的なメッセージ構造
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の前に弾丸の一部によって暗示されるように、受信したTALIメッセージの処理に関連するエラーチェックの一部を緩和する2.0 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は、各受信したメッセージをチェックしたフィールドを詳細に非常に厳しかったです。各受信されたメッセージが処理されたように、メッセージのSYNCコード、オペコードおよび長さフィールドをチェックしました。これらのフィールドのいずれかが無効であれば内部のプロトコル違反が発生しました。プロトコル違反の処理は、ソケットがダウンしていました。 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白金符号の支持体としてではなく、ITUの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）とのメッセージのためのオペコードフィールドに対するチェックは、メッセージが実装によって処理することができるかどうかを決定するために行われるべきです。実装は、特定2.0オペコードをサポートしないことを選択した場合、受信したメッセージは破棄されるべきである（例えば、測定、メッセージのログ、ユーザ通知など）の内部データは、イベントを記録することができ、及びTALI状態は影響されないはずです。
* 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）とのメッセージのためのプリミティブフィールドに対するチェックは、メッセージが実装によって処理することができるかどうかを決定するために行われるべきです。実装は、特定のプリミティブを理解していない、または特定のプリミティブのための機能を実装しないことを選択した、受信されたメッセージを破棄しなければならない場合、（例えば、測定、メッセージのログ、ユーザ通知など）の内部データは、イベントを記録することができ、そしてTALI状態は影響を受けません。
* 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オペコードとメッセージの他のフィールドタイプに対するチェックも「ソフト」な方法で実行されなければなりません。個々のフィールドで見つかったエラーが受信されたメッセージが破棄させなければならない、（このような測定、メッセージのログ、ユーザ通知など）の内部データは、イベントを記録でき、TALI状態は影響を受けません。
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.
その他の機能/拡張/などに関連した不正な形式/サポートされていないTALIメッセージにもかかわらず、：*接続（SS7データを転送するために継続するIE）の主な目的を実行するために、ソケットを維持するために。
* 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.
*プロトコルの拡張性を高めるために。緩いチェックはそれらが定義されているように、新しいプリミティブと新しい基本操作を追加することができるようにするために好ましい受けます。
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に記載されているように、ベースTALIヘッダーは依然として、SYNC + OPCODE + LENGTHから成ります。
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オペコードのメッセージ構造は、これらのメッセージは、表2のLENGTHフィールドに続くPRIMITIVE余分必須フィールドを定義する表9に示しました。
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で定義されたオペコードのためのメッセージ構造は、「MONI」というメッセージを除いて、先に提示された情報から変更されていません。 「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は、各新しいオペコード（ならびに「MONI /モナ」）のためにサポートしなければならないLENGTHフィールドの最小値と最大値を提供します。表11は、さらに、2.0で追加されたITUサポートの影響を示しています。 ANSIは、必要に応じてITUポイントコードのルーティングラベルは、4つのオクテットの代わりに7つのオクテットを使用します。
+------------------------------------------------------------------+
| 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：TALI 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の状態のいずれかで受信し、処理することができます。三つのプリミティブはこのオペコードで使用するために定義されています。
* '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トラフィックは、彼らが各ソケットの上に受け取りたいというストリームを構成することができます。この「ルーティングキー登録には」TALIメッセージを介して、帯域内で行われます。
* '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」オペコードのためのメッセージ構造
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（5）タイプをサポートしています。この文書では、以前の議論からリコール：
* A key for SCCP traffic, where key = DPC-SI-SSN, where SI=3.
SI = 3で、キー= DPC-SI-SSN、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.
* SIは5 = ISUPトラフィック、キー= DPC-SI-OPC-CICの範囲、のためのキー。伝統的な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.
* SIが4 = TUPトラフィック、キー= DPC-SI-OPC-CICの範囲、のためのキー。このキーは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.
* SIは13 = QBICCトラフィック（32ビットCICコードを使用ISUPの拡張）、=キーDPC-SI-OPC-CICのためのキー。 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、非ISUPのための非QBICC、非QBICC、ITUのための非TUP）トラフィック、キー= 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）、OTHER-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.
* DELETE：削除操作が特定のソケットと特定のアプリケーション・ルーティング・キーとの間の関連付けを削除します。関連のソケットは、常に「rkrp」が受信されたソケットです。同じアプリケーションルーティングキーのための他のソケットの関連付けが削除によって影響を受けません。ルーティングキーの最後のソケットの関連付けが削除されると、全体のルーティングキーのエントリは、データベースから削除されます。 DELETEオペレーション動作は、完全に指定されたSCCPキー、CICベースのキー（ISUP、Q.BICC、およびTUP）、OTHER-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.
* SPLIT：SPLIT動作は一緒に元の鍵と同じSS7トラフィックストリームを覆うキーをルーティング2アプリケーションに単一のアプリケーション・ルーティング・キーを変換するために使用されます。分割が行われた直後に、得られたエントリの両方は、元のルーティングキーと同じソケットの関連付けを保持します。分割が完了すると、ソケットの関連付けは、他の範囲の独立2つの得られた範囲のそれぞれについて変更することができます。分割操作は、完全CICベースのキー（ISUP、QBICC、およびTUP）を指定するためにのみ適用可能です。それぞれ完全に指定CICベースのキーを一意DPC / SI / OPC / CIC範囲の組み合わせによって識別されます。 CIC範囲はCICE（端部）にCICS（開始）から数字の連続集合です。アプリケーションルーティングキーの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).
* RESIZE：RESIZE動作はCICを修正するために使用されるキーをルーティングする単一のアプリケーションのために及びます。サイズ変更操作は、完全に指定されたCICベースのルーティングキーにのみ適用可能です。サイズ変更操作は、新しいCIC範囲（NCICS / NCICE）とルーティングキーのCICS / CICE値を置き換えます。 NCICS / NCICEの多種多様な既存のCICS / CICEに基づいてサポートすることができます範囲。ちょうど約唯一の制限は、新しい範囲が既にデータベースに存在することはできませんし、データベース内の他のエントリを重複しないことです。ルーティングキーのためのソケットの関連付けがCICS / CICEの変化による影響を受けません。 SPLIT動作は、完全に指定された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
0x000B - OTHER-MTP3-SI KEY 0x000Cを入力 - OTHER-MTP3-SI KEY 0x000Dを削除 - TUPキーを削除する（ITUのみ）0x000F - - SPLIT TUP KEY（のみITU）0x0010 - TUP KEY（ITUのみ）0x000EをENTER TUP KEYをリサイズ（ITUのみ）0x0011 - 部分鍵0x0012 DPC-SI-OPCを入力 - PARTIAL KEY 0x0013 DPC-SI-OPCを削除 - DPC-SI部分鍵0x0014を入力 - DPC-SI部分鍵の0x0015を削除 - DPC部分鍵0x0016を入力 - DPCをDELETE PARTIAL KEY 0x0017 - SI部分キーの0x0018をENTER - DELETE SI PARTIAL KEY 0x0019 - DEFAULT 0x001AをENTER - デフォルトのキー0x001Bを削除 - 複数の登録SUPPORT
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メッセージのバイト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：ALL「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が基づいているのMSUに関連する「rkrp」メッセージ（ISUP、Q.BICC ISUP、TUP及びのみ（ITU））に使用されるデータ構造です。表12に示すようなデータ構造は、以下のTALIメッセージのバイト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から14ビットCICの値を使用することが想定される（ITUネットワークで使用される12ビット）ANSIネットワークを示します。 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（ignoreCIC）を指定するために使用されるべきです。 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.
以下の表は、必須（R）、またはNot RKRPオペレーションフィールドに基づいて、表15のメッセージデータ構造の各フィールドに対して適用（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メッセージのバイト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.
以下の表は、必須（R）、またはNot RKRPオペレーションフィールドに基づいて、表17のメッセージデータ構造の各フィールドに対して適用（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（非SCCP、非CICベースのトラフィックの完全なキー、またはベースCICまたはSCCPのための部分的なキーのいずれか）、DPCベースの（部分鍵）、およびSi系に関する「rkrp」メッセージのために使用されるデータ構造（部分鍵）の操作次の表に示す通りです。表12に示すようなデータ構造は、以下のTALIメッセージのバイト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.
以下の表は、必須（R）、またはNot RKRPオペレーションフィールドに基づいて、表19のメッセージデータ構造の各フィールドに対して適用（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メッセージのバイト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.
以下の表は、必須（R）、またはNot RKRPオペレーションフィールドに基づいて、表21のメッセージデータ構造の各フィールドに対して適用（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メッセージ（オペコードが=「MGMT」、プリミティブ=「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メッセージのバイト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）、またはNot上記メッセージデータ構造の各フィールドに対して適用（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操作をサポートすることを決定するために、複数の登録・サポート操作を使用した後、この機能を使用したいデバイスは、1つの以上の登録要求/メッセージごとに応答の送信を開始することができます。各操作は直接TALIメッセージの前の操作に追従するようにこれを行うには、（表12に提示）「MGMT」オペコードのための基本的なメッセージ構造を拡張することができます。次のようになります3つのRKRP操作とTALIメッセージを示す例：
+------------------------------------------------------------------+
| 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ごとに複数の登録」を使用して、ノードは、遠端デバイスが機能をサポートしていることを確認しなければならないことを改めて表明しなければなりません。これを確認するための唯一の方法は、成功した複数の登録サポートリクエストを送信し、複数の登録SUPPORT応答を受信することです。
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 SNM（シグナリングネットワーク管理）従来のSS7ネットワークでのMSUとして符号化されるTFP / TFA（転送禁止転送可）、TFC（転送混雑）およびRCT（経路輻輳テスト）メッセージのような情報を提供します。 「MTP3プリミティブ」は、このステータス情報は、IPノードに、TALIメッセージを介して、インバンド転送することを可能にします。
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.
*ポイントコードUNAVAILABLE：このプリミティブ操作は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.
* POINTのCODE AVAILABLE：このプリミティブ操作はSS7ポイントコードが利用可能であることを発表しました（すなわち：SGは、先のトラフィックを送信するために利用できるSOMEルートを持っています）。 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.
*ポイントコードSTATUSの要求：このプリミティブ操作は、特定の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.
* CLUSTER UNAVAILABLE：このプリミティブ操作はSS7ポイントコードの全体のクラスタと発表しました（exは：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.
* AVAILABLE CLUSTER：このプリミティブ操作は、クラスタ内の少なくとも1 SS7ポイントコードが利用可能であることを発表しました（すなわち：SGは、そのクラスタ内の宛先の少なくとも1のトラフィックを送信するために利用できるSOMEルートを持っています）。 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.
*混雑DESTINATION：このプリミティブ操作は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を生成し、要求に輻輳レベルに一致するように設定された優先度とルート輻輳試験（RCT）、SS7ネットワーク管理メッセージを送信します。 RCTは、SS7先に向けて送信されます。 SS7宛先が依然として輻輳している場合、RCTは、プリミティブ輻輳DESTINATIONに変換されたIPノードに送信されるSG、に戻って到着SS7転送制御（TFC）をもたらすであろう。
* 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.
* USER PART UNAVAILABLE：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メッセージのバイト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.
以下の表は、必須（R）、またはNot MTPPオペレーションフィールドに基づいて、表26のメッセージデータ構造の各フィールドに対して適用（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ノードに、TALIメッセージを介して、インバンド転送することができます。
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旗の設定/ wの返信を送信する必要があります。
* 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.
*有効/無効BROADCAST PHASE MTPPプリミティブ：ときSTPのSS7ルーティングテーブル内の宛先のポイントコードの可用性の変更従来のSTPは、隣接する全てのノードにブロードキャストフェーズのTFPとのTFAを送信します。これらのブロードキャストフェーズTFA / TFP SS7メッセージは、SGとしてSGノードによってTALIのMTPPプリミティブに変換されます。 ENABLE / DISABLE BROADCAST PHASE 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において、定義された各ソケットは、ソケットが接続FALSEたびに初期化されるフラグ、「enable_broadcast_phase_primitives」を有しています。 IPノードは、それが特定のソケットのために迷惑ステータス変更を受信したいことを発表するSGへのBROADCAST PHASEメッセージを有効操作を送信する必要があります。 SGとして放送相のTFAを/のTFPは、それがそのソケット上の各ソケットに対して「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.
* / DISABLE応答METHOD MTPPプリミティブをENABLE：STPは、宛先が利用できない場合、隣接ノードに語った、：隣接ノード、すなわち（配信することはできませんSTPへのMSUを送信し続けるとき、従来のSTPは、隣接ノードへの応答方法のTFPを送信しかし、隣接ノードはSTPにその使用不能DPC）宛てのトラフィックを送信し続けます。これらの応答メソッドのメッセージはSTPで受信されるのMSUに応答して送信されます。これらの応答メソッドTFPメッセージは、SGとしてSGノードによってTALIのMTPPプリミティブに変換されます。 ENABLE / DISABLE RESPONSE METHOD MTPP PRIMITIVESオプションは、各IPノードはIPノードはSS7応答方法メッセージに起因MTPPプリミティブを受信したいかどうかをリモートエンドに伝えることができます。応答方法のTFP、2つの他のSS7ネットワーク管理メッセージ、すなわちのTFC（転送制御）とUPUs（利用できないユーザ部）に加えて、この応答方法のグループに分類されます。 TFCとUPUsが原因IPノード（いくつかの目的地に向けてトラフィックを送信する）ことにより、前のアクションが戻っIPノードへの応答方法イベントを発生させたことに応答メソッドのTFPに似ています。応答方法のTFC / UPUsに対する応答方法のTFPとの間の主な違いは、後に（レスポンス方式のTFC / UPUsが複数のソケットに複製される必要があるかもしれない応答メソッドTFPは、プリミティブだけ元のソケットに送り返さMTPPに変換されることです応答メソッドイベントを発生させているソケット伝える方法がないので）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において、定義された各ソケットは、ソケットが接続FALSEたびに初期化されるフラグ、「enable_response_method_primitives」を有しています。 IPノードは、それが適切な場合、特定のソケットの応答方法のTFPを受信したいことを発表するSGにENABLE RESPONSE METHOD MTPP PRIMITIVES操作を送信する必要があります。 SGバックIPノードに（プリミティブMTPP換算）応答メソッドTFPを送信する前に、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.
* / DISABLE NORMALIZED SCCPをENABLE：TALIのバージョン1.0は、「SCCP」TALIオペコードはSGとIPノード間でSCCPのMSUを送信するために接続をポイントツーマルチポイントで使用されなければならないことを指定しました。 「SCCP」オペコードを使用する場合、元のSS7 MSUのMTP3ヘッダ部分はMSUから剥離し、TALI接続を介して送信されるデータの一部ではありませんでした。 「SCCP」TALIメッセージの送信者は、「SCCPとして送信する前に、（被呼/発呼者アドレスのPtコードフィールドに）メッセージのSCCP部分に適切なフィールドにMTP3ヘッダからDPC / OPCフィールドを複製するための責任がありました「オペコード。このオプションは、送信されたデータの一部としてMTP3ヘッダを含む接続をマルチするTALI点を横切ってSCCPのMSUを送信する方法を提供し、そして元のSS7 SCCP MSUへの変更を伴いません。 NORMALIZED SCCPプリミティブENABLEを受信した場合、SCCPのMSU「はMTP3」オペコードを使用TALIインタフェースを介して送信されるべきです。この送信は、全体MTP3ヘッダ+元MSUのSCCP部分を含むべきです。オリジナルのSS7 MSUのいかなる変更は発生しません。 DISABLE NORMALIZED SCCPは、プリミティブを受信したときTALIのバージョン1.0で指定されるように、SCCPのMSUは「SCCP」オペコードを使用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.
* / DISABLE NORMALIZED ISUPをENABLE：TALIのバージョン1.0は、「ISOT」TALIオペコードはSGとIPノード間でISUPのMSUを送信するために接続をポイントツーマルチポイントで使用されなければならないことを指定しました。 MTP3ヘッダー部分を含む「ISOT」オペコード、元のSS7 MSUを使用する場合、「ISOT」TALIメッセージで送信されました。このオプションは、遠端が「ISOT」オペコードとは対照的に、「MTP3」TALIのオペコードを使用してISUPのMSUを受け取ることを好むことを示しています。オプションが有効になっている場合、「MTP3」オペコードは、TALI接続を介して、MTP3ヘッダーを含む、ISUPのMSUを送信するために使用されます。オプションを無効にすると、「ISOT」オペコードはTALIリリース1.0のように使用されています。
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メッセージのバイト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」、オペコードは、（「SCCP」、「ISOT」、「MTP3」、及び「SAAL」を越えて）サービストラフィックの他の種類を輸送する手段を提供するための基礎を築くためにTALI 2.0プロトコルに追加されそれぞれの新しいサービスの種類が識別され、追加される新しいオペコードを定義することなく、このプロトコルの将来の改訂です。彼らが追加されるPRIMITIVEフィールドは一意に、それぞれの新しいサービスの種類を識別します。いくつかの他の「xsrv」メッセージはNEA-FEA状態のみを受信して処理することができるが、そのようなバージョンでは、サービスデータとして（いくつかの「xsrv」メッセージはTALI NEX-FEX状態のいずれかで受信して処理することができることが想定されますTALIの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」は、オペコードは、ベンダーが実装が同じ特別なサービスを実装する他の機器に接続されている場合にのみ起動される彼らのTALI実装に特別なサービスを構築するための方法を提供するためにTALI 2.0プロトコルに追加されます。 「SPCL」メッセージはTALI NEX-FEXの状態のいずれかで受信し、処理することができます。このオペコードは、TALIセッションが接続されている方に関するより多くの情報を発見するために、一般的な手段を提供すること、および遠端でのベンダー/実装に基づいて特別な機能を有効にするための手段を提供することを意図しています。
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.
追加のプリミティブはTALIプロトコルの将来のバージョンで追加することができます。
+------------------------------------------------------------------+
| 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.
このメッセージは、PRIMITIVE「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'.
このメッセージは、接続の遠端を照会するために送信することができます（すなわち：VENDOR、TALIのバージョン、またはその他の機能についての詳細な情報を検索してみてください）。それぞれ2.0実装が「rply」で「qury」に応えることが期待されます。
+------------------------------------------------------------------+
| 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は」（「rplyが」のみ「qury」への応答で送信されなければならないのに対し）2.0実装することにより、いつでも送信することができます。
+------------------------------------------------------------------+
| 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.
、それはほとんどの実装は、T4のために非ゼロ値を使用する（またはそれ以降）2.0として自分自身を識別するために望むことが予想されるが - これはハード要件ではありません。 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オープン、MGMTクローズは、MGMTは、MGMT prohで、接続を確立できるように、接続が失われた）有効なまま。
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は、新しいTALI状態を導入しません。セクション3.6で定義されたTALI状態は有効なまま。
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機能にフォールバックする必要があり1.0実装に接続された相互運用下位互換性モード（2.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実装は、それが「MONI」メッセージを介して実装されたTALIバージョンを識別すべきです
* 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実装では、任意のは、遠端のTALIのバージョンを確認しようと、「MONI」メッセージを受信処理する必要があります。 2.0実装では、接続の遠端が実装しているTALIバージョンを追跡するために、このような「far_end_version」として、内部フラグを使用しなければなりません。 「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実装では、遠端が1.0実装のとき2.0オペコードを必要とTALIメッセージを送信するために（ソフトウェアそれ自身の製品でレイヤー、またはデバイスの管理インターフェイスからの要求から）内部要求を無視/拒否すべきです。 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:
各TALI実装はTALIプロトコルの違反が発生したときを検出し、それに応じて反応しなければなりません。プロトコル違反は、次のとおりです。
* Invalid sync code in a received message
*受信したメッセージに無効な同期コード
* Invalid opcode in a received message
*受信したメッセージに無効なオペコード
* 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タイマが満了する前に*、「試験」の発信に応じて、「アロ」または「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」）とTALIメッセージを受信します。
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.
*ブールsock_allowed。このフラグは、NEは、サービス・メッセージを運ぶために許可されているかどうかを示します。
* Far_end_version. This enumeration should track the TALI version of the far end of the socket.
* Far_end_version。この列挙体は、ソケットの遠端のTALIバージョンを追跡する必要があります。
Initial Conditions: sock_allowed = FALSE far_end_version = 1.0 state = OOS no timers running
初期条件：sock_allowed = FALSE far_end_version = 1.0状態= 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.
1つのトランザクションを意味エラー＃が正常に完了しました。 TALIのMSGの2の長さはrkrp操作3サポートされていない「rkrp」操作4無効SIに必要なすべての情報を含むのには不十分です。 SIは範囲0..15 5無効SI /操作の組み合わせでなければなりません。スプリットのみSI = 4,5,13のためのサポートのサイズを変更します。入力し、削除して、すべてのSIのためにサポートされ上書きされます。 6無効DPC。ポイントコードをゼロにすることはできない、とフルポイントコードでなければなりません。 7無効なSSN。 SSNは0〜255の範囲でなければなりません。 8無効なOPC。ポイントコードをゼロにすることはできない、とフルポイントコードでなければなりません。 9無効なCICS。範囲にSIおよびPCタイプに適している必要があります。 10無効CICE。範囲にSIおよびPCタイプに適している必要があります。 11無効CIC範囲。 CICSはCICE以下でなければなりません。分割操作では、CICSはCICE（一つだけのエントリを持つ範囲を分割することはできません）よりもより厳密に小さくなければなりません。 12無効なNCICS。範囲にSIおよびPCタイプに適している必要があります。
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無効なSPLIT値。範囲にSIおよびPCタイプに適している必要があります。 CICEにCICSより大きく以下でなければなりません。 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]ベルコミュニケーションズリサーチ、シグナリングシステムナンバー7の仕様、GT-246-CORE、ベルコア、1号、1994年12月。
[2] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[2]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[3] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[3]ポステル、J.、 "インターネット制御メッセージプロトコル"、STD 5、RFC 792、1981年9月。
[4] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[4]ポステル、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.
衝突検出（イーサネット）、IEEE 802.3およびISO 8802-3 CSMA / CDと[6]搬送波感知多重アクセス。
[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]ベルコミュニケーションズリサーチ、ATM高速信号リンク（HSLS）、GR-2878-CORE、1号、Bellcoreの、1995年11月支えるCCSノードの汎用要件。
[9] Bell Communications Research, Asynchronous Transfer Mode (ATM) and ATM Adaptation Layer (AAL) Protocols, GR-1113-CORE, Bellcore.
[9]ベル通信研究所、非同期転送モード（ATM）及びATMアダプテーションレイヤ（AAL）プロトコル、GR-1113-CORE、ベルコア。
[10] American National Standards Institute, B-ISDN Signaling ATM Adaptation Layer - Service Specific Connection Oriented Protocol (SSCOP), T1.637.
[10]米国規格協会、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.
ネットワークノードインタフェース（NNIのSSCF）、T1.645でシグナリングの支援のためのサービス依存コーディネーション機能 - [11]米国規格協会、B-ISDNシグナリングATMアダプテーションレイヤ。
[12] American National Standards Institute, B-ISDN Signaling ATM Adaptation Layer - Layer Management for the SAAL at the NNI, T1.652.
[12]米国規格協会、B-ISDNシグナリングATMアダプテーションレイヤ - NNI、T1.652でSAALのためのレイヤ管理。
The authors would like to thank Ken Morneault for his comments and contributions to the document.
作者は彼のコメントや文書への貢献のためにケンMorneaultに感謝したいと思います。
David Sprague Tekelec 5200 Paramount Pkwy. Morrisville, NC 27560 Phone: +1 919-460-5563 EMail: david.sprague@tekelec.com
デビッド・スプラーグTekelec 5200パラマウントパークウェイ。モリスビル、NC 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
ダンBrendes Tekelec 5200パラマウントパークウェイ。モリスビル、NC 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
ロビーBenedyk Tekelec 5200パラマウントパークウェイ。モリスビル、NC 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
ジョー・ケラーTekelec 5200パラマウントパークウェイ。モリスビル、NC 27560電話：+1 919-460-5549電子メール：joe.keller@tekelec.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。