[要約] 要約：RFC 3423は、XACCTのCRANEプロトコル仕様のバージョン1.0を定義しています。 目的：CRANEプロトコルは、ネットワーク要素の信頼性のある会計情報の収集と伝送を可能にすることを目的としています。
Network Working Group K. Zhang
Request for Comments: 3423 E. Elkin
Category: Informational XACCT Technologies
November 2002
XACCT's Common Reliable Accounting for Network Element (CRANE) Protocol Specification Version 1.0
XACCTのネットワーク要素（クレーン）プロトコル仕様バージョン1.0の一般的な信頼できる会計
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 (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
Abstract
概要
This document defines the Common Reliable Accounting for Network Element (CRANE) protocol that enables efficient and reliable delivery of any data, mainly accounting data from Network Elements to any systems, such as mediation systems and Business Support Systems (BSS)/ Operations Support Systems (OSS). The protocol is developed to address the critical needs for exporting high volume of accounting data from NE's with efficient use of network, storage, and processing resources.
このドキュメントでは、主にネットワーク要素から任意のシステムへの会計データ、メディエーションシステムおよびビジネスサポートシステム（BSS）/オペレーションサポートシステム（オペレーションサポートシステムなどのデータの効率的かつ信頼できる配信を可能にするネットワーク要素（クレーン）プロトコルの共通の信頼できるアカウンティングを定義します。OSS）。このプロトコルは、ネットワーク、ストレージ、処理リソースを効率的に使用して、NEからの大量の会計データをエクスポートするための重要なニーズに対処するために開発されています。
This document specifies the architecture of the protocol and the message format, which MUST be supported by all CRANE protocol implementations.
このドキュメントは、プロトコルのアーキテクチャとメッセージ形式を指定します。これは、すべてのクレーンプロトコルの実装でサポートする必要があります。
Table of Contents
目次
1 Introduction...................................................2
1.1 Specification of Requirements.............................3
1.2 Terminology...............................................3
2 Protocol Overview..............................................5
2.1 CRANE Architecture........................................6
2.2 CRANE over TCP............................................7
2.3 Alternate servers.........................................7
2.4 Templates.................................................9
2.5 Template Transmission and Negotiation....................10
2.6 Changing Templates.......................................11
2.7 Flow Control.............................................12
2.8 The CRANE Client Query Messages..........................13
2.9 CRANE Sessions...........................................13
3 CRANE Message Format..........................................14
4 CRANE Messages................................................16
4.1 Flow Start (START).......................................16
4.2 Flow Start Acknowledge (START ACK).......................16
4.3 Flow Stop (STOP).........................................17
4.4 Flow Stop Acknowledge (STOP ACK).........................17
4.5 Connect (CONNECT)........................................18
4.6 Template Data (TMPL DATA)................................18
4.7 Template Data Acknowledge (TMPL DATA ACK)................23
4.8 Final Template Data (FINAL TMPL DATA)....................25
4.9 Final Template Data Acknowledge (FINAL TMPL DATA ACK)....26
4.10 Get Sessions (GET SESS).................................26
4.11 Get Sessions Response (GET SESS RSP)....................27
4.12 Get Templates (GET TMPL)................................30
4.13 Get Templates Response(GET TMPL RSP)....................30
4.14 Start Negotiation (START NEGOTIATE).....................33
4.15 Start Negotiation Acknowledge (START NEGOTIATE ACK).....34
4.16 Data (DATA).............................................34
4.17 Data Acknowledge (DATA ACK).............................36
4.18 Error (ERROR)...........................................37
4.19 Status Request (STATUS REQ).............................38
4.20 Status Response (STATUS RSP)............................38
5 Protocol Version Negotiation..................................39
6 Security Considerations.......................................42
7 References....................................................43
8 Acknowledgments...............................................43
9 Authors' Addresses............................................44
10 Full Copyright Statement......................................45
1 Introduction
1はじめに
Network Elements are often required to export usage information to mediation and business support systems (BSS) to facilitate accounting. Though there are several existing mechanisms for usage information export, they are becoming inadequate to support the evolving business requirements from service providers.
ネットワーク要素は、多くの場合、使用情報を調停およびビジネスサポートシステム（BSS）にエクスポートして、会計を促進する必要があります。使用情報のエクスポートにはいくつかの既存のメカニズムがありますが、サービスプロバイダーからの進化するビジネス要件をサポートするには不十分になっています。
For example, some of the export mechanisms are legacies of the Telco world. Typically usage information is stored in Network Elements as Log files (e.g., CDR files), and exported to external systems in batches. These are reliable methods, however, they do not meet the real-time and high-performance requirements of today's rapidly evolving data networks.
たとえば、輸出メカニズムの一部は、電話会社の世界の遺産です。通常、使用情報は、ネットワーク要素にログファイル（CDRファイルなど）として保存され、バッチ内の外部システムにエクスポートされます。これらは信頼できる方法ですが、今日の急速に進化するデータネットワークのリアルタイムおよび高性能要件を満たしていません。
RADIUS [1] is a widely deployed protocol that may be used for exporting usage information. However, it can only handle a few outstanding requests and is not extensible due to its limited command and attribute address space. RADIUS also does not support unsolicited messages from a server to a client. A detailed analysis of limitations of RADIUS can be found in [3].
RADIUS [1]は、使用情報のエクスポートに使用できる広く展開されているプロトコルです。ただし、いくつかの未解決のリクエストしか処理できず、コマンドと属性のアドレススペースが限られているため、拡張できません。RADIUSは、サーバーからクライアントへの未承諾メッセージもサポートしていません。半径の制限の詳細な分析は、[3]に記載されています。
DIAMETER [2] is a new AAA protocol that retains the basic RADIUS model, and eliminates several drawbacks in RADIUS. The current DIAMETER protocol and its extensions focus on Internet and wireless network access, and their support to accounting is closely associated with authentication/authorization events. DIAMETER is intended to solve many problems in the AAA area; by doing so, it does not adequately address some critical issues such as efficiency and performance in an accounting protocol.
直径[2]は、基本的な半径モデルを保持し、半径のいくつかの欠点を排除する新しいAAAプロトコルです。現在の直径プロトコルとその拡張機能は、インターネットとワイヤレスネットワークアクセスに焦点を当てており、会計へのサポートは認証/認証イベントと密接に関連しています。直径は、AAAエリアで多くの問題を解決することを目的としています。そうすることで、会計プロトコルの効率やパフォーマンスなど、いくつかの重要な問題に適切に対処しません。
There are also SNMP based mechanisms that generally require a large amount of processing and bandwidth resources.
また、一般に大量の処理と帯域幅のリソースを必要とするSNMPベースのメカニズムもあります。
Based on the above analysis, a critical need for a reliable, fast, efficient and flexible accounting protocol exists. The XACCT's CRANE protocol is designed to address these critical requirements.
上記の分析に基づいて、信頼性が高く、高速で、効率的で柔軟な会計プロトコルの重要なニーズが存在します。XACCTのクレーンプロトコルは、これらの重要な要件に対処するように設計されています。
This document defines the CRANE protocol that enables efficient and reliable delivery of any data, mainly accounting data from Network Elements to any systems, such as mediation systems and BSS/OSS. The protocol is developed to address the critical needs for exporting high volume of accounting data from NE's with efficient use of network, storage, and processing resources.
このドキュメントでは、主にネットワーク要素からメディエーションシステムやBSS/OSSなどのシステムへの会計データを効率的かつ信頼できる配信を可能にするクレーンプロトコルを定義します。このプロトコルは、ネットワーク、ストレージ、処理リソースを効率的に使用して、NEからの大量の会計データをエクスポートするための重要なニーズに対処するために開発されています。
This document specifies the architecture of the protocol and the message format, which MUST be supported by all CRANE protocol implementations.
このドキュメントは、プロトコルのアーキテクチャとメッセージ形式を指定します。これは、すべてのクレーンプロトコルの実装でサポートする必要があります。
In this document, the keywords "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are to be interpreted as described in BCP 14 [5]. These keywords are not case sensitive in this document.
このドキュメントでは、キーワードは「必要はありません」、「そうではない」、「そうは思わない」、「必要はない」、および「可能性」は、BCP 14 [5]で説明されているように解釈されるべきです。これらのキーワードは、このドキュメントではケースに敏感ではありません。
CRANE Protocol
クレーンプロトコル
CRANE stands for Common Reliable Accounting for Network Element. The CRANE Protocol maybe referred as CRANE, or the Protocol in this document. The CRANE Protocol is used at the interface(s) between a CRANE client and one or multiple CRANE servers for the purpose of delivering accounting data.
クレーンは、ネットワーク要素の一般的な信頼できる会計を表しています。クレーンプロトコルは、このドキュメントのクレーンまたはプロトコルと呼ばれる可能性があります。クレーンプロトコルは、会計データを配信する目的で、クレーンクライアントと1つまたは複数のクレーンサーバー間のインターフェイスで使用されます。
Client or CRANE Client
クライアントまたはクレーンクライアント
A CRANE Client is an implementation on the data producing side of the CRANE protocol. It is typically integrated with the network element's software, enabling it to collect and send out accounting data to a mediation/billing system using the protocol defined herein.
クレーンクライアントは、クレーンプロトコルの生成側のデータの実装です。通常、ネットワーク要素のソフトウェアと統合されているため、本明細書に定義されているプロトコルを使用して、会計データをメディエーション/請求システムに収集して送信できます。
Server or CRANE Server
サーバーまたはクレーンサーバー
A CRANE Server is an implementation on the data receiving side of the CRANE protocol. It is typically part of a Business Support System (BSS) (e.g., Billing, Market Analysis, Fraud detection, etc.), or a mediation system. There could be more than one CRANE server connected to one CRANE client to improve robustness of the usage information export system.
クレーンサーバーは、クレーンプロトコルの受信側のデータの実装です。通常、ビジネスサポートシステム（BSS）（請求、市場分析、詐欺検出など）または調停システムの一部です。使用情報エクスポートシステムの堅牢性を向上させるために、1つのクレーンクライアントに接続された複数のクレーンサーバーがある可能性があります。
CRANE Session
クレーンセッション
A CRANE Session is a logical connection between a CRANE client and one or multiple CRANE servers for the purpose of delivering accounting data. Multiple sessions MAY be maintained concurrently in a CRANE client or a CRANE server; they are distinguished by Session IDs.
クレーンセッションは、会計データを提供する目的で、クレーンクライアントと1つまたは複数のクレーンサーバーとの間の論理的な接続です。複数のセッションは、クレーンクライアントまたはクレーンサーバーで同時に維持される場合があります。それらはセッションIDによって区別されます。
Server Priority
サーバーの優先順位
A CRANE server is assigned with a Priority value. Accounting data is always delivered to the perceived operating CRANE server (from the CRANE client point of view) with the highest Priority value (the primary server) within a CRANE Session.
クレーンサーバーには優先度の値が割り当てられます。会計データは、クレーンセッション内で最高の優先度値（プライマリサーバー）で、常に知覚されたオペレーティングクレーンサーバー（クレーンクライアントの観点から）に配信されます。
Message
メッセージ
A Message is encoded according to rules specified by the CRANE protocol and transmitted across the interface between a CRANE client and a CRANE server. It contains a common CRANE header and optionally control or user data payload.
メッセージは、クレーンプロトコルによって指定されたルールに従ってエンコードされ、クレーンクライアントとクレーンサーバーの間のインターフェイス全体に送信されます。一般的なクレーンヘッダーと、オプションでコントロールまたはユーザーデータペイロードが含まれています。
Data Record
データレコード
A Data Record is a collection of information gathered by the Network Element for various purposes, e.g., accounting. The structure of a Data Record is defined by a Template.
データレコードとは、さまざまな目的のためにネットワーク要素によって収集された情報のコレクションです。たとえば、会計。データレコードの構造は、テンプレートによって定義されます。
Template
テンプレート
A Template defines the structure of any types of Data Record, and specifies the data type, meaning, and location of the fields in the record.
テンプレートは、あらゆるタイプのデータレコードの構造を定義し、レコード内のフィールドのデータ型、意味、および場所を指定します。
Data Sequence Number (DSN)
データシーケンス番号（DSN）
An accounting Data Record level sequence number, which is attached to all data messages to facilitate reliable and in-sequence delivery.
信頼性の高いシーケンス配信を促進するために、すべてのデータメッセージに添付された会計データレベルのレベルシーケンス番号。
2 Protocol Overview
2プロトコルの概要
The CRANE protocol is designed to deliver accounting data reliably, efficiently, and quickly. Due to the nature of accounting data, large records often need to be transmitted; thus supporting fragmentation of large records is required. Furthermore, the value associated with accounting data is high; to prevent data loss, quick detection of unresponsive CRANE servers is also required for added robustness.
クレーンプロトコルは、会計データを確実に、効率的に、迅速に提供するように設計されています。会計データの性質により、多くの場合、大きな記録を送信する必要があります。したがって、大きな記録の断片化をサポートする必要があります。さらに、会計データに関連する値は高くなっています。データの損失を防ぐために、堅牢性を追加するには、反応しないクレーンサーバーの迅速な検出も必要です。
The CRANE protocol can be viewed as an application that uses the data transport service provided by lower layer protocols. It relies on a transport layer protocol to deliver reliable, in-sequence data packets.
クレーンプロトコルは、下層プロトコルが提供するデータトランスポートサービスを使用するアプリケーションと見なすことができます。信頼性の高いシーケンスデータパケットを提供するために、輸送層プロトコルに依存しています。
UDP is a simple connectionless transport layer protocol that has advantages of being fast and agile, but it provides no reliability and lacks flow control mechanisms. Hence, The CRANE protocol must not use UDP as the transport layer protocol to avoid the risk of adversely impacting the networks it is being run over.
UDPは、高速でアジャイルであるという利点を持つ単純なコネクションレストランスポートレイヤープロトコルですが、信頼性を提供せず、フロー制御メカニズムを欠いています。したがって、クレーンプロトコルは、実行中のネットワークに悪影響を与えるリスクを回避するために、輸送層プロトコルとしてUDPを使用してはなりません。
TCP and SCTP [4] are two transport layer protocols that fulfill the reliability requirement of CRANE. Either one of them MAY be used to transport CRANE messages. TCP meets some of the requirements, but not all (e.g., quick detection of server failure, the fact that TCP is stream oriented and not record oriented). Therefore, SCTP [4] is the preferred way to transmit CRANE messages.
TCPとSCTP [4]は、クレーンの信頼性要件を満たす2つの輸送層プロトコルです。そのいずれかがクレーンメッセージの輸送に使用される場合があります。TCPは、すべてではなくいくつかの要件を満たしています（たとえば、サーバー障害の迅速な検出、TCPがストリーム指向であり、レコード指向ではないという事実）。したがって、SCTP [4]は、クレーンメッセージを送信する好ましい方法です。
The CRANE protocol is an application running over a reliable transport layer protocol. The transport layer protocol is responsible for delivering CRANE messages between CRANE clients and CRANE servers. It MUST support the following capabilities:
クレーンプロトコルは、信頼できる輸送層プロトコルを介して実行されるアプリケーションです。トランスポートレイヤープロトコルは、クレーンクライアントとクレーンサーバー間でクレーンメッセージを配信する責任があります。次の機能をサポートする必要があります。
1. Reliable, in-sequence message delivery. 2. Connection oriented. 3. Delivery of messages with a length of up to 2^32 octets (i.e., the transport layer has to support fragmentation of messages when running over IP).
1. 信頼できる、シーケンスメッセージの配信。2.接続指向。3.最大2^32オクテットの長さのメッセージの配信（つまり、トランスポートレイヤーは、IPを実行するときにメッセージの断片化をサポートする必要があります）。
The transport layer MAY support:
輸送層がサポートする場合があります。
1. Authentication. 2. Bundling of multiple messages into a single datagram.
1. 認証。2.単一のデータグラムに複数のメッセージをバンドリングします。
Possible transport layer protocols MAY be TCP or SCTP [4]. TCP supports the minimal requirements for CRANE, but lacks some desirable capabilities that are available in SCTP, these include:
可能な輸送層プロトコルは、TCPまたはSCTPである可能性があります[4]。TCPはクレーンの最小要件をサポートしていますが、SCTPで利用可能ないくつかの望ましい機能がありません。これらには以下が含まれます。
1. Session level authentication. 2. Message based data delivery (as opposed to stream based). 3. Fast connection failure detection.
1. セッションレベル認証。2.メッセージベースのデータ配信（ストリームベースとは対照的に）。3.高速接続障害検出。
Reliable delivery of accounting data is achieved through both the transport layer level and the CRANE protocol level. The transport layer acknowledgments are used to ensure quick detection of lost data packets and unresponsive servers, while the CRANE protocol acknowledges CRANE messages after they have been processed and the accounting information has been placed in persistent storage.
会計データの信頼できる配信は、輸送層レベルとクレーンプロトコルレベルの両方を通じて達成されます。トランスポートレイヤーの確認は、失われたデータパケットと無反応サーバーの迅速な検出を確保するために使用されますが、クレーンプロトコルは処理された後にクレーンメッセージを認識し、会計情報が永続的なストレージに配置されました。
Being a reliable protocol for delivering accounting data, traffic flowing from a CRANE client to a CRANE server is mostly accounting data. There are also bi-directional control message exchanges, though they only comprise of small portion of the traffic.
会計データを提供するための信頼できるプロトコルであるため、クレーンクライアントからクレーンサーバーに流れるトラフィックは、ほとんどが会計データです。双方向制御メッセージ交換もありますが、トラフィックのごく一部のみで構成されています。
The following diagram illustrates the CRANE protocol architecture:
次の図は、クレーンプロトコルアーキテクチャを示しています。
+----------------+ +----------------+
| CRANE | | CRANE |+
| User | | User ||+
+----------------+ +----------------+||
| CRANE | ==========> | CRANE |+|
| Client | <---------- | Server ||+
+----------------+ +----------------+||
| Transport | | Transport |+|
| Layer | <---------> | Layer ||+
+----------------+ +----------------+||
| Lower | | Lower |+|
| Layers | <---------> | Layers ||+
+----------------+ +----------------+||
+----------------+|
+----------------+
TCP can be used as a transport layer for the CRANE protocol. CRANE running over TCP MUST conform to the following rules:
TCPは、クレーンプロトコルの輸送層として使用できます。TCPを介して実行するクレーンは、次のルールに準拠する必要があります。
1. The CRANE client MUST accept TCP connections over a specific TCP port. 2. The CRANE server MUST connect to the CRANE client, and SHOULD be responsible for reestablishing a connection in case of a failure. 3. CRANE messages are written as a stream of bytes into a TCP connection, the size of a CRANE message is specified by the Message Length field in the CRANE message header.
1. クレーンクライアントは、特定のTCPポートでTCP接続を受け入れる必要があります。2.クレーンサーバーはクレーンクライアントに接続する必要があり、障害が発生した場合に接続を再確立する責任を負う必要があります。3.クレーンメッセージは、バイトのストリームとしてTCP接続に記述されます。クレーンメッセージのサイズは、クレーンメッセージヘッダーのメッセージ長フィールドによって指定されます。
For purposes of improved reliability and robustness, redundant CRANE server configuration MAY be employed. The CRANE protocol supports delivering accounting data to alternate CRANE servers, which may be part of a mediation system or a BSS.
信頼性と堅牢性の向上の目的で、冗長なクレーンサーバーの構成が採用される場合があります。クレーンプロトコルは、メディエーションシステムまたはBSSの一部である可能性のある交互のクレーンサーバーに会計データの配信をサポートします。
A CRANE session may comprise of one or more CRANE servers. The CRANE client is responsible for configuring network addresses of all CRANE servers belonging to the session. A Server Priority is assigned to each CRANE server. The Server Priority reflects the CRANE client's preference regarding which CRANE server should receive accounting data. The assignment of the Server Priority should consider factors such as geographical distance, communication cost, and CRANE server loading, etc. It is also possible for several CRANE servers to have the same priority. In this case, the CRANE client could randomly choose one of them as the primary server to deliver accounting data.
クレーンセッションは、1つ以上のクレーンサーバーで構成されている場合があります。クレーンクライアントは、セッションに属するすべてのクレーンサーバーのネットワークアドレスを構成する責任があります。サーバーの優先度が各クレーンサーバーに割り当てられます。サーバーの優先順位は、どのクレーンサーバーが会計データを受信するかに関するクレーンクライアントの好みを反映しています。サーバーの優先度の割り当てでは、地理的距離、通信コスト、クレーンサーバーの読み込みなどの要因を考慮する必要があります。いくつかのクレーンサーバーが同じ優先事項を持つことも可能です。この場合、クレーンクライアントは、そのうちの1つをプライマリサーバーとしてランダムに選択して、会計データを提供できます。
Additional features such as load balancing may be implemented in a multi-server environment. The process of configuring CRANE client is carried out using the NE's configuration system and is outside the scope of this document.
ロードバランシングなどの追加機能は、マルチサーバー環境で実装できます。クレーンクライアントの構成プロセスは、NEの構成システムを使用して実行され、このドキュメントの範囲外です。
A CRANE client MUST deliver accounting data to its perceived operating CRANE server with the highest priority; if this CRANE server is deemed unreachable, the CRANE client MUST deliver the accounting data to the next highest priority CRANE server that is perceived to be operating. If no perceived operating CRANE servers are available, accounting data MUST be queued in the CRANE client until any CRANE server is available or the client's queue space runs out. An alarm should be generated to inform the CRANE user of the queue overflow condition.
クレーンクライアントは、最優先事項を持つ認知されたオペレーティングクレーンサーバーに会計データを配信する必要があります。このクレーンサーバーが到達不能と見なされる場合、クレーンクライアントは、操作していると認識されている次の優先度クレーンサーバーに会計データを配信する必要があります。知覚されたオペレーティングクレーンサーバーが利用できない場合、クレーンサーバーが利用可能になるか、クライアントのキュースペースがなくなるまで、クレーンクライアントで会計データをキューに掲載する必要があります。クレーンユーザーにキューオーバーフロー条件を通知するためにアラームを生成する必要があります。
Accounting data delivery SHOULD revert to the higher priority server when it is perceived to be operating again.
会計データの配信は、再び操作していると認識されている場合、より高い優先度サーバーに戻るはずです。
The CRANE protocol does not specify how a CRANE client should redirect accounting data to other CRANE servers, which is considered an implementation issue. But all the supporting mechanisms are provided by the protocol to work in a multiple-server environment (e.g., the template negotiation process, and configuration procedures, etc.). The transport layer (together with some other means) is responsible for monitoring server's responsiveness and notifying CRANE protocol for any failures. The client may choose to transition to an alternate server.
クレーンプロトコルは、クレーンクライアントが会計データを他のクレーンサーバーにリダイレクトする方法を指定していません。これは実装の問題と見なされます。しかし、すべてのサポートメカニズムは、プロトコルによって提供され、複数のサーバー環境（たとえば、テンプレートネゴシエーションプロセス、構成手順など）で機能します。輸送層（他の手段とともに）は、サーバーの応答性を監視し、障害についてクレーンプロトコルに通知する責任があります。クライアントは、代替サーバーに移行することを選択できます。
Implementation Note:
実装注：
The transition to an alternate CRANE server is an implementation issue and should occur under the following conditions:
代替クレーンサーバーへの移行は実装の問題であり、次の条件下で発生する必要があります。
A) Transport layer notifies the CRANE client that the corresponding port of the CRANE server is unresponsive.
a）トランスポートレイヤーは、クレーンサーバーの対応するポートが反応しないことをクレーンクライアントに通知します。
B) Total size of unacknowledged accounting records has exceeded a threshold (configurable) for certain duration (configurable).
b）未承認の会計記録の総サイズは、特定の期間（構成可能）のしきい値（設定可能）を超えています。
C) A STOP message is received from the active server.
c）Active Serverから停止メッセージが受信されます。
D) A lower priority server is the active one and a higher priority server has recovered.
d）優先度の低いサーバーはアクティブなサーバーであり、優先度サーバーが高いことが回復しました。
The CRANE protocol enables efficient delivery of accounting data. This is achieved by negotiating a set of Data Templates for a CRANE session before actual accounting data is delivered. A data template defines the structure of a DATA message payload by describing the data type, meaning, and location of the fields in the payload. By agreeing on session templates, CRANE servers understand how to process DATA messages received from a CRANE client. As a result, a CRANE client only needs to deliver actual accounting data without attaching any descriptors of the data; this reduces the amount of bytes sent over communication links.
クレーンプロトコルにより、会計データの効率的な配信が可能になります。これは、実際の会計データが配信される前に、クレーンセッションのデータテンプレートのセットを交渉することによって達成されます。データテンプレートは、ペイロード内のフィールドのデータタイプ、意味、および位置を記述することにより、データメッセージペイロードの構造を定義します。セッションテンプレートに同意することにより、クレーンサーバーは、クレーンクライアントから受信したデータメッセージを処理する方法を理解しています。その結果、クレーンクライアントは、データの記述子を添付せずに実際の会計データを配信するだけでよいです。これにより、通信リンクを介して送信されるバイトの量が減少します。
A template is an ordered list of keys. A key is the specification of a field in the template. It specifies an accounting item that a network element MAY collect and export. The specification MUST consist of the description and the data type of the accounting item. (e.g., 'Number of Sent Bytes' can be a key that is an unsigned integer of 32 bit long). A CRANE client typically defines keys.
テンプレートは、順序付けられたキーのリストです。キーは、テンプレート内のフィールドの仕様です。ネットワーク要素が収集してエクスポートできる会計項目を指定します。仕様は、説明項目の説明とデータ型で構成されている必要があります。（たとえば、「送信バイトの数」は、32ビットの長さの署名されていない整数であるキーになる可能性があります）。通常、クレーンクライアントはキーを定義します。
The CRANE protocol supports usage of several templates concurrently (for different accounting records). Keys contained in a template could be enabled or disabled. An enabled key implies that the outgoing data record will contain the data item specified by the key. A disabled key implies that the outgoing record will omit the specified data item. The enabling/disabling mechanism further reduces bandwidth requirement; it could also reduce processing in network elements, as only needed data items are produced.
クレーンプロトコルは、複数のテンプレートの使用を同時にサポートしています（異なる会計記録に対して）。テンプレートに含まれるキーを有効にしたり無効にしたりできます。有効なキーは、発信データレコードにキーによって指定されたデータ項目が含まれていることを意味します。無効なキーは、発信レコードが指定されたデータ項目を省略することを意味します。有効化/無効化メカニズムは、帯域幅要件をさらに削減します。また、必要なデータ項目のみが生成されるため、ネットワーク要素の処理を減らすこともできます。
In a CRANE session, all the CRANE servers and the CRANE client MUST use the same set of templates and associated enable/disable status. The templates' configuration and connectivity to an end application MUST be the same in all servers. The CRANE client MUST publish the relevant templates to all CRANE servers in a session through user configuration, before it starts to send data according to the templates.
クレーンセッションでは、すべてのクレーンサーバーとクレーンクライアントが同じテンプレートのセットを使用し、関連する/無効にするステータスを使用する必要があります。テンプレートの構成とエンドアプリケーションへの接続は、すべてのサーバーで同じでなければなりません。クレーンクライアントは、テンプレートに従ってデータの送信を開始する前に、ユーザー構成を介したセッションで、すべてのクレーンサーバーに関連するテンプレートをすべてのクレーンサーバーに公開する必要があります。
The complete set of templates residing in a CRANE client MUST bear a configuration ID that identifies the template set. Each data record is delivered with the Template ID and the Configuration ID, so that the correct template can be referenced. A server, when receiving a record with an older Configuration ID, MAY handle the record gracefully by keeping some template history. The transport layer should ensure that a server would not get messages with future configuration IDs.
クレーンクライアントに居住するテンプレートの完全なセットには、テンプレートセットを識別する構成IDを持つ必要があります。各データレコードは、テンプレートIDと構成IDで配信されるため、正しいテンプレートを参照できます。サーバーは、古い構成IDを使用してレコードを受信する場合、テンプレートの履歴を保持することにより、レコードを優雅に処理できます。トランスポートレイヤーは、サーバーが将来の構成IDを使用してメッセージを取得しないようにする必要があります。
As stated before, all CRANE servers MUST use the same set of templates in a CRANE session. In case that servers do not share the same set of templates (the templates are considered different if different keys are enabled or disabled), a negotiation process between the client and the server would ultimately determine one set of templates that is accepted and used by all the CRANE servers in a session.
前に述べたように、すべてのクレーンサーバーは、クレーンセッションで同じテンプレートのセットを使用する必要があります。サーバーが同じテンプレートのセットを共有しない場合（異なるキーが有効または無効になっている場合、テンプレートは異なると見なされます）。セッション内のクレーンサーバー。
After a CRANE session is established and the server sent a START message indicating that it is ready to take part in the session, the client MUST deliver the set of templates that it intends to use by sending a TMPL DATA message to the server. The CRANE server MUST acknowledge the reception of the set of templates.
クレーンセッションが確立され、サーバーがセッションに参加する準備ができていることを示すスタートメッセージを送信した後、クライアントはTMPLデータメッセージをサーバーに送信して使用するテンプレートのセットを配信する必要があります。クレーンサーバーは、テンプレートのセットの受信を確認する必要があります。
Templates are negotiable between a CRANE client and CRANE servers. A CRANE server may propose changes to the templates received from a CRANE client (e.g., enabling some keys and disabling others), or it can acknowledge the templates as is. In the case that a template or a key is not recognized by the server (e.g., they might be added to the client after the server configuration has completed), the server MAY choose to disable each unknown key or unknown templates in order to avoid unnecessary traffic. A template is disabled when all the keys are disabled. If changes were received from the CRANE servers, the client will send the changed template set to all connected servers (using FINAL_TMPL_DATA message). It is the client's responsibility to decide what would be the final set of templates used by a session. At this time, each CRANE server MUST accept and acknowledge the templates without changing anything (to avoid deadlock and loop conditions). Each CRANE server is given a single chance to propose any changes during the negotiation process.
テンプレートは、クレーンクライアントとクレーンサーバーの間で交渉可能です。クレーンサーバーは、クレーンクライアントから受信したテンプレートの変更を提案する場合（たとえば、いくつかのキーを有効にして他のキーを無効にする）、またはそのままテンプレートを認めることができます。テンプレートまたはキーがサーバーによって認識されない場合（たとえば、サーバーの構成が完了した後にクライアントに追加される場合があります）、サーバーは、不必要な回避のために各未知のキーまたは不明なテンプレートを無効にすることを選択できます。渋滞。すべてのキーが無効になっている場合、テンプレートは無効になります。クレーンサーバーから変更が受信された場合、クライアントは変更されたテンプレートセットをすべての接続サーバーに送信します（final_tmpl_dataメッセージを使用）。セッションで使用されるテンプレートの最終セットを決定することは、クライアントの責任です。現時点では、各クレーンサーバーは、何も変更せずにテンプレートを受け入れて確認する必要があります（デッドロックとループの条件を避けるため）。各クレーンサーバーには、交渉プロセス中に変更を提案する1つの機会が与えられます。
The template negotiation process is outlined as follows:
テンプレート交渉プロセスの概要は次のとおりです。
A) CRANE client sends a TMPL DATA message with a set of templates.
a）クレーンクライアントは、テンプレートのセットでTMPLデータメッセージを送信します。
B) CRANE server either responds with the TMPL DATA ACK message with changes in the template set (process continues in step C) or responds with FINAL TMPL DATA ACK message if no changes are needed (process continues in step E).
b）クレーンサーバーは、テンプレートセットの変更（ステップCでプロセスが継続する）を使用してTMPLデータACKメッセージで応答するか、変更が不要な場合は最終的なTMPLデータACKメッセージで応答します（ステップEでプロセスが継続します）。
C) CRANE client receives proposed changes, incorporates them if possible and then sends a FINAL TMPL DATA message containing the new set of templates to all servers (in order to deploy the change).
c）クレーンクライアントは、提案された変更を受信し、可能であればそれらを組み込んでから、すべてのサーバーに新しいテンプレートのセットを含む最終的なTMPLデータメッセージを送信します（変更を展開するために）。
D) CRANE server receives the FINAL TMPL DATA message containing the new set of templates and MUST send a FINAL TMPL DATA ACK message to acknowledge the reception of the templates. No changes are allowed at this stage and the templates, which the client sent, are going to be used.
d）クレーンサーバーは、新しいテンプレートの新しいセットを含む最終的なTMPLデータメッセージを受信し、テンプレートの受信を確認するために最終的なTMPLデータACKメッセージを送信する必要があります。この段階では変更は許可されておらず、クライアントが送信したテンプレートが使用されます。
E) CRANE client receives a FINAL TMPL DATA ACK message from the server and can assume that the server knows which templates to use.
e）クレーンクライアントは、サーバーから最終的なTMPLデータACKメッセージを受信し、サーバーが使用するテンプレートを知っていると想定できます。
All these stages take place only when there are multiple CRANE servers with differences in the template set (e.g., not all key states are identical). If all CRANE servers within a session share the same configuration exactly, all servers will respond with FINAL TMPL DATA ACK and the ping-pong between the client and the servers will end immediately. This is the common case, but in case some other CRANE servers have a different configuration, the protocol offers the way to maintain consistency among CRANE servers.
これらのすべての段階は、テンプレートセットに違いがある複数のクレーンサーバーがある場合にのみ発生します（たとえば、すべての重要な状態が同一ではない）。セッション内のすべてのクレーンサーバーが同じ構成を正確に共有する場合、すべてのサーバーは最終的なTMPLデータACKで応答し、クライアントとサーバー間のPing-Pongはすぐに終了します。これは一般的なケースですが、他のクレーンサーバーが異なる構成を持っている場合、プロトコルはクレーンサーバー間の一貫性を維持する方法を提供します。
Implementation Note:
実装注：
TMPL DATA messages SHOULD be sent only after all DATA messages with the previous configuration have been acknowledged. This ensures the server to transition properly to the new configuration.
TMPLデータメッセージは、以前の構成が認められたすべてのデータメッセージが確認された後にのみ送信する必要があります。これにより、サーバーが新しい構成に適切に遷移することが保証されます。
Though TMPL DATA messages allow for deploying and publicizing template, a need to configure the template set still exists. Each of the CRANE servers in a CRANE session may change the template set, which is typically requested by an end-user through User Interface. If the end-users need to know what templates are available and the current template set status, they may issue the GET TMPL message.
TMPLデータメッセージでは、テンプレートの展開と公開が可能ですが、テンプレートセットを構成する必要があります。クレーンセッションの各クレーンサーバーは、テンプレートセットを変更する場合があります。これは、通常、ユーザーインターフェイスを介してエンドユーザーが要求する場合があります。エンドユーザーが使用可能なテンプレートと現在のテンプレートを設定したステータスを知る必要がある場合、Get TMPLメッセージを発行する場合があります。
The following steps are performed in order to change the templates:
テンプレートを変更するために、次の手順が実行されます。
A) The server MUST retrieve from CRANE client the template set that requires change by issuing GET TMPL message. The server can issue a GET TMPL even if it has not yet issued a START message.
a）サーバーは、get tmplメッセージを発行することにより変更が必要なテンプレートセットをクレーンクライアントから取得する必要があります。サーバーは、開始メッセージをまだ発行していない場合でも、Get TMPLを発行できます。
B) After received a GET TMPL message, the client sends back a GET TMPL RSP message with the requested data.
b）Get TMPLメッセージを受信した後、クライアントは要求されたデータを使用してGET TMPL RSPメッセージを送信します。
C) The server makes the necessary changes to the templates and sends back a START NEGOTIATION message. This message triggers the CRANE client to inquire about changes made by the CRANE server.
c）サーバーは、テンプレートに必要な変更を加え、開始ネゴシエーションメッセージを送り返します。このメッセージは、クレーンサーバーが行った変更について問い合わせるためにクレーンクライアントにトリガーされます。
D) After received a START NEGOTIATE message, the client MUST respond with START NEGOTIATE ACK message followed by a TMPL DATA message. From this point on, the template negotiation process starts.
d）スタートネゴシエートメッセージを受信した後、クライアントはACKメッセージを開始してTMPLデータメッセージを使用して応答する必要があります。この時点から、テンプレートネゴシエーションプロセスが開始されます。
After templates have been deployed, DATA messages start to arrive at the primary CRANE server (the operational one with the highest priority within the CRANE session). Each DATA message contains a Data Sequence Number (DSN). The primary CRANE server MUST accept the data as long as it is in-sequence. Out-of-sequence DATA messages should be discarded.
テンプレートが展開された後、データメッセージはプライマリクレーンサーバー（クレーンセッション内で最優先事項を持つ動作のあるサーバー）に到達し始めます。各データメッセージには、データシーケンス番号（DSN）が含まれています。プライマリクレーンサーバーは、データがシーケンスである限り、データを受け入れる必要があります。アウトシーケンスデータメッセージを破棄する必要があります。
The CRANE server detects the start of accounting data when it receives the first DATA message either after startup or after a server transition. The first DATA message MUST have the 'S' bit ('DSN Synchronize' bit) set by the CRANE client. Upon reception of the message with initial DSN, the server MUST accept all in-sequence DATA messages. The DSN MUST be incremented by 1 for each new DATA message originated from the client.
Crane Serverは、起動後またはサーバーの遷移後に最初のデータメッセージを受信したときに、会計データの開始を検出します。最初のデータメッセージには、クレーンクライアントによって「s」ビット（「dsn同期」ビット）が設定されている必要があります。最初のDSNを使用してメッセージを受信すると、サーバーはすべてのシーケンスデータメッセージを受け入れる必要があります。DSNは、クライアントから発信された新しいデータメッセージごとに1個ずつ増加する必要があります。
A CRANE server MUST acknowledge the reception and correct processing of DATA messages by sending DATA ACK messages. The DATA ACK MUST contain the DSN of the last processed in-sequence DATA message. If the CRANE server receives an Out Of Sequence DATA message, it MUST also send a DATA ACK message. It will trigger an immediate retransmission of unacknowledged records.
クレーンサーバーは、データACKメッセージを送信して、データメッセージの受信と正しい処理を確認する必要があります。データACKには、最後の処理されたインセンセンスデータメッセージのDSNを含める必要があります。Crane ServerがSequence Dataメッセージメッセージを受信した場合、データACKメッセージも送信する必要があります。未承認のレコードの即時の再送信をトリガーします。
The CRANE client is responsible for delivering all the records. In the case of a redundant server configuration, there could be a scenario when one server does not receive all the records but another redundant CRANE server for the same mediation system receives the rest of the records. For example, server #1 could receive records 3042-3095 and then 3123-..., with server #2 receiving records 3096- 3122. It is the sender's responsibility to deliver all the records, in-sequence, but not necessarily to the same server.
クレーンクライアントは、すべてのレコードを配信する責任があります。冗長なサーバー構成の場合、あるサーバーがすべてのレコードを受信しないが、同じ調停システムの別の冗長クレーンサーバーが残りのレコードを受信する場合のシナリオがある可能性があります。たとえば、サーバー＃1はレコード3042-3095、その後3123 -...を受信することができます。サーバー＃2レコード3096-3122を受信します。同じサーバー。
The billing/mediation system eventually receives all the records, possibly through more than one CRANE server. The CRANE client MUST convey all the records it received to the billing/mediation system. This MAY result in duplicate records in the billing/mediation system. In this case, the DSN MUST be used to remove duplicates. To aid the process of duplicate removal, whenever a record is re-sent to another server, its 'Duplicate' bit MUST be set to suggest that this record might be a duplicate.
請求/調停システムは、おそらく複数のクレーンサーバーを介して、最終的にすべてのレコードを受信します。クレーンクライアントは、受け取ったすべての記録を請求/調停システムに伝える必要があります。これにより、請求/調停システムでレコードが重複する可能性があります。この場合、DSNを使用して重複を除去する必要があります。削除の重複のプロセスを支援するには、レコードが別のサーバーに再配置される場合はいつでも、このレコードが重複している可能性があることを示唆するために、その「複製」ビットを設定する必要があります。
Implementation Note:
実装注：
When the amount of unacknowledged records reaches a threshold, a timer should be started. When the timer expires, all the unacknowledged records should be transmitted to an alternate server with 'D' bit set in the DATA message; if alternate servers are not available, the records should be retransmitted.
承認されていないレコードの量がしきい値に達すると、タイマーを開始する必要があります。タイマーの有効期限が切れると、すべての未承認のレコードは、データメッセージに「d」ビットが設定された代替サーバーに送信される必要があります。代替サーバーが使用できない場合は、レコードを再送信する必要があります。
The CRANE flow control also supports redundant server configuration. A server MUST send a START message in order to move to the 'ready' state. In the 'ready' state, the server can receive and process CRANE messages. To leave the 'ready' state and stop the message flows from the client, the server should send a STOP message to the client.
クレーンフロー制御は、冗長なサーバー構成もサポートします。サーバーは、「準備が整った」状態に移動するために開始メッセージを送信する必要があります。「準備が整った」状態では、サーバーはクレーンメッセージを受信して処理できます。「準備が整った」状態を離れ、クライアントからのメッセージフローを停止するには、サーバーはクライアントに停止メッセージを送信する必要があります。
A CRANE server may query a CRANE client's status by sending query messages after it has established a session with the client. A CRANE client that is connected to the server MUST respond with response messages. All the Query Messages MUST be initiated by a CRANE server. The CRANE protocol defines three such Query Message pairs, they are:
クレーンサーバーは、クライアントとのセッションを確立した後にクエリメッセージを送信することにより、クレーンクライアントのステータスを照会することができます。サーバーに接続されているクレーンクライアントは、応答メッセージで応答する必要があります。すべてのクエリメッセージは、クレーンサーバーによって開始する必要があります。クレーンプロトコルは、3つのこのようなクエリメッセージペアを定義します。
Get Session (GET SESS) Get Session Response (GET SESS RSP)
セッションを取得する（sessを取得）セッション応答を取得（sess rspを取得）
Get Template (GET TMPL) Get Template Response (GET TMPL RSP)
テンプレートを取得（tmplを取得）テンプレート応答を取得（tmpl rspを取得）
Status Request (STATUS REQ) Status Response (STATUS RSP)
ステータスリクエスト（ステータスREQ）ステータス応答（ステータスRSP）
All the query messages incorporate a Request ID field for tagging purposes and matching requests and responses. This field contains a 16 bit counter incremented with every request and is set by the initiator of the request. Along with the CRANE server's IP address and port number, this constitutes a unique identifier for a request. This value MUST be copied to Request ID field in the response message in order to associate a specific response with a request.
すべてのクエリメッセージには、タグ付け目的と一致するリクエストと応答のためにリクエストIDフィールドが組み込まれています。このフィールドには、すべてのリクエストで16ビットのカウンターがインクリメントされ、リクエストの開始者によって設定されます。Crane ServerのIPアドレスとポート番号に加えて、これはリクエスト用の一意の識別子を構成します。この値は、特定の応答をリクエストに関連付けるために、応答メッセージのIDフィールドを要求するためにコピーする必要があります。
The CRANE client SHOULD collect and send out meta-data about the data collected (counters, statistics, etc.). This is done by creating status templates, which are treated like any other template, with the exception that these templates are marked with a /'Status' bit. Status templates are used with the set of STATUS REQ and STATUS RSP messages. A server MAY issue a STATUS REQ to a CRANE client and receive a STATUS RSP message with the requested data.
クレーンクライアントは、収集されたデータ（カウンター、統計など）についてメタデータを収集して送信する必要があります。これは、他のテンプレートと同様に扱われるステータステンプレートを作成することによって行われます。ステータステンプレートは、ステータスREQおよびステータスRSPメッセージのセットで使用されます。サーバーは、クレーンクライアントにステータスREQを発行し、要求されたデータを使用してステータスRSPメッセージを受信する場合があります。
A CRANE client MAY deliver accounting data to different mediation/billing systems by establishing different CRANE sessions.
クレーンクライアントは、さまざまなクレーンセッションを確立することにより、さまざまな調停/請求システムに会計データを提供できます。
Each session MAY consist of several CRANE servers in a redundant configuration. The session ID imbedded in all the CRANE messages enables the correct association of CRANE sessions with CRANE users. All the CRANE processes (e.g., template negotiation, configuration, flow control, etc.) should be carried out in the same way in a multi session scenario.
各セッションは、冗長構成のいくつかのクレーンサーバーで構成されている場合があります。すべてのクレーンメッセージに埋め込まれたセッションIDにより、クレーンセッションとクレーンユーザーとの正しい関連性が可能になります。すべてのクレーンプロセス（テンプレートネゴシエーション、構成、フロー制御など）は、マルチセッションシナリオで同じ方法で実行する必要があります。
Each session has its set of templates (these may be the same templates, but the keys could be enabled or disabled differently). The sessions are configured in the NE, each with a different session name with associated Session IDs. The session ID is carried in each message to associate the message with a specific session.
各セッションにはテンプレートのセットがあります（これらは同じテンプレートである可能性がありますが、キーは異なる方法で有効または無効にすることができます）。セッションはNEで構成されており、それぞれに関連するセッションIDと異なるセッション名があります。セッションIDは各メッセージに掲載され、メッセージを特定のセッションに関連付けます。
A CRANE server MAY take part in different sessions. When configuring a server, it needs to know the sessions in which it participates. The server can issue a GET SESS message to receive a list of relevant sessions.
クレーンサーバーは、さまざまなセッションに参加する場合があります。サーバーを構成するときは、参加するセッションを知る必要があります。サーバーは、get sessメッセージを発行して、関連するセッションのリストを受信できます。
3 CRANE Message Format
3クレーンメッセージ形式
A summary of the CRANE protocol message format is shown below. A CRANE message consists of an 8 octet message header; it is followed by a variable length message payload that is aligned to 32 bit boundary. Some of the messages do not have the CRANE Message Payload part. The fields are in network byte order and transmitted from left to right.
クレーンプロトコルメッセージ形式の概要を以下に示します。クレーンメッセージは、8オクテットメッセージヘッダーで構成されています。その後、32ビット境界に整列する可変長さメッセージペイロードが続きます。一部のメッセージには、クレーンメッセージペイロードパーツがありません。フィールドはネットワークバイトの順序であり、左から右に送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version |Message ID(MID)| Session ID | Message Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ CRANE Message Payload ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version: 8 bit unsigned integer
バージョン：8ビット署名されていない整数
The Version field indicates the supported CRANE protocol implementation. This field MUST be set to 1 to indicate the CRANE protocol Version 1.0. CRANE protocol Version 1.0 only supports Ipv4 addressing; however, it can be used to transfer information related to Ipv6 flows.
バージョンフィールドは、サポートされているクレーンプロトコルの実装を示します。このフィールドは、クレーンプロトコルバージョン1.0を示すために1に設定する必要があります。クレーンプロトコルバージョン1.0は、IPv4アドレス指定のみをサポートしています。ただし、IPv6フローに関連する情報を転送するために使用できます。
Message ID (MID): 8 bit unsigned integer
メッセージID（MID）：8ビット符号なし整数
The Message ID field identifies the type of the message. The message IDs defined by CRANE Version 1 are:
メッセージIDフィールドは、メッセージのタイプを識別します。クレーンバージョン1で定義されたメッセージIDは次のとおりです。
Message Name Short Name Message ID
--------------------- --------------- ------------
Reserved 0x00
Flow Start START 0x01
Flow Start Acknowledge START ACK 0x02
Flow Stop STOP 0x03
Flow Stop Acknowledge STOP ACK 0x04
Connect CONNECT 0x05
Template Data TMPL DATA 0x10
Template Data Acknowledge TMPL DATA ACK 0x11
Final Template Data FINAL TMPL DATA 0x12
Final Template Data Ack. FINAL TMPL DATA ACK 0x13
Get Sessions GET SESS 0x14
Get Sessions Response GET SESS RSP 0x15
Get Template GET TMPL 0x16
Get Template Response GET TMPL RSP 0x17
Start Negotiation START NEGOTIATE 0x18
Start Negotiation Ack. START NEGOTIATE ACK 0x19
Data DATA 0x20
Data Acknowledge DATA ACK 0x21
Error ERROR 0x23
Status Request STATUS REQ 0x30
Status Response STATUS RSP 0x31
Session ID: 8 bit unsigned char
セッションID：8ビット符号なしchar
The Session ID field identifies the session with which the message is associated. The session ID is ignored in the case of GET SESS and GET SESS RSP messages. More details about session can be found in Section 2.9.
セッションIDフィールドは、メッセージが関連付けられるセッションを識別します。セッションIDは、get sessとsess RSPメッセージを取得する場合に無視されます。セッションの詳細については、セクション2.9をご覧ください。
Message Flags: 8 bit unsigned char
メッセージフラグ：8ビット符号なしの文字
The Message Flags field can be used to identify options associated with the message. For CRANE Version 1.0, all the flags are reserved; unless otherwise specified, the flags are set to zero on transmit and are ignored on receipt.
メッセージフラグフィールドを使用して、メッセージに関連付けられたオプションを識別できます。クレーンバージョン1.0の場合、すべてのフラグが予約されています。特に指定されていない限り、フラグは送信時にゼロに設定され、受領時に無視されます。
Message Length: 32 bit unsigned integer
メッセージの長さ：32ビット符号なし整数
The Message Length field is the total length of the CRANE message in octet including the header.
メッセージの長さフィールドは、ヘッダーを含むOctetのクレーンメッセージの全長です。
4 CRANE Messages
4つのクレーンメッセージ
This section defines CRANE mandatory messages. They MUST be supported by any CRANE protocol implementation.
このセクションでは、クレーンの必須メッセージを定義します。これらは、クレーンプロトコルの実装によってサポートされる必要があります。
Description
説明
The Flow Start message is sent from a CRANE server to a CRANE client to indicate that the CRANE server is ready to receive CRANE messages.
フロースタートメッセージは、クレーンサーバーからクレーンクライアントに送信され、クレーンサーバーがクレーンメッセージを受信する準備ができていることを示します。
Message Format
メッセージ形式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | MID=0x01 | Session ID | Message Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Description
説明
The Flow Start Acknowledge message is sent by a CRANE client to acknowledge the reception of a START message from a specific CRANE server. It is sent only to that server to indicate that the client considers it ready to receive CRANE messages.
フロースタートの確認メッセージは、特定のクレーンサーバーからの開始メッセージの受信を確認するためにクレーンクライアントによって送信されます。クライアントがクレーンメッセージを受信する準備ができていると考えることを示すために、そのサーバーにのみ送信されます。
Message Format
メッセージ形式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | MID=0x02 | Session ID | Message Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client Boot Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Client Boot Time: 32 bit unsigned integer
クライアントブート時間：32ビット符号なし整数
The Client Boot Time field is the timestamp of the last client startup in seconds from 1970. This field can be combined with the DSN and the client's IP address to serve as a system wide unique record identifier.
クライアントブートタイムフィールドは、1970年の数秒での最後のクライアントスタートアップのタイムスタンプです。このフィールドは、DSNとクライアントのIPアドレスと組み合わせて、システム全体の一意のレコード識別子として機能します。
Description
説明
The Flow Stop message is sent from a CRANE server to a CRANE client to instruct it to stop sending data (to that server). The STOP message does not disconnect the server; it only stops the CRANE client from sending "DATA" messages.
フローストップメッセージは、クレーンサーバーからクレーンクライアントに送信され、データの送信を停止するように指示します（そのサーバーに）。STOPメッセージはサーバーを切断しません。クレーンクライアントが「データ」メッセージを送信するのを停止するだけです。
Message Format
メッセージ形式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | MID=0x03 | Session ID | Message Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Description
説明
The Flow Stop Acknowledgement message acknowledges the STOP message issued by a CRANE server.
Flow Stop Ancoundmentメッセージは、クレーンサーバーによって発行された停止メッセージを確認します。
Message Format
メッセージ形式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | MID=0x04 | Session ID | Message Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Description
説明
The CONNECT message is sent from a CRANE server to a CRANE client to identify itself. The message MUST be the first message sent over a transport layer connection between the server and the client.
Connectメッセージは、クレーンサーバーからクレーンクライアントに送信され、自分自身を識別します。メッセージは、サーバーとクライアントの間のトランスポートレイヤー接続を介して送信された最初のメッセージでなければなりません。
Message Format
メッセージ形式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | MID=0x05 | Session ID | Message Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Server Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Server Port | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Server Address: 32 bit unsigned integer
サーバーアドレス：32ビット符号なし整数
The Server Address field is the server's IP address (IPV4).
サーバーアドレスフィールドは、サーバーのIPアドレス（IPv4）です。
Server Port: 16 bit unsigned integer
サーバーポート：16ビット符号なし整数
The Server Port field is the server's port number for the transport layer (the port number specified here doesn't necessarily have to match the port number used by the transport layer)
サーバーポートフィールドは、トランスポートレイヤーのサーバーのポート番号です（ここで指定されているポート番号は、必ずしもトランスポートレイヤーで使用されるポート番号と一致する必要はありません）
Description
説明
A CRANE client sends the Template Data message to a CRANE server after a START or a START NEGOTIATE message was received from the server. The message MUST contain all the templates that are going to be used for the session. It SHOULD also include the template for the status records (See section 2.8)
クレーンクライアントは、スタートまたはスタートネゴチエートメッセージがサーバーから受信された後、テンプレートデータメッセージをクレーンサーバーに送信します。メッセージには、セッションに使用されるすべてのテンプレートが含まれている必要があります。また、ステータスレコードのテンプレートを含める必要があります（セクション2.8を参照）
The receiving CRANE server MUST acknowledge the message by sending either a TMPL DATA ACK (if template changes are needed) or a FINAL TMPL DATA ACK message. For more information, see section 2.5.
受信クレーンサーバーは、TMPLデータACK（テンプレートの変更が必要な場合）または最終的なTMPLデータACKメッセージのいずれかを送信することにより、メッセージを確認する必要があります。詳細については、セクション2.5を参照してください。
Message Format
メッセージ形式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | MID=0x10 | Session ID | Message Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Config ID | Flags |E| Number of Templates |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Template Block ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ... ... ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Template Block ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Configuration ID (Config. ID): 8 bit unsigned char
構成ID（config。id）：8ビットunsigned char
The Configuration ID field identifies the version number associated with a template set. Changes to any of the templates would result in a new template version, and the version number would be incremented by one. An implementation SHOULD handle rollovers of the version number.
構成IDフィールドは、テンプレートセットに関連付けられたバージョン番号を識別します。テンプレートのいずれかを変更すると、新しいテンプレートバージョンが表示され、バージョン番号は1つずつ増加します。実装は、バージョン番号のロールオーバーを処理する必要があります。
Flags: 8 bit unsigned char
フラグ：8ビット符号なしチャー
The Flags field identifies any options associated to the message.
Flagsフィールドは、メッセージに関連付けられたオプションを識別します。
The flag defined by the CRANE Version 1 is:
クレーンバージョン1で定義されているフラグは次のとおりです。
The 'E' bit indicates the transmission order of the "DATA" messages. If the field is set to 1, data is in big endian format; otherwise, little endian format is used.
「e」ビットは、「データ」メッセージの送信順序を示します。フィールドが1に設定されている場合、データはビッグエンド形式です。それ以外の場合、リトルエンディアン形式が使用されます。
Number of Templates: 16 bit unsigned integer
テンプレートの数：16ビット符号なし整数
The Number of Templates field is the number of Templates (a template is described by a Template Block) specified by the message.
テンプレートフィールドの数は、メッセージで指定されたテンプレートの数（テンプレートはテンプレートブロックで記述されます）です。
Template Block
テンプレートブロック
The Template Block field is of variable length and aligned to 32 bit boundary. It is the specification of a template.
テンプレートブロックフィールドはさまざまな長さで、32ビット境界に合わせます。テンプレートの仕様です。
Template Block Format:
テンプレートブロック形式：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID | Number of Keys |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template Flags |T| Description Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Description ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Key Block ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ... ... ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Key Block ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Template ID: 16 bit unsigned integer
テンプレートID：16ビット符号なし整数
The Template ID field identifies a specific template.
テンプレートIDフィールドは、特定のテンプレートを識別します。
Number of Keys: 16 bit unsigned integer
キー数：16ビット符号なし整数
The Number of Keys field is the number of keys included in the template.
キーフィールドの数は、テンプレートに含まれるキーの数です。
Template Flags: 16 bit unsigned integer
テンプレートフラグ：16ビット符号なし整数
The Template Flags field is composed of flags that indicate different attributes of the template. In CRANE Version 1.0, only the 'T' bit is defined, other bits in the field SHOULD be set to zero by the sender and ignored by the receiver.
テンプレートフラグフィールドは、テンプレートの異なる属性を示すフラグで構成されています。クレーンバージョン1.0では、「t」ビットのみが定義され、フィールド内の他のビットは送信者によってゼロに設定され、受信機によって無視される必要があります。
The 'T' bit ('Status' bit) indicates that the template is a status template that is used by the STATUS RSP message only. See section 2.8 for more details.
「t」ビット（「ステータス」ビット）は、テンプレートがステータスRSPメッセージのみで使用されるステータステンプレートであることを示します。詳細については、セクション2.8を参照してください。
Description Length: 16 bit unsigned integer
説明長：16ビット署名されていない整数
The Description Length field is the length of the Description field. If no description is supplied, the length MUST be 0.
説明の長さフィールドは、説明フィールドの長さです。説明が提供されていない場合、長さは0でなければなりません。
Template Block Length: 32 bit unsigned integer
テンプレートブロック長：32ビット符号なし整数
The Template Block Length is the length of the template block in octets.
テンプレートブロックの長さは、オクテットのテンプレートブロックの長さです。
Description: Variable length unsigned char
説明：可変長さ符号なしの文字
The Description field contains the text description of the template (e.g., "Aggregated by interface and ToS bits"). It is a variable length field of up to 64Kb long, and padded with 0 to the next 32 bit boundary.
説明フィールドには、テンプレートのテキスト説明が含まれています（たとえば、「インターフェイスとTOSビットによって集約されます」）。長さは最大64kbの可変長さフィールドであり、0でパッドで次の32ビットの境界です。
Key Block
キーブロック
A key Block contains the specification of a key within a template.
キーブロックには、テンプレート内のキーの仕様が含まれています。
Key Block Format
キーブロック形式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Type ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Attribute Vector |K|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key ID: 32 bit unsigned integer
キーID：32ビット符号なし整数
The Key ID field identifies the key within a template. See section 2.4 for more details.
キーIDフィールドは、テンプレート内のキーを識別します。詳細については、セクション2.4を参照してください。
Key Type ID: 16 bit unsigned integer
キータイプID：16ビット符号なし整数
The Key Type ID field specifies the data type of the key.
キータイプIDフィールドは、キーのデータ型を指定します。
The fixed length data types are defined as following:
固定された長さのデータ型は、次のように定義されます。
Data Type Data Type ID
--------------------- --------------
Boolean (1) 0x0001
Unsigned Integer8 0x0002
Signed Integer8 0x0003
Unsigned Integer16 0x0004
Signed Integer16 0x0005
Unsigned Integer32 0x0006
Signed Integer32 0x0007
Unsigned Integer64 0x0008
Signed Integer64 0x0009
Float (2) 0x000a Double (2) 0x000b
フロート（2）0x000Aダブル（2）0x000B
IP address (Ipv4) 0x0010 IP address (Ipv6) 0x0011 Time_SEC (3) 0x0012 Time_MSEC_64(4) 0x0013 Time_USEC_64 (5) 0x0014 Time_MSEC_32 (6) 0x0015 Time_USEC_32 (7) 0x0016
IPアドレス（IPv4）0x0010 IPアドレス（IPv6）0x0011 Time_Sec（3）0x0012 Time_msec_64（4）0x0013 time_usec_64（5）0x0014mmsec_32（6）0x0015 Time_usec_32（7）0x0016
The variable length data types are defined as following:
変数長データ型は、次のように定義されます。
String (8) 0x400c
Null Terminated String 0x400d
UTF-8 String 0x400e
UTF-16 String 0x400f
Arbitrary Data (BLOB) (9) 0x4015
(1) Boolean is represented as a single octet holding 0 for a value of FALSE and 1 for a value of TRUE.
(1) Booleanは、falseの値について0を保持し、Trueの値に対して1を保持している単一のOctetとして表されます。
(2) Float and Double are single and double precision floating point numbers that comply with the IEEE-754 standard.
(2) フロートとダブルは、IEEE-754標準に準拠する単一および二重精度の浮動小数点数です。
(3) Time_SEC is a 32 bit value, most significant octet first - seconds since 00:00:00 GMT, January 1, 1970.
(3) Time_Secは32ビットの値であり、最も重要な最初のオクテット - 00:00:00 GMT、1970年1月1日以来秒秒。
(4) Time_MSEC_64 is a 64 bit value, most significant octet first - milliseconds since 00:00:00 GMT, January 1, 1970.
(4) Time_msec_64は64ビット値であり、最も重要なOctetの最初 - 1970年1月1日、00:00:00 GMT以降のミリ秒。
(5) Time_USEC_64 is a 64 bit value, most significant octet first - microseconds since 00:00:00 GMT, January 1, 1970.
(5) Time_usec_64は64ビット値であり、最も重要なOctetの最初 - 1970年1月1日、00:00:00 GMT以降のマイクロ秒秒。
(6) Time_MSEC_32 is a 32 bit value, most significant octet first - milliseconds since 00:00:00 GMT, January 1, 1970.
(6) time_msec_32は32ビット値であり、最も重要な最初のオクテット - 1970年1月1日、00:00:00 GMT以降のミリ秒。
(7) Time_USEC_32 is a 32 bit value, most significant octet first - microseconds since 00:00:00 GMT, January 1, 1970.
(7) Time_usec_32は32ビット値であり、最も重要なOctetの最初 - 1970年1月1日、00:00:00 GMT以降のマイクロ秒秒。
(8) String is prefixed by a 32 bit length field that indicates the length of the string, and followed by ASCII codes of the string characters. This representation MUST only be used for encoding data records in a "DATA" message.
(8) 文字列には、文字列の長さを示す32ビットの長さフィールドが付けられ、文字列文字のASCIIコードが続きます。この表現は、「データ」メッセージのデータレコードをエンコードするためにのみ使用する必要があります。
(9) The arbitrary data is prefixed by a 32 bit length field and followed by the data in binary format.
(9) 任意のデータには、32ビットの長さフィールドが付いており、その後にバイナリ形式のデータが続きます。
Key Attribute Vector: 32 bit unsigned integer
キー属性ベクトル：32ビット符号なし整数
The Key Attribute Vector field indicates different attributes of the key. In CRANE Version 1, only the 'K' bit is defined, other bits in the field SHOULD be set to zero by the sender and ignored by the receiver.
キー属性ベクトルフィールドは、キーの異なる属性を示します。クレーンバージョン1では、「k」ビットのみが定義され、フィールド内の他のビットは送信者によってゼロに設定され、受信者によって無視される必要があります。
The 'K' bit ('Disabled bit') is set to 1 when the key is disabled in this template.
「k」ビット（「無効ビット」）は、このテンプレートでキーが無効になっているときに1に設定されます。
Description
説明
The Template Data Acknowledge message is sent from a CRANE server to a CRANE client after a TMPL DATA message has been received. It proposes changes of the templates and/or key status changes (enable/disable) for the templates.
TMPLデータメッセージが受信された後、テンプレートデータがクレーンサーバーからクレーンクライアントに送信されます。テンプレートのテンプレートおよび/またはキーステータスの変更（有効/無効）の変更を提案します。
If a CRANE server wishes to acknowledge reception of TMPL DATA without changes, it MUST respond with the FINAL TMPL DATA ACK message.
Crane Serverが変更せずにTMPLデータの受信を確認したい場合、最終的なTMPLデータACKメッセージで応答する必要があります。
Message Format
メッセージ形式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | MID=0x11 | Session ID | Message Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Config. ID | Reserved | Number of Template Changes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Template Change Block ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ... ... ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Template Change Block ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Configuration ID (Config. ID): 8 bit unsigned char
構成ID（config。id）：8ビットunsigned char
See Section 4.6. The value MUST be identical to the Config. ID field of the acknowledged TMPL DATA message.
セクション4.6を参照してください。値は構成と同一でなければなりません。確認されたTMPLデータメッセージのIDフィールド。
Number of Template Changes: 16 bit unsigned integer
テンプレートの変更の数：16ビット符号なし整数
The Number of Template Changes field is the number of changed Templates (a changed template is described by a Template Change Block) specified by the message.
テンプレートの変更フィールドの数は、メッセージで指定された変更されたテンプレートの数（変更されたテンプレートはテンプレート変更ブロックで記述されます）です。
Template Change Block
テンプレート変更ブロック
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID | Number of Keys |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Key Block ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ... ... ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Key Block ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Template ID: 16 bit unsigned integer
テンプレートID：16ビット符号なし整数
See Section 4.6.
セクション4.6を参照してください。
Number of Keys: 16 bit unsigned integer
キー数：16ビット符号なし整数
See Section 4.6.
セクション4.6を参照してください。
Key Block
キーブロック
See Section 4.6, only relevant keys are described.
セクション4.6を参照してください。関連するキーのみが説明されています。
Description
説明
The Final Template Data message is sent by a CRANE client to all the CRANE servers in a session, to convey the finalize templates. It is similar to the TMPL DATA message, with the only difference that a server must accept the templates in this message.
最終的なテンプレートデータメッセージは、ファイナライズテンプレートを伝えるために、セッション内のすべてのクレーンサーバーにクレーンクライアントによって送信されます。TMPLデータメッセージに似ており、サーバーがこのメッセージのテンプレートを受け入れる必要があるという唯一の違いがあります。
Message Format
メッセージ形式
Identical to the TMPL DATA (see section 4.6)
TMPLデータと同じ（セクション4.6を参照）
Message ID (MID)
メッセージID（MID）
0x12 Final Template Data
0x12最終テンプレートデータ
Description
説明
The CRANE server acknowledges reception of the TMPL DATA or FINAL TMPL DATA by sending a Final Template Data Acknowledge message. It does not carry any changes to the templates. Unlike TMPL DATA ACK messages, a FINAL TMPL DATA ACK message indicates the acceptance of the templates for the session. A server MAY respond with this message to a TMPL DATA (if it does not want any changes in the templates). A server MUST respond with this message to a FINAL TMPL DATA.
クレーンサーバーは、最終的なテンプレートデータ確認メッセージを送信することにより、TMPLデータまたは最終TMPLデータの受信を確認します。テンプレートの変更はありません。TMPLデータACKメッセージとは異なり、最終的なTMPLデータACKメッセージは、セッションのテンプレートの受け入れを示します。サーバーは、このメッセージでTMPLデータに応答する場合があります（テンプレートに変更が必要ない場合）。サーバーは、このメッセージで最終的なTMPLデータに応答する必要があります。
Message Format
メッセージ形式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | MID=0x13 | Session ID | Message Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Config. ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Configuration ID: 8 bit unsigned char
構成ID：8ビット符号なしChar
See Section 4.6. This field MUST copy the configuration ID from the acknowledged message.
セクション4.6を参照してください。このフィールドは、確認されたメッセージから構成IDをコピーする必要があります。
Description
説明
The Get Sessions message is sent by a CRANE server to a CRANE client to query what are the sessions it should participate. This is typically done just before a UI configuration of the CRANE client's templates. As each session has its own set of templates, there is a need to know the server's participation of all the sessions.
Get Sessionsメッセージは、クレーンサーバーからクレーンクライアントに送信され、参加するセッションは何ですか。これは通常、クレーンクライアントのテンプレートのUI構成の直前に行われます。各セッションには独自のテンプレートセットがあるため、すべてのセッションのサーバーの参加を知る必要があります。
The Session ID field in the CRANE message header MUST be ignored by the receiver.
クレーンメッセージヘッダーのセッションIDフィールドは、受信機によって無視する必要があります。
Message Format
メッセージ形式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | MID=0x14 | Session ID | Message Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Request ID: 16 bit unsigned integer
リクエストID：16ビット符号なし整数
The Request ID field identifies the specific request issued by the server. The same Request ID MUST be placed in the responding message in order to associate it with the request.
リクエストIDフィールドは、サーバーが発行した特定の要求を識別します。同じ要求IDをリクエストに関連付けるために、応答メッセージに配置する必要があります。
Description
説明
The Get Sessions Response message is sent by a CRANE client to a CRANE server as a reply to a GET SESS request. The message MUST contain all the information related to any session with which the requesting server is associated.
Get Sessions Responseメッセージは、Get Sessリクエストへの返信としてクレーンクライアントからクレーンサーバーに送信されます。メッセージには、要求サーバーが関連付けられているセッションに関連するすべての情報を含める必要があります。
The Session ID field in the common message header MUST be ignored by the receiver.
一般的なメッセージヘッダーのセッションIDフィールドは、受信機によって無視する必要があります。
Message Format
メッセージ形式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | MID=0x15 | Session ID | Message Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID | Number of Sessions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor String Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |
~ Vendor String ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Session Block ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ... ... ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Session Block ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Request ID: 16 bit unsigned integer
リクエストID：16ビット符号なし整数
See Section 4.10.
セクション4.10を参照してください。
Number of Sessions: 16 bit unsigned integer
セッションの数：16ビット署名されていない整数
The Number of Sessions field is the number of session blocks in the message.
セッションの数は、メッセージ内のセッションブロックの数です。
Vendor String Length: 16 bit unsigned integer
ベンダー文字列の長さ：16ビット符号なし整数
The Vendor String Length field is the length of Vendor String field in octet. The field limits vendor strings to 64Kb long. If no such string is supplied, the length MUST be set to 0.
ベンダー文字列長のフィールドは、Octetのベンダー文字列フィールドの長さです。フィールドは、ベンダーの文字列を長さ64kbに制限します。そのような文字列が提供されない場合、長さは0に設定する必要があります。
Vendor String: Variable length unsigned char
ベンダー文字列：可変長さ符号なしchar
The Vendor String field is a variable length field. It identifies the vendor that created the session. It MUST be padded with 0 to the next 32 bit boundary. The information differentiates similar templates from different vendors. The actual format of the information is application specific and outside the scope of this document.
ベンダー文字列フィールドは、可変長さフィールドです。セッションを作成したベンダーを識別します。次の32ビットの境界から0でパッドでパッドにする必要があります。この情報は、同様のテンプレートをさまざまなベンダーと区別します。情報の実際の形式は、アプリケーション固有であり、このドキュメントの範囲外です。
Session Block
セッションブロック
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID | Reserved | Session Name Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Description Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Session Name ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Session Description ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Session ID: 8 bit unsigned char
セッションID：8ビット符号なしchar
See Section 3.
セクション3を参照してください。
Session Name Length: 16 bit unsigned integer
セッション名の長さ：16ビット符号なし整数
The Session Name Length field is the length of the Session Name field. The field limits the session name strings to 64 Kb long. As a name is mandatory to differentiate between sessions, this field MUST NOT be 0.
セッション名の長さフィールドは、セッション名フィールドの長さです。フィールドは、セッション名の文字列を長さ64 kbに制限します。セッションを区別するには名前が必須であるため、このフィールドは0であってはなりません。
Session Description Length: 16 bit unsigned integer
セッションの説明長：16ビット署名されていない整数
The Session Description Length field is the length of a session description. The field limits the session description to 64Kb long. If no such Description is supplied, the length MUST be set to 0.
セッションの説明長のフィールドは、セッションの説明の長さです。このフィールドは、セッションの説明を長さ64kbに制限します。そのような説明が提供されていない場合、長さは0に設定する必要があります。
Session Name: Variable length unsigned char
セッション名：可変長さ符号なしchar
The Session Name field is the name for a session, which MAY be displayed to end-users. It MUST be padded with 0 to the next 32 bit boundary. Session Name MUST be unique within a CRANE client. This field is mandatory and MUST be a part of any Session Block.
セッション名フィールドはセッションの名前であり、エンドユーザーに表示される場合があります。次の32ビットの境界から0でパッドでパッドにする必要があります。セッション名は、クレーンクライアント内で一意でなければなりません。このフィールドは必須であり、セッションブロックの一部である必要があります。
Session Description: Variable length unsigned char
セッションの説明：可変長さ符号なしchar
The Session Description field is the text description of a session; it could be displayed to end-users. It MUST be padded with 0 to the next 32 bit boundary.
セッションの説明フィールドは、セッションのテキスト説明です。エンドユーザーに表示できます。次の32ビットの境界から0でパッドでパッドにする必要があります。
Description
説明
The Get Templates message is sent by a CRANE server to a CRANE client to query templates in a session.
Get Templatesメッセージは、セッションでテンプレートを照会するためにクレーンサーバーからクレーンクライアントに送信されます。
Message Format
メッセージ形式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | MID=0x16 | Session ID | Message Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Request ID: 16 bit unsigned integer
リクエストID：16ビット符号なし整数
See Section 4.10.
セクション4.10を参照してください。
Description
説明
The Get Templates Response message is sent by a CRANE client to a CRANE server as a response to a GET TMPL message. The message SHOULD contain all templates available for the specific session.
GET TMPLメッセージへの応答として、Get Templates ResponseメッセージはCraneクライアントからクレーンサーバーに送信されます。メッセージには、特定のセッションで使用可能なすべてのテンプレートを含める必要があります。
Message Format
メッセージ形式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | MID=0x17 | Session ID | Message Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID | Number of Templates |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Template Block ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ... ... ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Template Block ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Request ID: 16 bit unsigned integer
リクエストID：16ビット符号なし整数
See Section 4.10.
セクション4.10を参照してください。
Number of Templates: 16 bit unsigned integer
テンプレートの数：16ビット符号なし整数
See Section 4.6.
セクション4.6を参照してください。
Template Block
テンプレートブロック
Same as the template block defined in the TMPL DATA message (see Section 4.6). However, Extended Key Blocks MUST be used instead of Key Blocks. Extended key Block field provides extensive informational data that MAY be displayed to end-users.
TMPLデータメッセージで定義されているテンプレートブロックと同じ（セクション4.6を参照）。ただし、キーブロックの代わりに拡張キーブロックを使用する必要があります。拡張キーブロックフィールドは、エンドユーザーに表示される可能性のある広範な情報データを提供します。
Extended Key Block
拡張キーブロック
The Extended Key Block field provides comprehensive information about a key.
拡張キーブロックフィールドは、キーに関する包括的な情報を提供します。
Extended Key Block Format:
拡張キーブロック形式：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Type ID | Key Name Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Label Length | Key Help Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Key Name ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Key Label ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Key Help ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Attribute Vector |K|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key ID: 32 bit unsigned integer
キーID：32ビット符号なし整数
Same as section 4.6.
セクション4.6と同じ。
Key Type ID: 16 bit unsigned integer
キータイプID：16ビット符号なし整数
Same as section 4.6.
セクション4.6と同じ。
Key Name Length: 16 bit unsigned integer
キー名の長さ：16ビット符号なし整数
The Key Name Length field is the length of the Key Name field. The field limits Key Name strings to 64 Kb long. As a name is mandatory to a key, this field MUST NOT be 0.
キー名の長さフィールドは、キー名フィールドの長さです。フィールドは、キー名の文字列を長さ64 kbに制限します。名前はキーに必須であるため、このフィールドは0であってはなりません。
Key Label Length: 16 bit unsigned integer
キーラベルの長さ：16ビット符号なし整数
The Key Label Length field is the length of the Key Label field. The field limits Key Label strings to 64 Kb long. Length of 0 means that the Label field is to be skipped.
キーラベルの長さフィールドは、キーラベルフィールドの長さです。フィールドは、キーラベルの文字列を長さ64 kbに制限します。0の長さは、ラベルフィールドをスキップすることを意味します。
Key Help Length: 16 bit unsigned integer
キーヘルプ長：16ビット署名されていない整数
The Key Help Length field is the length of the Key Help field. The field limits Key Help strings to 64 Kb long. Length of 0 means that the Help field is to be skipped.
キーヘルプ長のフィールドは、キーヘルプフィールドの長さです。このフィールドは、キーのヘルプを64 kbの長さに制限します。0の長さは、ヘルプフィールドをスキップすることを意味します。
Key Name: Variable length unsigned char
キー名：可変長さ符号なしの文字
The Key Name field is the name for the key, which could be displayed to end users. It MUST be padded with 0 to the next 32 bit boundary. Key Name MUST be unique (within the template) and case sensitive. This field is mandatory and MUST be a part of any Extended Key Block.
キー名フィールドは、エンドユーザーに表示できるキーの名前です。次の32ビットの境界から0でパッドでパッドにする必要があります。キー名は（テンプレート内）一意であり、ケースに敏感でなければなりません。このフィールドは必須であり、拡張されたキーブロックの一部である必要があります。
Key Label: Variable length unsigned char
キーラベル：可変長さ符号なしchar
The Key Label field is a descriptive label, which could be displayed to end users concerning this key. It MUST be padded with 0 to the next 32 bit boundary. This field SHOULD be a part of any Extended Key Block.
キーラベルフィールドは、このキーに関するエンドユーザーに表示できる説明ラベルです。次の32ビットの境界から0でパッドでパッドにする必要があります。このフィールドは、拡張されたキーブロックの一部である必要があります。
Key Help: Variable length unsigned char
キーヘルプ：可変長さ符号なしチャー
The Key Help field is any Help string that could be displayed to end users concerning this key. It MUST be padded with 0 to the next 32 bit boundary. This field MAY be a part of any Extended Key Block.
キーヘルプフィールドは、このキーに関するエンドユーザーに表示できるヘルプストリングです。次の32ビットの境界から0でパッドでパッドにする必要があります。このフィールドは、拡張されたキーブロックの一部である可能性があります。
Key Attribute Vector: 32 bit unsigned integer
キー属性ベクトル：32ビット符号なし整数
Same as section 4.6.
セクション4.6と同じ。
Description
説明
The Start Negotiation message is sent by a CRANE server after the configuration process has completed. The message should initiate template negotiation by the client with all CRANE servers in a session. The CRANE server MAY re-send this message up to 3 times with repeat interval of 5 seconds unless it is acknowledged by the CRANE client. Otherwise, the CRANE user will be informed. The client should send TMPL DATA message to the servers after acknowledged the message.
開始ネゴシエーションメッセージは、構成プロセスが完了した後にクレーンサーバーによって送信されます。メッセージは、セッションですべてのクレーンサーバーを使用して、クライアントによるテンプレートネゴシエーションを開始する必要があります。クレーンサーバーは、クレーンクライアントによって認められない限り、5秒の繰り返し間隔でこのメッセージを最大3回再除去できます。それ以外の場合、クレーンユーザーに通知されます。クライアントは、メッセージを確認した後、TMPLデータメッセージをサーバーに送信する必要があります。
Message Format
メッセージ形式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | MID=0x18 | Session ID | Message Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Description
説明
The Start Negotiation Acknowledge message MUST be sent by a CRANE client to the server to acknowledge the reception of the START NEGOTIATE message.
開始交渉承認メッセージは、Crane Clientがサーバーに送信する必要があります。
Message Format
メッセージ形式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | MID=0x19 | Session ID | Message Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Description
説明
The DATA message carries actual data records from a CRANE client to a CRANE server. A data record is a structured collection of fields that matches a specific template.
データメッセージは、クレーンクライアントからクレーンサーバーに実際のデータレコードを伝えます。データレコードは、特定のテンプレートに一致するフィールドの構造化されたコレクションです。
Message Format
メッセージ形式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | MID=0x20 | Session ID | Message Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID | Config. ID | Flags |D|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Sequence Number (DSN) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Record Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Template ID: 16 bit unsigned integer
テンプレートID：16ビット符号なし整数
See Section 4.6.
セクション4.6を参照してください。
Configuration ID: 8 bit unsigned char
構成ID：8ビット符号なしChar
See Section 4.6. The Config. ID field can prevent out-of-the-blue messages with outdated templates arriving and erroneously processed. A server MAY keep a short history of templates in order to cope with this scenario.
セクション4.6を参照してください。構成。IDフィールドは、時代遅れのテンプレートが到着し、誤って処理される青いメッセージを防ぐことができます。サーバーは、このシナリオに対処するために、テンプレートの短い履歴を保持する場合があります。
Flags: 8 bit unsigned char
フラグ：8ビット符号なしチャー
The Flags field is composed of flag bits that indicate processing requirements of the data records. The CRANE Version 1 defined two flags for these purposes. Unless otherwise specified, the other flags are set to zero on transmit and are ignored on receipt.
フラグフィールドは、データレコードの処理要件を示すフラグビットで構成されています。クレーンバージョン1は、これらの目的のために2つのフラグを定義しました。特に指定されていない限り、他のフラグは送信時にゼロに設定され、受領時に無視されます。
The following flags are defined in CRANE Version 1:
次のフラグは、クレーンバージョン1で定義されています。
The 'D' bit ('Duplicate' bit): It is set for records that are re-sent to an alternate server after a server transition occurs. When the same records are sent to different servers, there is a possibility that duplicated data exists. The Status of the 'D' bit will help the billing/mediation system to perform de-duplication if desired.
「D」ビット（「Duplicate」ビット）：サーバーの遷移が発生した後に代替サーバーに再セントするレコード用に設定されています。同じレコードが異なるサーバーに送信されると、複製されたデータが存在する可能性があります。「d」ビットのステータスは、請求/調停システムが必要に応じて重複排除を実行するのに役立ちます。
The 'S' bit ('DSN Synchronize' bit): When set, it indicates that the record is the first one received by the server after starting (or restarting) of data transmission to this server. The server MUST set the initial DSN to the DSN specified in the record. The flag is set to zero by default.
's'ビット（ 'dsn synchronize'ビット）：設定すると、このサーバーへのデータ送信を開始（または再起動）した後にサーバーが最初に受信したレコードであることを示します。サーバーは、最初のDSNをレコードで指定されたDSNに設定する必要があります。フラグはデフォルトでゼロに設定されています。
Data Sequence Number: 32 bit unsigned integer
データシーケンス番号：32ビット符号なし整数
The Data Sequence Number field is the record sequence number used for preserving data orders and detecting data losses. The DSN MUST be incremented by one for each new record transmitted. The selection of the initial DSN number is implementation specific.
データシーケンス番号フィールドは、データ注文の保存とデータ損失の検出に使用されるレコードシーケンス番号です。DSNは、送信される新しいレコードごとに1つずつ増加する必要があります。初期DSN番号の選択は実装固有です。
Record Data: Variable Length unsigned octets
記録データ：可変長さ符号なしオクテット
The Record Data field carries the actual accounting/billing data that is structured according to the template identified by the Template ID field.
レコードデータフィールドには、テンプレートIDフィールドによって識別されたテンプレートに従って構成された実際の会計/請求データが含まれます。
Description
説明
The Data Acknowledgement message is sent from a CRANE server to acknowledge receipt of records. It acknowledges the maximal in-sequence DSN received.
データ承認メッセージは、レコードの受領を確認するためにクレーンサーバーから送信されます。受信した最大のシーケンスDSNを認めます。
Message Format
メッセージ形式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | MID=0x21 | Session ID | Message Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Config. ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Sequence Number: 32 bit unsigned integer
データシーケンス番号：32ビット符号なし整数
See Section 4.16. It MUST be DSN of the last in-sequence record that was received by the server.
セクション4.16を参照してください。サーバーが受信したのは、最後のシーケンスレコードのDSNでなければなりません。
Configuration ID: 8 bit unsigned char
構成ID：8ビット符号なしChar
See Section 4.16.
セクション4.16を参照してください。
Description
説明
The Error message MAY be issued by either a CRANE server or client. It indicates an error condition that was detected by the sender.
エラーメッセージは、クレーンサーバーまたはクライアントのいずれかによって発行される場合があります。これは、送信者によって検出されたエラー条件を示します。
Message Format
メッセージ形式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | MID=0x23 | Session ID | Message Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | Description Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Description ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Timestamp: 32 bit unsigned integer
タイムスタンプ：32ビット符号なし整数
The Timestamp field is a timestamp in seconds since 00:00:00 GMT, January 1, 1970.
タイムスタンプフィールドは、1970年1月1日、00:00:00 GMT以来の数秒でタイムスタンプです。
Error Code: 16 bit unsigned integer
エラーコード：16ビット符号なし整数
The Error Code field is a code assigned to an error condition.
エラーコードフィールドは、エラー条件に割り当てられたコードです。
The following error codes are defined in CRANE Version 1:
次のエラーコードは、クレーンバージョン1で定義されています。
Error Condition Error Code
----------- --------------
Unknown 0
Description Length: 16 bit unsigned integer
説明長：16ビット署名されていない整数
The Description Length field is the length of the Description field. The field limits Description strings to 64 Kb long. Length of 0 means that the Description field is to be skipped.
説明の長さフィールドは、説明フィールドの長さです。フィールドは、文字列を長さ64 kbに制限します。0の長さは、説明フィールドをスキップすることを意味します。
Description: Variable Length unsigned char
説明：可変長さ符号なしの文字
The Description field is a text description that allows the sender to provide more detailed information about the error condition. It MUST be padded with 0 to the next 32 bit boundary.
説明フィールドは、送信者がエラー条件に関するより詳細な情報を提供できるようにするテキストの説明です。次の32ビットの境界から0でパッドでパッドにする必要があります。
Description
説明
CRANE servers MAY inquire general operation status of a client by sending the Status Request message. The status information SHOULD include a collection of states, counters, accumulators of the data collection functions that reside with the client. The status MAY include more information about the CRANE client itself.
クレーンサーバーは、ステータスリクエストメッセージを送信して、クライアントの一般的な操作ステータスに問い合わせることができます。ステータス情報には、クライアントに存在する状態、カウンター、データ収集関数の蓄積者のコレクションを含める必要があります。ステータスには、クレーンクライアント自体に関する詳細情報が含まれる場合があります。
The status reporting mechanism relies on the status template of a session. It is determined similarly as other templates. Without a determined status template, no status information can be delivered.
ステータスレポートメカニズムは、セッションのステータステンプレートに依存しています。他のテンプレートと同様に決定されます。決定されたステータステンプレートがなければ、ステータス情報を配信することはできません。
Message Format
メッセージ形式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | MID=0x30 | Session ID | Message Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Description
説明
The Status Response message contains a status report that MUST be compatible with the status template of the session. It is client's response to a STATUS REQ message from a server.
ステータス応答メッセージには、セッションのステータステンプレートと互換性がある必要があるステータスレポートが含まれています。これは、サーバーからのステータスREQメッセージに対するクライアントの応答です。
Message Format
メッセージ形式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | MID=0x31 | Session ID | Message Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID | Reserved |Config. ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Record Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Template ID: 16 bit unsigned integer
テンプレートID：16ビット符号なし整数
See Section 4.6.
セクション4.6を参照してください。
Configuration ID: 8 bit unsigned integer
構成ID：8ビット符号なし整数
See Section 4.6. The version is needed here to prevent out-of-the-blue messages with outdated templates arriving and erroneously processed. A server MAY keep a short history of templates in order to cope with this scenario.
セクション4.6を参照してください。このバージョンは、時代遅れのテンプレートが到着して誤って処理された青いメッセージを防ぐために必要です。サーバーは、このシナリオに対処するために、テンプレートの短い履歴を保持する場合があります。
Record Length: 32 bit unsigned integer
レコード長：32ビットの署名整数
The Record Length field is the length of the Record Data field in octets.
レコードの長さフィールドは、オクテットのレコードデータフィールドの長さです。
Record Data: Variable Length unsigned octets
記録データ：可変長さ符号なしオクテット
The Record Data field contains the status data that complies with the status template. For more details see section 2.4
レコードデータフィールドには、ステータステンプレートに準拠するステータスデータが含まれています。詳細については、セクション2.4を参照してください
5 Protocol Version Negotiation
5プロトコルバージョンの交渉
Since the CRANE protocol may evolve in the future and it may run over different transport layers, a transport neutral version negotiation mechanism running over UDP is defined. A CRANE server MAY inquire a CRANE client about the CRANE protocol version and transport layer support by sending a UDP packet on an agreed UDP port. The client MUST respond to this request with a UDP packet carrying the protocol version, the transport type and the port number used for the specific transport. The Protocol Version Negotiation is optional for CRANE Version 1.
クレーンプロトコルは将来進化し、異なる輸送層を介して実行される可能性があるため、UDPを介して実行される輸送ニュートラルバージョンのネゴシエーションメカニズムが定義されています。クレーンサーバーは、Crane Protocolバージョンについてクレーンクライアントに問い合わせ、合意されたUDPポートにUDPパケットを送信することにより、レイヤーのサポートを輸送する場合があります。クライアントは、特定のトランスポートに使用されるプロトコルバージョン、トランスポートタイプ、およびポート番号を運ぶUDPパケットでこのリクエストに応答する必要があります。プロトコルバージョンのネゴシエーションは、クレーンバージョン1のオプションです。
The CRANE server sends the following message to query the client's protocol support.
クレーンサーバーは、クライアントのプロトコルサポートを照会するために次のメッセージを送信します。
Message Format
メッセージ形式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Server Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Server Boot Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 'C' | 'R' | 'A' | 'N' |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Server Address:
サーバーアドレス：
The Server Address field is the IP address (Ipv4) of the CRANE server.
サーバーアドレスフィールドは、クレーンサーバーのIPアドレス（IPv4）です。
Server Boot Time
サーバーブート時間
The Server Boot Time field is the timestamp of the last server startup in seconds from 1970.
サーバーブートタイムフィールドは、1970年の数秒での最後のサーバー起動のタイムスタンプです。
'C', 'R', 'A', 'N':
'c'、 'r'、 'a'、 'n'：
The 'C', 'R', 'A', 'N' fields are ASCII encoded characters to identify the CRANE server.
「c」、「r」、「a」、 'n'フィールドは、クレーンサーバーを識別するためのASCIIエンコード文字です。
The client's reply to a version negotiation request MUST comply with the following structure:
クライアントのバージョンネゴシエーションリクエストに対する返信は、次の構造に準拠する必要があります。
Message Format
メッセージ形式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Default Protocol Info |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Protocols Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Protocols Info |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Additional Protocols Info ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Protocols Info |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Default Protocol Info:
デフォルトのプロトコル情報：
The Default Protocol Info field contains information of the default protocol supported by the client. The field is structured as a Protocol Info Block described below.
デフォルトのプロトコル情報フィールドには、クライアントがサポートするデフォルトのプロトコルの情報が含まれています。フィールドは、以下で説明するプロトコル情報ブロックとして構成されています。
Additional Protocols Count: 32 bit unsigned integer
追加のプロトコルカウント：32ビット符号なし整数
The Additional Protocols Count field specifies the number of additional protocols supported by the client. In the case that only the default protocol is supported, the field MUST be set to 0.
追加のプロトコルカウントフィールドは、クライアントがサポートする追加のプロトコルの数を指定します。デフォルトのプロトコルのみがサポートされている場合、フィールドは0に設定する必要があります。
Additional Protocols Info:
追加のプロトコル情報：
The Additional Protocol Info field is an array of Protocol Info Blocks (described below) contain information about additional protocols supported by the client.
追加のプロトコル情報フィールドは、一連のプロトコル情報ブロック（以下で説明）に含まれています。クライアントがサポートする追加のプロトコルに関する情報が含まれています。
Protocol Info Block
プロトコル情報ブロック
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Number | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Transport Type: 32 bit unsigned integer
トランスポートタイプ：32ビット署名整数
1 - TCP, 2 - SCTP
1 -TCP、2 -SCTP
Protocol Version: 32 bit unsigned integer
プロトコルバージョン：32ビット符号なし整数
Version number of the CRANE protocol supported over the specific transport layer, the current version is 1.
特定の輸送層でサポートされているクレーンプロトコルのバージョン番号、現在のバージョンは1です。
Port Number: 16 bit unsigned integer
ポート番号：16ビット符号なし整数
Port number (either SCTP or TCP port) used for the protocol
プロトコルに使用されるポート番号（SCTPまたはTCPポートのいずれか）
6 Security Considerations
6つのセキュリティ上の考慮事項
The CRANE protocol can be viewed as an application running over a reliable transport layer, such as TCP and SCTP. The CRANE protocol is end-to-end in the sense that the CRANE messages are communicated between clients and servers identified by the host address and the transport protocol port number. Before any CRANE sessions can be initiated, a set of CRANE servers' addresses should be provisioned on a CRANE client. Similarly, a CRANE server maintains a list of CRANE clients' address with which it communicates. The provisioning is typically carried out securely using a network management system; in this way, the CRANE end-points can be authenticated and authorized. As this scheme is static, without additional security protections the CRANE protocol is vulnerable to attacks such as address spoofing.
クレーンプロトコルは、TCPやSCTPなどの信頼できる輸送層を介して実行されるアプリケーションと見なすことができます。クレーンプロトコルは、ホストアドレスとトランスポートプロトコルポート番号によって識別されるクライアントとサーバーの間でクレーンメッセージが通信されるという意味で、エンドツーエンドです。クレーンセッションを開始する前に、クレーンサーバーのアドレスのセットをクレーンクライアントにプロビジョニングする必要があります。同様に、クレーンサーバーは、通信するクレーンクライアントの住所のリストを維持しています。通常、プロビジョニングは、ネットワーク管理システムを使用して安全に実行されます。このようにして、クレーンのエンドポイントを認証および承認することができます。このスキームは静的であるため、追加のセキュリティ保護がなければ、クレーンプロトコルはアドレススプーフィングなどの攻撃に対して脆弱です。
The CRANE protocol itself does not offer strong security facilities; therefore, it cannot ensure confidentiality and integrity of CRANE messages. It is strongly recommended that users of the CRANE protocol evaluate their deployment configurations and implement appropriate security policies. For example, if the CRANE protocol is deployed over a local area network or a dedicated connection that ensure security, no additional security services or procedures may be required; however, if CRANE clients and servers are connected through the Internet, lower layer security services should be invoked.
クレーンプロトコル自体は、強力なセキュリティ施設を提供していません。したがって、クレーンメッセージの機密性と完全性を確保することはできません。クレーンプロトコルのユーザーが展開構成を評価し、適切なセキュリティポリシーを実装することを強くお勧めします。たとえば、クレーンプロトコルがローカルエリアネットワークまたはセキュリティを確保する専用の接続に展開されている場合、追加のセキュリティサービスや手順は必要ありません。ただし、クレーンクライアントとサーバーがインターネットを介して接続されている場合、下層セキュリティサービスを呼び出す必要があります。
To achieve a strong security protection of communications between CRANE clients and servers, lower layer security services are strongly recommended. The lower layer security services are transparent to the CRANE protocols. Security mechanisms may be provided at the IP layer using IPSEC [6], or it may be implemented for transport layer using TLS [7]. The provisioning of the lower layer security services is out of the scope of this document.
クレーンクライアントとサーバー間のコミュニケーションの強力なセキュリティ保護を実現するには、より低レイヤーセキュリティサービスを強くお勧めします。下層セキュリティサービスは、クレーンプロトコルに対して透明です。セキュリティメカニズムは、IPSEC [6]を使用してIPレイヤーで提供される場合があります。または、TLS [7]を使用して輸送層に実装される場合があります。下層セキュリティサービスのプロビジョニングは、このドキュメントの範囲外です。
7 References
7つの参照
[1] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[1] Rigney、C.、Willens、S.、Rubens、A。and W. Simpson、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、2000年6月。
[2] Calhoun, P., "DIAMETER Base Protocol", Work in Progress.
[2] Calhoun、P。、「直径ベースプロトコル」、進行中の作業。
[3] Calhoun, P., et. al., "DIAMETER Framework Document", Work in Progress.
[3] Calhoun、P.、et。al。、「直径フレームワークドキュメント」、進行中の作業。
[4] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Simple Control Transmission Protocol", RFC 2960, October 2000.
[4] Stewart、R.、Xie、Q.、Morneault、K.、Sharp、C.、Schwarzbauer、H.、Taylor、T.、Rytina、I.、Kalla、M.、Zhang、L。and V. Paxson、」Simple Control Transmission Protocol "、RFC 2960、2000年10月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[6] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[6] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[7] Dierks, T. and C. Allen, "The TLS Protocol, Version 1.0", RFC 2246, January 1999.
[7] Dierks、T。およびC. Allen、「TLSプロトコル、バージョン1.0」、RFC 2246、1999年1月。
8 Acknowledgments
8謝辞
Special thanks are due to Tal Givoly, Limor Schweitzer for conceiving the work, and Nir Pedhatzur, Batya Ferder, and Peter Ludemann from XACCT Technologies for accomplishing the first CRANE protocol implementation.
作品を妊娠したTal Givoly、Limor Schweitzer、およびNir Pedhatzur、Batya Ferder、およびPeter Ludemannの最初のクレーンプロトコルの実装を達成したことに感謝します。
Thanks are also due to Nevil Brownlee for his valuable comments on the work, as well as the IETF IPFIX WG.
また、Nevil Brownleeが仕事に関する貴重なコメントとIETF IPFIX WGに感謝します。
9 Authors' Addresses
9著者のアドレス
Kevin Zhang 10124 Treble Court Rockville, MD 20850 U.S.A.
Kevin Zhang 10124 Treble Court Rockville、MD 20850 U.S.A.
Phone +1 301 315 0033 EMail: kevinzhang@ieee.org
電話1 301 315 0033メール：kevinzhang@ieee.org
Eitan Elkin XACCT Technologies, Ltd. www.xacct.com 12 Hachilazon St. Ramat-Gan, Israel 52522
Eitan Elkin Xacct Technologies、Ltd。www.xacct.com 12 Hachilazon St. Ramat-Gan、イスラエル52522
Phone +1 972 3 576 4111 EMail: eitan@xacct.com
電話1 972 3 576 4111メール：eitan@xacct.com
10 Full Copyright Statement
10完全な著作権ステートメント
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
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エディター機能の資金は現在、インターネット協会によって提供されています。