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
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.
著作権（C）インターネット協会（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）/業務支援システムなどの任意のシステムへのネットワーク要素から主に会計データを任意のデータの効率的かつ信頼性の高い配信を可能にするネットワークエレメント（CRANE）プロトコルのための一般的な信頼性の高い会計を（定義しますOSS）。プロトコルは、ネットワーク、ストレージ、および処理リソースの効率的な利用とNEのから会計データの高いボリュームをエクスポートするための重要なニーズに対応するために開発されています。
This document specifies the architecture of the protocol and the message format, which MUST be supported by all CRANE protocol implementations.
この文書は、すべてのCRANEプロトコル実装によってサポートされなければならないプロトコルおよびメッセージ形式のアーキテクチャを指定します。
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はまた、サーバからクライアントに迷惑メッセージをサポートしていません。 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.
DIAMETER [2]基本的なRADIUSモデルを保持する新たなAAAプロトコルであり、RADIUSにいくつかの欠点を排除します。現在のDIAMETERプロトコルとその拡張は、インターネットおよびワイヤレスネットワークアクセスに焦点を当て、および会計への支援は密接に認証/認可イベントに関連付けられています。 DIAMETERは、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のCRANEプロトコルはこれらの重要な要件に対応するように設計されています。
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のような任意のシステムにネットワーク要素からのデータを占め、任意のデータの効率的かつ信頼性の高い配信を可能CRANEプロトコルを定義します。プロトコルは、ネットワーク、ストレージ、および処理リソースの効率的な利用とNEのから会計データの高いボリュームをエクスポートするための重要なニーズに対応するために開発されています。
This document specifies the architecture of the protocol and the message format, which MUST be supported by all CRANE protocol implementations.
この文書は、すべてのCRANEプロトコル実装によってサポートされなければならないプロトコルおよびメッセージ形式のアーキテクチャを指定します。
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.
この文書では、キーワード "MUST"、 "MUST NOT"、 "SHOULD"、[5] "はならない"、およびBCP 14に記載されるように解釈される "場合があります"。これらのキーワードは、この文書では大文字と小文字を区別しません。
CRANE Protocol
CRANEプロトコル
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.
CRANEは、ネットワーク要素のための一般的な信頼性の高い会計の略です。 CRANEプロトコルは多分CRANE、あるいはこの文書に記載されているプロトコルと呼ば。 CRANEプロトコルは、会計データを配信する目的で、クレーンのクライアントと一つまたは複数のCRANEサーバの間のインターフェース（複数可）で使用されています。
Client or CRANE Client
クライアントまたはクライアントCRANE
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.
CRANEクライアントは、クレーンプロトコルの側の製造データに実装です。これは、一般的に収集し、本明細書中で定義されたプロトコルを使用して調停/課金システムにアカウンティングデータを送信することを可能にする、ネットワーク要素のソフトウェアと統合されています。
Server or CRANE Server
サーバーまたはサーバーCRANE
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クライアントに接続され、複数のCRANEサーバーがあるかもしれません。
CRANE Session
CRANEセッション
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.
CRANEセッションは、会計データを配信する目的で、クレーンのクライアントと一つまたは複数のCRANEサーバ間の論理接続です。複数のセッションがCRANEクライアントまたはCRANEサーバで同時に維持することができます。それらは、セッション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.
CRANEサーバは優先順位値が割り当てられています。会計データは常にCRANEセッションの中で一番高い優先度値（プライマリサーバ）と（ビューのCRANEクライアントの観点から）、知覚の操作CRANEサーバーに配信されます。
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.
メッセージはCRANEプロトコルによって指定され、クレーンクライアントとCRANEサーバとの間のインターフェースを介して送信規則に従って符号化されます。これは、一般的CRANEヘッダおよび任意に制御またはユーザデータペイロードを含みます。
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.
CRANEプロトコルは確実に、効率的に、かつ迅速に会計データを提供するように設計されています。会計データの性質のために、大規模なレコードが頻繁に送信する必要があります。大記録のため、支援断片化が必要です。さらに、会計データに関連付けられた値が高くなります。データの損失を防ぐために、応答しないCRANEサーバの迅速な検出はまた、追加堅牢性のために必要とされます。
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.
CRANEプロトコルは、下位レイヤプロトコルによって提供されるデータ伝送サービスを使用するアプリケーションと見なすことができます。それは信頼性の高い、中・シーケンスのデータパケットを配信するために、トランスポート層プロトコルに依存しています。
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は、高速かつ機敏であることの利点を有する単純なコネクションレスのトランスポート層プロトコルであり、それには、信頼性を提供せず、フロー制御メカニズムを欠いています。したがって、CRANEプロトコルは悪それが上で実行されているネットワークに影響を与えるリスクを回避するために、トランスポート層プロトコルとして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つのトランスポート層プロトコルです。いずれか一方がCRANEメッセージを転送するために使用されるかもしれません。 TCPは、要件の一部を満たし、すべてではない（サーバ障害の、例えば、迅速な検出、TCPはストリーム指向していない記録指向であるということ）。したがって、SCTP [4] CRANEメッセージを送信するための好ましい方法です。
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:
CRANEプロトコルは、信頼性の高いトランスポート層プロトコル上で動作するアプリケーションです。トランスポート層プロトコルは、クレーンクライアントとCRANEサーバー間CRANEのメッセージを配信する責任があります。これは、次の機能をサポートする必要があります。
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.接続指向。最大2 ^ 32オクテットの長さを有するメッセージの配信3（すなわち、トランスポート層は、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.
会計データの信頼できる配信は、トランスポート層レベルとCRANEプロトコルレベルの両方によって達成されます。 CRANEプロトコルは、彼らが処理された後CRANEメッセージを承認し、会計情報が永続ストレージに配置されているが、トランスポート層肯定応答は、失われたデータパケットと応答しないサーバの迅速な検出を保証するために使用されています。
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.
CRANEサーバーにCRANEクライアントから流れるトラフィックは、ほとんどのデータを占めている、会計データを提供するための信頼性の高いプロトコルであること。彼らはトラフィックのみの小さな部分で構成するものの、双方向の制御メッセージ交換は、もあります。
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は、クレーンプロトコルのトランスポート層として使用することができます。 CRANEは、以下の規則に従わなければなりません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. CRANEクライアントは、特定のTCPポート上のTCP接続を受け入れなければなりません。 2. CRANEサーバはCRANEクライアントに接続する必要があり、および障害が発生した場合に接続を再確立するための責任を負わなければなりません。 3. CRANEメッセージは、クレーン・メッセージのサイズがCRANEメッセージヘッダにメッセージ長フィールドによって指定された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.
改善された信頼性およびロバスト性の目的のために、冗長CRANEサーバー構成を採用してもよいです。 CRANEプロトコルは、仲介システムまたはBSSの一部とすることができる代替CRANEサーバーに課金データを配信するサポート。
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.
CRANEセッションは、一つ以上のCRANEサーバから構成されてもよいです。 CRANEクライアントがセッションに属するすべてのCRANEサーバのネットワークアドレスを設定するための責任があります。サーバーの優先順位は、各CRANEサーバーに割り当てられています。サーバーの優先順位は、会計データを受け取るべきCRANEサーバに関するCRANEクライアントの好みを反映しています。サーバーの優先順位の割り当ては、いくつかのCRANEサーバが同じ優先順位を持つことも可能である地理的な距離などの要因、通信コスト、およびCRANEサーバーの負荷などを考慮すべきです。この場合、CRANEクライアントは、ランダムに会計データを提供するために、プライマリサーバとしてそれらのいずれかを選択できます。
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.
そのような負荷分散などの追加機能は、マルチサーバ環境で実装することができます。 CRANEクライアントを構成するプロセスには、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.
CRANEクライアントが最優先でその認知運転CRANEサーバにアカウンティングデータを提供しなければなりません。このCRANEサーバが到達不能と判断される場合には、CRANEクライアントが動作するように知覚される次の優先順位が最も高いCRANEサーバにアカウンティングデータを提供しなければなりません。何の認知運転CRANEサーバが利用できない場合は任意のCRANEサーバが利用可能であるか、クライアントのキュースペースがなくなるまで、会計データはCRANEクライアントにキューイングされなければなりません。アラームはキューオーバーフロー条件のCRANEユーザーに通知するために生成する必要があります。
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.
CRANEプロトコルはCRANEクライアントが実装の問題と考えられている他のCRANEサーバにアカウンティングデータをリダイレクトする方法を指定しません。しかし、すべての支持機構は、複数のサーバ環境（例えば、テンプレートの交渉プロセス、および構成手順など）で動作するプロトコルによって提供されます。 （一緒にいくつかの他の手段によって）輸送層は、サーバーの応答性を監視し、いずれかの障害のためにCRANEプロトコルを通知する責任があります。クライアントは、代替サーバに移行することもできます。
Implementation Note:
実装上の注意：
The transition to an alternate CRANE server is an implementation issue and should occur under the following conditions:
代替CRANEサーバーへの移行は、実装上の問題であり、以下の条件下で起こるべきです。
A) Transport layer notifies the CRANE client that the corresponding port of the CRANE server is unresponsive.
A）トランスポート層は、CRANEサーバの対応するポートが応答しないCRANEクライアントに通知します。
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）STOPメッセージは、アクティブサーバから受信されます。
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.
CRANEプロトコルは、会計データの効率的な配信を可能にします。これは、実際の会計データが配信される前にCRANEセッションのためのデータテンプレートのセットを交渉することによって達成されます。データテンプレートは、データ・タイプ、意味、およびペイロードのフィールドの位置を記述することにより、データメッセージのペイロードの構造を定義します。セッションテンプレートに同意することにより、CRANEサーバはCRANEクライアントから受信したデータメッセージを処理する方法を理解します。その結果、CRANEクライアントは、データのみのいずれかの記述子を付けずに、実際の会計データを提供する必要があります。これは、通信リンクを介して送信されたバイトの量を減少させます。
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ビット長の符号なし整数であるキーとすることができます）。 CRANEクライアントは、通常のキーを定義します。
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.
CRANEプロトコルは、（異なる会計記録のために）、同時にいくつかのテンプレートの使用をサポートしています。テンプレートに含まれているキーを有効または無効にすることができました。有効なキーは、発信データレコードがキーで指定されたデータ項目が含まれていることを意味します。無効なキーは、発信記録が指定されたデータ項目を省略することを意味します。有効化/無効化機構は、さらに、帯域幅要件を低減します。唯一必要なデータ項目が生成されるように、それはまた、ネットワーク要素の処理を減らすことができます。
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.
CRANEのセッションでは、すべてのCRANEサーバとCRANEクライアントは、テンプレートの同じセットを使用すると、関連する/無効状態を有効にする必要があります。エンド・アプリケーションへのテンプレート設定と接続がすべてのサーバーで同じでなければなりません。それは、テンプレートに基づいてデータを送信するために開始する前にCRANEクライアントは、ユーザーの設定によってセッション内のすべてのCRANEサーバーに関連したテンプレートを公開する必要があります。
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.
CRANEクライアントに常駐しているテンプレートの完全なセットは、テンプレートセットを識別する構成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.
前に述べたように、すべてのCRANEサーバはCRANEセッションでテンプレートの同じセットを使用しなければなりません。サーバは、テンプレートの同じセットを共有していないという場合には（異なるキーが有効か無効場合テンプレートが異なると考えられている）、クライアントとサーバ間の交渉プロセスが最終的に全員が受け入れられ、使用されているテンプレートの1セットを決定するであろうセッション中CRANEサーバ。
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.
CRANEセッションが確立され、サーバがセッションに参加する準備ができていることを示すSTARTメッセージを送信した後、クライアントはサーバにTMPLデータメッセージを送信することにより、使用しようとする一連のテンプレートを提供しなければなりません。 CRANEサーバは、テンプレートのセットの受信を確認しなければなりません。
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.
テンプレートはCRANEクライアントとCRANEのサーバー間で交渉しています。 CRANEサーバは、テンプレートへの変更を提案することができる（例えば、いくつかのキーを有効にし、他を無効）CRANEクライアントから受信した、またはあるように、テンプレートを確認することができます。テンプレートまたはキーが（サーバーの構成が完了した後などは、彼らがクライアントに追加される場合があります）サーバーによって認識されていない場合、サーバは不要避けるために、未知の各キーまたは未知のテンプレートを無効にすることを選ぶかもしれトラフィック。すべてのキーが無効になっているとき、テンプレートが無効になっています。変更がCRANEサーバから受信した場合、クライアントは（FINAL_TMPL_DATAメッセージを使用して）接続されているすべてのサーバに設定変更されたテンプレートを送信します。セッションで使用するテンプレートの最終セットになるかを決定するためのクライアントの責任です。このとき、各CRANEサーバは、（デッドロックやループ状態を回避するために）何も変更せずに、テンプレートを受け入れ、承認しなければなりません。各CRANEサーバは、ネゴシエーションプロセス中にすべての変更を提案するための単一のチャンスを与えられています。
The template negotiation process is outlined as follows:
次のようにテンプレートの交渉プロセスが概説されています。
A) CRANE client sends a TMPL DATA message with a set of templates.
A）CRANEクライアントは、テンプレートのセットで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).
いずれかのテンプレートセットの変化にTMPL DATA ACKメッセージで応答する（処理はステップCで継続）または変更が必要ない場合FINAL TMPL DATA ACKメッセージで応答B）CRANEサーバ（プロセス）は、ステップ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）CRANEクライアントは、可能な場合は、それらを組み込んで、提案された変更を受信してから）の変更を展開するためにすべてのサーバー（へのテンプレートの新しいセットを含むFINAL 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）CRANEサーバは、テンプレートの新しいセットを含む最終TMPLデータメッセージを受信して、テンプレートの受信を確認するためにFINAL TMPL DATA 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）CRANEクライアントは、サーバからFINAL TMPL DATA 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.
これらのすべての段階はテンプレートセットの違いで複数のCRANEサーバがある場合にのみ、場所を取る（例えば、すべてのキーの状態は同じです）。正確にセッション共有内のすべてのCRANEサーバと同じ構成の場合は、すべてのサーバは、FINAL TMPL DATA ACKで応答し、クライアントとサーバ間のピンポンはすぐに終了します。これは一般的なケースですが、いくつかの他のCRANEサーバが異なる構成を有している場合には、プロトコルがCRANEサーバ間の一貫性を維持する方法を提供しています。
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データメッセージは、テンプレートを展開し、公表を可能に、テンプレートセットを設定する必要性が依然として存在します。 CRANEセッションでCRANEサーバの各々は、典型的にはユーザインタフェースを介して、エンドユーザによって要求されたテンプレートセットを、変更することがあります。エンドユーザーはテンプレートが利用可能であり、現在のテンプレートセット状態かを知る必要がある場合は、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）サーバはCRANEクライアントからGET TMPLメッセージを発行することによって変更を必要とするテンプレートセットを取得する必要があります。それはまだSTARTメッセージを発行していない場合でも、サーバーがTMPL GETを発行することができます。
B) After received a GET TMPL message, the client sends back a GET TMPL RSP message with the requested data.
GETのTMPLメッセージを受信した後B）、クライアントは、要求されたデータを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）サーバは、テンプレートに必要な変更を行い、START交渉メッセージを送り返します。このメッセージは、CRANEサーバによって行われた変更を問い合わせるCRANEクライアントをトリガします。
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メッセージを交渉STARTを受信した後に）、クライアントはTMPLデータメッセージが続くACKメッセージを交渉開始に応答しなければなりません。この時点から、テンプレートの交渉プロセスが開始されます。
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.
テンプレートが展開された後、データメッセージは、プライマリサーバCRANE（CRANEセッション内で最も優先度の高い業務1）に到着し始めます。各データメッセージは、データシーケンス番号（DSN）が含まれています。主CRANEサーバは、それが中・シーケンスであるとしてデータを受け入れなければなりません。アウト・オブ・シーケンスデータメッセージは破棄されなければなりません。
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.
それは起動後またはサーバの移行後のどちらか最初のDATAメッセージを受信したときにCRANEサーバは、会計データの開始を検知します。最初のDATAメッセージは、クレーンのクライアントによって設定された「S」ビット（「DSN同期」ビット）が必要。最初のDSNとのメッセージを受信すると、サーバーは、すべてのインシーケンスデータメッセージを受け入れなければなりません。 DSNは、クライアントから発信それぞれの新しいDATAメッセージのために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.
CRANEサーバは、DATA ACKメッセージを送信することにより、データメッセージの受信、正しい処理を確認する必要があります。 DATA ACKは、最後に処理におけるシーケンスDATAメッセージのDSNを含まなければなりません。 CRANEサーバは、シーケンスデータメッセージのアウトを受信した場合、また、データ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.
CRANEクライアントは、すべてのレコードを提供する責任があります。 1台のサーバがすべてのレコードを受信しませんが、同じ仲介システムのための別の冗長CRANEサーバーは、レコードの残りの部分を受信した場合に冗長サーバ構成の場合には、シナリオがあるかもしれません。例えば、サーバ＃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.
課金/仲介システムは、最終的には、おそらく、複数のCRANEサーバーを介して、すべてのレコードを受け取ります。 CRANEのクライアントは、課金/仲介システムに受け取ったすべてのレコードを伝えなければなりません。これは、課金/仲介システムで重複するレコードをもたらすことができます。この場合、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.
未確認レコードの量がしきい値に達すると、タイマーが開始されなければなりません。タイマが満了すると、全ての未確認のレコードは、DATAメッセージに設定「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.
CRANEフロー制御は、冗長サーバ構成をサポートしています。サーバは、「準備完了」状態に移行するために、STARTメッセージを送らなければなりません。 「準備完了」状態では、サーバはCRANEメッセージを受信して処理することができます。 「準備完了」状態のままにして、メッセージがクライアントからの流れを停止するには、サーバがクライアントにSTOPメッセージを送信する必要があります。
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:
CRANEサーバは、クライアントとのセッションを確立した後にクエリーメッセージを送信することにより、CRANEクライアントのステータスを問い合わせることができます。サーバーに接続されているCRANEクライアントは、応答メッセージで応じなければなりません。すべてのクエリメッセージはCRANEサーバによって開始されなければなりません。 CRANEプロトコルは3つのこのようなクエリメッセージのペアを定義し、それらは：
Get Session (GET SESS) Get Session Response (GET SESS RSP)
取得セッション（SESSをGET）を取得し、セッション応答（SESS RSPをGET）
Get Template (GET TMPL) Get Template Response (GET TMPL RSP)
取得テンプレート（TMPLをGET）取得テンプレート応答（TMPL RSPをGET）
Status Request (STATUS REQ) Status Response (STATUS RSP)
ステータス要求（STATUS REQ）ステータス応答（STATUS 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サーバーの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.
CRANEクライアントが収集し、収集したデータ（カウンタ、統計情報など）に関するメタデータを送信すべきです。これは、これらのテンプレートは/「ステータス」ビットでマークされていることを除いて、他のテンプレートと同様に扱われ、ステータステンプレートを作成することによって行われます。ステータステンプレートはSTATUSのREQとSTATUS RSPメッセージのセットで使用されています。サーバーはCRANEクライアントにステータスREQを発行し、要求されたデータとステータスRSPメッセージを受信することができます。
A CRANE client MAY deliver accounting data to different mediation/billing systems by establishing different CRANE sessions.
CRANEクライアントは異なるCRANEセッションを確立することによって、異なる調停/課金システムへの会計データを配信することができます。
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.
各セッションは、冗長構成のいくつかのCRANEサーバから構成されてもよいです。すべてCRANEメッセージに埋め込まれたセッションIDはCRANEユーザーとCRANEセッションの正しい関連付けを可能にします。全てCRANEプロセス（例えば、テンプレートネゴシエーション、構成、フロー制御、等）は、マルチセッションシナリオで同様に行われるべきです。
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.
CRANEサーバは、異なるセッションに参加するかもしれません。サーバーを構成するとき、それが参加するセッションを知っている必要があります。サーバーは、関連するセッションのリストを受信するためのGET SESSメッセージを発行することができます。
3 CRANE Message Format
3 CRANEメッセージ形式
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.
CRANEプロトコルメッセージフォーマットの概要は以下に示されています。 CRANEメッセージは、8オクテットのメッセージヘッダから成ります。これは、32ビット境界に整列される可変長メッセージペイロードが続きます。メッセージの一部がCRANEメッセージペイロード部分を持っていません。フィールドは、ネットワークバイト順であり、左から右に送信されます。
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.
バージョンフィールドは、サポートされているCRANEプロトコルの実装を示します。このフィールドは、CRANEプロトコルバージョン1.0を示すために1に設定しなければなりません。 CRANEプロトコルバージョン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フィールドは、メッセージのタイプを識別する。 CRANEバージョン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
フロースタートSTART 0x01の流れスタートSTOP ACK 0x04の接続CONNECT 0x05のアクノリッジSTART ACK 0x02の流れの停止STOP 0x03の流れの停止を認めます
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
テンプレートデータTMPLデータ0x10をテンプレートデータがTMPL DATA ACK 0x11を最終テンプレートデータFINAL TMPLデータ0x12を最終テンプレートデータのAckを認めます。 FINAL TMPL DATA ACKは、セッションSESSはセッションの応答がSESS RSPをゲット0x14に0x13をゲットするテンプレートがTMPLをゲット0x15の0x16は、テンプレート応答がGET TMPL RSP 0x17のスタート交渉STARTをゲット0x18のスタート交渉のAckを交渉。 STARTは、ACK 0x19を交渉します
Data DATA 0x20 Data Acknowledge DATA ACK 0x21 Error ERROR 0x23
データデータ0x20のデータがACK 0x21でエラーERROR 0x23を認めます
Status Request STATUS REQ 0x30 Status Response STATUS RSP 0x31
ステータス要求ステータスREQ 0x30のステータス応答ステータスRSP 0x31
Session ID: 8 bit unsigned char
セッションID：8ビットのunsigned 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ビットのunsigned char型
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.
メッセージフラグフィールドは、メッセージに関連するオプションを識別するために使用することができます。 CRANEバージョン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.
メッセージ長フィールドは、ヘッダを含むオクテットのCRANEメッセージの全長です。
4 CRANE Messages
4件のCRANEメッセージ
This section defines CRANE mandatory messages. They MUST be supported by any CRANE protocol implementation.
このセクションでは、CRANE必須のメッセージを定義します。彼らはすべてのCRANEプロトコルの実装でサポートしなければなりません。
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.
フロー開始メッセージがCRANEサーバがCRANEメッセージを受信する準備ができていることを示すためにCRANEクライアントに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=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.
フロースタートメッセージを確認し、特定のCRANEサーバからSTARTメッセージの受信を確認するためにCRANEクライアントによって送信されます。クライアントが用意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=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.
クライアントのブート時のフィールドは、このフィールドには、システム全体で一意なレコード識別子として機能するDSN、クライアントのIPアドレスと組み合わせることができる1970年からの秒の最後のクライアントの起動のタイムスタンプです。
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メッセージは、（そのサーバーに）データの送信を停止することを指示するCRANEクライアントにCRANEサーバーから送信されます。 STOPメッセージは、サーバーを切断しません。それが唯一の「DATA」メッセージを送信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=0x03 | Session ID | Message Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Description
説明
The Flow Stop Acknowledgement message acknowledges the STOP message issued by a CRANE server.
フロー停止確認メッセージがCRANEサーバによって発行された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=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メッセージが自身を識別するためにCRANEクライアントに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=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)
CRANEクライアントがSTART後CRANEサーバーにテンプレートのデータ・メッセージを送信するか、STARTメッセージは、サーバから受信したNEGOTIATE。メッセージは、セッションのために使用されようとしているすべてのテンプレートを含まなければなりません。また、ステータスレコードのテンプレートを含むべきである（セクション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.
受信CRANEサーバはTMPL DATA ACK（テンプレートの変更が必要な場合）、またはFINAL TMPL DATA 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（構成ID）：8ビットの符号なしの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ビットのunsigned char型
The Flags field identifies any options associated to the message.
Flagsフィールドは、メッセージに関連するすべてのオプションを示します。
The flag defined by the CRANE Version 1 is:
CRANEバージョン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」ビットが「DATA」メッセージの送信順序を示します。フィールドが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.
テンプレートのFlagsフィールドは、テンプレートの異なる属性を示すフラグで構成されています。 CRANEバージョン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
説明：可変長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.
Descriptionフィールドは、テンプレート（例えば、「インターフェースおよびToSビットによって集約」）のテキスト記述を含みます。これは64kビットまで長の可変長フィールドであり、次の32ビット境界まで0で埋め。
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）0x0014 Time_MSEC_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
ストリング（8）0x400cヌル終了文字列0x400d UTF-8文字列の任意のデータ0x400f 0x400e UTF-16文字列（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）ブールはTRUEの値をFALSEの値は0と1を保持する単一のオクテットとして表されます。
(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.
00:00:00 GMT 1970年1月1日からの秒 - （3）Time_SECは、32ビット値、最も重要なオクテット最初です。
(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ビット値、最も重要なオクテットが最初である - 00:00:00 GMT 1970年1月1日からのミリ秒。
(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ビット値、最も重要なオクテットが最初である - 00:00:00 GMT、1970年1月1日からマイクロ。
(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ビット値、最も重要なオクテットが最初である - 00:00:00 GMT 1970年1月1日からのミリ秒。
(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ビット値、最も重要なオクテットが最初である - 00:00:00 GMT、1970年1月1日からマイクロ。
(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コードが続きます。この表現は、「DATA」メッセージ内のデータ・レコードを符号化するために使用しなければなりません。
(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.
キー属性ベクトル場は、キーの異なる属性を示します。 CRANEバージョン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 DATAメッセージが受信された後CRANEクライアントにCRANEサーバーから送信されます。これは、テンプレートの（有効/無効）テンプレートの変更および/またはキーの状態の変更を提案しています。
If a CRANE server wishes to acknowledge reception of TMPL DATA without changes, it MUST respond with the FINAL TMPL DATA ACK message.
CRANEサーバは変更せずにTMPLデータの受信を確認したい場合は、FINAL TMPL DATA 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（構成ID）：8ビットの符号なしのchar
See Section 4.6. The value MUST be identical to the Config. ID field of the acknowledged TMPL DATA message.
4.6節を参照してください。値はコンフィグと同じでなければなりません。定評TMPL DATAメッセージの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.
最終的なテンプレートデータメッセージは、ファイナライズテンプレートを伝えるために、セッション内のすべてのCRANEサーバにCRANEクライアントによって送信されます。これは、サーバーがこのメッセージでテンプレートを受け入れなければならない唯一の違いは、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.
CRANEサーバは最終テンプレートデータ応答メッセージを送信することにより、TMPL DATAまたは最終TMPLデータの受信を肯定応答します。これは、テンプレートへの変更を運びません。 TMPL DATA ACKメッセージとは異なり、FINAL TMPL DATA ACKメッセージは、セッションのためのテンプレートの受け入れを示します。サーバはTMPL DATA（それは、テンプレートの変更を望んでいない場合）に、このメッセージで応答することができます。サーバーは、FINAL TMPL DATAに、このメッセージで応じなければなりません。
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ビットのunsigned 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.
取得セッションメッセージは、それが参加すべきセッションであるかを照会するCRANEクライアントにCRANEサーバーによって送信されます。これは典型的にはちょうどCRANEクライアントのテンプレートのUI構成の前に行われます。各セッションは、テンプレートの独自のセットを持っているとして、すべてのセッションのサーバの参加を知る必要があります。
The Session ID field in the CRANE message header MUST be ignored by the receiver.
CRANEメッセージヘッダのセッション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のSESS要求に対する応答としてCRANEサーバーにCRANEクライアントによって送信されます。メッセージは、要求サーバーが関連付けられている任意のセッションに関連するすべての情報を含まなければなりません。
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.
ベンダー文字列の長さフィールドは、オクテットのベンダー文字列フィールドの長さです。フィールドの制限のベンダー文字列が長い64KBします。そのような文字列が供給されない場合、長さが0に設定しなければなりません。
Vendor String: Variable length unsigned char
ベンダー文字列：可変長unsigned 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ビットのunsigned 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.
セッション記述長フィールドはセッション記述の長さです。フィールドには、64Kバイトの長にセッション記述を制限します。そのような説明が提供されていない場合、長さが0に設定しなければなりません。
Session Name: Variable length unsigned char
セッション名：可変長unsigned 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で埋めなければなりません。セッション名はCRANEクライアント内で一意でなければなりません。このフィールドは必須であり、任意のセッションブロックの一部でなければなりません。
Session Description: Variable length unsigned char
セッション記述：可変長unsigned 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.
取得テンプレートのメッセージは、セッション中にテンプレートを照会するCRANEクライアントに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=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メッセージに対する応答としてCRANEサーバーに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
キー名：可変長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
鍵ラベル：可変長unsigned 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
キーヘルプ：可変長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.
設定プロセスが完了した後にスタート交渉メッセージがCRANEサーバーによって送信されます。メッセージは、セッション内のすべてのCRANEサーバとクライアントでテンプレートの交渉を開始すべきです。それはCRANEクライアントによって確認されない限りCRANEサーバは、5秒の繰り返し間隔で3回にこのメッセージをアップ再送るかもしれません。それ以外の場合は、CRANEのユーザーが通知されます。メッセージを認めた後、クライアントがサーバに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.
スタート交渉はメッセージを確認メッセージを交渉STARTの受信を確認するために、サーバーに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=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.
DATAメッセージはCRANEサーバーに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=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ビットのunsigned 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ビットのunsigned char型
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.
Flagsフィールドは、データレコードの処理要求を示すフラグビットで構成されています。 CRANEバージョン1は、これらの目的のための2つのフラグを定義しました。特に指定のない限り、他のフラグは送信時にゼロに設定され、領収書の上で無視されます。
The following flags are defined in CRANE Version 1:
以下のフラグはCRANEバージョン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」ビット（ビット「重複」）：これは、サーバーの遷移が発生した後、代替サーバに再送信されたレコードに設定されています。同じレコードが別のサーバーに送信されると、データが存在する重複可能性があります。 「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同期」ビット）：セットは、このサーバーへのデータ送信の記録が開始（又は再開）した後にサーバによって受信された最初のものであることを示している場合。サーバーは、レコードで指定された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.
データ受信確認メッセージは、レコードの受信を確認するためにCRANEサーバから送信されます。これは、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ビットのunsigned 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.
エラーメッセージは、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=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.
タイムスタンプフィールドは00:00:00 GMT、1970年1月1日以降の秒のタイムスタンプです。
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:
以下のエラーコードがCRANEバージョン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
説明：可変長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.
CRANEサーバは、ステータス要求メッセージを送信することにより、クライアントの一般的な動作状態を問い合わせてもよいです。ステータス情報は、状態、カウンター、クライアントに常駐するデータ収集機能のアキュムレータのコレクションを含むべきです。ステータスはCRANEクライアント自体についての詳細情報を含むことができます。
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.
CRANEプロトコルは、将来的に発展することがあり、それは異なるトランスポート層の上に実行することがありますので、UDP上で実行されているトランスポートニュートラルバージョン交渉メカニズムが定義されています。 CRANEサーバは、合意されたUDPポートにUDPパケットを送信することにより、CRANEプロトコルのバージョンとトランスポート層のサポートについてCRANEクライアントを問い合わせてもよいです。クライアントは、プロトコルバージョン、トランスポート・タイプおよび特定の輸送に使用するポート番号を運ぶUDPパケットを使用してこの要求に応答しなければなりません。プロトコルバージョンネゴシエーションはCRANEバージョン1のためのオプションです。
The CRANE server sends the following message to query the client's protocol support.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Server Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Server Boot Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 'C' | 'R' | 'A' | 'N' |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Server Address:
サーバーアドレス：
The Server Address field is the IP address (Ipv4) of the CRANE server.
サーバアドレス]フィールドには、CRANEサーバの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.
追加議定Infoフィールドは、（後述）プロトコル情報ブロックの配列は、クライアントでサポートされている追加のプロトコルに関する情報が含まれています。
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.
特定のトランスポート層の上に支持さCRANEプロトコルのバージョン番号は、現在のバージョンは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.
CRANEプロトコルは、TCPやSCTPなどの信頼性の高いトランスポート層上で動作するアプリケーションと見なすことができます。 CRANEプロトコルは、エンドツーエンドCRANEメッセージがホストアドレスおよびトランスポート・プロトコル・ポート番号によって識別されるクライアントとサーバ間で通信されるという意味です。任意のCRANEセッションを開始する前に、CRANEのサーバのアドレスのセットはCRANEクライアントにプロビジョニングする必要があります。同様に、CRANEサーバは、それが通信するCRANEのクライアントのアドレスのリストを保持します。プロビジョニングは、典型的には、ネットワーク管理システムを使用して確実に行われます。このように、クレーンのエンドポイントには、認証および認可することができます。この方式は静的であるように、追加のセキュリティ保護なしCRANEプロトコルは、アドレススプーフィングなどの攻撃に対して脆弱です。
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.
CRANEプロトコル自体は、強力なセキュリティ機能を提供していません。したがって、それはCRANEメッセージの機密性と完全性を保証することはできません。強くCRANEプロトコルのユーザーが自分の配置構成を評価し、適切なセキュリティポリシーを実装することをお勧めします。 CRANEプロトコルは、ローカルエリアネットワークやセキュリティを確保するための専用の接続を介して展開されている場合、例えば、追加のセキュリティサービス、操作等の設定は必要としなくてもよいです。 CRANEのクライアントとサーバがインターネットを介して接続されている場合は、下位層のセキュリティサービスを起動する必要があります。
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.
CRANEクライアントとサーバ間の通信の強力なセキュリティ保護を実現するために、下位層のセキュリティサービスを強くお勧めします。下位層のセキュリティサービスは、CRANEプロトコルに対して透過的です。セキュリティメカニズムは、IPSecを使用してIP層に設けることができる[6]、またはそれが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.、ウィレンス、S.、ルーベン、A.およびW.シンプソン、RFC 2865、2000年6月 "ユーザーサービス（RADIUS）においてリモート認証ダイヤル"。
[2] Calhoun, P., "DIAMETER Base Protocol", Work in Progress.
[2]カルフーン、P.、 "DIAMETERベースプロトコル"、ProgressのWork。
[3] Calhoun, P., et. al., "DIAMETER Framework Document", Work in Progress.
[3]カルフーン、P.、ら。ら、 "DIAMETER Frameworkのドキュメント" が進行中で働いています。
[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]スチュワート、R.、謝、Q.、Morneault、K.、シャープ、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カラ、M.、チャン、L.およびV.パクソン、 "簡単な制御伝送プロトコル"、RFC 2960、2000年10月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[6] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[6]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[7] Dierks, T. and C. Allen, "The TLS Protocol, Version 1.0", RFC 2246, January 1999.
[7]ダークス、T.とC.アレン、 "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.
特別な感謝は仕事を妊娠ためタルGivoly、Limorシュバイツァーによるものであり、第1 CRANEプロトコルの実装を達成するためのXACCT Technologies社のニールPedhatzur、Batya Ferder、そしてピーターLudemann。
Thanks are also due to Nevil Brownlee for his valuable comments on the work, as well as the IETF IPFIX WG.
おかげで仕事の彼の貴重なコメントにもNevilブラウンリーによるものであるだけでなく、IETF IPFIX WG。
9 Authors' Addresses
9本の著者のアドレス
Kevin Zhang 10124 Treble Court Rockville, MD 20850 U.S.A.
ケビン・張10124トレブル裁判所ロックビル、MD 20850 U.S.A.
Phone +1 301 315 0033 EMail: kevinzhang@ieee.org
電話+1 301 315 0033 Eメール：kevinzhang@ieee.org
Eitan Elkin XACCT Technologies, Ltd. www.xacct.com 12 Hachilazon St. Ramat-Gan, Israel 52522
エイタンエルキンXACCTテクノロジー株式会社www.xacct.com 12 Hachilazon聖ラマト・ガン、イスラエル52522
Phone +1 972 3 576 4111 EMail: eitan@xacct.com
電話+1 972 3 576 4111 Eメール：eitan@xacct.com
10 Full Copyright Statement
10完全な著作権に関する声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。