RFC3423 日本語訳
3423 XACCT's Common Reliable Accounting for Network Element (CRANE)Protocol Specification Version 1.0. K. Zhang, E. Elkin. November 2002. (Format: TXT=97731 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group K. Zhang
Request for Comments: 3423 E. Elkin
Category: Informational XACCT Technologies
November 2002
コメントを求めるワーキンググループK.チャン要求をネットワークでつないでください: 3423年のE.エルキンカテゴリ: 情報のXACCT技術2002年11月
XACCT's Common Reliable Accounting for Network Element (CRANE)
Protocol Specification Version 1.0
ネットワーク要素(クレーン)プロトコル仕様バージョン1.0のためのXACCTの一般的な信頼できる会計
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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.
このドキュメントはどんなデータの効率的で信頼できる配送も可能にするNetwork Element(CRANE)プロトコルのためにCommon Reliable Accountingを定義します、データを主にNetwork Elementsからどんなシステムまでも説明して、仲介システムやBusiness Support Systems(BSS)/操作Support Systems(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
1つの序論…2 1.1 要件の仕様…3 1.2用語…3 2は概要について議定書の中で述べます…5 2.1 アーキテクチャをためらってください…6 2.2 TCPの上でためらってください…7 2.3 サーバを交替してください…7 2.4個のテンプレート…9 2.5のテンプレートトランスミッションと交渉…10 2.6 テンプレートを変えます…11 2.7フロー制御…12 2.8 クレーンクライアント質問メッセージ…13
Zhang & Elkin Informational [Page 1] RFC 3423 XACCT's CRANE Protocol Specification November 2002
チャンとエルキン情報[1ページ]のRFC3423XACCTのクレーンプロトコル仕様2002年11月
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
2.9 クレーンセッション…13 3 メッセージ・フォーマットをためらってください…14 4 メッセージをためらってください…16 4.1 流れ始め(始めます)…16 4.2 流れ始めは(スタートACK)を承認します…16 4.3 流れ停止(停止)…17 4.4流れ停止は(停止ACK)を承認します…17 4.5 接続してください(接続してください)…18 4.6 テンプレートデータ(TMPLデータ)…18 データが承認する4.7テンプレート(TMPLデータACK)…23 4.8 最終的なテンプレートデータ(最終的なTMPLデータ)…25 データが承認する4.9の最終的なテンプレート(最終的なTMPLデータACK)…26 4.10 セッションを得てください(SESSを手に入れてください)…26 4.11 セッション応答を得てください(SESS RSPを手に入れてください)…27 4.12 テンプレートを手に入れてください(TMPLを手に入れてください)…30 4.13 テンプレート応答を得てください(TMPL RSPを手に入れてください)…30 4.14 交渉(開始は交渉される)を始めてください…33 4.15 スタート交渉は…を承認します(始めはACKを交渉します)。34 4.16のデータ(データ)…34 4.17のデータが(データACK)を承認します…36 4.18 誤り(誤り)…37 4.19状態要求(状態REQ)…38 4.20 状態応答(状態RSP)…38 5 バージョン交渉について議定書の中で述べてください…39 6 セキュリティ問題…42 7つの参照箇所…43 8つの承認…43 9人の作者のアドレス…44 10の完全な著作権宣言文…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.
ネットワークElementsは、仲介への情報を用法にエクスポートして、しばしば容易にするビジネスサポート・システム(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.
例えば、いくつかの輸出メカニズムが通信業者世界のレガシーです。 用法情報は、通常、Logが(例えば、CDRファイル)をファイルするのでNetwork Elementsに保存されて、バッチで外的システムにエクスポートされます。 これらが確かな方法である、しかしながら、彼らは今日の急速に発展しているデータ網のリアルタイムで高い性能の必要条件を満たしません。
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
RADIUS[1]は用法が情報であるとエクスポートするのに使用されるかもしれない広く配布しているプロトコルです。 しかしながら、それは、いくつかの傑出している要求を扱うことができるだけであって、限られたコマンドのために広げることができません。
Zhang & Elkin Informational [Page 2] RFC 3423 XACCT's CRANE Protocol Specification November 2002
チャンとエルキン情報[2ページ]のRFC3423XACCTのクレーンプロトコル仕様2002年11月
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もサーバからクライアントまでお節介なメッセージをサポートしません。 [3]でRADIUSの限界の詳細に渡る分析を見つけることができます。
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モデルを保有して、RADIUSのいくつかの欠点を排除する新しいAAAプロトコルです。 現在の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.
このドキュメントはどんなデータの効率的で信頼できる配送も可能にするCRANEプロトコルを定義します、データを主にNetwork Elementsからどんなシステムまでも説明して、仲介システムやBSS/OSSのように。 プロトコルは、ネットワーク、ストレージ、および処理リソースの効率的な使用でNEのものからの会計データの高いボリュームをエクスポートすることに関する決定的な必要性を扱うために開発されます。
This document specifies the architecture of the protocol and the message format, which MUST be supported by all CRANE protocol implementations.
このドキュメントはプロトコルのアーキテクチャとメッセージ・フォーマットを指定します。(すべてのCRANEプロトコル実装でそれをサポートしなければなりません)。
1.1 Specification of Requirements
1.1 要件の仕様
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"、「必須NOT」“SHOULD"で「」 「5月」はBCP14[5]で説明されるように解釈されることになっているべきです。 これらのキーワードは本書では大文字と小文字を区別していません。
1.2 Terminology
1.2 用語
CRANE Protocol
クレーンプロトコル
CRANE stands for Common Reliable Accounting for Network Element.
The CRANE Protocol maybe referred as CRANE, or the Protocol in
this document. The CRANE Protocol is used at the interface(s)
between a CRANE client and one or multiple CRANE servers for the
purpose of delivering accounting data.
CRANEはNetwork ElementのためにCommon Reliable Accountingを表します。 多分、CRANEプロトコルはCRANE、またはプロトコルとして本書では参照されました。 CRANEプロトコルは会計データを提供する目的にCRANEクライアントと1か複数のCRANEサーバとのインタフェースで使用されます。
Zhang & Elkin Informational [Page 3] RFC 3423 XACCT's CRANE Protocol Specification November 2002
チャンとエルキン情報[3ページ]のRFC3423XACCTのクレーンプロトコル仕様2002年11月
Client or CRANE Client
クライアントかクレーンクライアント
A CRANE Client is an implementation on the data producing side of
the CRANE protocol. It is typically integrated with the network
element's software, enabling it to collect and send out accounting
data to a mediation/billing system using the protocol defined
herein.
CRANE ClientはCRANEプロトコルのデータ生産側の上の実装です。 それはネットワーク要素のソフトウェアについて通常統合しています、仲介/支払いシステムに会計データを集めて、出すのをここに定義されたプロトコルを使用することで可能にして。
Server or CRANE Server
サーバかクレーンサーバ
A CRANE Server is an implementation on the data receiving side of
the CRANE protocol. It is typically part of a Business Support
System (BSS) (e.g., Billing, Market Analysis, Fraud detection,
etc.), or a mediation system. There could be more than one CRANE
server connected to one CRANE client to improve robustness of the
usage information export system.
CRANE ServerはCRANEプロトコルのデータ受信側の上の実装です。 それは、通常Business Support System(BSS)(例えば、Billing、Market Analysis、Fraud検出など)の一部、または仲介システムです。 用法情報輸出システムの丈夫さを改良するために1人のCRANEクライアントに接された1つ以上のCRANEサーバがあるかもしれません。
CRANE Session
クレーンセッション
A CRANE Session is a logical connection between a CRANE client and
one or multiple CRANE servers for the purpose of delivering
accounting data. Multiple sessions MAY be maintained concurrently
in a CRANE client or a CRANE server; they are distinguished by
Session IDs.
CRANE SessionはCRANEクライアントと1との論理的な接続か会計データを提供する目的のための複数のCRANEサーバです。 同時に、複数のセッションがCRANEクライアントかCRANEサーバで維持されるかもしれません。 それらはSession 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サーバはPriority値で割り当てられます。 CRANE Sessionの中に最も高いPriority値(プライマリサーバ)がある状態で、会計データはいつも知覚された操作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.
MessageはCRANEプロトコルによって指定された規則に従って、コード化されて、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.
Data Recordは様々な目的、例えば、会計でNetwork Elementによって集められた情報の収集です。 Data Recordの構造はTemplateによって定義されます。
Zhang & Elkin Informational [Page 4] RFC 3423 XACCT's CRANE Protocol Specification November 2002
チャンとエルキン情報[4ページ]のRFC3423XACCTのクレーンプロトコル仕様2002年11月
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.
TemplateはData 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.
説明しているData Record平らな一連番号。(その一連番号は信頼できて系列の配送を容易にするすべてのデータメッセージに付けられています)。
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]はCRANEに関する信頼度要求事項を実現させる2つのトランスポート層プロトコルです。 それらのどちらかが、CRANEメッセージを輸送するのに使用されるかもしれません。 TCPは必要条件のいくつかを満たしますが、すべて(例えば、サーバ失敗、TCPが適応する記録ではなく、適応するストリームであるという事実の迅速な検出)満たすというわけではありません。 したがって、SCTP[4]はCRANEメッセージを送る都合のよい方法です。
Zhang & Elkin Informational [Page 5] RFC 3423 XACCT's CRANE Protocol Specification November 2002
チャンとエルキン情報[5ページ]のRFC3423XACCTのクレーンプロトコル仕様2002年11月
2.1 CRANE Architecture
2.1 クレーンアーキテクチャ
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サーバの間でメッセージを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. 適応する接続。 3. 最大2^32の八重奏(IPをひくとき、すなわち、トランスポート層はメッセージの断片化をサポートしなければならない)の長さがあるメッセージの配送。
The transport layer MAY support:
トランスポート層は以下をサポートするかもしれません。
1. Authentication. 2. Bundling of multiple messages into a single datagram.
1. 認証。 2. 単一のデータグラムへの複数のメッセージのバンドリング。
Possible transport layer protocols MAY be TCP or SCTP [4]. TCP supports the minimal requirements for CRANE, but lacks some desirable capabilities that are available in SCTP, these include:
可能なトランスポート層プロトコルは、TCPかSCTP[4]であるかもしれない。 TCPはCRANEのために最小量の要件をサポートしますが、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サーバまで流れるトラフィックはほとんど会計データです。 また、小さいことでトラフィックの部分を包括するだけですが、双方向のコントロール交換処理があります。
Zhang & Elkin Informational [Page 6] RFC 3423 XACCT's CRANE Protocol Specification November 2002
チャンとエルキン情報[6ページ]のRFC3423XACCTのクレーンプロトコル仕様2002年11月
The following diagram illustrates the CRANE protocol architecture:
以下のダイヤグラムはCRANEプロトコルアーキテクチャを例証します:
+----------------+ +----------------+
| CRANE | | CRANE |+
| User | | User ||+
+----------------+ +----------------+||
| CRANE | ==========> | CRANE |+|
| Client | <---------- | Server ||+
+----------------+ +----------------+||
| Transport | | Transport |+|
| Layer | <---------> | Layer ||+
+----------------+ +----------------+||
| Lower | | Lower |+|
| Layers | <---------> | Layers ||+
+----------------+ +----------------+||
+----------------+|
+----------------+
+----------------+ +----------------+ | クレーン| | クレーン|+ | ユーザ| | ユーザ||+ +----------------+ +----------------+|| | クレーン| ==========>| ためらってください。|+| | クライアント| <、-、-、-、-、-、-、-、-、--、| サーバ||+ +----------------+ +----------------+|| | 輸送| | 輸送|+| | 層| <、-、-、-、-、-、-、-、--、>| 層||+ +----------------+ +----------------+|| | 下ろしてください。| | 下ろしてください。|+| | 層| <、-、-、-、-、-、-、-、--、>| 層||+ +----------------+ +----------------+|| +----------------+| +----------------+
2.2 CRANE over TCP
2.2はTCPの上でためらいます。
TCP can be used as a transport layer for the CRANE protocol. CRANE running over TCP MUST conform to the following rules:
CRANEプロトコルにトランスポート層としてTCPを使用できます。 TCP MUSTをひくCRANEが以下の規則に従います:
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クライアント、およびSHOULDに接しなければなりません。失敗の場合に接続を回復させるのに責任があってください。 3. CRANEメッセージはバイトのストリームとしてTCP接続に書かれていて、CRANEメッセージのサイズはCRANEメッセージヘッダーのMessage Length分野によって指定されます。
2.3 Alternate servers
2.3 代替のサーバ
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プロトコルは、CRANEサーバを交替するために会計データを配送にサポートします。(サーバは仲介システムかBSSの一部であるかもしれません)。
A CRANE session may comprise of one or more CRANE servers. The CRANE client is responsible for configuring network addresses of all CRANE servers belonging to the session. A Server Priority is assigned to each CRANE server. The Server Priority reflects the CRANE client's preference regarding which CRANE server should receive accounting data. The assignment of the Server Priority should consider factors such as geographical distance, communication cost, and CRANE server loading, etc. It is also possible for several CRANE servers to have the same priority. In this case, the CRANE client could randomly choose one of them as the primary server to deliver accounting data.
CRANEセッションは1CRANEでサーバを包括するかもしれません。 CRANEクライアントはセッションに属するすべてのCRANEサーバのネットワーク・アドレスを構成するのに責任があります。 Server PriorityはそれぞれのCRANEサーバに割り当てられます。Server Priorityはデータを説明するどのCRANEサーバを見なすかと受けられるべきであるCRANEクライアントの好みを反映します。 Server Priorityの課題は地理的な距離や、コミュニケーション費用や、CRANEサーバ荷重などの要素を考えるべきです。 また、いくつかのCRANEサーバには同じ優先権があるのも、可能です。 この場合、CRANEクライアントは、会計データを提供するためにプライマリサーバとして手当たりしだいにそれらの1つを選ぶことができました。
Zhang & Elkin Informational [Page 7] RFC 3423 XACCT's CRANE Protocol Specification November 2002
チャンとエルキン情報[7ページ]のRFC3423XACCTのクレーンプロトコル仕様2002年11月
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.
それが再び作動していると知覚されるとき、会計データ配送SHOULDは、より高い優先権サーバに戻ります。
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) 低優先度サーバはアクティブなものです、そして、より高い優先権サーバは回復しました。
Zhang & Elkin Informational [Page 8] RFC 3423 XACCT's CRANE Protocol Specification November 2002
チャンとエルキン情報[8ページ]のRFC3423XACCTのクレーンプロトコル仕様2002年11月
2.4 Templates
2.4 テンプレート
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セッションのためにData Templatesの1セットを交渉することによって、達成されます。 データテンプレートは、ペイロードの分野のデータ型、意味、および位置について説明することによって、DATAメッセージペイロードの構造を定義します。 セッションテンプレートに同意することによって、CRANEサーバはCRANEクライアントから受け取られたDATAメッセージを処理する方法を理解しています。 その結果、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.
テンプレートはキーの規則正しいリストです。 キーはテンプレートの分野の仕様です。 それはネットワーク要素が集めて、エクスポートするかもしれない会計項目を指定します。 仕様は会計項目に関する記述とデータ型から成らなければなりません。 (例えば、'Sent Bytesの数'は長い間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に構成に堪えなければなりません。 各データレコードはTemplate IDとConfiguration IDと共に提供されます、正しいテンプレートに参照をつけることができるように。 より古いConfiguration IDと共に記録を受け取るとき、サーバは、何らかのテンプレート歴史を保管することによって、優雅に記録を扱うかもしれません。 トランスポート層は、サーバが将来の構成IDがあるメッセージを得ないのを確実にするはずです。
Zhang & Elkin Informational [Page 9] RFC 3423 XACCT's CRANE Protocol Specification November 2002
チャンとエルキン情報[9ページ]のRFC3423XACCTのクレーンプロトコル仕様2002年11月
2.5 Template Transmission and Negotiation
2.5 テンプレートトランスミッションと交渉
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セッションのときに同じセットのテンプレートを使用しなければなりません。 同じくらいが設定したシェアではなく、サーバがするテンプレート(異なったキーが可能にされるか、または損傷されるなら、テンプレートは異なると考えられる)の場合では、クライアントとサーバの間の交渉プロセスは結局、セッションのときにすべてのCRANEサーバによって受け入れられて、使用される1セットのテンプレートを決定するでしょう。
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 DATAメッセージをサーバに送ることによって使用するつもりであるテンプレートのセットを提供しなければなりません。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クライアントは1セットのテンプレートでTMPL DATAメッセージを送ります。
B) CRANE server either responds with the TMPL DATA ACK message with changes in the template set (process continues in step C) or responds with FINAL TMPL DATA ACK message if no changes are needed (process continues in step E).
B) CRANEサーバは、テンプレートセット(プロセスはステップCで持続する)における変化に伴うTMPL DATA ACKメッセージで応じるか、または変化が全く必要でないなら(プロセスはステップEで持続します)、FINAL TMPL DATA ACKメッセージで反応します。
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 DATAメッセージを送ります(変化を配布するために)。
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
D) CRANEサーバは、新しいセットのテンプレートを含むFINAL TMPL DATAメッセージを受け取って、FINAL TMPL DATA ACKメッセージを送らなければなりません。
Zhang & Elkin Informational [Page 10] RFC 3423 XACCT's CRANE Protocol Specification November 2002
チャンとエルキン情報[10ページ]のRFC3423XACCTのクレーンプロトコル仕様2002年11月
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.
テンプレートのレセプションを承認してください。 変化は全く現在のところ許容されていません、そして、テンプレート(クライアントは送った)は使用するでしょう。
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 DATAはSHOULDを通信させます。送って、結局、前の構成があるDATAメッセージが承認されるだけであったということになってください。 これは適切に新しい構成に変遷へのサーバを確実にします。
2.6 Changing Templates
2.6 テンプレートを変えること。
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 DATAメッセージは、テンプレートを配布して、ピーアールすると考慮しますが、テンプレートがセットしたのを構成する必要性はまだ存在しています。 CRANEセッションにおける、それぞれのCRANEサーバはテンプレートセットを変えるかもしれません。(それは、User Interfaceを通してエンドユーザによって通常要求されています)。 エンドユーザが、どんなテンプレートが利用可能であるかを知る必要があって、現在のテンプレートが状態を設定したなら、それらは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メッセージを発行していなくても、サーバはGET TMPLを発行できます。
B) After received a GET TMPL message, the client sends back a GET TMPL RSP message with the requested data.
B) 受け取った後に、GET TMPLメッセージであり、クライアントは要求されたデータでGET TMPL RSPメッセージを返送します。
C) The server makes the necessary changes to the templates and sends back a START NEGOTIATION message. This message triggers the CRANE client to inquire about changes made by the CRANE server.
C) サーバは、テンプレートへの必要な改革を作って、START NEGOTIATIONメッセージを返送します。 このメッセージは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) 受け取った後に、TMPL DATAメッセージがSTART NEGOTIATE ACKメッセージのあとに続いていて、START NEGOTIATEメッセージ、クライアントは応じなければなりません。 この地点から先は、テンプレート交渉プロセスは始まります。
Zhang & Elkin Informational [Page 11] RFC 3423 XACCT's CRANE Protocol Specification November 2002
チャンとエルキン情報[11ページ]のRFC3423XACCTのクレーンプロトコル仕様2002年11月
2.7 Flow Control
2.7フロー制御
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.
テンプレートが配布された後に、DATAメッセージはプライマリCRANEサーバ(CRANEセッション中の最優先がある操作上のもの)に到着し始めます。 それぞれのDATAメッセージはData Sequence Number(DSN)を含んでいます。 それが系列である限り、プライマリCRANEサーバはデータを受け入れなければなりません。 順序が狂ってDATAメッセージは捨てられるべきです。
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メッセージがそうしたに違いない、'CRANEクライアントによって設定されたビット('DSN Synchronize'は噛み付いた)はそうです。 初期のDSNとのメッセージのレセプションでは、サーバは系列のすべてのDATAメッセージを受け入れなければなりません。 DSN MUST、クライアントから溯源されたそれぞれの新しい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メッセージのレセプションと正しい処理を承諾しなければなりません。 DATA ACK MUSTは系列の最後に処理されたDATAメッセージのDSNを含んでいます。 また、CRANEサーバがOut Of Sequence DATAメッセージを受け取るなら、それはDATA ACKメッセージを送らなければなりません。 それは不承認の記録の即座の「再-トランスミッション」の引き金となるでしょう。
The CRANE client is responsible for delivering all the records. In the case of a redundant server configuration, there could be a scenario when one server does not receive all the records but another redundant CRANE server for the same mediation system receives the rest of the records. For example, server #1 could receive records 3042-3095 and then 3123-..., with server #2 receiving records 3096- 3122. It is the sender's responsibility to deliver all the records, in-sequence, but not necessarily to the same server.
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.
支払い/仲介システムは結局すべての記録を受け取ります、ことによると1つ以上のCRANEサーバを通して。CRANEクライアントはそれが支払い/仲介システムに受け取ったすべての記録を伝えなければなりません。 これは支払い/仲介システムの重複レコードをもたらすかもしれません。 この場合DSN MUST、使用されて、写しを取り除いてください。 別のサーバに記録を再送するときはいつも、写し取り外しのプロセスを支援するために、この記録が写しであるかもしれないと示唆するように'写し'ビットを設定しなければなりません。
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
不承認の記録の量が敷居に達するとき、タイマは始動されるべきです。 タイマが期限が切れるとき、すべての不承認の記録が補欠に伝えられるべきです。
Zhang & Elkin Informational [Page 12] RFC 3423 XACCT's CRANE Protocol Specification November 2002
チャンとエルキン情報[12ページ]のRFC3423XACCTのクレーンプロトコル仕様2002年11月
server with 'D' bit set in the DATA message; if alternate servers
are not available, the records should be retransmitted.
'D'ビットがあるサーバはDATAメッセージにセットしました。 代替のサーバが利用可能でないなら、記録は再送されるべきです。
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メッセージをクライアントに送るべきです。
2.8 The CRANE Client Query Messages
2.8 クレーンクライアント質問メッセージ
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サーバですべてのQuery Messagesを開始しなければなりません。CRANEプロトコルがそのような3Query Message組を定義するので、彼らは以下の通りです。
Get Session (GET SESS) Get Session Response (GET SESS RSP)
得る、セッション(SESSを手に入れる)はセッション応答を得ます。(SESS RSPを手に入れます)
Get Template (GET TMPL) Get Template Response (GET TMPL RSP)
得る、テンプレート(TMPLを手に入れる)はテンプレート応答を得ます。(TMPL RSPを手に入れます)
Status Request (STATUS REQ) Status Response (STATUS RSP)
状態要求(状態REQ)状態応答(状態RSP)
All the query messages incorporate a Request ID field for tagging purposes and matching requests and responses. This field contains a 16 bit counter incremented with every request and is set by the initiator of the request. Along with the CRANE server's IP address and port number, this constitutes a unique identifier for a request. This value MUST be copied to Request ID field in the response message in order to associate a specific response with a request.
すべての質問メッセージが、目的にタグ付けをして、要求と応答に合うようにRequest ID分野を取り入れます。 この分野は、あらゆる要求に従って増加された16ビットのカウンタを含んでいて、要求の創始者によって設定されます。 CRANEサーバのIPアドレスとポートナンバーと共に、これは要求のためのユニークな識別子を構成します。 特定の応答を要求に関連づけるために応答メッセージにおけるRequest 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クライアントSHOULDは集められたデータ(カウンタ、統計など)に関するメタデータを集めて、出します。 いかなる他のテンプレートのようにも扱われる状態テンプレートを作成することによって、これをします、これらのテンプレートが/'状態'ビットでマークされる例外で。 状態テンプレートはSTATUS REQとSTATUS RSPメッセージのセットと共に使用されます。 サーバは、CRANEクライアントにSTATUS REQを発行して、要求されたデータでSTATUS RSPメッセージを受け取るかもしれません。
2.9 CRANE Sessions
2.9 クレーンセッション
A CRANE client MAY deliver accounting data to different mediation/billing systems by establishing different CRANE sessions.
CRANEクライアントは、異なったCRANEセッションを確立することによって、異なった仲介/支払いシステムに会計データを提供するかもしれません。
Zhang & Elkin Informational [Page 13] RFC 3423 XACCT's CRANE Protocol Specification November 2002
チャンとエルキン情報[13ページ]のRFC3423XACCTのクレーンプロトコル仕様2002年11月
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サーバから成るかもしれません。 IDがすべてのCRANEメッセージで埋め込んだセッションは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でそれぞれ関連Session 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 クレーンメッセージ・フォーマット
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 Message有効搭載量部分がありません。 野原は、ネットワークバイトオーダーにはあって、左から右まで伝えられます。
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン|メッセージID(中間の)| セッションID| メッセージ旗| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ クレーンメッセージ有効搭載量~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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流れに関連する情報を移すのにそれを使用できます。
Zhang & Elkin Informational [Page 14] RFC 3423 XACCT's CRANE Protocol Specification November 2002
チャンとエルキン情報[14ページ]のRFC3423XACCTのクレーンプロトコル仕様2002年11月
Message ID (MID): 8 bit unsigned integer
メッセージID(中間の): 8の噛み付いている符号のない整数
The Message ID field identifies the type of the message. The
message IDs defined by CRANE Version 1 are:
Message ID分野はメッセージのタイプを特定します。 CRANEバージョン1によって定義されたメッセージIDは以下の通りです。
Message Name Short Name Message ID
--------------------- --------------- ------------
Reserved 0x00
メッセージ名前省略名メッセージID--------------------- --------------- ------------ 予約された0×00
Flow Start START 0x01
Flow Start Acknowledge START ACK 0x02
Flow Stop STOP 0x03
Flow Stop Acknowledge STOP ACK 0x04
Connect CONNECT 0x05
流れスタートスタート0x01流れ始めは、流れ停止停止0×03流れ停止が、停止ACK0x04が接続すると認めるスタートACK0x02が0×05を接続すると認めます。
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データ0×10テンプレートデータはTMPLの最終的なテンプレートデータ最終的なTMPLデータACK0x11データ0x12の最終的なテンプレートデータAckを承認します。 0×15がテンプレートを手に入れるSESS RSPは0×16が手に入れるTMPLを手に入れます。ACK0x13がセッションを得る最終的なTMPLデータが0×14がセッション応答を得るSESSを手に入れる、得る、テンプレート応答はスタート交渉始めが交渉するTMPL RSP0x17に0×18スタート交渉Ackを手に入れます。 始めはACK0x19を交渉します。
Data DATA 0x20
Data Acknowledge DATA ACK 0x21
Error ERROR 0x23
データデータ0x20データはデータACK0x21誤り誤り0x23を承諾します。
Status Request STATUS REQ 0x30
Status Response STATUS RSP 0x31
状態は状態REQ0x30状態応答状態RSP0x31を要求します。
Session ID: 8 bit unsigned char
セッションID: 8ビットの未署名の炭
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.
Session ID分野はメッセージが関連しているセッションを特定します。 セッションIDはGET SESSとGET SESS RSPメッセージの場合で無視されます。 セクション2.9でおよそセッションその他の詳細を見つけることができます。
Message Flags: 8 bit unsigned char
メッセージ旗: 8ビットの未署名の炭
The Message Flags field can be used to identify options associated
with the message. For CRANE Version 1.0, all the flags are
reserved; unless otherwise specified, the flags are set to zero on
transmit and are ignored on receipt.
メッセージに関連しているオプションを特定するのにMessage Flags分野を使用できます。 CRANEバージョン1.0において、すべての旗が予約されています。 別の方法で指定されない場合、旗はゼロにオンなセットが伝わって、領収書の上で無視されるということです。
Zhang & Elkin Informational [Page 15] RFC 3423 XACCT's CRANE Protocol Specification November 2002
チャンとエルキン情報[15ページ]のRFC3423XACCTのクレーンプロトコル仕様2002年11月
Message Length: 32 bit unsigned integer
メッセージ長: 32の噛み付いている符号のない整数
The Message Length field is the total length of the CRANE message
in octet including the header.
Message Length分野はヘッダーを含む八重奏で、CRANEメッセージの全長です。
4 CRANE Messages
4 クレーンメッセージ
This section defines CRANE mandatory messages. They MUST be supported by any CRANE protocol implementation.
このセクションはCRANEの義務的なメッセージを定義します。 どんなCRANEプロトコル実装でもそれらをサポートしなければなりません。
4.1 Flow Start (START)
4.1流れ始め(始め)
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クライアントにFlow Startメッセージを送ります。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン| 中間の=0x01| セッションID| メッセージ旗| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.2 Flow Start Acknowledge (START ACK)
4.2 始めが承認する流れ(スタートACK)
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クライアントは、特定のCRANEサーバからのSTARTメッセージのレセプションを承認するためにFlow Start Acknowledgeメッセージを送ります。クライアントが、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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン| 中間の=0x02| セッションID| メッセージ旗| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | クライアントブート時間| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Zhang & Elkin Informational [Page 16] RFC 3423 XACCT's CRANE Protocol Specification November 2002
チャンとエルキン情報[16ページ]のRFC3423XACCTのクレーンプロトコル仕様2002年11月
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.
Client Boot Time分野は1970年からの秒における最後のクライアント始動に関するタイムスタンプです。 システムの広いユニークなレコード識別名として役立つDSNとクライアントのIPアドレスにこの分野を結合できます。
4.3 Flow Stop (STOP)
4.3 流れ停止(停止)
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.
データ(そのサーバへの)を送るのを止めるようそれに命令するためにCRANEサーバからCRANEクライアントにFlow Stopメッセージを送ります。 STOPメッセージはサーバから切断しません。 それによって、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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン| 中間の=0x03| セッションID| メッセージ旗| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.4 Flow Stop Acknowledge (STOP ACK)
4.4 停止が承認する流れ(停止ACK)
Description
記述
The Flow Stop Acknowledgement message acknowledges the STOP
message issued by a CRANE server.
Flow Stop Acknowledgementメッセージは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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン| 中間の=0x04| セッションID| メッセージ旗| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Zhang & Elkin Informational [Page 17] RFC 3423 XACCT's CRANE Protocol Specification November 2002
チャンとエルキン情報[17ページ]のRFC3423XACCTのクレーンプロトコル仕様2002年11月
4.5 Connect (CONNECT)
4.5は接続します。(接続します)
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.
それ自体を特定するためにCRANEサーバからCRANEクライアントにCONNECTメッセージを送ります。 メッセージはサーバとクライアントとのトランスポート層関係の上に送られた最初のメッセージであるに違いありません。
Message Format
メッセージ・フォーマット
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | MID=0x05 | Session ID | Message Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Server Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Server Port | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン| 中間の=0x05| セッションID| メッセージ旗| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サーバアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サーバポート| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Server Address: 32 bit unsigned integer
サーバアドレス: 32の噛み付いている符号のない整数
The Server Address field is the server's IP address (IPV4).
Server Address分野はサーバの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)
Server Port分野はトランスポート層のためのサーバのポートナンバーです。(ここで指定されたポートナンバーは必ずトランスポート層によって使用されるポートナンバーに合う必要はありません)
4.6 Template Data (TMPL DATA)
4.6 テンプレートデータ(TMPLデータ)
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)
サーバからSTARTかSTART NEGOTIATEメッセージを受け取った後にCRANEクライアントはTemplate DataメッセージをCRANEサーバに送ります。メッセージはセッションに使用されるすべてのテンプレートを含まなければなりません。 それ、また、SHOULDは状態記録のためのテンプレートを含んでいます。(セクション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を見てください。
Zhang & Elkin Informational [Page 18] RFC 3423 XACCT's CRANE Protocol Specification November 2002
チャンとエルキン情報[18ページ]のRFC3423XACCTのクレーンプロトコル仕様2002年11月
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン| 中間の=0x10| セッションID| メッセージ旗| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コンフィグID| 旗|E| テンプレートの数| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ テンプレートブロック~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ... ... ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ テンプレートブロック~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Configuration ID (Config. ID): 8 bit unsigned char
構成ID(コンフィグID): 8ビットの未署名の炭
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.
Configuration ID分野はテンプレートセットに関連しているバージョン番号を特定します。 テンプレートのどれかへの変化は新しいテンプレートバージョンをもたらすでしょう、そして、バージョン番号は1つ増加されるでしょう。 バージョン番号の実装SHOULDハンドルロールオーバー。
Flags: 8 bit unsigned char
旗: 8ビットの未署名の炭
The Flags field identifies any options associated to the message.
Flags分野はメッセージに関連づけられたどんなオプションも特定します。
The flag defined by the CRANE Version 1 is:
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'ビットは「データ」メッセージのトランスミッション命令を示します。 分野が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.
Templates分野のNumberはメッセージによって指定されたTemplates(テンプレートはTemplate Blockによって説明される)の数です。
Zhang & Elkin Informational [Page 19] RFC 3423 XACCT's CRANE Protocol Specification November 2002
チャンとエルキン情報[19ページ]のRFC3423XACCTのクレーンプロトコル仕様2002年11月
Template Block
テンプレートブロック
The Template Block field is of variable length and aligned to 32
bit boundary. It is the specification of a template.
Template Block分野は可変長があって、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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | テンプレートID| キーの数| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | テンプレート旗|T| 記述の長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | テンプレートブロック長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ 記述~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ キー・ブロック~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ... ... ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ キー・ブロック~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Template ID: 16 bit unsigned integer
テンプレートID: 16の噛み付いている符号のない整数
The Template ID field identifies a specific template.
Template ID分野は特定のテンプレートを特定します。
Number of Keys: 16 bit unsigned integer
キーの数: 16の噛み付いている符号のない整数
The Number of Keys field is the number of keys included in the
template.
キーズ分野のNumberはテンプレートにキーを含む数です。
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.
Template Flags分野はテンプレートの異なった属性を示す旗で構成されます。 CRANEバージョン1.0では、送付者によってゼロに設定されて、受信機によって無視されて、唯一の'T'ビットは分野SHOULDの定義されて、他のビットです。
Zhang & Elkin Informational [Page 20] RFC 3423 XACCT's CRANE Protocol Specification November 2002
チャンとエルキン情報[20ページ]のRFC3423XACCTのクレーンプロトコル仕様2002年11月
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'ビット('状態'ビット)は、テンプレートがSTATUS 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.
記述Length分野は記述分野の長さです。 記述を全く供給しないなら、長さは0であるに違いありません。
Template Block Length: 32 bit unsigned integer
テンプレートブロック長: 32の噛み付いている符号のない整数
The Template Block Length is the length of the template block in
octets.
Template Block Lengthは八重奏で、テンプレートブロックの長さです。
Description: Variable length unsigned char
記述: 可変長の未署名の炭
The Description field contains the text description of the
template (e.g., "Aggregated by interface and ToS bits"). It is a
variable length field of up to 64Kb long, and padded with 0 to the
next 32 bit boundary.
記述分野はテンプレート(例えば、「インタフェースとToSビットで、集められる」)のテキスト記述を含んでいます。 それは長さ最大64KB、次の32ビット境界への0でそっと歩くことの可変長フィールドです。
Key Block
キー・ブロック
A key Block contains the specification of a key within a template.
主要なBlockはテンプレートの中にキーの仕様を含んでいます。
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 主要なID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 主要なタイプID| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 主要な属性ベクトル|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.
Key ID分野はテンプレートの中にキーを特定します。 その他の詳細に関してセクション2.4を見てください。
Key Type ID: 16 bit unsigned integer
主要なタイプID: 16の噛み付いている符号のない整数
The Key Type ID field specifies the data type of the key.
Key Type ID分野はキーに関するデータ型を指定します。
Zhang & Elkin Informational [Page 21] RFC 3423 XACCT's CRANE Protocol Specification November 2002
チャンとエルキン情報[21ページ]のRFC3423XACCTのクレーンプロトコル仕様2002年11月
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
データ型データ型ID--------------------- -------------- Integer64 0x0009であると署名されるInteger32 0x0007の未署名のInteger64 0x0008であると署名されるInteger16 0x0005の未署名のInteger32 0x0006であると署名されるInteger8 0x0003の未署名のInteger16 0x0004であると署名される論理演算子(1)0×0001の未署名のInteger8 0x0002
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)0x0010IPアドレス(Ipv6)0x0011Time_SEC(3)0×0012Time_MSEC_64(4)0×0013Time_USEC_64(5)0x0014Time_MSEC_32(6)0x0015Time_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ヌルはストリングのストリングの0x400e UTF-16のストリングの0x400fの任意の0x400d UTF-8データ(一滴)(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) 論理演算子はFALSEの値のための0とTRUEの値のための1を保持するただ一つの八重奏として表されます。
(2) Float and Double are single and double precision floating
point numbers that comply with the IEEE-754 standard.
(2) DoubleはIEEE-754規格に従う浮いてください。そうすれば、シングルと倍精度浮動小数点です。
(3) Time_SEC is a 32 bit value, most significant octet first
- seconds since 00:00:00 GMT, January 1, 1970.
(3) 最初に、時間_SECは32ビットの値、最も重要な八重奏です--グリニッジ標準時0時0分0秒、1970年1月1日以来の秒。
(4) Time_MSEC_64 is a 64 bit value, most significant octet
first - milliseconds since 00:00:00 GMT, January 1, 1970.
(4) 最初に、時間_MSEC_64は64ビットの値、最も重要な八重奏です--グリニッジ標準時0時0分0秒、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) 最初に、時間_USEC_64は64ビットの値、最も重要な八重奏です--グリニッジ標準時0時0分0秒、1970年1月1日以来のマイクロセカンド。
Zhang & Elkin Informational [Page 22] RFC 3423 XACCT's CRANE Protocol Specification November 2002
チャンとエルキン情報[22ページ]のRFC3423XACCTのクレーンプロトコル仕様2002年11月
(6) Time_MSEC_32 is a 32 bit value, most significant octet
first - milliseconds since 00:00:00 GMT, January 1, 1970.
(6) 最初に、時間_MSEC_32は32ビットの値、最も重要な八重奏です--グリニッジ標準時0時0分0秒、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) 最初に、時間_USEC_32は32ビットの値、最も重要な八重奏です--グリニッジ標準時0時0分0秒、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コードはあとに続いています。 「データ」メッセージのデータレコードをコード化するのにこの表現を使用するだけでよいです。
(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.
Key Attribute Vector分野はキーの異なった属性を示します。 CRANEバージョン1では、送付者によってゼロに設定されて、受信機によって無視されて、唯一の'K'ビットは分野SHOULDの定義されて、他のビットです。
The 'K' bit ('Disabled bit') is set to 1 when the key is disabled
in this template.
キーがこのテンプレートで損傷されるとき、'K'ビット('身体障害者は噛み付いた')は1に設定されます。
4.7 Template Data Acknowledge (TMPL DATA ACK)
4.7 データが承認するテンプレート(TMPLデータACK)
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クライアントにTemplate Data Acknowledgeメッセージを送ります。 それはテンプレートのためにテンプレート、そして/または、主要な状態変化(可能にするか、または無効にする)の変化を提案します。
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 DATAのレセプションを承認したいなら、それはFINAL TMPL DATA ACKメッセージで応じなければなりません。
Zhang & Elkin Informational [Page 23] RFC 3423 XACCT's CRANE Protocol Specification November 2002
チャンとエルキン情報[23ページ]のRFC3423XACCTのクレーンプロトコル仕様2002年11月
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン| 中間の=0x11| セッションID| メッセージ旗| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コンフィグID| 予約されます。| テンプレート変化の数| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ テンプレート変化ブロック~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ... ... ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ テンプレート変化ブロック~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Configuration ID (Config. ID): 8 bit unsigned char
構成ID(コンフィグID): 8ビットの未署名の炭
See Section 4.6. The value MUST be identical to the Config. ID
field of the acknowledged TMPL DATA message.
セクション4.6を見てください。 値は. IDがさばく承認されたTMPL DATAメッセージのConfigと同じであるに違いありません。
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 Changes分野のNumberはメッセージによって指定された変えられたTemplates(変えられたテンプレートはTemplate Change Blockによって説明される)の数です。
Zhang & Elkin Informational [Page 24] RFC 3423 XACCT's CRANE Protocol Specification November 2002
チャンとエルキン情報[24ページ]のRFC3423XACCTのクレーンプロトコル仕様2002年11月
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | テンプレートID| キーの数| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ キー・ブロック~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ... ... ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ キー・ブロック~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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を見てください、そして、関連キーだけが説明されます。
4.8 Final Template Data (FINAL TMPL DATA)
4.8 最終的なテンプレートデータ(最終的なTMPLデータ)
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.
Final Template DataメッセージがセッションのときにCRANEクライアントによってすべてのCRANEサーバに送られる、運ぶ、テンプレートを成立させてください。 それはサーバがこのメッセージでテンプレートを受け入れなければならないという唯一の違いがあるTMPL DATAメッセージと同様です。
Message Format
メッセージ・フォーマット
Identical to the TMPL DATA (see section 4.6)
TMPLデータと同じです。(セクション4.6を見ます)
Message ID (MID)
メッセージID(中間)です。
0x12 Final Template Data
0×12 最終的なテンプレートデータ
Zhang & Elkin Informational [Page 25] RFC 3423 XACCT's CRANE Protocol Specification November 2002
チャンとエルキン情報[25ページ]のRFC3423XACCTのクレーンプロトコル仕様2002年11月
4.9 Final Template Data Acknowledge (FINAL TMPL DATA ACK)
4.9 データが承認する最終的なテンプレート(最終的なTMPLデータACK)
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サーバは、Final Template Data Acknowledgeメッセージを送ることによって、TMPL DATAかFINAL TMPL DATAのレセプションを承認します。 それはテンプレートへの少しの変化も運びません。 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン| 中間の=0x13| セッションID| メッセージ旗| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コンフィグID| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Configuration ID: 8 bit unsigned char
構成ID: 8ビットの未署名の炭
See Section 4.6. This field MUST copy the configuration ID from
the acknowledged message.
セクション4.6を見てください。 この分野は構成IDを承認されたメッセージを回避しなければなりません。
4.10 Get Sessions (GET SESS)
4.10はセッションを得ます。(SESSを手に入れます)
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サーバでGetセッションズメッセージをCRANEクライアントに送って、何がそれが関与するべきであるセッションであるかを質問します。 CRANEクライアントのテンプレートのUI構成のすぐ前に通常これをします。 各セッションにそれ自身のテンプレートのセットがあるとき、サーバのすべてのセッションの参加を知る必要があります。
The Session ID field in the CRANE message header MUST be ignored
by the receiver.
受信機でCRANEメッセージヘッダーのSession ID分野を無視しなければなりません。
Zhang & Elkin Informational [Page 26] RFC 3423 XACCT's CRANE Protocol Specification November 2002
チャンとエルキン情報[26ページ]のRFC3423XACCTのクレーンプロトコル仕様2002年11月
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン| 中間の=0x14| セッションID| メッセージ旗| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IDを要求してください。| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Request ID分野はサーバによって出された特定の要求を特定します。それを要求に関連づけるために同じRequest IDを応じるメッセージに置かなければなりません。
4.11 Get Sessions Response (GET SESS RSP)
4.11はセッション応答を得ます。(SESS RSPを手に入れます)
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セッションズResponseメッセージはGET SESS要求に関する回答としてCRANEクライアントによってCRANEサーバに送られます。 メッセージは要求サーバが関連しているどんなセッションのときにも関連したすべての情報を含まなければなりません。
The Session ID field in the common message header MUST be ignored
by the receiver.
受信機で一般的なメッセージヘッダーのSession ID分野を無視しなければなりません。
Zhang & Elkin Informational [Page 27] RFC 3423 XACCT's CRANE Protocol Specification November 2002
チャンとエルキン情報[27ページ]のRFC3423XACCTのクレーンプロトコル仕様2002年11月
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 --+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン| 中間の=0x15| セッションID| メッセージ旗| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IDを要求してください。| セッションの数| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ベンダーストリング長| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | | ~ ベンダーストリング~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ セッションブロック~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ... ... ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ セッションブロック~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
セッションズ分野のNumberはメッセージのセッションブロックの数です。
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.
Vendor String Length分野は八重奏で、Vendor String分野の長さです。 ベンダーが長い間64KBに結ぶ分野の限界。 どんなそのようなストリングも供給しないなら、0に長さを設定しなければなりません。
Zhang & Elkin Informational [Page 28] RFC 3423 XACCT's CRANE Protocol Specification November 2002
チャンとエルキン情報[28ページ]のRFC3423XACCTのクレーンプロトコル仕様2002年11月
Vendor String: Variable length 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.
Vendor String分野は可変長フィールドです。 それはセッションを作成したベンダーを特定します。 0で次の32ビット境界にそれを水増ししなければなりません。 情報は異なったベンダーと同様のテンプレートを区別します。 アプリケーション特有であり、このドキュメントの範囲の外で情報の実際の形式。
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | セッションID| 予約されます。| セッション名前の長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | セッション記述の長さ| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ セッション名~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ セッション記述~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Session ID: 8 bit unsigned char
セッションID: 8ビットの未署名の炭
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.
Session Name Length分野はSession Name分野の長さです。 セッション名が長い間64KBに結ぶ分野の限界。 名前がセッションを区別するために義務的であるので、この分野は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.
Session記述Length分野はセッション記述の長さです。 分野は長い間、セッション記述を64KBに制限します。 どんなそのような記述も供給しないなら、0に長さを設定しなければなりません。
Zhang & Elkin Informational [Page 29] RFC 3423 XACCT's CRANE Protocol Specification November 2002
チャンとエルキン情報[29ページ]のRFC3423XACCTのクレーンプロトコル仕様2002年11月
Session Name: Variable length 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.
Session Name分野はセッションのための名前です。(それは、エンドユーザに表示されるかもしれません)。 0で次の32ビット境界にそれを水増ししなければなりません。 セッションNameはCRANEクライアントの中でユニークであるに違いありません。 この分野は、義務的であり、どんなSession Blockの一部であるに違いありません。
Session Description: Variable length 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.
Session記述分野はセッションのテキスト記述です。 エンドユーザにそれを表示できました。 0で次の32ビット境界にそれを水増ししなければなりません。
4.12 Get Templates (GET TMPL)
4.12はテンプレートを手に入れます。(TMPLを手に入れます)
Description
記述
The Get Templates message is sent by a CRANE server to a CRANE
client to query templates in a session.
CRANEサーバでGet Templatesメッセージを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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン| 中間の=0x16| セッションID| メッセージ旗| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IDを要求してください。| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Request ID: 16 bit unsigned integer
IDを要求してください: 16の噛み付いている符号のない整数
See Section 4.10.
セクション4.10を見てください。
4.13 Get Templates Response (GET TMPL RSP)
4.13はテンプレート応答を得ます。(TMPL RSPを手に入れます)
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 Templates ResponseメッセージはGET TMPLメッセージへの応答としてCRANEクライアントによってCRANEサーバに送られます。 メッセージSHOULDは特定のセッションに利用可能なすべてのテンプレートを含んでいます。
Zhang & Elkin Informational [Page 30] RFC 3423 XACCT's CRANE Protocol Specification November 2002
チャンとエルキン情報[30ページ]のRFC3423XACCTのクレーンプロトコル仕様2002年11月
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン| 中間の=0x17| セッションID| メッセージ旗| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IDを要求してください。| テンプレートの数| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ テンプレートブロック~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ... ... ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ テンプレートブロック~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 DATAメッセージ(セクション4.6を見る)で定義されたテンプレートブロックと同じです。 しかしながら、Key Blocksの代わりにExtended Key Blocksを使用しなければなりません。 拡張主要なBlock分野はエンドユーザに表示されるかもしれない大規模な情報のデータを提供します。
Extended Key Block
拡張キー・ブロック
The Extended Key Block field provides comprehensive information
about a key.
Extended Key Block分野はキーの包括的な情報を提供します。
Zhang & Elkin Informational [Page 31] RFC 3423 XACCT's CRANE Protocol Specification November 2002
チャンとエルキン情報[31ページ]のRFC3423XACCTのクレーンプロトコル仕様2002年11月
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 主要なID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 主要なタイプID| 主要な名前の長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 主要なラベルの長さ| 主要なヘルプの長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ 主要な名前~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ 主要なラベル~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ヘルプ~主要な| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 主要な属性ベクトル|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.
Key Name Length分野はKey Name分野の長さです。 Key Nameが長い間64KBに結ぶ分野の限界。 名前がキーに義務的であるので、この分野は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.
Key Label Length分野はKey Label分野の長さです。 Key Labelが長い間64KBに結ぶ分野の限界。 0の長さは、Label分野がスキップされることであることを意味します。
Zhang & Elkin Informational [Page 32] RFC 3423 XACCT's CRANE Protocol Specification November 2002
チャンとエルキン情報[32ページ]のRFC3423XACCTのクレーンプロトコル仕様2002年11月
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.
KeyヘルプLength分野はKeyヘルプ分野の長さです。 Keyヘルプが長い間64KBに結ぶ分野の限界。 0の長さは、ヘルプ分野がスキップされることであることを意味します。
Key Name: Variable length unsigned char
主要な名前: 可変長の未署名の炭
The Key Name field is the name for the key, which could be
displayed to end users. It MUST be padded with 0 to the next 32
bit boundary. Key Name MUST be unique (within the template) and
case sensitive. This field is mandatory and MUST be a part of any
Extended Key Block.
Key Name分野はキーのための名前です。(エンドユーザにそれを表示できました)。 0で次の32ビット境界にそれを水増ししなければなりません。 主要なNameはユニークであって(テンプレートの中の)、大文字と小文字を区別しているに違いありません。 この分野は、義務的であり、どんなExtended Key Blockの一部であるに違いありません。
Key Label: Variable length 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.
Key Label分野は品質表示です。(このキーに関してその品質表示をエンドユーザに表示できました)。 0で次の32ビット境界にそれを水増ししなければなりません。 これはいずれかの一部がExtended Key BlockであったならSHOULDをさばきます。
Key Help: Variable length unsigned char
ヘルプ主要な: 可変長の未署名の炭
The Key Help field is any Help string that could be displayed to
end users concerning this key. It MUST be padded with 0 to the
next 32 bit boundary. This field MAY be a part of any Extended
Key Block.
Keyヘルプ分野はこのキーに関してエンドユーザに表示できたあらゆるヘルプストリングです。 0で次の32ビット境界にそれを水増ししなければなりません。 この分野はどんなExtended Key Blockの一部であるかもしれません。
Key Attribute Vector: 32 bit unsigned integer
主要な属性ベクトル: 32の噛み付いている符号のない整数
Same as section 4.6.
セクション4.6と同じです。
4.14 Start Negotiation (START NEGOTIATE)
4.14 スタート交渉(開始は交渉されます)
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サーバはStart Negotiationメッセージを送ります。 メッセージはセッションのときにすべてのCRANEサーバでクライアントによるテンプレート交渉を開始するべきです。 それがCRANEクライアントによって承認されない場合、CRANEサーバはこのメッセージを5秒の反復間隔がある3回まで再送するかもしれません。 さもなければ、CRANEユーザは知識があるようになるでしょう。 承認された後にクライアントはTMPL DATAメッセージをサーバに送るべきです。メッセージ。
Zhang & Elkin Informational [Page 33] RFC 3423 XACCT's CRANE Protocol Specification November 2002
チャンとエルキン情報[33ページ]のRFC3423XACCTのクレーンプロトコル仕様2002年11月
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン| 中間の=0x18| セッションID| メッセージ旗| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.15 Start Negotiation Acknowledge (START NEGOTIATE ACK)
4.15交渉が承諾する始め(始めはACKを交渉します)
Description
記述
The Start Negotiation Acknowledge message MUST be sent by a CRANE
client to the server to acknowledge the reception of the START
NEGOTIATE message.
CRANEクライアントは、START NEGOTIATEメッセージのレセプションを承認するためにStart Negotiation Acknowledgeメッセージをサーバに送らなければなりません。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン| 中間の=0x19| セッションID| メッセージ旗| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.16 Data (DATA)
4.16 データ(データ)
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サーバまで実際のデータレコードを運びます。データレコードは特定のテンプレートに合っている分野の構造化された収集です。
Zhang & Elkin Informational [Page 34] RFC 3423 XACCT's CRANE Protocol Specification November 2002
チャンとエルキン情報[34ページ]のRFC3423XACCTのクレーンプロトコル仕様2002年11月
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン| 中間の=0x20| セッションID| メッセージ旗| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | テンプレートID| コンフィグID| 旗|D|S| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ一連番号(DSN)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ データ~を記録してください。| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Template ID: 16 bit unsigned integer
テンプレートID: 16の噛み付いている符号のない整数
See Section 4.6.
セクション4.6を見てください。
Configuration ID: 8 bit unsigned char
構成ID: 8ビットの未署名の炭
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分野が青の外で防ぐことができるConfigは通信します。 サーバは、このシナリオに対処するためにテンプレートの短い歴史を保管するかもしれません。
Flags: 8 bit unsigned char
旗: 8ビットの未署名の炭
The Flags field is composed of flag bits that indicate processing
requirements of the data records. The CRANE Version 1 defined two
flags for these purposes. Unless otherwise specified, the other
flags are set to zero on transmit and are ignored on receipt.
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'ビットのStatusは、支払い/仲介システムが反-複製を実行するのを助けるでしょう。
Zhang & Elkin Informational [Page 35] RFC 3423 XACCT's CRANE Protocol Specification November 2002
チャンとエルキン情報[35ページ]のRFC3423XACCTのクレーンプロトコル仕様2002年11月
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.
'、'ビット('DSN Synchronize'は噛み付いた)です: 設定されると、それは、記録がこのサーバへのデータ伝送の始まった後にサーバによって受け取られた最初の1つ(または、再開)であることを示します。サーバは記録で指定された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.
Data Sequence Number分野はデータ命令を保存して、データの損失を検出するのに使用されるレコードの順序番号です。 DSN MUST、伝えられたそれぞれの新しい記録あたり1つ増加されてください。 初期のDSN番号の選択は実装特有です。
Record Data: Variable Length unsigned octets
データを記録してください: 可変Length未署名の八重奏
The Record Data field carries the actual accounting/billing data
that is structured according to the template identified by the
Template ID field.
Record Data分野はTemplate ID分野によって特定されたテンプレートに従って構造化される実際の会計/課金データを運びます。
4.17 Data Acknowledge (DATA ACK)
データが承認する4.17(データACK)
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サーバからData Acknowledgementメッセージを送ります。 それは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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン| 中間の=0x21| セッションID| メッセージ旗| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コンフィグID| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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であるに違いありません。
Zhang & Elkin Informational [Page 36] RFC 3423 XACCT's CRANE Protocol Specification November 2002
チャンとエルキン情報[36ページ]のRFC3423XACCTのクレーンプロトコル仕様2002年11月
Configuration ID: 8 bit unsigned char
構成ID: 8ビットの未署名の炭
See Section 4.16.
セクション4.16を見てください。
4.18 Error (ERROR)
4.18 誤り(誤り)
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.
Errorメッセージは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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン| 中間の=0x23| セッションID| メッセージ旗| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイムスタンプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | エラーコード| 記述の長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ 記述~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Timestamp: 32 bit unsigned integer
タイムスタンプ: 32の噛み付いている符号のない整数
The Timestamp field is a timestamp in seconds since 00:00:00 GMT,
January 1, 1970.
Timestamp分野はグリニッジ標準時0時0分0秒、1970年1月1日以来の秒のタイムスタンプです。
Error Code: 16 bit unsigned integer
エラーコード: 16の噛み付いている符号のない整数
The Error Code field is a code assigned to an error condition.
Error Code分野はエラー条件に割り当てられたコードです。
The following error codes are defined in CRANE Version 1:
以下のエラーコードはCRANEバージョン1で定義されます:
Error Condition Error Code
----------- --------------
Unknown 0
エラー条件エラーコード----------- -------------- 未知0
Zhang & Elkin Informational [Page 37] RFC 3423 XACCT's CRANE Protocol Specification November 2002
チャンとエルキン情報[37ページ]のRFC3423XACCTのクレーンプロトコル仕様2002年11月
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.
記述Length分野は記述分野の長さです。 記述が長い間64KBに結ぶ分野の限界。 0の長さは、記述分野がスキップされることであることを意味します。
Description: Variable Length unsigned char
記述: 可変Length未署名の炭
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.
記述分野は送付者がエラー条件の、より詳細な情報を提供できるテキスト記述です。 0で次の32ビット境界にそれを水増ししなければなりません。
4.19 Status Request (STATUS REQ)
4.19 状態要求(状態REQ)
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サーバは、Status Requestメッセージを送ることによって、一般的な操作状態についてクライアントに問い合わせるかもしれません。 状態情報SHOULDは州の収集を含んでいます、カウンタ、クライアントと共にあるデータ収集機能のアキュムレータ。 状態は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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン| 中間の=0x30| セッションID| メッセージ旗| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.20 Status Response (STATUS RSP)
4.20 状態応答(状態RSP)
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.
Status Responseメッセージはセッションの状態テンプレートと互換性があるに違いない現状報告を含んでいます。 それはサーバからのSTATUS REQメッセージへのクライアントの応答です。
Zhang & Elkin Informational [Page 38] RFC 3423 XACCT's CRANE Protocol Specification November 2002
チャンとエルキン情報[38ページ]のRFC3423XACCTのクレーンプロトコル仕様2002年11月
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン| 中間の=0x31| セッションID| メッセージ旗| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | テンプレートID| 予約されます。|コンフィグID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | レコード長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ データ~を記録してください。| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Length分野は八重奏で、Record Data分野の長さです。
Record Data: Variable Length unsigned octets
データを記録してください: 可変Length未署名の八重奏
The Record Data field contains the status data that complies with
the status template. For more details see section 2.4
Record Data分野は状態テンプレートに従う状態データを含んでいます。 その他の詳細に関しては、セクション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
CRANEプロトコルが将来、発展するかもしれなくて、異なったトランスポート層をひくかもしれないので、UDPをひく輸送の中立バージョン交渉メカニズムは定義されます。 CRANEサーバは、CRANEプロトコルバージョンとトランスポート層サポートに関して同意されたUDPポートにUDPパケットを送ることによって、CRANEクライアントについて問い合わせるかもしれません。 UDPパケットがプロトコルを運んでいて、クライアントはこの要求に応じなければなりません。
Zhang & Elkin Informational [Page 39] RFC 3423 XACCT's CRANE Protocol Specification November 2002
チャンとエルキン情報[39ページ]のRFC3423XACCTのクレーンプロトコル仕様2002年11月
version, the transport type and the port number used for the specific transport. The Protocol Version Negotiation is optional for CRANE Version 1.
バージョン、輸送タイプ、およびポートナンバーは特定に輸送を使用しました。 CRANEバージョン1に、プロトコルバージョンNegotiationは任意です。
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' |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サーバアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サーバブート時間| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 'C'| 'R'| 'A'| '、'| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Server Address:
サーバアドレス:
The Server Address field is the IP address (Ipv4) of the CRANE
server.
Server Address分野はCRANEサーバのIPアドレス(Ipv4)です。
Server Boot Time
サーバブート時間
The Server Boot Time field is the timestamp of the last server
startup in seconds from 1970.
Server Boot Time分野は1970年からの秒における最後のサーバ始動に関するタイムスタンプです。
'C', 'R', 'A', 'N':
''C''、R'、'A'、'、:
The 'C', 'R', 'A', 'N' fields are ASCII encoded characters to
identify the CRANE server.
''C'、'R''、''分野はASCIIがCRANEサーバを特定するためにキャラクタをコード化したということです。
Zhang & Elkin Informational [Page 40] RFC 3423 XACCT's CRANE Protocol Specification November 2002
チャンとエルキン情報[40ページ]のRFC3423XACCTのクレーンプロトコル仕様2002年11月
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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:
デフォルトプロトコルインフォメーション:
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.
DefaultプロトコルInfo分野はクライアントによってサポートされたデフォルトプロトコルの情報を含んでいます。 プロトコルInfo Blockが以下で説明したように分野は構造化されます。
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.
AdditionalプロトコルCount分野はクライアントによってサポートされた追加議定書の数を指定します。 デフォルトプロトコルだけがサポートされて、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.
AdditionalプロトコルInfo分野はプロトコルInfo Blocks(以下で、説明される)の配列がクライアントによってサポートされた追加議定書の情報を含んでいるということです。
Zhang & Elkin Informational [Page 41] RFC 3423 XACCT's CRANE Protocol Specification November 2002
チャンとエルキン情報[41ページ]のRFC3423XACCTのクレーンプロトコル仕様2002年11月
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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: 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.
TCPやSCTPなどの信頼できるトランスポート層をひくアプリケーションとしてCRANEプロトコルを見なすことができます。 CRANEプロトコルは、CRANEメッセージがクライアントの間で伝えられるという感覚とホスト・アドレスとトランスポート・プロトコルポートナンバーによって特定されたサーバへの終わりから終わりです。 どんなCRANEセッションも開始できる前に、1セットの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
CRANEプロトコル自体は堅固なセキュリティ施設を提供しません。 したがって、それはCRANEメッセージの秘密性と保全を確実にすることができません。 CRANEプロトコルのユーザが彼らの展開構成を評価して、適切な安全保障政策を実装することが強く勧められます。 例えば、CRANEプロトコルがローカル・エリア・ネットワークの上で配布されるか、そして、aが接続のためにそれを捧げました。
Zhang & Elkin Informational [Page 42] RFC 3423 XACCT's CRANE Protocol Specification November 2002
チャンとエルキン情報[42ページ]のRFC3423XACCTのクレーンプロトコル仕様2002年11月
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クライアントとサーバがインターネットを通して接されるなら、下層セキュリティー・サービスは呼び出されるべきです。
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[6]を使用するIP層でセキュリティー対策を提供するかもしれませんか、またはトランスポート層のためにTLS[7]を使用することでそれを実装するかもしれません。 このドキュメントの範囲の外に下層セキュリティー・サービスの食糧を供給することがあります。
7 References
7つの参照箇所
[1] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, June
2000.
[1]RigneyとC.とウィレンスとS.とルーベン、A.とW.シンプソン、「ユーザサービス(半径)におけるリモート認証ダイヤル」RFC2865(2000年6月)。
[2] Calhoun, P., "DIAMETER Base Protocol", Work in Progress.
[2] カルフーン、P.、「直径基地のプロトコル」が進行中で働いています。
[3] Calhoun, P., et. al., "DIAMETER Framework Document", Work in
Progress.
[3] etカルフーン、P.、アル、「直径フレームワークドキュメント」、ProgressのWork。
[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.、K.の、そして、鋭いMorneault、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カッラ、M.、チャン、L.、および「簡単な制御伝動プロトコル」、RFC2960(2000年10月)対パクソン
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[5] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[6] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[6] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[7] Dierks, T. and C. Allen, "The TLS Protocol, Version 1.0", RFC
2246, January 1999.
[7] Dierks、T.、およびC.アレン、「TLSはRFC2246、1999年1月についてバージョン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シュバイツアーのためです、そして、最初の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.
感謝は仕事の彼の貴重なコメントのためのネヴィル・ブラウンリーのもためです、IETF IPFIX WGと同様に。
Zhang & Elkin Informational [Page 43] RFC 3423 XACCT's CRANE Protocol Specification November 2002
チャンとエルキン情報[43ページ]のRFC3423XACCTのクレーンプロトコル仕様2002年11月
9 Authors' Addresses
9人の作者のアドレス
Kevin Zhang 10124 Treble Court Rockville, MD 20850 U.S.A.
ケビン・チャン10124・3重な法廷MD20850ロックビル(米国)
Phone +1 301 315 0033 EMail: kevinzhang@ieee.org
+1に、0033がメールする301 315に電話をしてください: kevinzhang@ieee.org
Eitan Elkin XACCT Technologies, Ltd. www.xacct.com 12 Hachilazon St. Ramat-Gan, Israel 52522
ラマトガン、EitanエルキンXACCT Technologies Ltd.www.xacct.com12Hachilazon通りイスラエル52522
Phone +1 972 3 576 4111 EMail: eitan@xacct.com
+1 4111年の972 3 576メールに電話をしてください: eitan@xacct.com
Zhang & Elkin Informational [Page 44] RFC 3423 XACCT's CRANE Protocol Specification November 2002
チャンとエルキン情報[44ページ]のRFC3423XACCTのクレーンプロトコル仕様2002年11月
10 Full Copyright Statement
10 完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Zhang & Elkin Informational [Page 45]
チャンとエルキンInformationalです。[45ページ]
一覧
スポンサーリンク
