RFC2975 日本語訳
2975 Introduction to Accounting Management. B. Aboba, J. Arkko, D.Harrington. October 2000. (Format: TXT=129771 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Aboba
Request for Comments: 2975 Microsoft Corporation
Category: Informational J. Arkko
Ericsson
D. Harrington
Cabletron Systems Inc.
October 2000
Abobaがコメントのために要求するワーキンググループB.をネットワークでつないでください: 2975年のマイクロソフト社カテゴリ: 情報のJ.のD.ハリントンCabletronシステム株式会社Arkkoエリクソン2000年10月
Introduction to Accounting Management
会計管理への紹介
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 (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
The field of Accounting Management is concerned with the collection of resource consumption data for the purposes of capacity and trend analysis, cost allocation, auditing, and billing. This document describes each of these problems, and discusses the issues involved in design of modern accounting systems.
Accounting Managementの分野は容量、傾向変動分析、費用配分、監査、および支払いの目的のためのリソース消費実績の収集に関係があります。 このドキュメントは、それぞれのこれらの問題について説明して、現代の会計システムの設計にかかわる問題について議論します。
Since accounting applications do not have uniform security and reliability requirements, it is not possible to devise a single accounting protocol and set of security services that will meet all needs. Thus the goal of accounting management is to provide a set of tools that can be used to meet the requirements of each application. This document describes the currently available tools as well as the state of the art in accounting protocol design. A companion document, RFC 2924, reviews the state of the art in accounting attributes and record formats.
会計アプリケーションには一定のセキュリティと信頼度要求事項がないので、すべての需要を満たすただ一つの会計プロトコルと1セットのセキュリティー・サービスについて工夫するのは可能ではありません。 したがって、会計管理の目標はそれぞれのアプリケーションに関する必要条件を満たすのに使用できる1セットのツールを提供することです。 また、このドキュメントは会計プロトコルデザインにおける到達技術水準として現在利用可能なツールを記述します。 仲間ドキュメント(RFC2924)は会計属性とレコード形式の到達技術水準を見直します。
Aboba, et al. Informational [Page 1] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[1ページ]のRFC2975序論
Table of Contents
目次
1. Introduction 2
1.1 Requirements language 3
1.2 Terminology 3
1.3 Accounting management architecture 5
1.4 Accounting management objectives 7
1.5 Intra-domain and inter-domain accounting 10
1.6 Accounting record production 11
1.7 Requirements summary 13
2. Scaling and reliability 14
2.1 Fault resilience 14
2.2 Resource consumption 23
2.3 Data collection models 26
3. Review of Accounting Protocols 32
3.1 RADIUS 32
3.2 TACACS+ 33
3.3 SNMP 33
4. Review of Accounting Data Transfer 43
4.1 SMTP 44
4.2 Other protocols 44
5. Summary 45
6. Security Considerations 48
7. Acknowledgments 48
8. References 48
9. Authors' Addresses 52
10. Intellectual Property Statement 53
11. Full Copyright Statement 54
1. 序論2 1.1Requirements言語3 1.2Terminology3 1.3Accounting管理体系5 1.4のAccounting管理目的7 1.5Intra-ドメインと相互ドメイン会計10 1.6Accounting記録的な生産11 1.7Requirements概要、13、2 スケーリングと信頼性の14 2.1Fault弾力14 2.2Resource消費23 2.3Data収集は3に26をモデル化します。 会計プロトコル32 3.1半径32 3.2TACACS+33 3.3SNMP33 4のレビュー。 Accounting Data Transfer43 4.1SMTP44 4.2のOtherプロトコル44 5のレビュー。 概要45 6。 セキュリティ問題48 7。 承認48 8。 参照48 9。 作者のアドレス52 10。 知的所有権声明53 11。 完全な著作権宣言文54
1. Introduction
1. 序論
The field of Accounting Management is concerned with the collection of resource consumption data for the purposes of capacity and trend analysis, cost allocation, auditing, and billing. This document describes each of these problems, and discusses the issues involved in design of modern accounting systems.
Accounting Managementの分野は容量、傾向変動分析、費用配分、監査、および支払いの目的のためのリソース消費実績の収集に関係があります。 このドキュメントは、それぞれのこれらの問題について説明して、現代の会計システムの設計にかかわる問題について議論します。
Since accounting applications do not have uniform security and reliability requirements, it is not possible to devise a single accounting protocol and set of security services that will meet all needs. Thus the goal of accounting management is to provide a set of tools that can be used to meet the requirements of each application. This document describes the currently available tools as well as the state of the art in accounting protocol design. A companion document, RFC 2924, reviews the state of the art in accounting attributes and record formats.
会計アプリケーションには一定のセキュリティと信頼度要求事項がないので、すべての需要を満たすただ一つの会計プロトコルと1セットのセキュリティー・サービスについて工夫するのは可能ではありません。 したがって、会計管理の目標はそれぞれのアプリケーションに関する必要条件を満たすのに使用できる1セットのツールを提供することです。 また、このドキュメントは会計プロトコルデザインにおける到達技術水準として現在利用可能なツールを記述します。 仲間ドキュメント(RFC2924)は会計属性とレコード形式の到達技術水準を見直します。
Aboba, et al. Informational [Page 2] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[2ページ]のRFC2975序論
1.1. Requirements language
1.1. 要件言語
In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [6].
そして、このドキュメント、「5月」というキーワードで「必須、「必須NOT」、「任意」の、そして、「お勧め」の“SHOULD"、「」、[6]で説明されるように解釈されることになっていてください、」であるべきです
1.2. Terminology
1.2. 用語
This document frequently uses the following terms:
このドキュメントは頻繁に次の用語を使用します:
Accounting
The collection of resource consumption data for the
purposes of capacity and trend analysis, cost allocation,
auditing, and billing. Accounting management requires that
resource consumption be measured, rated, assigned, and
communicated between appropriate parties.
容量と傾向変動分析の目的のためのリソース消費実績の収集を説明して、配分、監査、および支払いかかってください。 会計管理は、リソース消費が適切なパーティーの間で測定されて、評定されて、割り当てられて、伝えられるのを必要とします。
Archival accounting
In archival accounting, the goal is to collect all
accounting data, to reconstruct missing entries as best as
possible in the event of data loss, and to archive data for
a mandated time period. It is "usual and customary" for
these systems to be engineered to be very robust against
accounting data loss. This may include provisions for
transport layer as well as application layer
acknowledgments, use of non-volatile storage, interim
accounting capabilities (stored or transmitted over the
wire), etc. Legal or financial requirements frequently
mandate archival accounting practices, and may often
dictate that data be kept confidential, regardless of
whether it is to be used for billing purposes or not.
記録保管所の会計In記録保管所の会計、目標は、すべての会計データを集めて、データの損失の場合、なくなったエントリーをできるだけ最もよく再建して、強制された期間、データを格納することです。 これらのシステムが会計データの損失に対して非常に強健になるように設計されるのは、「普通で通例です」。 これは応用層承認、非揮発性記憶装置の使用、当座の会計能力(ワイヤの上に保存されるか、または伝えられる)などと同様にトランスポート層のための条項を含むかもしれません。 法的であるか財政的な要件は、頻繁に記録保管所の会計実務を強制して、しばしばデータが秘密にされると決めるかもしれません、それが支払い目的に使用されることになっているかどうかにかかわらず。
Rating The act of determining the price to be charged for use of a
resource.
価格がリソースの使用に課されることを決定する行為を評定します。
Billing The act of preparing an invoice.
準備の行為にインボイスを請求します。
Usage sensitive billing
A billing process that depends on usage information to
prepare an invoice can be said to be usage-sensitive. In
contrast, a process that is independent of usage
information is said to be non-usage-sensitive.
用法敏感であるとインボイスを準備するために用法情報に依存する用法の敏感な支払いA課金プロセスを言うことができます。 対照的に、aを処理して、情報が言われている用法の如何にかかわらずすなわち、いてください、非用法敏感
Auditing The act of verifying the correctness of a procedure. In
order to be able to conduct an audit it is necessary to be
able to definitively determine what procedures were
actually carried out so as to be able to compare this to
手順の正当性について確かめる行為を監査します。 決定的に監査をできるのが必要である行うことができるには、手順がこれを比較できるように実際に何に行われたか決定してください。
Aboba, et al. Informational [Page 3] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[3ページ]のRFC2975序論
the recommended process. Accomplishing this may require
security services such as authentication and integrity
protection.
お勧めのプロセス。 これを達成するのは認証や保全保護などのセキュリティー・サービスを必要とするかもしれません。
Cost Allocation
The act of allocating costs between entities. Note that
cost allocation and rating are fundamentally different
processes. In cost allocation the objective is typically
to allocate a known cost among several entities. In rating
the objective is to determine the amount to be charged for
use of a resource. In cost allocation, the cost per unit
of resource may need to be determined; in rating, this is
typically a given.
実体の間にコストを割り当てる行為Allocationにかかってください。 費用配分と格付けが基本的に異なったプロセスであることに注意してください。 費用配分では、目的は通常、知られている費用をいくつかの実体に割り当てることです。 格付けでは、目的は量がリソースの使用のために請求されることを決定することです。 費用配分では、リソースのユニットあたりの費用は、断固とする必要があるかもしれません。 格付けでは、通常、これは当然のことです。
Interim accounting
Interim accounting provides a snapshot of usage during a
user's session. This may be useful in the event of a
device reboot or other network problem that prevents the
reception or generation of a session summary packet or
session record. Interim accounting records can always be
summarized without the loss of information. Note that
interim accounting records may be stored internally on the
device (such as in non-volatile storage) so as to survive a
reboot and thus may not always be transmitted over the
wire.
当座の会計Interim会計はユーザのセッションの間、用法のスナップを提供します。 これはセッション概要パケットかセッション記録のレセプションか世代を防ぐデバイスリブートか他のネットワーク問題の場合、役に立つかもしれません。 情報の損失なしで当座の会計帳簿をいつもまとめることができます。 当座の会計帳簿がリブートを乗り切るためにデバイス(非揮発性記憶装置などの)に内部的に保存されて、その結果、いつもワイヤの上に伝えられるかもしれないというわけではないことに注意してください。
Session record
A session record represents a summary of the resource
consumption of a user over the entire session. Accounting
gateways creating the session record may do so by
processing interim accounting events or accounting events
from several devices serving the same user.
セッション記録Aセッション記録は全体のセッションの間、ユーザのリソース消費の概要を表します。 セッション記録を作成する会計ゲートウェイは同じユーザに役立つ数台のデバイスから処理で当座の会計イベントか会計イベントをそうするかもしれません。
Accounting Protocol
A protocol used to convey data for accounting purposes.
会計プロトコルAプロトコルは以前はよく会計目的のためのデータを伝えていました。
Intra-domain accounting
Intra-domain accounting involves the collection of
information on resource usage within an administrative
domain, for use within that domain. In intra-domain
accounting, accounting packets and session records
typically do not cross administrative boundaries.
イントラドメイン会計Intra-ドメイン会計は管理ドメインの中のリソース用法における情報の収集にかかわります、そのドメインの中の使用のために。 イントラドメイン会計では、会計パケットとセッション記録は管理境界を通常越えません。
Inter-domain accounting
Inter-domain accounting involves the collection of
information on resource usage within an administrative
相互ドメイン会計Inter-ドメイン会計が中でリソース用法における情報の収集にかかわる、管理
Aboba, et al. Informational [Page 4] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[4ページ]のRFC2975序論
domain, for use within another administrative domain. In
inter-domain accounting, accounting packets and session
records will typically cross administrative boundaries.
別の管理ドメインの中の使用のためのドメイン。 相互ドメイン会計では、会計パケットとセッション記録は管理境界を通常越えるでしょう。
Real-time accounting
Real-time accounting involves the processing of information
on resource usage within a defined time window. Time
constraints are typically imposed in order to limit
financial risk.
リアルタイムの会計レアル-時間会計は定義されたタイムウィンドウの中のリソース用法で情報の処理にかかわります。 時間規制は、財政危機を制限するために通常課されます。
Accounting server
The accounting server receives accounting data from devices
and translates it into session records. The accounting
server may also take responsibility for the routing of
session records to interested parties.
サーバが会計サーバであることを説明するのが、デバイスから会計データを受け取って、セッション記録にそれを翻訳します。 また、会計サーバはセッション記録のルーティングへの責任を利害関係者に取るかもしれません。
1.3. Accounting management architecture
1.3. 会計管理体系
The accounting management architecture involves interactions between network devices, accounting servers, and billing servers. The network device collects resource consumption data in the form of accounting metrics. This information is then transferred to an accounting server. Typically this is accomplished via an accounting protocol, although it is also possible for devices to generate their own session records.
会計管理体系はネットワークデバイスと、会計サーバと、支払いサーバとの相互作用にかかわります。 ネットワークデバイスは会計測定基準の形にリソース消費実績を集めます。 次に、この情報を会計サーバに移します。通常、これは会計プロトコルで達成されます、また、デバイスが、それら自身のセッションが記録であると生成するのも、可能ですが。
The accounting server then processes the accounting data received from the network device. This processing may include summarization of interim accounting information, elimination of duplicate data, or generation of session records.
そして、会計サーバはネットワークデバイスから受け取られた会計データを処理します。 この処理は当座の課金情報の総括、重複データの除去、またはセッション記録の世代を含むかもしれません。
The processed accounting data is then submitted to a billing server, which typically handles rating and invoice generation, but may also carry out auditing, cost allocation, trend analysis or capacity planning functions. Session records may be batched and compressed by the accounting server prior to submission to the billing server in order to reduce the volume of accounting data and the bandwidth required to accomplish the transfer.
処理会計データは、次に、支払いサーバに提出しますが、また、監査、費用配分、傾向変動分析またはキャパシティプランニング機能を行うかもしれません。(サーバは格付けとインボイス世代を通常扱います)。 セッション記録は、支払いサーバへの服従の前にデータと帯域幅が転送を実行するのを必要とした会計のボリュームを減少させるために会計サーバによってbatchedされて、圧縮されるかもしれません。
One of the functions of the accounting server is to distinguish between inter and intra-domain accounting events and to route them appropriately. For session records containing a Network Access Identifier (NAI), described in [8], the distinction can be made by examining the domain portion of the NAI. If the domain portion is absent or corresponds to the local domain, then the session record is treated as an intra-domain accounting event. Otherwise, it is treated as an inter-domain accounting event.
会計サーバの機能のひとりが見分けることになっている、間、そして、適切にイベントとルートにそれらを説明するイントラドメイン。 [8]で説明されたNetwork Access Identifier(NAI)を含むセッション記録に関しては、NAIのドメイン一部を調べることによって、区別をすることができます。 ドメイン部分が休むか、または局所領域に対応しているなら、セッション記録はイントラドメイン会計イベントとして扱われます。 さもなければ、それは相互ドメイン会計イベントとして扱われます。
Aboba, et al. Informational [Page 5] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[5ページ]のRFC2975序論
Intra-domain accounting events are typically routed to the local billing server, while inter-domain accounting events will be routed to accounting servers operating within other administrative domains. While it is not required that session record formats used in inter and intra-domain accounting be the same, this is desirable, since it eliminates translations that would otherwise be required.
イントラドメイン会計イベントはローカルの支払いサーバに通常発送されます、相互ドメイン会計イベントが他の管理ドメインの中で作動する会計サーバに発送されるでしょうが。 中で中古のレコード形式が埋葬するセッションとイントラドメイン会計が同じであることが必要ではありませんが、これは望ましいです、別の方法で必要である翻訳を排除するので。
Where a proxy forwarder is employed, domain-based access controls may be employed by the proxy forwarder, rather than by the devices themselves. The network device will typically speak an accounting protocol to the proxy forwarder, which may then either convert the accounting packets to session records, or forward the accounting packets to another domain. In either case, domain separation is typically achieved by having the proxy forwarder sort the session records or accounting messages by destination.
プロキシ混載業者が採用しているところでは、ドメインベースのアクセス制御はデバイス自体でというよりむしろプロキシ混載業者によって使われるかもしれません。 ネットワークデバイスは会計プロトコルをプロキシ混載業者に通常話すでしょう。(次に、その混載業者は、会計パケットをセッション記録に変換するか、または会計パケットを別のドメインに送るかもしれません)。 どちらの場合ではも、プロキシ混載業者に目的地のそばでセッション記録か会計メッセージを分類させることによって、ドメイン分離は通常達成されます。
Where the accounting proxy is not trusted, it may be difficult to verify that the proxy is issuing correct session records based on the accounting messages it receives, since the original accounting messages typically are not forwarded along with the session records. Therefore where trust is an issue, the proxy typically forwards the accounting packets themselves. Assuming that the accounting protocol supports data object security, this allows the end-points to verify that the proxy has not modified the data in transit or snooped on the packet contents.
会計プロキシが信じられないところでは、プロキシがそれが受け取る会計メッセージに基づく正しいセッション記録を発行していることを確かめるのは難しいかもしれません、オリジナルの会計メッセージがセッション記録と共に通常転送されないので。 したがって、信頼が問題であるところに、プロキシは会計パケット自体を通常送ります。 会計プロトコルが、データがオブジェクトセキュリティであるとサポートすると仮定して、エンドポイントは、これでプロキシがトランジットでデータを変更もしませんし、パケットコンテンツで詮索もしていないことを確かめることができます。
Aboba, et al. Informational [Page 6] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[6ページ]のRFC2975序論
The diagram below illustrates the accounting management architecture:
以下のダイヤグラムは会計管理体系を例証します:
+------------+
| |
| Network |
| Device |
| |
+------------+
|
Accounting |
Protocol |
|
V
+------------+ +------------+
| | | |
| Org B | Inter-domain session records | Org A |
| Acctg. |<----------------------------->| Acctg. |
|Proxy/Server| or accounting protocol | Server |
| | | |
+------------+ +------------+
| |
| |
Transfer | Intra-domain |
Protocol | Session records |
| |
V V
+------------+ +------------+
| | | |
| Org B | | Org A |
| Billing | | Billing |
| Server | | Server |
| | | |
+------------+ +------------+
+------------+ | | | ネットワーク| | デバイス| | | +------------+ | 会計| プロトコル| | +に対して------------+ +------------+ | | | | | Org B| 相互ドメインセッション記録| Org A| | Acctg。 | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| Acctg。 | |プロキシ/サーバ| または、会計プロトコル| サーバ| | | | | +------------+ +------------+ | | | | 転送| イントラドメイン| プロトコル| セッション記録| | | +に対するV------------+ +------------+ | | | | | Org B| | Org A| | 支払い| | 支払い| | サーバ| | サーバ| | | | | +------------+ +------------+
1.4. Accounting management objectives
1.4. 会計管理目的
Accounting Management involves the collection of resource consumption data for the purposes of capacity and trend analysis, cost allocation, auditing, billing. Each of these tasks has different requirements.
会計Managementは容量と傾向変動分析の目的のためのリソース消費実績の収集にかかわります、費用配分、監査しています、請求しています。 それぞれに関するこれらのタスクには、異なった要件があります。
1.4.1. Trend analysis and capacity planning
1.4.1. 傾向変動分析とキャパシティプランニング
In trend analysis and capacity planning, the goal is typically a forecast of future usage. Since such forecasts are inherently imperfect, high reliability is typically not required, and moderate packet loss can be tolerated. Where it is possible to use statistical sampling techniques to reduce data collection
傾向変動分析とキャパシティプランニングでは、通常、目標は将来の用法の予測です。 そのような予測が本来不完全であるので、高信頼性を通常必要としません、そして、適度のパケット損失を黙認できます。 データ収集を抑えるのに統計調査のテクニックを使用するのが可能であるところ
Aboba, et al. Informational [Page 7] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[7ページ]のRFC2975序論
requirements while still providing the forecast with the desired statistical accuracy, it may be possible to tolerate high packet loss as long as bias is not introduced.
偏見が紹介されない限り、高いパケット損失を黙認するのがまだ必要な統計的な精度を予測に提供している間、可能であるかもしれないという要件。
The security requirements for trend analysis and capacity planning depend on the circumstances of data collection and the sensitivity of the data. Additional security services may be required when data is being transferred between administrative domains. For example, when information is being collected and analyzed within the same administrative domain, integrity protection and authentication may be used in order to guard against collection of invalid data. In inter-domain applications confidentiality may be desirable to guard against snooping by third parties.
傾向変動分析とキャパシティプランニングのためのセキュリティ要件はデータ収集の事情とデータの感度に依存します。 管理ドメインの間にデータを移しているとき、追加担保サービスを必要とするかもしれません。 情報が同じ管理ドメインの中で集められて、分析されているとき、例えば、保全保護と認証は、無効のデータの収集に用心するのに使用されるかもしれません。 相互ドメインアプリケーションでは、秘密性は第三者による詮索に用心するのにおいて望ましいかもしれません。
1.4.2. Billing
1.4.2. 支払い
When accounting data is used for billing purposes, the requirements depend on whether the billing process is usage-sensitive or not.
会計データが支払い目的に使用されるとき、要件は課金プロセスが用法敏感であるかどうかよります。
1.4.2.1. Non-usage sensitive billing
1.4.2.1. 非用法の敏感な支払い
Since by definition, non-usage-sensitive billing does not require usage information, in theory all accounting data can be lost without affecting the billing process. Of course this would also affect other tasks such as trend analysis or auditing, so that such wholesale data loss would still be unacceptable.
以来、定義上、非用法敏感である、課金プロセスに影響しないで、支払いは用法情報を必要としないで、理論上すべての会計データは失うことができます。 また、もちろん、これは傾向変動分析か監査などの他のタスクに影響するでしょう、そのような大量のデータの損失はまだ容認できないでしょう。
1.4.2.2. Usage-sensitive billing
1.4.2.2. 用法敏感な支払い
Since usage-sensitive billing processes depend on usage information, packet loss may translate directly to revenue loss. As a result, the billing process may need to conform to financial reporting and legal requirements, and therefore an archival accounting approach may be needed.
用法敏感な課金プロセスが用法情報によるので、パケット損失は直接収入の減少に移すかもしれません。 その結果、課金プロセスは、財務報告と法的必要条件に従う必要があるかもしれません、そして、したがって、記録保管所の会計アプローチが必要であるかもしれません。
Usage-sensitive systems may also require low processing delay. Today credit risk is commonly managed by computerized fraud detection systems that are designed to detect unusual activity. While efficiency concerns might otherwise dictate batched transmission of accounting data, where there is a risk of fraud, financial exposure increases with processing delay. Thus it may be advisable to transmit each event individually to minimize batch size, or even to utilize quality of service techniques to minimize queuing delays. In addition, it may be necessary for authorization to be dependent on ability to pay.
また、用法敏感なシステムは低い処理遅れを必要とするかもしれません。 今日、信用リスクは珍しい活動を検出するように設計されているコンピューター化している詐欺の検出システムによって一般的に管理されます。 効率関心は別の方法で詐欺のリスクがある会計データのbatched伝達を決めるかもしれませんが、処理による財政的な暴露増加は延着します。 したがって、それは、バッチサイズを最小にするか、または遅れを列に並ばせる最小にするサービスの質のテクニックを利用するのさえ個別に各イベントを伝えるのにおいて賢明であるかもしれません。 さらに、承認が支払能力に依存しているのが必要であるかもしれません。
Aboba, et al. Informational [Page 8] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[8ページ]のRFC2975序論
Whether these techniques will be useful varies by application since the degree of financial exposure is application-dependent. For dial-up Internet access from a local provider, charges are typically low and therefore the risk of loss is small. However, in the case of dial-up roaming or voice over IP, time-based charges may be substantial and therefore the risk of fraud is larger. In such situations it is highly desirable to quickly detect unusual account activity, and it may be desirable for authorization to depend on ability to pay. In situations where valuable resources can be reserved, or where charges can be high, very large bills may be rung up quickly, and processing may need to be completed within a defined time window in order to limit exposure.
財政的な暴露の度合いがアプリケーション依存しているので、これらのテクニックが役に立つかどうかがアプリケーションで異なります。 ローカルのプロバイダーからのダイヤルアップインターネットアクセスには、充電は通常低いです、そして、したがって、危険負担は小さいです。 しかしながら、IPの上のダイヤルアップローミングか声の場合では、時間ベースの充電は実質的であるかもしれません、そして、したがって、詐欺のリスクは、より大きいです。 そのような状況で、すぐに珍しいアカウント活動を検出するのが非常に望ましく、承認を支払能力に依存するのは、望ましいかもしれません。 予約できるか、または充電が貴重なリソースが高い場合がある状況で、非常に大きい請求書はすばやくレジに記録されるかもしれません、そして、処理は暴露を制限するために定義されたタイムウィンドウの中で完成される必要があるかもしれません。
Since in usage-sensitive systems, accounting data translates into revenue, the security and reliability requirements are greater. Due to financial and legal requirements such systems need to be able to survive an audit. Thus security services such as authentication, integrity and replay protection are frequently required and confidentiality and data object integrity may also be desirable. Application-layer acknowledgments are also often required so as to guard against accounting server failures.
会計データが用法敏感なシステムで収入に翻訳されるので、セキュリティと信頼度要求事項は、よりすばらしいです。 財政的で法的な要件のため、そのようなシステムは、監査を乗り切ることができる必要があります。 したがって、認証や、保全や反復操作による保護などのセキュリティー・サービスが頻繁に必要です、そして、また、秘密性とデータ・オブジェクト保全も望ましいかもしれません。 また、応用層承認が、会計サーバ失敗に用心するのにしばしば必要です。
1.4.3. Auditing
1.4.3. 監査
With enterprise networking expenditures on the rise, interest in auditing is increasing. Auditing, which is the act of verifying the correctness of a procedure, commonly relies on accounting data. Auditing tasks include verifying the correctness of an invoice submitted by a service provider, or verifying conformance to usage policy, service level agreements, or security guidelines.
企業ネットワーク費用が上昇中で、監査への関心は大きくなっています。 監査(手順の正当性について確かめる行為である)は一般的に会計データを当てにします。 監査のタスクは、サービスプロバイダーによって提出されたインボイスの正当性について確かめるか、または用法方針、サービスレベル協定、または安全ガイドラインに順応について確かめるのを含んでいます。
To permit a credible audit, the auditing data collection process must be at least as reliable as the accounting process being used by the entity that is being audited. Similarly, security policies for the audit should be at least as stringent as those used in preparation of the original invoice. Due to financial and legal requirements, archival accounting practices are frequently required in this application.
確かな監査を可能にするために、監査のデータ収集プロセスは監査されている実体によって使用されることで会計作業と少なくとも同じくらい信頼できなければなりません。 同様に、監査のための安全保障政策はオリジナル・インボイスの準備に使用されるものと少なくとも同じくらい厳しいはずです。 財政的で法的な要件のため、記録保管所の会計実務がこのアプリケーションで頻繁に必要です。
Where auditing procedures are used to verify conformance to usage or security policies, security services may be desired. This typically will include authentication, integrity and replay protection as well as confidentiality and data object integrity. In order to permit response to security incidents in progress, auditing applications frequently are built to operate with low processing delay.
監査の手順が用法か安全保障政策に順応について確かめるのに用いられるところでは、セキュリティー・サービスは望まれるかもしれません。 これは秘密性とデータ・オブジェクト保全と同様に認証、保全、および反復操作による保護を通常含むでしょう。 進行中のセキュリティインシデントへの応答を可能にして、監査のアプリケーションは、低い処理遅れで作動するために頻繁に組立てられます。
Aboba, et al. Informational [Page 9] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[9ページ]のRFC2975序論
1.4.4. Cost allocation
1.4.4. 配分かかってください。
The application of cost allocation and billback methods by enterprise customers is not yet widespread. However, with the convergence of telephony and data communications, there is increasing interest in applying cost allocation and billback procedures to networking costs, as is now commonly practiced with telecommunications costs.
法人顧客による費用配分とbillbackメソッドの適用はまだ広範囲ではありません。 しかしながら、費用配分とbillback手順をネットワークコストに適用しながら関心を増やすのが電話とデータ通信の集合と共にあります、現在テレコミュニケーションコストで一般的に練習されるように。
Cost allocation models, including traditional costing mechanisms described in [21]-[23] and activity-based costing techniques described in [24] are typically based on detailed analysis of usage data, and as a result they are almost always usage-sensitive. Whether these techniques are applied to allocation of costs between partners in a venture or to allocation of costs between departments in a single firm, cost allocation models often have profound behavioral and financial impacts. As a result, systems developed for this purposes are typically as concerned with reliable data collection and security as are billing applications. Due to financial and legal requirements, archival accounting practices are frequently required in this application.
配分モデルかかってください、メカニズムが[21]で説明した伝統的なかかることを含んでいて--[23]と[24]で説明された活動基準原価計算のテクニックは用法データの詳細に渡る分析に通常基づいています、そして、その結果、彼らはほとんどいつも用法敏感です。 これらのテクニックがベンチャーにおけるパートナーの間のコストの配分、または、単一企業における部の間のコストの配分に適用されるか否かに関係なく、費用配分モデルには、深遠な行動的、そして、財政的な影響力がしばしばあります。 目的は結果、システムがこれのために展開したから支払いアプリケーションのように確実な資料収集とセキュリティに関係があるように通常です。 財政的で法的な要件のため、記録保管所の会計実務がこのアプリケーションで頻繁に必要です。
1.5. Intra-domain and inter-domain accounting
1.5. イントラドメインと相互ドメイン会計
Much of the initial work on accounting management has focused on intra-domain accounting applications. However, with the increasing deployment of services such as dial-up roaming, Internet fax, Voice and Video over IP and QoS, applications requiring inter-domain accounting are becoming increasingly common.
会計管理に対する初期の仕事の多くがイントラドメイン会計アプリケーションに焦点を合わせました。 しかしながら、IPとQoSの上のダイヤルアップローミングや、インターネットファックスや、VoiceやVideoなどのサービスの増加する展開に従って、相互ドメイン会計を必要とするアプリケーションがますます一般的になっています。
Inter-domain accounting differs from intra-domain accounting in several important ways. Intra-domain accounting involves the collection of information on resource consumption within an administrative domain, for use within that domain. In intra-domain accounting, accounting packets and session records typically do not cross administrative boundaries. As a result, intra-domain accounting applications typically experience low packet loss and involve transfer of data between trusted entities.
相互ドメイン会計はいくつかの重要な方法でイントラドメイン会計と異なっています。 イントラドメイン会計はそのドメインの中の使用のために管理ドメインの中のリソース消費の情報の収集にかかわります。 イントラドメイン会計では、会計パケットとセッション記録は管理境界を通常越えません。 その結果、イントラドメイン会計アプリケーションは、低いパケット損失を通常経験して、信じられた実体の間のデータ転送にかかわります。
In contrast, inter-domain accounting involves the collection of information on resource consumption within an administrative domain, for use within another administrative domain. In inter-domain accounting, accounting packets and session records will typically cross administrative boundaries. As a result, inter-domain accounting applications may experience substantial packet loss. In addition, the entities involved in the transfers cannot be assumed to trust each other.
対照的に、相互ドメイン会計は管理ドメインの中のリソース消費の情報の収集にかかわります、別の管理ドメインの中の使用のために。 相互ドメイン会計では、会計パケットとセッション記録は管理境界を通常越えるでしょう。 その結果、相互ドメイン会計アプリケーションはかなりのパケット損失になるかもしれません。 さらに、転送にかかわる実体が互いを信じると思うことができません。
Aboba, et al. Informational [Page 10] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[10ページ]のRFC2975序論
Since inter-domain accounting applications involve transfers of accounting data between domains, additional security measures may be desirable. In addition to authentication, replay and integrity protection, it may be desirable to deploy security services such as confidentiality and data object integrity. In inter-domain accounting each involved party also typically requires a copy of each accounting event for invoice generation and auditing.
相互ドメイン会計アプリケーションがドメインの間の会計データの転送にかかわるので、追加セキュリティ対策は望ましいかもしれません。 認証、再生、および保全保護に加えて、セキュリティが秘密性やデータ・オブジェクト保全などのサービスであると配布するのは望ましいかもしれません。 また、相互ドメイン会計では、それぞれのかかわったパーティーはインボイス世代と監査のためにそれぞれの会計イベントのコピーを通常必要とします。
1.6. Accounting record production
1.6. 会計帳簿生産
Typically, a single accounting record is produced per session, or in some cases, a set of interim records which can be summarized in a single record for billing purposes. However, to support deployment of services such as wireless access or complex billing regimes, a more sophisticated approach is required.
通常、ただ一つの会計帳簿はセッション、またはいくつかのケース、支払い目的のためのただ一つの記録にまとめることができる1セットの当座の記録で作り出されます。 しかしながら、ワイヤレス・アクセスか複雑な支払い政権などのサービスの展開をサポートするために、より洗練されたアプローチが必要です。
It is necessary to generate several accounting records from a single session when pricing changes during a session. For instance, the price of a service can be higher during peak hours than off-peak. For a session continuing from one tariff period to another, it becomes necessary for a device to report "packets sent" during both periods.
セッションの間変化に値を付けるとき、ただ一つのセッションからいくつかの会計帳簿を生成するのが必要です。 例えば、サービスの価格はピーク時の間、オフピークより高い場合があります。 ある関税の期間から別のものに続くセッションのために、デバイスが、両方の期間、「パケットは発信しました」と報告するのが必要になります。
Time is not the only factor requiring this approach. For instance, in mobile access networks the user may roam from one place to another while still being connected in the same session. If roaming causes a change in the tariffs, it is necessary to account for resource consumed in the first and second areas. Another example is where modifications are allowed to an ongoing session. For example, it is possible that a session could be re-authorized with improved QoS. This would require production of accounting records at both QoS levels.
時間はこのアプローチを必要とする唯一の要素ではありません。 例えば、モバイルアクセスネットワークでは、ユーザは同じセッションのときにまだ接続されている間、1つの場所から別の場所まで歩き回るかもしれません。 ローミングが関税における変化を引き起こすなら、1番目で消費されたリソースと2番目の領域を説明するのが必要です。 別の例は変更が進行中のセッションまで許されているところです。 例えば、改良されたQoSと共にセッションを再認可できたのは可能です。 これは両方のQoSレベルで会計帳簿の生産を必要とするでしょう。
These examples could be addressed by using vectors or multi- dimensional arrays to represent resource consumption within a single session record. For example, the vector or array could describe the resource consumption for each combination of factors, e.g. one data item could be the number of packets during peak hour in the area of the home operator. However, such an approach seems complicated and inflexible and as a result, most current systems produce a set of records from one session. A session identifier needs to be present in the records to permit accounting systems to tie the records together.
ただ一つのセッション記録の中にリソース消費を表すのにベクトルかマルチ次元の配列を使用することによって、これらの例を扱うことができるでしょう。 例えば、ベクトルか配列が要素の各組み合わせのためのリソース消費について説明するかもしれなくて、例えば、1つのデータ項目がホームのオペレータの領域のピーク時の間のパケットの数であるかもしれません。 しかしながら、そのようなアプローチは複雑で融通がきかなく思えます、そして、その結果、ほとんどの現在のシステムが1つのセッションから1セットの記録を作り出します。 セッション識別子は、会計システムが記録を結びつけることを許可するのに記録に存在している必要があります。
In most cases, the network device will determine when multiple session records are needed, as the local device is aware of factors affecting local tariffs, such as QoS changes and roaming. However, future systems are being designed that enable the home domain to
多くの場合、ネットワークデバイスは、複数のセッション記録がいつ必要であるかを決定するでしょう、ローカル装置が要素が地方の関税に影響するのを意識しているように、QoS変化やローミングのように。 しかしながら、将来のシステムは設計していることにされますそれがホームドメインを可能にする。
Aboba, et al. Informational [Page 11] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[11ページ]のRFC2975序論
control the generation of accounting records. This is of importance in inter-domain accounting or when network devices do not have tariff information. The centralized control of accounting record production can be realized, for instance, by having authorization servers require re-authorization at certain times and requiring the production of accounting records upon each re-authorization.
会計帳簿の世代を制御してください。 これは重要です。相互ドメイン会計かそれともいつ、ネットワークデバイスには関税情報がないかの 例えば、承認サーバに、ある時に再承認を必要とさせて、それぞれの再承認での会計帳簿の生産を必要とすることによって、会計帳簿生産の集中制御を実現できます。
In conclusion, in some cases it is necessary to produce multiple accounting records from a single session. It must be possible to do this without requiring the user to start a new session or to re- authenticate. The production of multiple records can be controlled either by the network device or by the AAA server. The requirements for timeliness, security and reliability in multiple record sessions are the same as for single-record sessions.
結論として、いくつかの場合、ただ一つのセッションから複数の会計帳簿を作り出すのが必要です。 それはユーザが新しいセッションを出発させる必要でないこれをするか、または再認証するのにおいて可能であるに違いありません。 ネットワークデバイスかAAAサーバは複数の記録の生産を制御できます。複数の記録的なセッションにおけるタイムリー、セキュリティ、および信頼性のための要件はただ一つの記録セッションのように同じです。
Aboba, et al. Informational [Page 12] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[12ページ]のRFC2975序論
1.7. Requirements summary
1.7. 要件概要
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Usage | Intra-domain | Inter-domain | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Robustness vs. | Robustness vs. | | | packet loss | packet loss | | Capacity | | | | Planning | Integrity, | Integrity, | | | authentication, | authentication, | | | replay protection | replay prot. | | | [confidentiality] | confidentiality | | | | [data object sec.]| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Non-usage | Integrity, | Integrity, | | Sensitive | authentication, | authentication, | | Billing | replay protection | replay protection | | | [confidentiality] | confidentiality | | | | [data object sec.]| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Archival | Archival | | Usage | accounting | accounting | | Sensitive | Integrity, | Integrity, | | Billing, | authentication, | authentication, | | Cost | replay protection | replay prot. | | Allocation & | [confidentiality] | confidentiality | | Auditing | [Bounds on | [data object sec.]| | | processing delay] | [Bounds on | | | | processing delay] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Archival | Archival | | Time | accounting | accounting | | Sensitive | Integrity, | Integrity, | | Billing, | authentication, | authentication, | | fraud | replay protection | replay prot. | | detection, | [confidentiality] | confidentiality | | roaming | | [Data object | | | Bounds on | security and | | | processing delay | receipt support] | | | | Bounds on | | | | processing delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | 用法| イントラドメイン| 相互ドメイン| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 丈夫さ| 丈夫さ| | | パケット損失| パケット損失| | 容量| | | | 計画| 保全| 保全| | | 認証| 認証| | | 反復操作による保護| protを再演してください。 | | | [秘密性]| 秘密性| | | | [データ・オブジェクト秒]| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 非用法| 保全| 保全| | 敏感| 認証| 認証| | 支払い| 反復操作による保護| 反復操作による保護| | | [秘密性]| 秘密性| | | | [データ・オブジェクト秒]| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 記録保管所| 記録保管所| | 用法| 会計| 会計| | 敏感| 保全| 保全| | 支払い| 認証| 認証| | 費用| 反復操作による保護| protを再演してください。 | | 配分| [秘密性]| 秘密性| | 監査| [|領域[データ・オブジェクト秒]| | | 処理遅れ]| [|領域| | | 処理遅れ]| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 記録保管所| 記録保管所| | 時間| 会計| 会計| | 敏感| 保全| 保全| | 支払い| 認証| 認証| | 詐欺| 反復操作による保護| protを再演してください。 | | 検出| [秘密性]| 秘密性| | ローミング| | [データ・オブジェクト| | | | セキュリティの領域と| | | 処理は延着します| 領収書サポート]| | | | バウンドしています。| | | | 処理遅れ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key [] = optional
主要な[]=任意です。
Aboba, et al. Informational [Page 13] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[13ページ]のRFC2975序論
2. Scaling and reliability
2. スケーリングと信頼性
With the continuing growth of the Internet, it is important that accounting management systems be scalable and reliable. This section discusses the resources consumed by accounting management systems as well as the scalability and reliability properties exhibited by various data collection and transport models.
インターネットの継続した成長によって、会計管理システムがスケーラブルであって、高信頼であることは、重要です。 このセクションはスケーラビリティと同様に会計管理システムによって消費されたリソースと収集と輸送がモデル化する様々なデータによって示された信頼性の特性について論じます。
2.1. Fault resilience
2.1. 欠点弾力
As noted earlier, in applications such as usage-sensitive billing, cost allocation and auditing, an archival approach to accounting is frequently mandated, due to financial and legal requirements. Since in such situations loss of accounting data can translate to revenue loss, there is incentive to engineer a high degree of fault resilience. Faults which may be encountered include:
より早く用法敏感な支払いや、費用配分や監査などのアプリケーションに述べられるように、会計への記録保管所のアプローチは頻繁に強制されます、財政的で法的な要件のため。 会計のそのような状況の損失では、データが収入の減少に翻訳されることができるので、高度合いの欠点弾力を設計する誘因があります。 遭遇するかもしれない欠点は:
Packet loss
Accounting server failures
Network failures
Device reboots
パケット損失Accountingサーバ失敗Network失敗Deviceリブート
To date, much of the debate on accounting reliability has focused on resilience against packet loss and the differences between UDP, SCTP and TCP-based transport. However, it should be understood that resilience against packet loss is only one aspect of meeting archival accounting requirements.
これまで、会計の信頼性に関する討論の多くがUDPと、SCTPとTCPベースの輸送のパケット損失に対する弾力と違いに焦点を合わせました。 しかしながら、パケット損失に対する弾力が記録保管所の会計必要条件を満たす1つの局面にすぎないことが理解されるべきです。
As noted in [18], "once the cable is cut you don't need more retransmissions, you need a *lot* more voltage." Thus, the choice of transport has no impact on resilience against faults such as network partition, accounting server failures or device reboots. What does provide resilience against these faults is non-volatile storage.
[18]に述べられるように「ケーブルがいったん切られるとあなたが、より多くの「再-トランスミッション」を必要としないで、*ロットを*さらに必要とする、電圧、」 したがって、輸送の選択はネットワークパーティション、会計サーバ失敗またはデバイスリブートなどのせいに弾力に関する影響を全く抱きません。 これらの欠点に対して弾力を提供することは非揮発性記憶装置です。
The importance of non-volatile storage in design of reliable accounting systems cannot be over-emphasized. Without non-volatile storage, event-driven systems will lose data once the transmission timeout has been exceeded, and batching designs will experience data loss once the internal memory used for accounting data storage has been exceeded. Via use of non-volatile storage, and internally stored interim records, most of these data losses can be avoided.
高信頼の会計システムの設計における、非揮発性記憶装置の重要性を偏重できません。 非揮発性記憶装置がなければ、トランスミッションタイムアウトがいったん超えられていると、イベントドリブンシステムはデータを失って、会計データ保存に使用される内部の記憶がいったん超えられていると、バッチングデザインはデータの損失になるでしょう。 非揮発性記憶装置の、そして、内部的に保存された当座の記録の使用で、これらのデータの損失の大部分を避けることができます。
It may even be argued that non-volatile storage is more important to accounting reliability than network connectivity, since for many years reliable accounting systems were implemented based solely on physical storage, without any network connectivity. For example,
非揮発性記憶装置がネットワークの接続性より会計の信頼性に重要であると主張さえされるかもしれません、高信頼の会計システムが何年間も唯一物理的なストレージに基づいた状態で実装されたので、少しもネットワークの接続性なしで。 例えば
Aboba, et al. Informational [Page 14] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[14ページ]のRFC2975序論
phone usage data used to be stored on paper, film, or magnetic media and carried from the place of collection to a central location for bill processing.
紙上で保存されるのに使用される用法データ、フィルム、または磁気媒体に電話をして、請求書処理のために収集の場所から中心の位置まで運ばれます。
2.1.1. Interim accounting
2.1.1. 当座の会計
Interim accounting provides protection against loss of session summary data by providing checkpoint information that can be used to reconstruct the session record in the event that the session summary information is lost. This technique may be applied to any data collection model (i.e. event-driven or polling) and is supported in both RADIUS [25] and in TACACS+.
当座の会計は、セッション概要情報が無くなる場合セッション記録を再建するのに使用できるチェックポイント情報を提供することによって、セッション概要データの損失に対する保護を提供します。 このテクニックは、どんなデータ収集モデル(すなわち、イベントドリブンの、または、投票している)にも適用されるかもしれなくて、両方のRADIUS[25]とTACACS+でサポートされます。
While interim accounting can provide resilience against packet loss, server failures, short-duration network failures, or device reboot, its applicability is limited. Transmission of interim accounting data over the wire should not be thought of as a mainstream reliability improvement technique since it increases use of network bandwidth in normal operation, while providing benefits only in the event of a fault.
当座の会計はパケット損失、サーバ失敗、短期間ネットワーク失敗、またはデバイスリブートに対して弾力を提供できますが、適用性は限られています。 通常の操作におけるネットワーク回線容量の使用を増強するので、欠点場合にだけ利益を提供している間、主流の信頼性の改良のテクニックとしてワイヤの上の当座の会計データの伝達を考えるべきではありません。
Since most packet loss on the Internet is due to congestion, sending interim accounting data over the wire can make the problem worse by increasing bandwidth usage. Therefore on-the-wire interim accounting is best restricted to high-value accounting data such as information on long-lived sessions. To protect against loss of data on such sessions, the interim reporting interval is typically set several standard deviations larger than the average session duration. This ensures that most sessions will not result in generation of interim accounting events and the additional bandwidth consumed by interim accounting will be limited. However, as the interim accounting interval decreases toward the average session time, the additional bandwidth consumed by interim accounting increases markedly, and as a result, the interval must be set with caution.
インターネットにおけるほとんどのパケット損失が混雑のためである、当座の会計データをワイヤの上に送るのに、問題は、帯域幅用法を増強することによって、より悪くなる場合があります。 したがって、ワイヤにおける当座の会計を長命のセッションの情報などの高値の会計データに制限するのは最も良いです。 そのようなセッションのときにデータの喪失から守るために、当座の報告間隔は平均したセッション持続時間より大きいいくつかの通常設定された標準の逸脱です。 これは、ほとんどのセッションが当座の会計イベントの世代で結果として生じないのを確実にします、そして、当座の会計で消費された追加帯域幅は制限されるでしょう。 しかしながら、当座の会計間隔が平均したセッション時間に向かって減少するのに従って、当座の会計で消費された追加帯域幅激増します、そして、その結果、慎重に間隔を設定しなければなりません。
Where non-volatile storage is unavailable, interim accounting can also result in excessive consumption of memory that could be better allocated to storage of session data. As a result, implementors should be careful to ensure that new interim accounting data overwrites previous data rather than accumulating additional interim records in memory, thereby worsening the buffer exhaustion problem.
また、非揮発性記憶装置が入手できないところでは、当座の会計はセッションデータのストレージに割り当てることができたほうがよいメモリの過剰消費をもたらすことができます。 その結果、作成者は新しい当座の会計データがメモリでの追加当座の記録を蓄積するよりむしろ前のデータを上書きするのを保証するのに慎重であるはずです、その結果、バッファ疲労困憊問題を悪化させます。
Given the increasing popularity of non-volatile storage for use in consumer devices such as digital cameras, such devices are rapidly declining in price. This makes it increasingly feasible for network devices to include built-in support for non-volatile storage. This can be accomplished, for example, by support for compact PCMCIA cards.
デジタルカメラなどの民生品における使用のための非揮発性記憶装置の増加する人気を考えて、そのようなデバイスは価格で急速に減退しています。 これで、ネットワークデバイスが標準装備を含んでいるのが非揮発性記憶装置のためにますます可能になります。 例えば、コンパクトなPCMCIAカードのサポートでこれを達成できます。
Aboba, et al. Informational [Page 15] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[15ページ]のRFC2975序論
Where non-volatile storage is available, this can be used to store interim accounting data. Stored interim events are then replaced by updated interim events or by session data when the session completes. The session data can itself be erased once the data has been transmitted and acknowledged at the application layer. This approach avoids interim data being transmitted over the wire except in the case of a device reboot. When a device reboots, internally stored interim records are transferred to the accounting server.
非揮発性記憶装置が利用可能であるところでは、当座の会計データを保存するのにこれを使用できます。 次にイベントが取り替えられる保存された当座は当座のイベントかセッションデータでいつをアップデートしたか。セッションは完成します。 セッションデータ缶自体、データが応用層でいったん送られて、承認された後、消されてください。 このアプローチはデバイスリブートに関するケースを除いて、ワイヤの上に送られる当座のデータを避けます。 デバイスがリブートされるとき、内部的に保存された当座の記録を会計サーバに移します。
2.1.2. Multiple record sessions
2.1.2. 複数の記録的なセッション
Generation of multiple accounting records within a session can introduce scalability problems that cannot be controlled using the techniques available in interim accounting.
セッション以内の複数の会計帳簿の世代は当座の会計で利用可能なテクニックを使用することにおける制御できないスケーラビリティ問題を紹介できます。
For example, in the case of interim records kept in non-volatile storage, it is possible to overwrite previous interim records with the most recent one or summarize them to a session record. Where interim updates are sent over the wire, it is possible to control bandwidth usage by adjusting the interim accounting interval.
例えば、非揮発性記憶装置でつけられた当座の記録の場合では、最新のもので前の当座の記録を上書きするか、またはセッション記録へそれらをまとめるのが可能です。 それは当座の会計間隔を調整することによって、当座であるところでは、アップデートがワイヤの上に送られるのがコントロール帯域幅用法に可能です。
These measures are not applicable where multiple session records are produced from a single session, since these records cannot be summarized or overwritten without loss of information. As a result, multiple record production can result in increased consumption of bandwidth and memory. Implementors should be careful to ensure that worst-case multiple record processing requirements do not exceed the capabilities of their systems.
これらの測定は複数のセッション記録がただ一つのセッションから作り出されるところで適切ではありません、情報の損失なしでこれらの記録をまとめることができないか、上書きできないので。 その結果、複数の記録的な生産が帯域幅とメモリの増強された消費をもたらすことができます。 作成者は最悪の場合の倍数の記録的な処理所要がそれらのシステムの能力を超えていないのを保証するのに慎重であるはずです。
As an example, a tariff change at a particular time of day could, if implemented carelessly, create a sudden peak in the consumption of memory and bandwidth as the records need to be stored and/or transported. Rather than attempting to send all of the records at once, it may be desirable to keep them in non-volatile storage and send all of the related records together in a batch when the session completes. It may also be desirable to shape the accounting traffic flow so as to reduce the peak bandwidth consumption. This can be accomplished by introduction of a randomized delay interval. If the home domain can also control the generation of multiple accounting records, the estimation of the worst-case processing requirements can be very difficult.
例として、不注意に実装されるなら、記録が、保存される、そして/または、輸送される必要があるとき、特定の時刻の関税変化はメモリの消費と帯域幅で突然のピークを作成するかもしれません。 すぐに記録のすべてを送るのを試みるよりむしろ、非揮発性記憶装置でそれらを保って、セッションであるなら一括して一緒にいる記録が完成する関連のすべてを送るのは望ましいかもしれません。 また、会計交通の流れを形成するのも、ピーク帯域幅消費を抑えるために望ましいかもしれません。 ランダマイズされた遅れ間隔の導入でこれを達成できます。 また、ホームドメインが複数の会計帳簿の世代を制御できるなら、最悪の場合処理所要の見積りは非常に難しい場合があります。
2.1.3. Packet loss
2.1.3. パケット損失
As packet loss is a fact of life on the Internet, accounting protocols dealing with session data need to be resilient against packet loss. This is particularly important in inter-domain accounting, where packets often pass through Network Access Points
パケット損失がインターネットに関する現実であるので、セッションデータに対処する会計プロトコルは、パケット損失に対して弾力がある必要があります。 これは相互ドメイン会計で特に重要です。そこでは、パケットがしばしばNetwork Access Pointsを通り抜けます。
Aboba, et al. Informational [Page 16] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[16ページ]のRFC2975序論
(NAPs) where packet loss may be substantial. Resilience against packet loss can be accomplished via implementation of a retry mechanism on top of UDP, or use of TCP [7] or SCTP [26]. On-the-wire interim accounting provides only limited benefits in mitigating the effects of packet loss.
パケット損失が実質的であるかもしれない(NAPs。) UDPの上の再試行メカニズムの実装、またはTCP[7]かSCTP[26]の使用でパケット損失に対する弾力を達成できます。 ワイヤにおける当座の会計はパケット損失の影響を緩和するのに限られた利益だけを提供します。
UDP-based transport is frequently used in accounting applications. However, this is not appropriate in all cases. Where accounting data will not fit within a single UDP packet without fragmentation, use of TCP or SCTP transport may be preferred to use of multiple round-trips in UDP. As noted in [47] and [49], this may be an issue in the retrieval of large tables.
UDPベースの輸送は会計アプリケーションで頻繁に使用されます。 しかしながら、これはすべての場合で適切ではありません。 会計データが単一のUDPパケットの中で断片化なしで合わないところでは、TCPかSCTP輸送の使用はUDPにおける複数の周遊旅行の使用として好まれるかもしれません。 [47]と[49]に述べられるように、これは大きいテーブルの検索で問題であるかもしれません。
In addition, in cases where congestion is likely, such as in inter- domain accounting, TCP or SCTP congestion control and round-trip time estimation will be very useful, optimizing throughput. In applications which require maintenance of session state, such as simultaneous usage control, TCP and application-layer keep alive packets or SCTP with its built-in heartbeat capabilities provide a mechanism for keeping track of session state.
さらに、混雑が相互ドメイン会計などのようにありそうである場合では、TCPかSCTP輻輳制御と往復の時間見積りが非常に役に立ちます、スループットを最適化して。 同時の用法コントロールなどのセッション状態のメインテナンスを必要とするアプリケーションでは、内蔵の鼓動能力がある応用層のTCPとキープアライブパケットかSCTPがセッション状態の動向をおさえるのにメカニズムを提供します。
When implementing UDP retransmission, there are a number of issues to keep in mind:
UDP retransmissionを実装するとき、覚えておく多くの問題があります:
Data model
Retry behavior
Congestion control
Timeout behavior
データモデルRetry振舞いCongestionコントロールTimeoutの振舞い
Accounting reliability can be influenced by how the data is modeled. For example, it is almost always preferable to use cumulative variables rather than expressing accounting data in terms of a change from a previous data item. With cumulative data, the current state can be recovered by a successful retrieval, even after many packets have been lost. However, if the data is transmitted as a change then the state will not be recovered until the next cumulative update is sent. Thus, such implementations are much more vulnerable to packet loss, and should be avoided wherever possible.
データがどうモデル化されるかによって会計の信頼性に影響を及ぼすことができます。 例えば、変化に関して前のデータ項目から会計データを言い表すよりむしろ累積している変数を使用するのはほとんどいつも望ましいです。 累積しているデータで、多くのパケットが失われた後にさえうまくいっている検索で現状を埋め合わせることができます。 しかしながら、データが変化として送られると、状態は次の累積しているアップデートを送るまで回復されないでしょう。 したがって、そのような実装は、パケット損失にはるかに被害を受け易く、どこでも、可能であるところで避けられるべきです。
In designing a UDP retry mechanism, it is important that the retry timers relate to the round-trip time, so that retransmissions will not typically occur within the period in which acknowledgments may be expected to arrive. Accounting bandwidth may be significant in some circumstances, so that the added traffic due to unnecessary retransmissions may increase congestion levels.
UDP再試行メカニズムを設計するのにおいて、再試行タイマが往復の時間まで関係するのは、重要です、「再-トランスミッション」が承認が到着すると予想されるかもしれない時代中に通常現れないように。 会計帯域幅はいくつかの事情で重要であるかもしれません、不要な「再-トランスミッション」による加えられたトラフィックが混雑レベルを増強できるように。
Aboba, et al. Informational [Page 17] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[17ページ]のRFC2975序論
Congestion control in accounting data transfer is a somewhat controversial issue. Since accounting traffic is often considered mission-critical, it has been argued that congestion control is not a requirement; better to let other less-critical traffic back off in response to congestion. Moreover, without non-volatile storage, congestive back-off in accounting applications can result in data loss due to buffer exhaustion.
会計データ転送における輻輳制御はいくらか論議を呼んだ問題です。 会計トラフィックがミッションクリティカルであるとしばしば考えられるので、輻輳制御が要件でないと主張されました。 混雑に対応して他のそれほど重要でないトラフィックを放って戻すほうがよいです。 そのうえ、非揮発性記憶装置がなければ、下に会計アプリケーションにおける充血性の後部はバッファ疲労困憊によるデータの損失をもたらすことができます。
However, it can also be argued that in modern accounting implementations, it is possible to implement congestion control while improving throughput and maintaining high reliability. In circumstances where there is sustained packet loss, there simply is not sufficient capacity to maintain existing transmission rates. Thus, aggregate throughput will actually improve if congestive back- off is implemented. This is due to elimination of retransmissions and the ability to utilize techniques such as RED to desynchronize flows. In addition, with QoS mechanisms such as differentiated services, it is possible to mark accounting packets for preferential handling so as to provide for lower packet loss if desired. Thus considerable leeway is available to the network administrator in controlling the treatment of accounting packets and hard coding inelastic behavior is unnecessary. Typically, systems implementing non-volatile storage allow for backlogged accounting data to be placed in non-volatile storage pending transmission, so that buffer exhaustion resulting from congestive back-off need not be a concern.
しかしながら、また、現代の会計実装では、スループットを改良して、高信頼性を維持している間、混雑がコントロールであると実装するのが可能であると主張できます。 持続しているパケット損失がある事情には、既存の通信速度を維持できるくらいの容量が絶対にありません。 したがって、スループットが充血性の後部であるなら実際に向上するために望んでいる集合は実装されます。 これは「再-トランスミッション」の除去のためです、そして、反連動するのにREDなどのテクニックを利用する能力は流れます。 さらに、差別化されたサービスなどのQoSメカニズムでは、優先の取り扱いのために会計がパケットであるとマークするのは、望まれているなら低いパケット損失に備えるために可能です。 したがって、会計パケットの処理を制御することにおけるネットワーク管理者にとって、かなりの余裕が利用可能です、そして、困難なコード化弾力性のない振舞いは不要です。 通常、非揮発性記憶装置を実装するシステムは、バックログされた会計データがトランスミッションまで非揮発性記憶装置に置かれるのを許容します、下に充血性の後部から生じるバッファ疲労困憊が関心である必要はないように。
Since UDP is not really a transport protocol, UDP-based accounting protocols such as [4] often do not prescribe timeout behavior. Thus implementations may exhibit widely different behavior. For example, one implementation may drop accounting data after three constant duration retries to the same server, while another may implement exponential back-off to a given server, then switch to another server, up to a total timeout interval of twelve hours, while storing the untransmitted data on non-volatile storage. The practical difference between these approaches is substantial; the former approach will not satisfy archival accounting requirements while the latter may. More predictable behavior can be achieved via use of SCTP or TCP transport.
UDPが本当にトランスポート・プロトコルでないので、[4]などのUDPベースの会計プロトコルはしばしばタイムアウトの振舞いを定めるというわけではありません。 したがって、実装ははなはだしく異なった振舞いを示すかもしれません。 例えば、次に、別のものが下に指数の後部を与えられたサーバに実装しているかもしれない間、同じサーバへの3つの一定の持続時間再試行が別のサーバに切り替わった後に1つの実装が会計データを下げるかもしれません、非揮発性記憶装置に関する「非-伝え」られたデータを保存している間の12時間の総タイムアウト間隔まで。 これらのアプローチの実用的な違いは実質的です。 前のアプローチは後者が満たしている間、記録保管所の会計要件を満たさないでしょう。 SCTPかTCP輸送の使用で、より予測できる振舞いを達成できます。
2.1.4. Accounting server failover
2.1.4. 会計サーバフェイルオーバー
In the event of a failure of the primary accounting server, it is desirable for the device to failover to a secondary server. Providing one or more secondary servers can remove much of the risk of accounting server failure, and as a result use of secondary servers has become commonplace.
プライマリ会計サーバの失敗の場合、デバイスに、それはセカンダリサーバへのフェイルオーバーに望ましいです。会計サーバ失敗のリスク、セカンダリサーバの結果使用が平凡になったようにより多くの提供1セカンダリサーバは取り外されることができます。
Aboba, et al. Informational [Page 18] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[18ページ]のRFC2975序論
For protocols based on TCP, it is possible for the device to maintain connections to both the primary and secondary accounting servers, using the secondary connection after expiration of a timer on the primary connection. Alternatively, it is possible to open a connection to the secondary accounting server after a timeout or loss of the primary connection, or on expiration of a timer. Thus, accounting protocols based on TCP are capable of responding more rapidly to connectivity failures than TCP timeouts would otherwise allow, at the expense of an increased risk of duplicates.
TCPに基づくプロトコルに、デバイスが両方のプライマリの、そして、セカンダリの会計サーバに接続を維持するのは、可能です、プライマリ接続のタイマの満了の後にセカンダリ接続を使用して。 あるいはまた、プライマリ接続のタイムアウトか損失の後かタイマの満了ときのセカンダリ会計サーバに接続を開くのは可能です。 したがって、TCPに基づく会計プロトコルはTCPタイムアウトが別の方法で許容するだろうより接続性失敗に急速に応じることができます、写しの増強されたリスクを犠牲にして。
With SCTP, it is possible to control transport layer timeout behavior, and therefore it is not necessary for the accounting application to maintain its own timers. SCTP also enables multiplexing of multiple connections within a single transport connection, all maintaining the same congestion control state, avoiding the "head of line blocking" issues that can occur with TCP. However, since SCTP is not widely available, use of this transport can impose an additional implementation burden on the designer.
SCTPでは、トランスポート層タイムアウトの振舞いを制御するのが可能であり、したがって、会計アプリケーションがそれ自身のタイマを維持するのは必要ではありません。 また、SCTPは単独の輸送接続の中の複数の接続のマルチプレクシングを可能にします、同じ輻輳制御状態を皆、維持して、TCPと共に起こることができる「系列ブロッキングのヘッド」問題を避けて。 しかしながら、SCTPが広く利用可能でないので、この輸送の使用は追加実装負担をデザイナーに課すことができます。
For protocols using UDP, transmission to the secondary server can occur after a number of retries or timer expiration. For compatibility with congestion avoidance, it is advisable to incorporate techniques such as round-trip-time estimation, slow start and congestive back-off. Thus the accounting protocol designer utilizing UDP often is lead to re-inventing techniques already existing in TCP and SCTP. As a result, the use of raw UDP transport in accounting applications is not recommended.
UDPを使用するプロトコルのために、セカンダリサーバへのトランスミッションは多くの再試行かタイマ満了の後に起こることができます。 輻輳回避との互換性に、往復の時間見積りや、遅れた出発や下に充血性の後部などのテクニックを取り入れるのは賢明です。 したがって、しばしばUDPを利用している会計プロトコルデザイナーはTCPとSCTPに既に存在するテクニックを再発明することへのリードです。 その結果、会計アプリケーションにおける生のUDP輸送の使用は推薦されません。
With any transport it is possible for the primary and secondary accounting servers to receive duplicate packets, so support for duplicate elimination is required. Since accounting server failures can result in data accumulation on accounting clients, use of non- volatile storage can ensure against data loss due to transmission timeouts or buffer exhaustion. On-the-wire interim accounting provides only limited benefits in mitigating the effects of accounting server failures.
プライマリの、そして、セカンダリの会計サーバが受けるのが、可能であるあらゆる輸送で、写し除去のサポートが必要であるようにパケットをコピーしてください。 会計サーバ失敗が会計クライアントでデータ蓄積をもたらすことができるので、非揮発性記憶装置の使用はトランスミッションタイムアウトかバッファ疲労困憊によるデータの損失から身を守ることができます。 ワイヤにおける当座の会計は会計サーバ失敗の影響を緩和するのに限られた利益だけを提供します。
2.1.5. Application layer acknowledgments
2.1.5. 応用層承認
It is possible for the accounting server to experience partial failures. For example, a failure in the database back end could leave the accounting retrieval process or thread operable while the process or thread responsible for storing the data is non-functional. Similarly, it is possible for the accounting application to run out of disk space, making it unable to continue storing incoming session records.
会計サーバが部分的な失敗になるのは、可能です。 例えば、データを保存するのに原因となるプロセスかスレッドが非機能的である間、データベースバックエンドにおける失敗は検索過程か手術可能なスレッドに会計を放置するかもしれません。 同様に、会計アプリケーションが椎間腔を使い果たすのは、可能です、入って来るセッション記録を保存し続けているのをして。
Aboba, et al. Informational [Page 19] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[19ページ]のRFC2975序論
In such cases it is desirable to distinguish between transport layer acknowledgment and application layer acknowledgment. Even though both acknowledgments may be sent within the same packet (such as a TCP segment carrying an application layer acknowledgment along with a piggy-backed ACK), the semantics are different. A transport-layer acknowledgment means "the transport layer has taken responsibility for delivering the data to the application", while an application- layer acknowledgment means "the application has taken responsibility for the data".
そのような場合それはトランスポート層承認と応用層承認を見分けるのにおいて望ましいです。 同じくらい中で両方の承認を送るかもしれませんが、パケット(便乗しているACKに伴う応用層承認を運ぶTCPセグメントなどの)、意味論は異なっています。 トランスポート層承認は、「トランスポート層はデータをアプリケーションに提供することへの責任を取りました」と意味します、アプリケーション層の承認は、「アプリケーションはデータへの責任を取りました」と意味しますが。
A common misconception is that use of TCP transport guarantees that data is delivered to the application. However, as noted in RFC 793 [7]:
ありがちな誤解はTCP輸送の使用が、データがアプリケーションに提供されるのを保証するということです。 RFC793[7]で有名:
An acknowledgment by TCP does not guarantee that the data has been
delivered to the end user, but only that the receiving TCP has taken
the responsibility to do so.
TCPによる承認は、データがエンドユーザに提供されましたが、受信TCPがそうする責任を取るだけであったのを保証しません。
Therefore, if receiving TCP fails after sending the ACK, the application may not receive the data. Similarly, if the application fails prior to committing the data to stable storage, the data may be lost. In order for a sending application to be sure that the data it sent was received by the receiving application, either a graceful close of the TCP connection or an application-layer acknowledgment is required. In order to protect against data loss, it is necessary that the application-layer acknowledgment imply that the data has been written to stable storage or suitably processed so as to guard against loss.
したがって、ACKを送った後に受信TCPが失敗するなら、アプリケーションはデータを受信しないかもしれません。 同様に、安定貯蔵にデータを遂行する前にアプリケーションが失敗するなら、データは失われるかもしれません。 送付アプリケーションがそれが送ったデータが受信アプリケーションで受け取られたのを確信しているように、TCP接続の優雅な閉鎖か応用層承認のどちらかが必要です。 データの損失から守るために、応用層承認が、損失に用心するためにデータを安定貯蔵まで書かれているか、または適当に処理してあるのを含意するのが必要です。
In the case of partial failures, it is possible for the transport layer to acknowledge receipt via transport layer acknowledgment, without having delivered the data to the application. Similarly, the application may not complete the tasks necessary to take responsibility for the data.
部分的な失敗の場合では、トランスポート層に、トランスポート層承認で領収書を受け取ったことを知らせるのは可能です、データをアプリケーションに提供していなくて。 同様に、アプリケーションはデータへの責任を取るのに必要なタスクを完成しないかもしれません。
For example, an accounting server may receive data from the transport layer but be incapable of storing it data due to a back end database problem or disk fault. In this case it should not send an application layer acknowledgment, even though a a transport layer acknowledgment is appropriate. Rather, an application layer error message should be sent indicating the source of the problem, such as "Backend store unavailable".
例えば、会計サーバは、バックエンドデータベース問題かディスク欠点としてデータ当然の状態でトランスポート層からデータを受け取りますが、それを保存できないかもしれません。 この場合、aトランスポート層承認は適切ですが、それは応用層承認を送るべきではありません。 むしろ、「入手できないバックエンド店」などの問題について出所を明らかにするのを応用層エラーメッセージに送るべきです。
Thus application-layer acknowledgment capability requires not only the ability to acknowledge when the application has taken responsibility for the data, but also the ability to indicate when the application has not taken responsibility for the data, and why.
したがって、応用層承認能力はアプリケーションがデータへの責任を取ったと認める能力だけではなく、アプリケーションがいつデータ、およびなぜへの責任を取っていないかを示す能力も必要とします。
Aboba, et al. Informational [Page 20] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[20ページ]のRFC2975序論
2.1.6. Network failures
2.1.6. ネットワーク失敗
Network failures may result in partial or complete loss of connectivity for the accounting client. In the event of partial connectivity loss, it may not be possible to reach the primary accounting server, in which case switch over to the secondary accounting server is necessary. In the event of a network partition, it may be necessary to store accounting events in device memory or non-volatile storage until connectivity can be re-established.
ネットワーク失敗は会計クライアントへの接続性の部分的であるか完全な損失をもたらすかもしれません。 部分的な接続性の損失の場合、プライマリ会計サーバに達するのが可能でないかもしれない、その場合、セカンダリ会計サーバへのスイッチが必要です。 ネットワークパーティションの場合、接続性が復職できるまで、デバイスメモリか非揮発性記憶装置で会計イベントを保存するのが必要であるかもしれません。
As with accounting server failures, on-the-wire interim accounting provides only limited benefits in mitigating the effects of network failures.
会計サーバ失敗、ワイヤにおける当座の会計はネットワーク失敗の影響を緩和するのに限られた利益だけを提供します。
2.1.7. Device reboots
2.1.7. デバイスリブート
In the event of a device reboot, it is desirable to minimize the loss of data on sessions in progress. Such losses may be significant even if the devices themselves are very reliable, due to long-lived sessions, which can comprise a significant fraction of total resource consumption. To guard against loss of these high-value sessions, interim accounting data is typically transmitted over the wire. When interim accounting in-place is combined with non-volatile storage it becomes possible to guard against data loss in much shorter sessions. This is possible since interim accounting data need only be stored in non-volatile memory until the session completes, at which time the interim data may be replaced by the session record. As a result, interim accounting data need never be sent over the wire, and it is possible to decrease the interim interval so as to provide a very high degree of protection against data loss.
デバイスリブートの場合、進行中のセッションのときにデータの喪失を最小にするのは望ましいです。 デバイス自体が非常に高信頼であっても、そのような損失は重要であるかもしれません、長命のセッションのため。セッションは総リソース消費で重要な断片を包括できます。 これらの高値のセッションの損失に用心するために、当座の会計データはワイヤの上に通常送られます。 適所にある当座の会計が非揮発性記憶装置に結合されるとき、はるかに短いセッションにおけるデータの損失に用心するのは可能になります。 当座の会計データが非揮発性メモリーに保存されるだけでよいので、セッションがどの時間で当座のデータを取り替えるかもしれないかときセッション記録を完成するまで、これは可能です。 その結果、当座の会計データをワイヤの上に決して送ってはいけません、そして、当座の間隔を減少させるのは、データの損失に対する非常に高度合いの保護を提供するために可能です。
2.1.8. Accounting proxies
2.1.8. 会計プロキシ
In order to maintain high reliability, it is important that accounting proxies pass through transport and application layer acknowledgments and do not store and forward accounting packets. This enables the end-systems to control re-transmission behavior and utilize techniques such as non-volatile storage and secondary servers to improve resilience.
高信頼性を維持するために、会計プロキシが会計パケットを輸送と応用層承認を通り抜けて、保存して、進めないのは、重要です。 これは、エンドシステムが弾力を改良するのに再トランスミッションの振舞いを制御して、非揮発性記憶装置やセカンダリサーバなどのテクニックを利用するのを可能にします。
Accounting proxies sending a transport or application layer ACK to the device without receiving one from the accounting server fool the device into thinking that the accounting request had been accepted by the accounting server when this is not the case. As a result, the device can delete the accounting packet from non-volatile storage before it has been accepted by the accounting server. The leaves the
会計サーバからの1を受け取らないでACKの輸送か応用層をデバイスに送る会計プロキシがこれがそうでないときに、受け入れられた会計が会計サーバから要求する考えにデバイスをだまします。 その結果、会計サーバでそれを受け入れる前にデバイスが非揮発性記憶装置から会計パケットを削除できる、葉
Aboba, et al. Informational [Page 21] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[21ページ]のRFC2975序論
accounting proxy responsible for delivering accounting packets. If the accounting proxy involves moving parts (e.g. a disk drive) while the devices do not, overall system reliability can be reduced.
会計パケットを提供するのに責任があるプロキシを説明します。 デバイスがかかわりませんが、会計プロキシが可動部(例えば、ディスクドライブ)にかかわるなら、総合体系の信頼性は減少できます。
Store and forward accounting proxies only add value in situations where the accounting subsystem is unreliable. For example, where devices do not implement non-volatile storage and the accounting protocol lacks transport and application layer reliability, locating the accounting proxy (with its stable storage) close to the device can reduce the risk of data loss.
ストアと未来会計プロキシだけが会計サブシステムが頼り無い状況で価値を高めます。 例えば、デバイスの近くにデバイスが非揮発性記憶装置を実装しないで、会計プロトコルが輸送と応用層の信頼性を欠いているところに会計プロキシ(安定貯蔵がある)を位置させるのはデータの損失の危険を減少させることができます。
However, such systems are inherently unreliable so that they are only appropriate for use in capacity planning or non-usage sensitive billing applications. If archival accounting reliability is desired, it is necessary to engineer a reliable accounting system from the start using the techniques described in this document, rather than attempting to patch an inherently unreliable system by adding store and forward accounting proxies.
しかしながら、そのようなシステムが本来頼り無いので、キャパシティプランニングか非用法の敏感な支払いアプリケーションにおける使用だけに、それらは適切です。 記録保管所の会計の信頼性が望まれているなら、始めから高信頼の会計システムを設計するのが、会計プロキシを保存して、進めるように言い足すことによって本来頼り無いシステムにパッチするのを試みるより本書ではむしろ説明されたテクニックを使用することで必要です。
Aboba, et al. Informational [Page 22] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[22ページ]のRFC2975序論
2.1.9. Fault resilience summary
2.1.9. 欠点弾力概要
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Fault | Counter-measures | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Packet | Retransmission based on RTT | | loss | Congestion control | | | Well-defined timeout behavior | | | Duplicate elimination | | | Interim accounting* | | | Non-volatile storage | | | Cumulative variables | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Accounting | Primary-secondary servers | | server & net | Duplicate elimination | | failures | Interim accounting* | | | Application layer ACK & error msgs. | | | Non-volatile storage | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Device | Interim accounting* | | reboots | Non-volatile storage | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | 欠点| 対応策| | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | パケット| RTTに基づくRetransmission| | 損失| 輻輳制御| | | 明確なタイムアウトの振舞い| | | 除去をコピーしてください。| | | 当座の会計*| | | 非揮発性記憶装置| | | 累積している変数| | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | 会計| プライマリセカンダリサーバ| | サーバとネット| 除去をコピーしてください。| | 失敗| 当座の会計*| | | 応用層ACKとエラーメッセージ。 | | | 非揮発性記憶装置| | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | デバイス| 当座の会計*| | リブート| 非揮発性記憶装置| | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key * = limited usefulness without non-volatile storage
キー*は非揮発性記憶装置なしで限られた有用性と等しいです。
Note: Accounting proxies are not a reliability enhancement mechanism.
以下に注意してください。 会計プロキシは信頼性のエンハンスメカニズムではありません。
2.2. Resource consumption
2.2. リソース消費
In the process of growing to meet the needs of providers and customers, accounting management systems consume a variety of resources, including:
プロバイダーと顧客の需要を満たすために成長することの途中に、会計管理システムはさまざまなリソースを消費します、である:
Network bandwidth
Memory
Non-volatile storage
State on the accounting management system
CPU on the management system and managed devices
マネージメントシステムと管理されたデバイスの上の会計管理システムCPUの上のネットワーク回線容量Memory Non-揮発性記憶装置州
Aboba, et al. Informational [Page 23] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[23ページ]のRFC2975序論
In order to understand the limits to scaling, we examine each of these resources in turn.
スケーリングへの限界を理解するために、私たちは順番にそれぞれに関するこれらのリソースを調べます。
2.2.1. Network bandwidth
2.2.1. ネットワーク回線容量
Accounting management systems consume network bandwidth in transferring accounting data. The network bandwidth consumed is proportional to the amount of data transferred, as well as required network overhead. Since accounting data for a given event may be 100 octets or less, if each event is transferred individually, overhead can represent a considerable proportion of total bandwidth consumption. As a result, it is often desirable to transfer accounting data in batches, enabling network overhead to be spread over a larger payload, and enabling efficient use of compression. As noted in [48], compression can be enabled in the accounting protocol, or can be done at the IP layer as described in [5].
会計管理システムは会計データを移す際にネットワーク回線容量を消費します。 帯域幅が消費したネットワークは必要なネットワークオーバーヘッドと同様に移されたデータ量に比例しています。 個別に各イベントを移すなら与えられたイベントのための会計データが100以下の八重奏であるかもしれないので、オーバーヘッドは総帯域幅消費の大部分を表すことができます。 その結果、バッチにおける会計データを移すのはしばしば望ましいです、ネットワークオーバーヘッドが、より大きいペイロードに広がられるのを可能にして、圧縮の効率的な使用を可能にして。 [48]に述べられるように、会計プロトコルで可能にすることができるか、または[5]で説明されるようにIP層に圧縮できます。
2.2.2. Memory
2.2.2. メモリ
In accounting systems without non-volatile storage, accounting data must be stored in volatile memory during the period between when it is generated and when it is transferred. The resulting memory consumption will depend on retry and retransmission algorithms. Since systems designed for high reliability will typically wish to retry for long periods, or may store interim accounting data, the resulting memory consumption can be considerable. As a result, if non-volatile storage is unavailable, it may be desirable to compress accounting data awaiting transmission.
非揮発性記憶装置のない会計システムでは、発生している時、それがわたっている時期間、揮発性メモリーに会計データを保存しなければなりません。 結果として起こるメモリ消費は再試行と再送信アルゴリズムに依存するでしょう。高信頼性のために設計されたシステムが長期の間、再試行することを通常願うか、または当座の会計データを保存するかもしれないので、結果として起こるメモリ消費は無視できない場合があります。 その結果、非揮発性記憶装置が入手できないなら、トランスミッションを待つ会計データを圧縮するのは望ましいかもしれません。
As noted earlier, implementors of interim accounting should take care to ensure against excessive memory usage by overwriting older interim accounting data with newer data for the same session rather than accumulating interim data in the buffer.
より早く注意されるように、当座の会計の作成者は過度のメモリ使用量から同じセッションのための、より新しいデータでむしろバッファの当座のデータを蓄積するより古い当座の会計データを上書きすることによって身を守るために注意するべきです。
2.2.3. Non-volatile storage
2.2.3. 非揮発性記憶装置
Since accounting data stored in memory will typically be lost in the event of a device reboot or a timeout, it may be desirable to provide non-volatile storage for undelivered accounting data. With the costs of non-volatile storage declining rapidly, network devices will be increasingly capable of incorporating non-volatile storage support over the next few years.
会計メモリに格納されたデータがデバイスリブートかタイムアウトの場合通常失われるので、非提供された会計データに非揮発性記憶装置を提供するのは望ましいかもしれません。 非揮発性記憶装置のコストが急速に下落していて、ネットワークデバイスはますますこの数年間にわたって非揮発性記憶装置サポートを取り入れることができるでしょう。
Non-volatile storage may be used to store interim or session records. As with memory utilization, interim accounting overwrite is desirable so as to prevent excessive storage consumption. Note that the use of ASCII data representation enables use of highly efficient text compression algorithms that can minimize storage requirements. Such
非揮発性記憶装置は、当座かセッション記録を保存するのに使用されるかもしれません。 メモリ使用量のように、当座の会計重ね書きは、過度のストレージ消費を防ぐために望ましいです。 ASCIIデータ表現の使用がストレージ要件を最小にすることができる高能率的なテキスト圧縮アルゴリズムの使用を可能にすることに注意してください。 そのようなもの
Aboba, et al. Informational [Page 24] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[24ページ]のRFC2975序論
compression algorithms are only typically applied to session records so as to enable implementation of interim data overwrite.
圧縮アルゴリズムは、当座のデータ重ね書きの実装を可能にするためにセッション記録に通常適用されるだけです。
2.2.4. State on the accounting management system
2.2.4. 会計管理システムの上の状態
In order to keep track of received accounting data, accounting management systems may need to keep state on managed devices or concurrent sessions. Since the number of devices is typically much smaller than the number of concurrent sessions, it is desirable to keep only per-device state if possible.
受信された会計データの動向をおさえるために、システムがオンに状態を維持する必要があるかもしれない会計管理はデバイスか同時発生のセッションを管理しました。 デバイスの数が同時発生のセッションの数よりはるかに通常少ないので、できれば、各装置状態だけを維持するのは望ましいです。
2.2.5. CPU requirements
2.2.5. CPU要件
CPU consumption of the managed and managing nodes will be proportional to the complexity of the required accounting processing. Operations such as ASN.1 encoding and decoding, compression/decompression, and encryption/decryption can consume considerable resources, both on accounting clients and servers.
管理とノードを管理するCPU消費は必要な会計処理の複雑さに比例するようになるでしょう。 ASN.1コード化や解読などの操作、圧縮/減圧、および暗号化/復号化は会計クライアントとサーバに関するかなりのリソースを消費できます。
The effect of these operations on accounting system reliability should not be under-estimated, particularly in the case of devices with moderate CPU resources. In the event that devices are over- taxed by accounting tasks, it is likely that overall device reliability will suffer.
会計システムの信頼性へのこれらの操作の効果を過小評価するべきではありません、特に適度のCPUリソースがあるデバイスの場合で。 デバイスが会計タスクによって税をかけられ過ぎると、総合的なデバイスの信頼性に苦しみそうでしょう。
Aboba, et al. Informational [Page 25] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[25ページ]のRFC2975序論
2.2.6. Efficiency measures
2.2.6. 効率測定
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Resource | Efficiency measures | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Network | Batching | | Bandwidth | Compression | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Memory | Compression | | | Interim accounting overwrite | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Non-volatile | Compression | | Storage | Interim accounting overwrite | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | System | Per-device state | | state | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | CPU | Hardware assisted | | requirements | compression/encryption | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | リソース| 効率測定| | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | ネットワーク| バッチング| | 帯域幅| 圧縮| | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | メモリ| 圧縮| | | 当座の会計重ね書き| | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | 非揮発性です。| 圧縮| | ストレージ| 当座の会計重ね書き| | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | システム| 各装置状態| | 状態| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | CPU| ハードウェアは補助されました。| | 要件| 圧縮/暗号化| | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.3. Data collection models
2.3. データ収集モデル
Several data collection models are currently in use today for the purposes of accounting data collection. These include:
現在、数個のデータ収集モデルが今日の会計データ収集の目的の使用であります。 これらは:
Polling model
Event-driven model without batching
Event-driven model with batching
Event-driven polling model
投票して、バッチングのEvent駆動の世論調査モデルと共にバッチングのEvent駆動のモデルなしでEvent駆動のモデルをモデル化してください。
Aboba, et al. Informational [Page 26] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[26ページ]のRFC2975序論
2.3.1. Polling model
2.3.1. 世論調査モデル
In the polling model, an accounting manager will poll devices for accounting information at regular intervals. In order to ensure against loss of data, the polling interval will need to be shorter than the maximum time that accounting data can be stored on the polled device. For devices without non-volatile stage, this is typically determined by available memory; for devices with non- volatile storage the maximum polling interval is determined by the size of non-volatile storage.
世論調査モデルでは、経理担当重役は課金情報のために一定の間隔を置いてデバイスに投票するでしょう。 データの喪失から身を守るために、ポーリングインタバルは、投票されたデバイスに会計データを保存できる最大の時間より短い必要があるでしょう。 非揮発性のステージのないデバイスに関しては、これは利用可能なメモリで通常断固としています。 非揮発性記憶装置があるデバイスに関しては、非揮発性記憶装置のサイズに従って、最大のポーリングインタバルは決定しています。
The polling model results in an accumulation of data within individual devices, and as a result, data is typically transferred to the accounting manager in a batch, resulting in an efficient transfer process. In terms of Accounting Manager state, polling systems scale with the number of managed devices, and system bandwidth usage scales with the amount of data transferred.
世論調査モデルは個々のデバイスの中にデータの蓄積をもたらします、そして、その結果、一括している経理担当重役にデータを通常移します、効率的な転送プロセスをもたらして。 Accountingマネージャ状態に関して、世論調査システムは管理されたデバイスの数、およびデータ量を移しているシステムの帯域幅用法スケールで比例します。
Without non-volatile storage, the polling model results in loss of accounting data due to device reboots, but not due to packet loss or network failures of sufficiently short duration to be handled within available memory. This is because the Accounting Manager will continue to poll until the data is received. In situations where operational difficulties are encountered, the volume of accounting data will frequently increase so as to make data loss more likely. However, in this case the polling model will detect the problem since attempts to reach the managed devices will fail.
非揮発性記憶装置がなければ、世論調査モデルはデバイスリブートのためデータを説明しますが、パケット損失のため説明するというわけではない損失か利用可能なメモリの中で扱われない十分短い持続時間のネットワークのことをもたらします。 これはAccountingマネージャが、データが受信されるまで投票し続けるからです。 運転上の諸問題が遭遇する状況で、会計データのボリュームは、データをおそらく、損失にするように頻繁に増加するでしょう。 しかしながら、管理されたデバイスに達する試みが失敗するので、この場合、世論調査モデルは問題を検出するでしょう。
The polling model scales poorly for implementation of shared use or roaming services, including wireless data, Internet telephony, QoS provisioning or Internet access. This is because in order to retrieve accounting data for users within a given domain, the Accounting Management station would need to periodically poll all devices in all domains, most of which would not contain any relevant data. There are also issues with processing delay, since use of a polling interval also implies an average processing delay of half the polling interval. This may be too high for accounting data that requires low processing delay. Thus the event-driven polling or the pure event-driven approach is more appropriate for usage sensitive billing applications such as shared use or roaming implementations.
世論調査モデルは共有された使用かローミング・サービスの実装のために不十分に比例します、ワイヤレスのデータ、インターネット電話、QoSの食糧を供給することまたはインターネット・アクセスを含んでいて。 Accounting Managementステーションは、与えられたドメインの中のユーザのために会計データを検索するのに定期的にそれの大部分が少しの関連データも含まないだろうすべてのドメインのすべてのデバイスに投票する必要があるでしょう、したがって、これがそうです。 処理遅れには問題もあります、また、ポーリングインタバルの使用がポーリングインタバルの半分の平均した処理遅れを含意するので。 低い処理遅れを必要とする会計データには、これは高過ぎるかもしれません。 したがって、イベントドリブン世論調査か純粋なイベントドリブンアプローチが、共有された使用などの用法の敏感な支払い応用に適切であるか実装に移動します。
Per-device state is typical of polling-based network management systems, which often also carry out accounting management functions, since network management systems need to keep track of the state of network devices for operational purposes. These systems offer average processing delays equal to half the polling interval.
各装置状態は世論調査ベースのネットワーク管理システムの典型です、ネットワーク管理システムが、操作上の目的のためにネットワークデバイスの状態の動向をおさえる必要があるので。(また、ネットワーク管理システムはしばしば会計管理機能を行います)。 これらのシステムはポーリングインタバルの半分と等しい平均した処理遅れを提供します。
Aboba, et al. Informational [Page 27] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[27ページ]のRFC2975序論
2.3.2. Event-driven model without batching
2.3.2. バッチングのないイベントドリブンモデル
In the event-driven model, a device will contact the accounting server or manager when it is ready to transfer accounting data. Most event-driven accounting systems, such as those based on RADIUS accounting, described in [4], transfer only one accounting event per packet, which is inefficient.
それが会計データを移す準備ができているとき、イベントドリブンモデルで、デバイスは会計サーバかマネージャに連絡するでしょう。 [4]で説明されたRADIUS会計に基づくものなどのイベントドリブンほとんどの会計システムが1パケットあたり1回の会計イベントだけを移します。(パケットは効率が悪いです)。
Without non-volatile storage, a pure event-driven model typically stores accounting events that have not yet been delivered only until the timeout interval expires. As a result this model has the smallest memory requirements. Once the timeout interval has expired, the accounting event is lost, even if the device has sufficient buffer space to continue to store it. As a result, the event-driven model is the least reliable, since accounting data loss will occur due to device reboots, sustained packet loss, or network failures of duration greater than the timeout interval. In event-driven protocols without a "keep alive" message, accounting servers cannot assume a device failure should no messages arrive for an extended period. Thus, event-driven accounting systems are typically not useful in monitoring of device health.
非揮発性記憶装置がなければ、純粋なイベントドリブンモデルはタイムアウト間隔が期限が切れるまでしかまだ提供されていない会計イベントを通常保存します。 その結果、このモデルには、最も小さいメモリ要件があります。 タイムアウト間隔がいったん期限が切れると、会計イベントは無くなります、デバイスにそれを保存し続けることができるくらいのバッファ領域があっても。 その結果、イベントドリブンモデルは最も頼もしくはありません、会計データの損失がタイムアウト間隔より大きい持続時間のデバイスリブート、持続しているパケット損失、またはネットワーク失敗のため発生するので。 「生きているままでいてください」というメッセージのないイベントドリブンプロトコル、メッセージが全く長期間の間、到着しないならサーバがデバイスの故障であると仮定できない会計で。 したがって、イベントドリブン会計システムはデバイス健康のモニターで通常役に立ちません。
The event-driven model is frequently used in shared use networks and roaming, since this model sends data to the recipient domains without requiring them to poll a large number of devices, most of which have no relevant data. Since the event-driven model typically does not support batching, it permits accounting records to be sent with low processing delay, enabling application of fraud prevention techniques. However, because roaming accounting events are frequently of high value, the poor reliability of this model is an issue. As a result, the event-driven polling model may be more appropriate.
イベントドリブンモデルはネットワークを使用して、移動しながら、共有されるところで頻繁に使用されます、このモデルがそれの大部分にはどんな関連データもないデバイスの投票多くにそれらを必要としないで受取人ドメインにデータを送るので。 イベントドリブンモデルがバッチングを通常サポートしないので、会計帳簿が低い処理遅れと共に送られることを許可します、詐欺防止のテクニックの応用を可能にして。 しかしながら、ローミング会計イベントには頻繁な高い価値があるので、このモデルの貧しい信頼性は問題です。 その結果、イベントドリブン世論調査モデルは、より適切であるかもしれません。
Per-session state is typical of event-driven systems without batching. As a result, the event-driven approach scales poorly. However, event-driven systems offer the lowest processing delay since events are processed immediately and there is no possibility of an event requiring low processing delay being caught behind a batch transfer.
1セッションあたりの状態はイベントドリブンシステムのバッチングのない典型です。 その結果、イベントドリブンアプローチは不十分に比例します。 しかしながら、イベントドリブンシステムはイベントがすぐに、処理されて、イベントがバッチ転送の後ろに捕らえられる低い処理遅れを必要とする可能性が全くなくて以来の最も低い処理遅れを提供します。
2.3.3. Event-driven model with batching
2.3.3. バッチングがあるイベントドリブンモデル
In the event-driven model with batching, a device will contact the accounting server or manager when it is ready to transfer accounting data. The device can contact the server when a batch of a given size has been gathered, when data of a certain type is available or after a minimum time period has elapsed. Such systems can transfer more than one accounting event per packet and are thus more efficient.
それが会計データを移す準備ができているとき、バッチングがあるイベントドリブンモデルで、デバイスは会計サーバかマネージャに連絡するでしょう。 与えられたサイズのバッチを集めてあるとき、デバイスはサーバに連絡できます、あるタイプに関するデータが利用可能であるか、または最小の期間の後に経過したとき。 そのようなシステムは、1パケットあたり1回以上の会計イベントを移すことができて、その結果、より効率的です。
Aboba, et al. Informational [Page 28] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[28ページ]のRFC2975序論
An event-driven system with batching will store accounting events that have not yet been delivered up to the limits of memory. As a result, accounting data loss will occur due to device reboots, but not due to packet loss or network failures of sufficiently short duration to be handled within available memory. Note that while transfer efficiency will increase with batch size, without non- volatile storage, the potential data loss from a device reboot will also increase.
バッチングがあるイベントドリブンシステムはまだメモリの限界まで提供されていない会計イベントを保存するでしょう。 その結果、会計データの損失は、デバイスリブートのため起こりますが、十分短い持続時間が利用可能なメモリの中で扱われないパケット損失かネットワークのことのため起こるというわけではないでしょう。 また、バッチサイズに従って転送効率が非揮発性記憶装置なしで増加している間デバイスリブートからの潜在的データの損失が上がることに注意してください。
Where event-driven systems with batching have a keep-alive interval and run over reliable transport, the accounting server can assume that a failure has occurred if no messages are received within the keep-alive interval. Thus, such implementations can be useful in monitoring of device health. When used for this purpose the average time delay prior to failure detection is one half the keep-alive interval.
バッチングがあるイベントドリブンシステムが生きている生活費間隔を持って、信頼できる輸送をひくところでは、会計サーバは、生きている生活費間隔中にメッセージを全く受け取らないなら失敗が起こったと仮定できます。 したがって、そのような実装はデバイス健康のモニターで役に立つ場合があります。 平均時間が失敗検出の前に遅らせるこの目的に使用されているとき、半分が生きている生活費間隔ですか?
Through implementation of a scheduling algorithm, event-driven systems with batching can deliver appropriate service to accounting events that require low processing delay. For example, high-value inter-domain accounting events could be sent immediately, thus enabling use of fraud-prevention techniques, while all other events would be batched. However, there is a possibility that an event requiring low processing delay will be caught behind a batch transfer in progress. Thus the maximum processing delay is proportional to the maximum batch size divided by the link speed.
スケジューリングアルゴリズムの実装を通して、バッチングがあるイベントドリブンシステムは低い処理遅れを必要とする会計イベントに対する適切なサービスを提供できます。 例えば、すぐに高値の相互ドメイン会計イベントを送ることができました、その結果、詐欺防止のテクニックの使用を可能にします、他のすべてのイベントがbatchedされるでしょうが。 しかしながら、低い処理遅れを必要とするイベントが進行中のバッチ転送の後ろに捕らえられる可能性があります。 したがって、最大の処理遅れは最大のリンク速度が割られたバッチサイズに比例しています。
Event-driven systems with batching scale with the number of active devices. As a result this approach scales better than the pure event-driven approach, or even the polling approach, and is equivalent in terms of scaling to the event-driven polling approach. However, the event-driven batching approach has lower processing delay than the event-driven polling approach, since delivery of accounting data requires fewer round-trips and events requiring low processing delay can be accommodated if a scheduling algorithm is employed.
バッチングがあるイベントドリブンシステムは能動素子の数で比例します。 その結果、このアプローチは、純粋なイベントドリブンアプローチ、または世論調査アプローチよりさえよく比例して、イベントドリブン世論調査アプローチに比例するのにおいて同等です。 しかしながら、イベントドリブンバッチングアプローチには、イベントドリブン世論調査アプローチより低い処理遅れがあります、会計データの配送がさらに少ない周遊旅行を必要として、スケジューリングアルゴリズムが採用しているなら低い処理遅れを必要とするイベントは設備することができるので。
2.3.4. Event-driven polling model
2.3.4. イベントドリブン世論調査モデル
In the event-driven polling model an accounting manager will poll the device for accounting data only when it receives an event. The accounting client can generate an event when a batch of a given size has been gathered, when data of a certain type is available or after a minimum time period has elapsed. Note that while transfer efficiency will increase with batch size, without non-volatile storage, the potential data loss from a device reboot will also increase.
イベントを受けるときだけ、イベントドリブン世論調査モデルでは、経理担当重役は会計データのためにデバイスに投票するでしょう。 与えられたサイズのバッチを集めてあるとき、会計クライアントはイベントを生成できます、あるタイプに関するデータが利用可能であるか、または最小の期間の後に経過したとき。 また、バッチサイズに従って転送効率が非揮発性記憶装置なしで増加している間デバイスリブートからの潜在的データの損失が上がることに注意してください。
Aboba, et al. Informational [Page 29] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[29ページ]のRFC2975序論
Without non-volatile storage, an event-driven polling model will lose data due to device reboots, but not due to packet loss, or network partitions of short-duration. Unless a minimum delivery interval is set, event-driven polling systems are not useful in monitoring of device health.
非揮発性記憶装置がなければ、イベントドリブン世論調査モデルは、デバイスによるデータリブートを失いますが、パケット損失、または短期間のネットワークパーティションを失うというわけではないでしょう。 最小の配送間隔が設定されない場合、イベントドリブン世論調査システムはデバイス健康のモニターで役に立ちません。
The event-driven polling model can be suitable for use in roaming since it permits accounting data to be sent to the roaming partners with low processing delay. At the same time non-roaming accounting can be handled via more efficient polling techniques, thereby providing the best of both worlds.
イベントドリブン世論調査モデルは会計データが低い処理遅れのローミングパートナーに送られることを許可するので移動することにおける使用に適している場合があります。 同時に、より効率的な世論調査のテクニックで非ローミング会計を扱うことができます、その結果、両方の最善な世界を提供します。
Where batching can be implemented, the state required in event-driven polling can be reduced to scale with the number of active devices. If portions of the network vary widely in usage, then this state may actually be less than that of the polling approach. Note that processing delay in this approach is higher than in event-driven accounting with batching since at least two round-trips are required to deliver data: one for the event notification, and one for the resulting poll.
バッチングを実装することができるところでは、イベントドリブン世論調査で必要である状態は、能動素子の数で比例するように減少できます。 ネットワークの一部が用法でばらつきが大きいなら、この状態は実際に世論調査アプローチのもの以下であるかもしれません。 少なくとも2つの周遊旅行がデータを提供するのに必要であるのでこのアプローチの処理遅れがバッチングによるイベントドリブン会計より高いことに注意してください: イベント通知のためのもの、および結果として起こる投票のためのもの。
Aboba, et al. Informational [Page 30] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[30ページ]のRFC2975序論
2.3.5. Data collection summary
2.3.5. データ収集概要
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Model | Pros | Cons | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Polling | Per-device state | Not robust | | | Robust against | against device | | | packet loss | reboot, server | | | Batch transfers | or network | | | | failures* | | | | Polling interval | | | | determined by | | | | storage limit | | | | High processing | | | | delay | | | | Unsuitable for | | | | use in roaming | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Event-driven, | Lowest processing | Not robust | | no batching | delay | against packet | | | Suitable for | loss, device | | | use in roaming | reboot, or | | | | network | | | | failures* | | | | Low efficiency | | | | Per-session state | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Event-driven, | Single round-trip | Not robust | | with batching | latency | against device | | and | Batch transfers | reboot, network | | scheduling | Suitable for | failures* | | | use in roaming | | | | Per active device | | | | state | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Event-driven | Batch transfers | Not robust | | polling | Suitable for | against device | | | use in roaming | reboot, network | | | Per active device | failures* | | | state | Two round-trip | | | | latency | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | モデル| プロ| コンズ| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 世論調査| 各装置状態| 強健でない| | | 強健| デバイスに対して| | | パケット損失| リブート、サーバ| | | バッチ転送| または、ネットワーク| | | | 失敗*| | | | ポーリングインタバル| | | | 自決します。| | | | ストレージ限界| | | | 高い処理| | | | 遅れ| | | | 不適当| | | | ローミングにおける使用| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | イベントドリブン| 最も低い処理| 強健でない| | バッチングがありません。| 遅れ| パケットに対して| | | 適当| 損失、デバイス| | | ローミングにおける使用| リブート| | | | ネットワーク| | | | 失敗*| | | | 低い能率| | | | 1セッションあたりの状態| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | イベントドリブン| ただ一つの丸い旅行| 強健でない| | バッチングで| 潜在| デバイスに対して| | そして| バッチ転送| リブート、ネットワーク| | スケジューリング| 適当| 失敗*| | | ローミングにおける使用| | | | 能動素子単位で| | | | 状態| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | イベントドリブン| バッチ転送| 強健でない| | 世論調査| 適当| デバイスに対して| | | ローミングにおける使用| リブート、ネットワーク| | | 能動素子単位で| 失敗*| | | 状態| 2、往復| | | | 潜在| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key * = addressed by non-volatile storage
非揮発性記憶装置で扱われた主要な*=
Aboba, et al. Informational [Page 31] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[31ページ]のRFC2975序論
3. Review of Accounting Protocols
3. 会計プロトコルのレビュー
Accounting systems have been successfully implemented using protocols such as RADIUS, TACACS+, and SNMP. This section describes the characteristics of each of these protocols.
会計システムは、RADIUSや、TACACS+や、SNMPなどのプロトコルを使用することで首尾よく実装されました。 このセクションはそれぞれのこれらのプロトコルの特性について説明します。
3.1. RADIUS
3.1. 半径
RADIUS accounting, described in [4], was developed as an add-on to the RADIUS authentication protocol, described in [3]. As a result, RADIUS accounting shares the event-driven approach of RADIUS authentication, without support for batching or polling. As a result, RADIUS accounting scales with the number of accounting events instead of the number of devices, and accounting transfers are inefficient.
[4]で説明されたRADIUS会計はアドオンとして[3]で説明されたRADIUS認証プロトコルに開発されました。 その結果、RADIUS会計はバッチングか世論調査のサポートなしでRADIUS認証のイベントドリブンアプローチを共有します。 その結果、RADIUS会計はデバイスの数の代わりに会計イベントの数で比例します、そして、会計転送は効率が悪いです。
Since RADIUS accounting is based on UDP and timeout and retry parameters are not specified, implementations vary widely in their approach to reliability, with some implementations retrying until delivery or buffer exhaustion, and others losing accounting data after a few retries. Since RADIUS accounting does not provide for application-layer acknowledgments or error messages, a RADIUS Accounting-Response is equivalent to a transport-layer acknowledgment and provides no protection against application layer malfunctions. Due to the lack of reliability, it is not possible to do simultaneous usage control based on RADIUS accounting alone. Typically another device data source is required, such as polling of a session MIB or a command-line session over telnet.
RADIUS会計がUDPとタイムアウトに基づいていて、再試行パラメタが指定されないので、実装は信頼性への彼らのアプローチでばらつきが大きいです、いくつかの実装が配送かバッファ疲労困憊までいくつか再試行されていて、他のものが次々と会計データを失っていて。 RADIUS会計が応用層承認かエラーメッセージに備えないので、RADIUS Accounting-応答は、トランスポート層承認に同等であり、応用層不調に対してノー・プロテクションを提供します。 信頼性の不足のために、単独でRADIUS会計に基づく同時の用法コントロールをするのは可能ではありません。 別のデバイスデータ送信端末がセッションMIBかtelnetの上のコマンドラインセッションの世論調査などのように通常、必要です。
RADIUS accounting implementations are vulnerable to packet loss as well as application layer failures, network failures and device reboots. These deficiencies are magnified in inter-domain accounting as is required in roaming ([1],[2]). On the other hand, the event- driven approach of RADIUS accounting is useful where low processing delay is required, such as credit risk management or fraud detection.
RADIUS会計実装は応用層の故障、ネットワーク失敗、およびデバイスリブートと同様にパケット損失に被害を受け易いです。 これらの欠乏はローミング([1]、[2])で必要である相互ドメイン会計で拡大されます。 他方では、RADIUS会計の追い立てられたイベントアプローチは低い処理遅れが必要であるところで役に立ちます、信用リスク管理や詐欺の検出のように。
While RADIUS accounting does provide hop-by-hop authentication and integrity protection, and IPSEC can be employed to provide hop-by-hop confidentiality, data object security is not supported, and thus systems based on RADIUS accounting are not capable of being deployed with untrusted proxies, or in situations requiring auditability, as noted in [2].
RADIUS会計はホップごとの認証と保全保護を提供します、そして、ホップごとの秘密性を提供するのにIPSECは使うことができますが、データ・オブジェクトセキュリティをサポートしません、そして、その結果、RADIUS会計に基づくシステムは信頼されていないプロキシ、または監査能力を必要とする状況で配布することができません、[2]に述べられるように。
While RADIUS does not support compression, IP compression, described in [5], can be employed to provide this. While in principle extensible with the definition of new attributes, RADIUS suffers from the very small standard attribute space (256 attributes).
RADIUSが圧縮をサポートしていない間、これを提供するのに[5]で説明されたIP圧縮は使うことができます。 原則として新しい属性の定義で広げることができますが、RADIUSは非常に小さい標準の属性スペース(256の属性)が欠点です。
Aboba, et al. Informational [Page 32] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[32ページ]のRFC2975序論
3.2. TACACS+
3.2. TACACS+
TACACS+ offers an accounting model with start, stop, and interim update messages. Since TACACS+ is based on TCP, implementations are typically resilient against packet loss and short-lived network partitions, and TACACS+ scales with the number of devices. Since TACACS+ runs over TCP, it offers support for both transport layer and application layer acknowledgments, and is suitable for simultaneous usage control and handling of accounting events that require moderate though not the lowest processing delay.
+が会計を提供するTACACSは始め、停止、および当座のアップデートメッセージでモデル化します。 TACACS以来、+はTCPに基づいていて、実装はデバイスの数でパケット損失、短命なネットワークパーティション、およびTACACS+スケールに対して通常弾力があります。 TCPの上のTACACS+走行以来、それは、トランスポート層と応用層承認の両方のためにサポートを提供して、最も低い処理遅れではなく、もっとも中道主義者を必要とする会計イベントの同時の用法コントロールと取り扱いに適しています。
TACACS+ provides for hop-by-hop authentication and integrity protection as well as hop-by-hop confidentiality. Data object security is not supported, and therefore systems based on TACACS+ accounting are not deployable in the presence of untrusted proxies. While TACACS+ does not support compression, IP compression, described in [5], can be employed to provide this.
+がホップごとの秘密性と同様にホップごとの認証と保全保護に提供するTACACS。 データ・オブジェクトセキュリティはサポートされません、そして、したがって、TACACS+会計に基づくシステムは信頼されていないプロキシの面前で配布可能ではありません。 +がするTACACSが圧縮をサポートしていない間、これを提供するのに[5]で説明されたIP圧縮は使うことができます。
3.3. SNMP
3.3. SNMP
SNMP, described in [19],[27]-[41], has been widely deployed in a wide variety of intra-domain accounting applications, typically using the polling data collection model. Polling allows data to be collected on multiple accounting events simultaneously, resulting in per-device state. Management applications are able to retry requests when a response is not received, providing resiliency against packet loss or even short-lived network partitions. Implementations without non- volatile storage are not robust against device reboots or network failures, but when combined with non-volatile storage they can be made highly reliable.
[19]で説明されたSNMP([27]--[41])はさまざまなイントラドメイン会計アプリケーションで広く配布されました、世論調査データ収集モデルを通常使用して。 世論調査で、各装置状態をもたらして、データは同時に、複数の会計イベントに集まります。 応答が受け取られていないとき、管理アプリケーションは要求を再試行できます、パケット損失か短命なネットワークパーティションに対してさえ弾性を提供して。 非揮発性記憶装置のない実装はデバイスリブートかネットワーク失敗に対して強健ではありませんが、非揮発性記憶装置に結合すると、それらを高信頼性にすることができます。
SMIv1, the data modeling language of SNMPv1, has traps to permit trap-directed polling, but the traps are not acknowledged, and lost traps can lead to a loss of data. SMIv2, used by SNMPv2c and SNMPv3, has Inform Requests which are acknowledged notifications. This makes it possible to implement a more reliable event-driven polling model or event-driven batching model. However, we are not aware of any SNMP-based accounting implementations currently built on the use of Informs.
罠は承認されません、そして、SMIv1(SNMPv1のデータのモデル化言語)には、罠で指示された世論調査を可能にする罠がありますが、無くなっている罠はデータの喪失に通じることができます。 SNMPv2cとSNMPv3によって使用されたSMIv2は承認された通知であるInform Requestsを持っています。 これで、より頼もしいイベントドリブン世論調査モデルかイベントドリブンバッチングモデルを実装するのは可能になります。 しかしながら、私たちはInformsの使用のときに現在築き上げられているどんなSNMPベースの会計実装も意識していません。
3.3.1. Security services
3.3.1. セキュリティー・サービス
SNMPv1 and SNMPv2c support per-packet authentication and read-only and read-write access profiles, via the community string. This clear-text password approach provides only trivial authentication, and no per-packet integrity checks, replay protection or confidentiality. View-based access control [40] can be supported using the snmpCommunityMIB, defined in [11], and SNMPv1 or SNMPv2c
SNMPv1とSNMPv2cは1パケットあたりの認証と書き込み禁止をサポートして、共同体ストリングを通したアクセスプロフィールを読書して書きます。 このクリアテキストパスワードアプローチは些細な認証だけにもかかわらず、どんな1パケットあたりの保全にもチェック、反復操作による保護または秘密性を提供しません。 [11]で定義されたsnmpCommunityMIBを使用して、SNMPv1かSNMPv2cであると視点ベースのアクセス制御[40]をサポートすることができます。
Aboba, et al. Informational [Page 33] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[33ページ]のRFC2975序論
messages. The updated SNMP architecture [rfc2571] supports per- packet hop-by-hop authentication, integrity and replay protection, confidentiality and access control.
メッセージ。 アップデートされたSNMPアーキテクチャ[rfc2571]がサポートする、-、ホップごとのパケット認証、保全、反復操作による保護、秘密性、およびアクセスは制御されます。
The SNMP User Security Model (USM) [38] uses shared secrets, and when the product of the number of domains and devices is large, such as in inter-domain accounting applications, the number of shared secrets can get out of hand. The localized key capability in USM allows a manager to have one central key, sharing it with many SNMP entities in a localized way while preventing the other entities from getting at each other's data. This can assist in cross-domain security if deployed properly.
SNMP User Security Model(USM)[38]は共有秘密キーを使用します、そして、ドメインとデバイスの数の製品が相互ドメイン会計アプリケーションなどのように大きいときに、共有秘密キーの数は手に負えなくなることができます。 マネージャはUSMのローカライズしている主要な能力で1個の中央のキーを持つことができます、他の実体が互いのデータに達するのを防いでいる間、ローカライズしている方法で多くのSNMP実体とそれを共有して。 適切に配布されるなら、これは交差しているドメインセキュリティを助けることができます。
SNMPv3 does not support end-to-end data object integrity and confidentiality; SNMP proxy entities decrypt and re-encrypt the data they forward. In the presence of an untrusted proxy entity, this would be inadequate.
SNMPv3は、終わりから終わりへのデータ・オブジェクトが保全と秘密性であるとサポートしません。 SNMPプロキシ実体は、それらが転送するデータを解読して、再暗号化します。 信頼されていないプロキシ実体があるとき、これは不十分でしょう。
3.3.2. Application layer acknowledgments
3.3.2. 応用層承認
SNMP uses application-layer acknowledgment to indicate that data has been processed. SNMP Responses to get, get-next, or get-bulk requests return the requested data, or an error code indicating the nature of the error encountered.
SNMPは、データを処理してあるのを示すのに応用層承認を使用します。 得るSNMP Responses、気付いてください。さもないと、嵩を得ている要求は要求されたデータ、または誤りの本質が遭遇したのを示すエラーコードを返します。
A noError SNMP Response to a SET command indicates that the requested assignments were made by the application. SNMP SETs are atomic; the command either succeeds or fails. An error-response indicates that the entity received the request, but did not succeed in executing it.
SETコマンドへのnoError SNMP Responseは、アプリケーションで要求された課題をしたのを示します。 SNMP SETsは原子です。 コマンドは、成功するか、または失敗します。 誤り応答は、実体が、要求を受け取りましたが、それを実行するのに成功しなかったのを示します。
Notifications do not use acknowledgements to indicate that data has been processed. The Inform notification returns an acknowledgement of receipt, but not of processing, by design. Since the updated SNMP architecture treats entities as peers with varying levels of functionality, it is possible to use SETs in either direction between cooperating entities to achieve processing acknowledgements.
通知は、データを処理してあるのを示すのに承認を使用しません。 Inform通知は、デザインで受領通知を返しますが、処理について返すというわけではありません。 アップデートされたSNMPアーキテクチャが異なったレベルの機能性をもっている同輩として実体を扱うので、処理承認を達成するのに協力実体の間のどちらの方向にもSETsを使用するのは可能です。
There are eighteen SNMP error codes. The design of SNMP makes service-specific error codes unnecessary and undesirable.
18のSNMPエラーコードがあります。 SNMPのデザインで、サービス特有のエラーコードは不要で望ましくなくなります。
3.3.3. Proxy forwarders
3.3.3. プロキシ混載業者
In the accounting management architecture, proxy forwarders play an important role, forwarding intra and inter-domain accounting events to the correct destinations. The proxy forwarder may also play a role in a polling or event-driven polling architecture.
会計管理体系では、プロキシ混載業者は重要な役割を果たします、イントラと相互ドメイン会計イベントを正しい目的地に送って。 また、プロキシ混載業者は世論調査かイベントドリブン世論調査アーキテクチャにおける役割を果たすかもしれません。
Aboba, et al. Informational [Page 34] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[34ページ]のRFC2975序論
The functionality of an SNMP Proxy Forwarder is defined in [39]. For example, the network devices may be configured to send notifications for all domains to the Proxy Forwarder, and the devices may be configured to allow the Proxy Forwarder to access all MIB data.
SNMP Proxy Forwarderの機能性は[39]で定義されます。 例えば、ネットワークデバイスはProxy Forwarderへのすべてのドメインに通告を送るために構成されるかもしれません、そして、デバイスは、Proxy ForwarderがすべてのMIBデータにアクセスするのを許容するために構成されるかもしれません。
The use of proxy forwarders may reduce the number of shared secrets required for inter-domain accounting. With Proxy Forwarders, the domains could share a secret with the Proxy Forwarder, and in turn, the Proxy Forwarder could share a secret with each of the devices. Thus the number of shared secrets will scale with the sum of the number of devices and domains rather than the product.
プロキシ混載業者の使用は相互ドメイン会計で必要である共有秘密キーの数を減少させるかもしれません。 Proxy Forwardersと共に、ドメインはProxy Forwarderと秘密を共有するかもしれません、そして、順番に、Proxy Forwarderはそれぞれのデバイスと秘密を共有できました。 したがって、共有秘密キーの数は製品よりむしろデバイスとドメインの数で比例するでしょう。
The engine of an SNMP Proxy Forwarder does not look inside the PDU of the message except to determine to which SNMP engine the PDU should be forwarded or which local SNMP application should process the PDU. The SNMP Proxy Forwarder does not modify the varbind values; it does not modify the varbind list except to translate between SNMP versions; and it does not provide any varbind level access control.
どのSNMPエンジンにPDUを送るべきであるか、そして、またはどのローカルのSNMPアプリケーションがPDUを処理するべきであるかを決定する以外に、SNMP Proxy ForwarderのエンジンはメッセージのPDUの中で見ません。 SNMP Proxy Forwarderはvarbind値を変更しません。 SNMPバージョンの間で翻訳する以外に、それはvarbindリストを変更しません。 そして、それはどんなvarbindの平らなアクセス制御も提供しません。
3.3.4. Domain-based access controls in SNMP
3.3.4. SNMPのドメインベースのアクセス制御
Domain-based access controls are required where multiple administrative domains are involved, such as in the shared use networks and roaming associations described in [1]. Since the same device may be accessed by multiple organizations, it is often necessary to control access to accounting data according to the user's organization. This ensures that organizations may be given access to accounting data relating to their users, but not to data relating to users of other organizations.
ドメインベースのアクセス制御が複数の管理ドメインがかかわるところで必要です、ネットワークとローミング協会が[1]で説明した共有された使用などのように。 同じデバイスが複数の組織によってアクセスされるかもしれないので、ユーザの組織によると、会計データへのアクセスを制御するのがしばしば必要です。 これは、組織が彼らのユーザに関連する会計データへの与えられたアクセスであるかもしれないことを確実にしますが、他の組織のユーザに関連するデータに確実にするというわけではありません。
In order to apply domain-based access controls, in inter-domain accounting, it is first necessary to identify the data subset that is to have its access controlled. Several conceptual abstractions are used for identifying subsets of data in SNMP. These include engines, contexts, and views. This section describes how this functionality may be applied in intra and inter-domain accounting.
ドメインベースのアクセス制御を適用するために、相互ドメイン会計では、アクセスを制御することになっているデータ部分集合を特定するのが最初に、必要です。 いくつかの概念的な抽象化が、SNMPのデータの部分集合を特定するのに使用されます。 これらはエンジン、文脈、および視点を含んでいます。 このセクションはこの機能性がイントラと相互ドメイン会計でどう適用されるかもしれないかを説明します。
3.3.4.1. Engines
3.3.4.1. エンジン
The new SNMP architecture, described in [27], added the concept of an SNMP engine to improve mobility support and to identify which data source is being referenced. The engine is the portion of an SNMP entity that constructs messages, provides security functions, and maps to the transport layer. Traditional agents and traditional managers each contain an SNMP engine. engineID allows an SNMP engine to be uniquely identified, independent of the address where it is attached to the network.
[27]で説明された新しいSNMPアーキテクチャは、移動性サポートを改良して、どのデータ送信端末が参照をつけられているかを特定するためにSNMPエンジンの概念を加えました。 エンジンはメッセージを構成するSNMP実体の部分です、とセキュリティ機能、および地図はトランスポート層に供給します。 伝統的なエージェントと伝統的なマネージャはそれぞれSNMPエンジンを含みます。engineIDは、SNMPエンジンが唯一特定されるのを許容します、それがネットワークに付けられているアドレスの如何にかかわらず。
Aboba, et al. Informational [Page 35] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[35ページ]のRFC2975序論
A securityEngineID field in a message identifies the engine which provides access to the security credentials contained in the message header. A contextEngineID field in a message identifies the engine which provides access to the data contained in the PDU.
メッセージのsecurityEngineID分野はメッセージヘッダーに含まれたセキュリティー証明書へのアクセスを提供するエンジンを特定します。 メッセージのcontextEngineID分野はPDUに含まれたデータへのアクセスを提供するエンジンを特定します。
The SNMPv3 message format explicitly passes both. In SNMPv1 and SNMPv2c, the data origin is typically assumed to be the communications endpoint (SNMP agent). SNMPv1 and SNMPv2c messages contain a community name; the community name and the source address can be mapped to an engineID via the snmpCommunityTable, described in [11].
SNMPv3メッセージ・フォーマットは明らかに両方を通過します。 SNMPv1とSNMPv2cでは、データ発生源はコミュニケーション終点(SNMPエージェント)であると通常思われます。 SNMPv1とSNMPv2cメッセージは共同体名を含んでいます。 [11]で説明されたsnmpCommunityTableを通して共同体名とソースアドレスをengineIDに写像できます。
3.3.4.2. Contexts
3.3.4.2. 文脈
Contexts are used to identify subsets of objects, within the scope of an engine, that are tied to instrumentation. A contextName refers to a particular subset within an engine.
文脈は、エンジンの範囲の中の計装に結ばれるオブジェクトの部分集合を特定するのに使用されます。 contextNameはエンジンの中の特定の部分集合を示します。
Contexts are commonly tied to hardware components, to logical entities related to the hardware components, or to logical services. For example, contextNames might include board5, board7, repeater1, repeater2, etc.
文脈は一般的にハードウェアの部品、または、ハードウェアの部品に関連する論理的な実体、または、論理的なサービスに結ばれます。 例えば、contextNamesはboard5、board7、repeater1、repeater2などを含むかもしれません。
An SNMP agent populates a read-only dynamic table to tell the manager what contexts it recognizes. Typically contexts are defined by the agent rather than the manager since if the manager defined them, the agent would not know how to tie the contexts to the underlying instrumentation. It is possible that MIB modules could be defined to allow a manager to assign contextNames to a logical subset of instrumentation.
SNMPエージェントは、それがどんな文脈を認識するかをマネージャに言うために書き込み禁止のダイナミックなテーブルに居住します。 マネージャがそれらを定義するなら、エージェントが基本的な計装に文脈を結ぶ方法を知らないので、通常、文脈はマネージャよりむしろエージェントによって定義されます。 マネージャが計装の論理的な部分集合にcontextNamesを割り当てるのを許容するためにMIBモジュールを定義できたのは可能です。
While each context may support instances of multiple MIB modules, each contextName is limited to one instance of a particular MIB module. If multiple instances of a MIB module are required per engine, then unique contextNames must be defined (e.g. repeater1, repeater2). The default context "" is used for engines which only support single instances of MIB modules, and it is used for MIB modules where it only makes sense to have one instance of that MIB module in an engine and that instance must be easy to locate, such as the system MIB or the security MIBs.
各文脈が複数のMIBモジュールのインスタンスをサポートしているかもしれない間、各contextNameは特定のMIBモジュールの1つのインスタンスに制限されます。 MIBモジュールの複数のインスタンスがエンジン単位で必要であるなら、ユニークなcontextNamesを定義しなければなりません(例えば、repeater1、repeater2)。 デフォルト文脈、「「サポートシングルだけがMIBモジュールについて例証して、エンジンにそのMIBモジュールのあるインスタンスを持つ意味になるだけであり、そのインスタンスが簡単であるに違いないMIBモジュールにおいて、システムMIBやセキュリティMIBsのように場所を見つけるのが使用されているエンジンに使用される、」
SNMPv3 messages contain contextNames which are limited to the scope of the contextEngineID in the message. SNMPv1 and SNMPv2c messages contain communities which can be mapped to contextNames within the local engine, or can be mapped to contextNames within other engines via the snmpCommunityTable, described in [11].
SNMPv3メッセージはメッセージでcontextEngineIDの範囲に制限されるcontextNamesを含んでいます。 SNMPv1とSNMPv2cメッセージは地方のエンジンの中のcontextNamesに写像できるか、または[11]で説明されたsnmpCommunityTableを通して他のエンジンの中のcontextNamesに写像できる共同体を含みます。
Aboba, et al. Informational [Page 36] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[36ページ]のRFC2975序論
3.3.4.3. Views
3.3.4.3. 視点
Views are defined in the View-based Access Control Model. A view is a mask which is used to determine access to the managed objects in a particular context. The view identifies which objects are visible, by specifying OIDs of the subtrees included and excluded. There is also a mechanism to allow wildcards in the OID specification.
視点はViewベースのAccess Control Modelで定義されます。 視点は特定の文脈の管理オブジェクトへのアクセスを決定するのに使用されるマスクです。 視点は、どのオブジェクトが含まれていて、除かれた下位木のOIDsを指定することによって目に見えるかを特定します。 また、OID仕様にワイルドカードを許容するために、メカニズムがあります。
For example, it is possible to define a view that includes RMON tables, and another view that includes only the SNMPv3 security related tables. Using these views, it is possible to allow access to the RMON view for users Joe and Josephine (the RMON administrators), and access to the SNMPv3 security tables for user Adam (the SNMP security Administrator).
例えば、RMONテーブルを含んでいる視点、およびそれが含む別の視点だけを定義するために、SNMPv3セキュリティがテーブルを関係づけたのは、可能です。 これらの視点を使用して、ユーザジョーとジョセフィーヌ(RMON管理者)のためのRMON視点にアクセスを許して、ユーザアダム(SNMPセキュリティAdministrator)のためのSNMPv3セキュリティテーブルにアクセスを許すのは可能です。
Views can be set up with wildcards. For a table that is indexed using IP addresses, Joe can be allowed access to all rows in given RMON tables (e.g. the RMON hostTable) that are in the subnet 10.2.x.x, while Josephine is given access to all rows for subnet 10.200.x.x.
ワイルドカードで視点をセットアップできます。 IPアドレスを使用することで索引をつけられるテーブルに関しては、サブネット10.200.x.xのためにすべての行へのアクセスをジョセフィーヌに与える間のサブネット10.2.x.xにある与えられたRMONテーブル(例えば、RMON hostTable)のすべての行へのアクセスをジョーに許すことができます。
Views filter at the name level (OIDs), not at the value level, so defining views based on the values of non-index data is not supported. In this example, were the IP address to have been used merely as a data item rather than an index, it would not be possible to utilize view-based access control to achieve the desired objective (delegation of administrative responsibility according to subnet).
したがって、値のレベルでないことで非指数データの値に基づく視点を定義しないのがサポートされないレベルという名前(OIDs)でフィルタを見ます。 この例では、IPアドレスが単にインデックスよりむしろデータ項目として使用されるつもりであったなら、必要な目的(サブネットに従った行政責任の委譲)を達成するのに視点ベースのアクセスコントロールを利用するのは可能でないでしょう。
View-based access control is independent of message version. It can be utilized by entities using SNMPv1, SNMPv2c, or SNMPv3 message formats.
視点ベースのアクセスコントロールはメッセージバージョンから独立しています。 実体でSNMPv1、SNMPv2c、またはSNMPv3メッセージ・フォーマットを使用することでそれを利用できます。
3.3.5. Inter-domain access-control alternatives
3.3.5. 相互ドメインアクセス制御代替手段
As the number of network devices within the shared use or roaming network grows, the polling model of data collection becomes increasingly impractical since most devices will not carry data relating to the polling organization. As a result, shared-use networks or roaming associations relying on SNMP-based accounting have generally collected data for all organizations and then sorted the resulting session records for delivery to each organization. While functional, this approach will typically result in increased processing delay as the number of organizations and data records grows.
共有された使用かローミングネットワークの中のネットワークデバイスの数が成長するのに従って、ほとんどのデバイスが世論調査組織に関連するデータを運ばないので、データ収集の世論調査モデルはますます非実用的になります。 その結果、共有された使用ネットワークかSNMPベースの会計に依存しながら協会に移動すると、一般に集まっているデータがすべての組織のために持たれて、次に、結果として起こるセッション記録は配送のために各組織に分類されました。 機能的である間、組織とデータレコードの数が成長するのに従って、このアプローチは増強された処理遅れを通常もたらすでしょう。
This issue can be addressed in SNMP using the event-driven, event- driven polling or event-driven batching approaches. Traps and Informs permit SNMP-enabled devices to notify domains that have
SNMPでイベントドリブンの、そして、イベント駆動の世論調査かイベントドリブンバッチングアプローチを使用することでこの問題を扱うことができます。 罠とInformsは、SNMPによって可能にされたデバイスがそうしたドメインに通知するのを可能にします。
Aboba, et al. Informational [Page 37] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[37ページ]のRFC2975序論
accounting data awaiting collection. SNMP Applications [39] defines a standard module for managing notifications.
収集を待つデータを説明します。 SNMP Applications[39]は通知を管理するための標準のモジュールを定義します。
To use the event-driven approaches, the device must be able to determine when information is available for a domain. Domain- specific data can be differentiated at the SNMP agent level through the use of the domain as an index, and the separation of data into domain-specific contexts.
イベントドリブンアプローチを使用するために、デバイスは、情報がいつドメインに利用可能であるかを決定できなければなりません。 SNMPエージェントレベルでドメインの特定のデータをドメイン特有の文脈にインデックスとしてのドメインの使用、およびデータの分離で差別化できます。
3.3.5.1. Domain as index
3.3.5.1. インデックスとしてのドメイン
View-based access control [40] allows multiple fine-grained views of an SNMP MIB to be assigned to specific groups of users, such that access rights to the included data elements depend on the identity of the user making the request.
視点ベースのアクセス制御[40]は、SNMP MIBの複数のきめ細かに粒状の視点がユーザの特定のグループに配属されるのを許容します、含まれているデータ要素へのアクセス権が要求をしているユーザのアイデンティティによるように。
For example, all users of bigco.com which are allowed access to the device would be defined in the User-based security MIB module (or other security model MIB module). For simplicity in administering access control, the users can be grouped using a vacmGroupName, e.g. bigco. A view of a subset of the data objects in the MIB can be defined in the vacmViewFamilyTreeTable. A vacmAccessTable pairs groups and views. For messages received from users in the bigco group, access would only be provided to the data permitted to be viewed by bigco users, as defined in the view family tree. This requires that each domain accessing the data be given one or more separate vacmGroupNames, an appropriate ViewTable be defined, and the vacmAccessTable be configured for each group.
例えば、デバイスへのアクセスが許されているbigco.comのすべてのユーザがUserベースのセキュリティMIBモジュール(または、他の機密保護モデルMIBモジュール)で定義されるでしょう。 アクセスコントロールを管理することにおける簡単さにおいて、vacmGroupName、例えばbigcoを使用することでユーザを分類できます。 vacmViewFamilyTreeTableでMIBのデータ・オブジェクトの部分集合の視点を定義できます。 vacmAccessTableはグループと視点を対にします。 ユーザからbigcoグループで受け取られたメッセージにおいてbigcoユーザによって見られることが許可されたデータにアクセスを提供するだけでしょう、視点系図で定義されるように。 これは、与えられたより多くのものが別々のvacmGroupNames、適切なViewTableであったならデータにアクセスする各ドメインが定義されていてvacmAccessTableであることを必要とします。各グループのために、構成されます。
Views filter at the name (OID) level, not at the data (value) level. When using views to filter by domain it is necessary to use the domain as an index. Standard view-based access control is not designed to filter based on the values on non-indexed fields.
データ(値)レベルで見るのではなく、名前(OID)レベルでフィルタを見ます。 ドメインでフィルターにかける視点を使用するとき、インデックスとしてドメインを使用するのが必要です。 標準の視点ベースのアクセスコントロールは非索引をつけられたフィールドで値に基づくフィルタに設計されていません。
For example, a table of session data could be indexed by record number and domain, allowing a view to be defined that could restrict access to bigco data to the administrators of the bigco domain.
例えば、bigcoドメインの管理者へのbigcoデータへのアクセスを制限する場合があった視点が定義されるのを許容する記録的な数とドメインはセッションデータのテーブルに索引をつけることができました。
An advantage of using domains as an index is that this technique can be used with SNMPv1 and SNMPv2c agents as well as with SNMPv3 agents. A disadvantage is that the MIB modules must be specifically designed for this purpose. Since existing MIB modules rarely use the domain as an index, domain separation cannot be enabled within legacy MIB modules using this technique.
インデックスとしてドメインを使用する利点はSNMPv1とSNMPv2cエージェントとSNMPv3エージェントと共にこのテクニックを使用できるということです。 不都合は明確にこのためにMIBモジュールを設計しなければならないということです。 既存のMIBモジュールがインデックスとしてめったにドメインを使用しないので、レガシーMIBモジュールの中でこのテクニックを使用することでドメイン分離を可能にすることができません。
SNMP does support a RowPointer convention that could be used to define a new table, indexed by domain, which holds tuples between the domain and existing rows of data. This would introduce issues of
SNMPはドメインと存在の間でtuplesを支えるドメインによって索引をつけられた新しいテーブルを定義するのに使用できたRowPointerコンベンションにデータの行をサポートします。 これは問題を紹介するでしょう。
Aboba, et al. Informational [Page 38] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[38ページ]のRFC2975序論
synchronization between tables.
テーブルの間の同期。
3.3.5.2. Contexts
3.3.5.2. 文脈
ContextNames can be used to differentiate multiple instances of a MIB module within an engine.
エンジンの中にMIBモジュールの複数のインスタンスを差別化するのにContextNamesを使用できます。
Individual domains, such as bigco.com, could be mapped to logical contexts, such as a bigco context. The agent would need to create and recognize new contexts and to know which instrumentation is associated with the logical context. The agent needs to collect accounting data by domain and make the data accessible via distinct contexts, so that access control can be applied to the context to prevent disclosure of sensitive information to the wrong domain. The VACM access control views are applied relative to the context, so an operation can be permitted or denied a user based on the context which contains the data.
bigco文脈などの論理的な関係にbigco.comなどの個々のドメインを写像できました。 エージェントは、新しい関係を作成して、認めて、どの計装が論理的な関係に関連しているかを知る必要があるでしょう。 エージェントは、ドメインのそばに会計データを集めて、データを異なった文脈でアクセスしやすくする必要があります、間違ったドメインに機密情報の公開を防ぐためにアクセスコントロールを文脈に適用できるように。 VACMアクセス制御視点が文脈に比例して適用されるので、操作は、データを含む文脈に基づくユーザに対して、受入れられる場合があるか、または否定される場合があります。
Domain separation is handled by using contextName to differentiate multiple virtual tables. For example, if accounting data has been collected on users with the bigco.com and smallco.com domains, then a separate virtual instance of the accounting session record table would exist for each domain, and each domain would have a corresponding contextName. When a get-bulk request is made with a contextName of bigco, then data from the virtual table in the bigco context, i.e. corresponding to the bigco.com domain, would be returned.
ドメイン分離は、複数の仮想のテーブルを差別化するのにcontextNameを使用することによって、扱われます。 例えば、ユーザにbigco.comとsmallco.comドメインで会計データを集めてあるなら、会計セッション記録テーブルの別々の仮想のインスタンスは各ドメインに存在しているでしょう、そして、各ドメインには、対応するcontextNameがあるでしょう。 bigcoのcontextNameと共に嵩を得ている要求をするとき、bigco文脈の仮想のテーブルからの次にすなわち、bigco.comドメインに対応するデータを返すでしょう。
There are a number of design approaches to creating new contexts and associating the contexts with appropriate instrumentation, most notably a sub-agent approach and a manager-configured MIB approach.
新しい関係を作成して、適切な計装に文脈を関連づけることへの多くの設計手法、最も著しくサブエージェントアプローチ、およびマネージャによって構成されたMIBアプローチがあります。
AgentX [51], which standardizes a registration protocol between sub- agents and master agents to simplify SNMP agent implementation, allows for the creation and recognition of new contextNames when a subagent registers to provide support for a particular MIB subtree range. The sub-agent knows how to support a particular functionality, e.g. instrumentation exposed via a range of MIB objects. Based on values detected in the data, such as source=bigco.com, the sub-agent could determine that a new domain needed to be tracked and create the appropriate context for the collection of the data, plus the appropriate access control entries. The determination could be table-driven, using MIB configuration.
AgentX[51](SNMPエージェント実装を簡素化するためにサブエージェントとマスターエージェントの間の登録プロトコルを標準化します)は、副代理店が登録されるときの新しいcontextNamesの作成と認識が特定のMIB下位木範囲のサポートを提供するのを許容します。 サブエージェントは特定の機能性をサポートする方法を知っています、例えば、計装がさまざまなMIBを通してオブジェクトを暴露しました。 ソース=bigco.comなどのデータに検出された値に基づいて、サブエージェントは、新しいドメインが、追跡される必要だったと決心して、データの収集のための適切な関係、および適切なアクセス制御エントリーを作成できました。 MIB構成を使用して、決断はテーブルによる駆動であるかもしれません。
A manager-driven approach could use a MIB module to predefine contextNames corresponding to the domains of interest, and to indicate which objects should be collected, how to differentiate to which domain the data should be applied based on a specified
マネージャ駆動のアプローチは興味があるドメインに対応するcontextNamesを事前に定義して、どのオブジェクトが集められるべきであるかを示すのにMIBモジュールを使用するかもしれません、差別化するために、データがaに基づいてどのドメインに適用されているべきであるかはどう指定したか。
Aboba, et al. Informational [Page 39] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[39ページ]のRFC2975序論
condition, and what access control rules apply to the context.
状態とどんなアクセスが規則を制御するかは文脈に適用されます。
Either technique could associate existing MIB modules to domain- specific contexts, so domain separation can be applied to MIB modules not specifically designed with domain separation in mind. Legacy agents would not be designed to do this, so they would need to be updated to support inter-domain separation and VACM access control.
テクニックが既存のMIBモジュールをドメインの特定の文脈に関連づけるかもしれないので、ドメイン分離で明確に念頭に設計されなかったMIBモジュールにドメイン分離を適用できます。 レガシーエージェントはこれをするように設計されていないでしょう、したがって、彼らが相互ドメイン分離とVACMがアクセスコントロールであるとサポートするためにアップデートする必要があるでしょう。
The use of contextNames for inter-domain separation represents new territory, so careful consideration would be needed in designing the MIB modules and applications to provide domain to context and context to instrumentation mappings, and to ensure that security is not weakened.
contextNamesの相互ドメイン分離の使用は新しい領土を表します、考慮が文脈へのドメインと計装マッピングへの文脈を前提として、セキュリティが弱められないのを保証するようにMIBモジュールとアプリケーションを設計するのにおいて必要であるようにとても慎重です。
3.3.6. Outstanding issues
3.3.6. 未解決の問題
There are issues that arise when using SNMP for transfer of bulk data, including issues of latency, network overhead, and table retrieval, as discussed in [49].
大量のデータの転送にSNMPを使用するとき起こる問題があります、潜在、ネットワークオーバーヘッド、およびテーブル検索の問題を含んでいて、[49]で議論するように。
In accounting applications, management stations often must retrieve large tables. Latency can be high, even with the get-bulk operation, because the response must fit into the largest supported packet size, requiring multiple round-trips. Transfers may be serialized and the resulting latency will be a combination of multiple round-trip times, possible timeout and re-transmission delays and processing overhead, which may result in unacceptable performance. Since data may change during the course of multiple retrievals, it can be difficult to get a consistent snapshot.
会計アプリケーションでは、管理局はしばしば大きいテーブルを検索しなければなりません。 潜在は高い場合があります、嵩を得ている操作があっても、応答がパケットサイズであるとサポートされる中で最も大きいものに収まらなければならないので、複数の周遊旅行を必要として。 転送は連載されるかもしれません、そして、結果として起こる潜在は複数の往復の回、可能なタイムアウト、および再トランスミッション遅れと処理オーバヘッドの組み合わせのようになるでしょう。(それは、容認できない性能をもたらすかもしれません)。 データが複数のretrievalsのコースの間、変化するかもしれないので、一貫したスナップを得るのは難しい場合があります。
For bulk transfers, SNMP network overhead can be high due to the lack of compression, inefficiency of BER encoding, the transmission of redundant OID prefixes, and the "get-bulk overshoot problem". In bulk transfer of a table, the OIDs transferred are redundant: all OID prefixes up to the column number are identical, as are the instance identifier postfixes of all entries of a single table row. Thus it may be possible to reduce this redundancy by compressing the OIDs, or by not transferring an OID with each variable.
そして、バルク転送に、SNMPネットワークオーバーヘッドは圧縮の不足のために高い場合があります、BERコード化の非能率、余分なOID接頭語の送信、「嵩を得る、問題を飛び越えさせてください、」 大量に、移してください。テーブルでは、移されたOIDsは余分です: 桁位置までのすべてのOID接頭語が同じです、ただ一つのテーブル行のすべてのエントリーのインスタンス識別子ポストフィックスのように。 したがって、OIDsを圧縮するか、または各変数でOIDを移さないことによってこの冗長を減らすのは可能であるかもしれません。
The "get-bulk overshoot problem", described in reference [50], occurs when using the get-bulk PDU. The problem is that the manager typically does not know the number of rows in the table. As a result, it must either request too many rows, retrieving unneeded data, or too few, resulting in the need for multiple get-bulk requests. Note that the "get-bulk overshoot" problem may be preventable on the agent side. Reference [41] states that an agent can terminate the get-bulk because of "local constraints" (see items 1 and 3 on pages 15/16 of [41]). This could be interpreted to mean
問題を飛び越えさせてください。「嵩を得る、」 嵩を得ているPDUを使用するとき、参照[50]で説明されて、起こります。 問題はマネージャがテーブルの行の数を通常知らないということです。 その結果、あまりに多くの行を要求しなければなりません、不要なデータ、またはわずか過ぎるしか検索しないで、複数の嵩を得ている要求の必要性をもたらして。 」 問題を飛び越えさせてください。それに注意してください、「嵩を得る、エージェント側で予防可能であってもよいです。 参照[41]は、エージェントが、「地方の規制」のために嵩を得終えることができると述べます。(15/16ページの[41])で項目1と3を見てください。 平均にこれを解釈できました。
Aboba, et al. Informational [Page 40] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[40ページ]のRFC2975序論
that it is possible to stop at the end of a table.
テーブルの端に止まるのは可能です。
3.3.6.1. Ongoing research
3.3.6.1. 継続中の研究
To address issues of latency and efficiency, the Network Management Research Group (NMRG) was formed within the Internet Research Task Force (IRTF). Since the NMRG work is research and is not on the standards track, it should be understood that the NMRG proposals may never be standardized, or may change substantially during the standardization process. As a result, these proposals represent works in progress and are not readily available for use.
潜在と効率の問題を扱うために、Network Management Research Group(NMRG)はインターネットResearch Task Force(IRTF)の中で形成されました。 NMRG仕事は研究であり、標準化過程の上にないので、NMRG提案が決して標準化されないか、または標準化過程の間実質的に変化するかもしれないのが理解されるべきです。 その結果、これらの提案は、執筆中の作品を表して、容易に使用に利用可能ではありません。
The proposals under discussion in the IRTF Network Management Research Group (NMRG) are described in [46]. These include an SNMP- over-TCP transport mapping, described in [47]; SNMP payload compression, described in [48]; and the addition of a "get subtree" PDU or the subtree retrieval MIB [50].
IRTF Network Management Research Group(NMRG)での議論での提案は[46]で説明されます。 これらは[47]で説明されたSNMP過剰TCP輸送マッピングを含んでいます。 [48]で説明されたSNMPペイロード圧縮。 そして、「下位木を得てください」というPDUか下位木検索MIB[50]の追加。
The SNMP-over-TCP transport mapping may result in substantial latency reductions in table retrieval. The latency reduction of an SNMP- over-TCP transport mapping will likely manifest itself primarily in the polling, event-driven polling and event-driven batching modes.
SNMP過剰TCP輸送マッピングはテーブル検索のかなりの潜在減少をもたらすかもしれません。 SNMP過剰TCP輸送マッピングの潜在減少は主として世論調査、イベントドリブン世論調査、およびイベントドリブンバッチングモードでおそらく現れるでしょう。
Payload compression methods include compression of the IP packet, as described in [5] or compression of the SNMP payload, described in [48].
有効搭載量圧縮方法はIPパケットの圧縮を含んでいます、[5]か[48]で説明されたSNMPペイロードの圧縮で説明されるように。
Proposed improvements to table retrieval include a subtree retrieval MIB and the addition of a get-subtree PDU. The subtree retrieval MIB [50] requires no changes to the SNMP protocol or SNMP protocol engine, so it can be implemented and deployed more easily than a change to the protocol. The addition of a get-subtree PDU implies changes to the protocol and to the engines of all SNMP entities which would support it. Since it may be possible to address the "get-bulk overshoot problem" without changes to the SNMP protocol, the necessity of this modification is controversial.
検索を見送る提案された改良は下位木を得ているPDUの下位木検索MIBと追加を含んでいます。 下位木検索MIB[50]がSNMPプロトコルかSNMPプロトコルエンジンへの変化を全く必要としないので、プロトコルへの変化より容易にそれを実装して、配布することができます。 下位木を得ているPDUの追加はプロトコルと、そして、それをサポートするすべてのSNMP実体のエンジンへの変化を含意します。 以来にそれが扱うのにおいて可能であるかもしれない、「嵩を得る、」 プロトコル、この変更のSNMPへの変化のない必要性が論議を呼ぶことにおける問題を飛び越えさせてください。
Reference [49] also discusses file-based storage of SNMP data, and use of an FTP MIB, to enable storage of SNMP data in non-volatile storage, and subsequent bulk transfer via FTP. This approach would require implementation of additional MIB modules as well as FTP, and requires separate security mechanisms such as IPSEC to provide authentication, replay, integrity protection and confidentiality for the data in transit. The file-based transfer approach has an important benefit - compatibility with non-volatile storage.
また、参照[49]は、FTPで非揮発性記憶装置の、そして、その後のバルク転送における、SNMPデータのストレージを可能にするためにSNMPデータのファイルベースのストレージ、およびFTP MIBの使用について議論します。 このアプローチは、FTPと同様に追加MIBモジュールの実装を必要として、トランジットで認証、再生、保全保護、および秘密性をデータに提供するためにIPSECなどの別々のセキュリティー対策を必要とします。 ファイルベースの転送アプローチには、重要な利益があります--非揮発性記憶装置との互換性。
Aboba, et al. Informational [Page 41] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[41ページ]のRFC2975序論
Issues of legacy support exist with the NMRG proposals. Devices which do not implement the new functionality would need to be accommodated. This is especially problematic for proxy forwarders, which may need to act as translators between new and legacy entities. In these situations, the overhead of translation may offset the benefits of the new technologies.
レガシーサポートの問題はNMRG提案で存在しています。 新しい機能性を実装しないデバイスは、設備される必要があるでしょう。 プロキシ混載業者には、これは特に問題が多いです。(その混載業者は、新しい、そして、レガシー実体の間の翻訳者として務める必要があるかもしれません)。 これらの状況で、翻訳のオーバーヘッドは新技術の利益を相殺するかもしれません。
3.3.6.2. On-going security extension research
3.3.6.2. 継続しているセキュリティ拡大研究
In order to simplify key management and enable use of certificate- based security in SNMPv3, a Kerberos Security Model (KSM) for SNMPv3 has been proposed in [44]. This memo is not on the standards track, and therefore is not yet readily available for use.
かぎ管理を簡素化して、SNMPv3における証明書のベースのセキュリティの使用を可能にするために、SNMPv3のためのケルベロスSecurity Model(KSM)は[44]で提案されました。 このメモは、標準化過程の上になくて、またしたがって、まだ容易に使用に利用可能ではありません。
Use of Kerberos with SNMPv3 requires storage of a key on the KDC for each device and domain, while dynamically generating a session key for conversations between domains and devices. In terms of stored keys, the KSM approach scales with the sum of devices and domains; in terms of dynamic session keys, it scales as the product of domains and devices.
SNMPv3とのケルベロスの使用はダイナミックにドメインとデバイスとの会話に、主要なセッションを生成している間、KDCにおけるキーのストレージを各デバイスとドメインに必要とします。 保存されたキーに関して、KSMアプローチはデバイスとドメインの合計で比例します。 ダイナミックなセッションキーに関して、それはドメインとデバイスの製品として比例します。
As Kerberos is extended to allow initial authentication via public key, as described in [42], and cross-realm authentication, as described in [43], the KSM inherits these capabilities. As a result, this approach may have potential to reduce or even eliminate the shared secret management problem. However, it should also be noted that certificate-based authentication can strain the limits of UDP packet sizes supported in SNMP implementations, so that alternate transport mappings may be required to support this.
ケルベロスが公開鍵で初期の認証を許すために広げられるのに従って、[42]、および交差している分野認証で説明されるように、KSMは[43]で説明されるようにこれらの能力を引き継ぎます。 その結果、このアプローチには、減少するか、または共有秘密キー管理問題を解決するのさえ可能性があるかもしれません。 しかしながら、また、証明書ベースの認証がSNMP実装でサポートされたUDPパケットサイズの限界を張ることができることに注意されるべきです、これをサポートするために代替の輸送マッピングを必要とすることができるように。
An IPSEC-based security model for SNMPv3 has been discussed. Implementation of such a security model would require the SNMPv3 engine to be able to retrieve the properties of the IPSEC security association used to protect the SNMPv3 traffic. This would include the security services invoked, as well as information relating to the other endpoint, such as the authentication method and presented identity and certificate. To date such APIs have not been widely implemented, and in addition, most IPSEC implementations only support machine certificates, which may not provide the required granularity of identification. Thus, an IPSEC-based security model for SNMPv3 would probably take several years to come to fruition.
SNMPv3のIPSECベースの機密保護モデルについて議論しました。 そのような機密保護モデルの実装は、SNMPv3エンジンがSNMPv3トラフィックを保護するのに使用されるIPSECセキュリティ協会の特性を検索できるのを必要とするでしょう。 これはサービスが呼び出したセキュリティを含んでいるでしょう、もう片方の終点に関連する情報と同様に、認証方法や、提示されたアイデンティティや証明書のように。 デートするために、そのようなAPIは広く実装されていません、そして、さらに、ほとんどのIPSEC実装がマシン証明書を支えるだけです。(証明書は識別の必要な粒状を提供しないかもしれません)。 したがって、SNMPv3のIPSECベースの機密保護モデルは、実を結ぶにはたぶん数年かかるでしょう。
3.3.7. SNMP summary
3.3.7. SNMP概要
Given the wealth of existing accounting-related MIB modules, it is likely that SNMP will remain a popular accounting protocol for the foreseeable future.
既存の会計関連のMIBモジュールの富を考えて、SNMPは予見できる未来のポピュラーな会計プロトコルのままで残りそうでしょう。
Aboba, et al. Informational [Page 42] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[42ページ]のRFC2975序論
Support for notifications makes it possible to implement the event- driven, event-driven polling and event-driven batching models. This makes it possible to notify domains of available data rather than requiring them to poll for it, which is critical in shared use networks and roaming.
通知のサポートで、イベントがやる気満々の、そして、イベントドリブンの世論調査とイベントドリブンバッチングモデルであると実装するのが可能になります。 これで、それに投票するのが必要であるというよりもむしろ利用可能なデータのドメインに通知するのは可能になって、どれが共有されるところで重要であるかがネットワークとローミングを使用します。
Given the SNMPv3 security enhancements, it is desirable for SNMP- based intra-domain accounting implementations to upgrade to SNMPv3. Such an upgrade is virtually mandatory for inter-domain applications.
SNMPv3セキュリティ増進を考えて、SNMPのベースのイントラドメイン会計実装がSNMPv3にアップグレードするのは、望ましいです。 そのようなアップグレードは実際には相互ドメインアプリケーションに義務的です。
In inter-domain accounting, the burden of managing SNMPv3 shared secrets can be reduced via the localized key capability or via implementation of a Proxy Forwarder. In the long term, alternative security models such as the Kerberos Security Model may further reduce the effort required to manage security and enable streamlined inter-domain operation.
相互ドメイン会計では、SNMPv3共有秘密キーを管理する負担はローカライズしている主要な能力かProxy Forwarderの実装で減少できます。 長期で、ケルベロスSecurity Modelなどの代替の機密保護モデルは、セキュリティを管理するのに必要である取り組みをさらに減少させて、流線型の相互ドメイン操作を可能にするかもしれません。
SNMP-based accounting has limitations in terms of efficiency and latency that may make it inappropriate for use in situations requiring low processing delay or low overhead. This includes usage sensitive billing applications where fraud detection may be required. These issues can be addressed via proposals under discussion in the IRTF Network Management Research Group (NMRG). The experimental SNMP over TCP transport mapping may prove helpful at reducing latency. Depending on the volume of data, some form of compression may also be worth considering. However, since these proposals are still in the research stage, and are not on the standards track, these capabilities are not readily available, and the specifications could change considerably before they reach their final form.
SNMPベースの会計には、それを低い処理遅れか低いオーバーヘッドを必要とする状況における使用に不適当にするかもしれない効率と潜在に関して制限があります。 これは詐欺の検出が必要であるかもしれない用法の敏感な支払いアプリケーションを含んでいます。 IRTF Network Management Research Group(NMRG)での議論での提案でこれらの問題を扱うことができます。 TCP輸送マッピングの上の実験的なSNMPは、レイテンシを減少させるところで役立っていると判明するかもしれません。 データ量によって、また、何らかの形式の圧縮は考える価値があるかもしれません。 しかしながら、これらの提案はまだ研究段階にあって、標準化過程の上にないので、これらの能力は容易に利用可能ではありません、そして、自己の最終形態に達する前に仕様はかなり変化できました。
SNMP supports separation of accounting data by domain, using either of two general approaches with the VACM access control model. The domain as index approach can be used if the desired MIB module supports domain indexing, or it can implemented using an additional table. The domain-context approach can be used in agents which support dynamic logical contexts and a domain-to-context and context-to-instrumentation mapping mechanism. Either approach can be supported using SNMPv1, SNMPv2c, or SNMPv3 messages, by utilizing the snmpCommunitytable [11] to provide a community-to-context mapping.
VACMアクセス制御モデルに関する2つの一般的方法のどちらかを使用して、SNMPはドメインのそばで会計データの分離をサポートします。 ドメインインデックス、またはそれがそうすることができる必要なMIBモジュールサポートが、使用が追加テーブルであると実装したなら、インデックスアプローチとしてのドメインを使用できます。 エージェントでドメイン文脈アプローチを使用できます(ダイナミックな論理的な関係とドメインから文脈と文脈から計装へのマッピングメカニズムをサポートします)。 SNMPv1を使用するか、SNMPv2c、またはSNMPv3メッセージであるとアプローチをサポートすることができます、共同体から文脈へのマッピングを提供するのにsnmpCommunitytable[11]を利用することによって。
4. Review of Accounting Data Transfer
4. 会計データ転送のレビュー
In order for session records to be transmitted between accounting servers, a transfer protocol is required. Transfer protocols in use today include SMTP, FTP, and HTTP. For a review of accounting attributes and record formats, see [45].
セッション記録が会計サーバの間に伝えられるために、転送プロトコルが必要です。 使用中の転送プロトコルは今日、SMTP、FTP、およびHTTPを含んでいます。 会計属性とレコード形式のレビューに関しては、[45]を見てください。
Aboba, et al. Informational [Page 43] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[43ページ]のRFC2975序論
Reference [49] contains a discussion of alternative encodings for SMI data types, as well as alternative protocols for transmission of accounting data. For example, [49] describes how MIME tags and XML DTDs may be used for encoding of SNMP messages or SMI data types. This enables data from SNMP MIBs to be transported using any protocol that can encapsulate MIME or XML, including SMTP and HTTP.
参照[49]はSMIデータ型のための代替のencodingsの議論を含んでいます、会計データの伝達のための代替のプロトコルと同様に。 例えば、[49]はMIMEタグとXML DTDがSNMPメッセージかSMIデータ型のコード化にどう使用されるかもしれないかを説明します。 これは、SNMP MIBsからのデータが輸送されるのをMIMEかXMLをカプセル化することができるどんなプロトコルも使用することで可能にします、SMTPとHTTPを含んでいて。
4.1. SMTP
4.1. SMTP
To date, few accounting management systems have been built on SMTP since the implementation of a store-and-forward message system has traditionally required access to non-volatile storage which has not been widely available on network devices. However, SMTP-based implementations have many desirable characteristics, particularly with regards to security.
これまで、店とフォワードメッセージシステムの実装がネットワークデバイスで広く利用可能でない非揮発性記憶装置へのアクセスを伝統的に必要として以来、わずかな会計管理システムしかSMTPに構築されていません。 しかしながら、SMTPベースの実装は特にあいさつがある多くの望ましい特性をセキュリティに持っています。
Accounting management systems using SMTP for accounting transfer will typically support batching so that message processing overhead will be spread over multiple accounting records. As a result, these systems result in per-active device state. Since accounting systems using SMTP as a transfer mechanism have access to substantial non- volatile storage, they can generate, compress if necessary, and store accounting records until they are transferred to the collection site. As a result, accounting systems implemented using SMTP can be highly efficient and scalable. Using IPSEC, TLS or Kerberos, hop-by-hop security services such as authentication, integrity protection and confidentiality can be provided.
会計転送にSMTPを使用する会計管理システムは、メッセージ処理オーバヘッドが複数の会計帳簿の上に広げられるように、バッチングを通常サポートするでしょう。 その結果、これらのシステムは1能動素子あたりの状態をもたらします。 トランスファ・メカニズムとしてSMTPを使用する会計システムがかなりの非揮発性記憶装置に近づく手段を持っているので、それらは、収集サイトにそれらを移すまで会計帳簿を生成して、必要なら、圧縮して、保存できます。 その結果、SMTPを使用することで実装された会計システムは、高能率的であって、スケーラブルである場合があります。 IPSEC、TLSまたはケルベロスを使用して、ホップごとの認証や、保全保護や秘密性などのセキュリティー・サービスを提供できます。
As described in [13] and [15], data object security is available for SMTP, and in addition, the facilities described in [12] make it possible to request and receive signed receipts, which enables non- repudiation as described in [12]-[17]. As a result, accounting systems utilizing SMTP for accounting data transfer are capable of satisfying the most demanding security requirements. However, such systems are not typically capable of providing low processing delay, although this may be addressed by the enhancements described in [20].
さらに、[12]で説明された施設で、署名している領収書を要求して、受け取るのは可能になります([12]で説明されるように非拒否を可能にします)--[13]と[15]で説明されるように、データ・オブジェクトセキュリティはSMTPに利用可能です、そして、[17]。 その結果、会計データ転送にSMTPを利用する会計システムは最も過酷なセキュリティ要件を満たすことができます。 しかしながら、そのようなシステムは低い処理遅れを通常提供できません、これが[20]で説明された増進で扱われるかもしれませんが。
4.2. Other protocols
4.2. 他のプロトコル
File transfer protocols such as FTP and HTTP have been used for transfer of accounting data. For example, Reference [9] describes a means for representing ASN.1-based accounting data for storage on archival media. Through the use of the Bulk File MIB, accounting data from an SNMP MIB can be stored in ASN.1, bulk binary or Bulk ASCII format, and then subsequently retrieved as required using the FTP Client MIB.
FTPやHTTPなどのファイル転送プロトコルは会計データの転送に使用されました。 例えば、Reference[9]は記録保管所のメディアにストレージのためのASNの.1ベースの会計データを表すための手段を説明します。 Bulk File MIBの使用で、ASN.1(2進の、または、Bulk ASCII書式であって、次に、次に必要に応じてFTP Client MIBを使用することで検索された大量)にSNMP MIBからの会計データを保存できます。
Aboba, et al. Informational [Page 44] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[44ページ]のRFC2975序論
Given access to sufficient non-volatile storage, accounting systems based on record formats and transfer protocols can avoid loss of data due to long-duration network partitions, server failures or device reboots. Since it is possible for the transfer to be driven from the collection site, the collector can retry transfers until successful, or with HTTP may even be able to restart partially completed transfers. As a result, file transfer-based systems can be made highly reliable, and the batching of accounting records makes possible efficient transfers and application of required security services with lessened overhead.
十分な非揮発性記憶装置へのアクセスを考えて、レコード形式と転送プロトコルに基づく会計システムは長い持続時間ネットワークパーティション、サーバ失敗またはデバイスリブートによるデータの喪失を避けることができます。 転送が収集サイトから運転されるのが、可能であるので、コレクタは、うまくいくまで転送を再試行できるか、またはHTTPで部分的に完成した転送を再開さえできるかもしれません。 その結果、ファイル転送ベースのシステムを高信頼性にすることができます、そして、会計帳簿のバッチングは少なくなっているオーバーヘッドで必要なセキュリティの可能な効率的な転送とアプリケーションをサービスにします。
5. Summary
5. 概要
As noted previously in this document, accounting applications vary in their security and reliability requirements. Some uses such as capacity planning may only require authentication, integrity and replay protection, and modest reliability. Other applications such as inter-domain usage-sensitive billing may require the highest degree of security and reliability, since in these cases the transfer of accounting data will lead directly to the transfer of funds.
以前に本書では注意されるように、会計アプリケーションはそれらのセキュリティと信頼度要求事項で異なります。 キャパシティプランニングなどのいくつかの用途が認証、保全、反復操作による保護、および穏やかな信頼性を必要とするだけであるかもしれません。 相互ドメインの用法敏感な支払いなどの他のアプリケーションは最も高度合いのセキュリティと信頼性を必要とするかもしれません、これらの場合では、会計データの転送が直接資金移動に通じるので。
Since accounting applications do not have uniform security and reliability requirements, it is not possible to devise a single accounting protocol and set of security services that will meet all needs. Rather, the goal of accounting management should be to provide a set of tools that can be used to construct accounting systems meeting the requirements of an individual application. As a result, it is important to analyze a given accounting application to ensure that the methods chosen meet the security and reliability requirements of the application.
会計アプリケーションには一定のセキュリティと信頼度要求事項がないので、すべての需要を満たすただ一つの会計プロトコルと1セットのセキュリティー・サービスについて工夫するのは可能ではありません。 むしろ、会計管理の目標は個々のアプリケーションに関する必要条件を満たす会計システムを構成するのに使用できる1セットのツールを提供することであるべきです。 その結果、選ばれたメソッドがアプリケーションに関するセキュリティと信頼度要求事項を満たすのを保証するために与えられた会計アプリケーションを分析するのは重要です。
Based on an analysis of the requirements, it appears that existing deployed protocols are capable of meeting the requirements for intra-domain capacity planning and non-usage sensitive billing. In these applications efficient transfer of bulk data is useful although not critical. Thus, it is possible to use SNMPv3 to satisfy these requirements, without the NMRG extensions. These include TCP transport mapping, sub-tree retrieval, and OID compression.
要件の分析に基づいて、配布しているプロトコルがイントラドメインキャパシティプランニングと非用法の敏感な支払いのために条件を満たすことができるようにその存在に見えます。 これらのアプリケーションでは、重要ではありませんが、大量のデータの効率的な転送は役に立ちます。 したがって、これらの要件を満たすのにNMRG拡張子なしでSNMPv3を使用するのは可能です。 これらがTCP輸送マッピングを含んで、下位木が検索であり、OIDは圧縮です。
In inter-domain capacity planning and non-usage sensitive billing, the security and reliability requirements are greater. As a result, no existing deployed protocol satisfies the requirements. For example, existing protocols lack data object security support and extensions to improve scalability of inter-domain authentication are needed, such as the Kerberos Security Model (KSM) for SNMPv3.
相互ドメインキャパシティプランニングと非用法の敏感な支払いでは、セキュリティと信頼度要求事項は、よりすばらしいです。 その結果、プロトコルであると配布された存在は要件を満たしません。 例えば、データ・オブジェクトセキュリティがサポートする既存のプロトコル不足と相互ドメイン認証のスケーラビリティを改良する拡大が必要です、SNMPv3のためのケルベロスSecurity Model(KSM)などのように。
Aboba, et al. Informational [Page 45] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[45ページ]のRFC2975序論
For usage sensitive billing, as well as cost allocation and auditing applications, the reliability requirement are greater. Here transport layer reliability is required to provide robustness against packet loss, as well as application layer acknowledgments to provide robustness against accounting server failures. SNMP operations with the exception of InforRequest provide application layer acknowledgments, and the TCP transport mapping proposed by NMRG provides robustness against packet loss. Inter-domain operation can benefit from data object security (which no existing protocol provides) as well as inter-domain security model enhancements (such as the KSM).
用法が、敏感な支払いと費用配分と監査のアプリケーション、信頼度要求事項は、より大きいです。 ここで、トランスポート層の信頼性が、パケット損失、および応用層承認に対して丈夫さを提供するのに会計サーバ失敗に対して丈夫さを提供するのに必要です。 InforRequest以外のSNMP操作は応用層承認を提供します、そして、NMRGによって提案されたTCP輸送マッピングはパケット損失に対して丈夫さを提供します。 相互ドメイン操作は相互ドメイン機密保護モデル増進(KSMなどの)と同様にデータ・オブジェクトセキュリティ(どんな既存のプロトコルも提供しない)の利益を得ることができます。
Where high-value sessions are involved, such as in roaming, Mobile IP, or telephony, it may be necessary to put bounds on processing delay. This implies the need to reduce latency. As a result, the NMRG extensions are required in time sensitive billing applications, including TCP transport mapping, get-subtree capabilities and OID compression. High reliability is also required in this application, implying the need for application layer as well as transport layer acknowledgments. SNMPv3 with the NMRG extensions and security scalability improvements such as the KSM can satisfy the requirements in intra-domain use.
高値のセッションがローミング、モバイルIP、または電話などのようにかかわるところでは、処理遅れに領域を置くのが必要であるかもしれません。 これはレイテンシを減少させる必要性を含意します。 その結果、NMRG拡張子は、必要なTCP輸送マッピングを含んでいて、時間の敏感な支払いアプリケーションで下位木を得ている能力とOID圧縮です。 また、トランスポート層承認と同様に応用層の必要性を含意して、高信頼性がこのアプリケーションで必要です。 KSMなどのNMRG拡張子とセキュリティスケーラビリティ改良を伴うSNMPv3はイントラドメイン使用での要件を満たすことができます。
However, in inter-domain use, additional security precautions such as data object security and receipt support are required. No existing protocol can meet these requirements. A summary is given in the table on the next page.
しかしながら、相互ドメイン使用で、データ・オブジェクトセキュリティや領収書サポートなどの追加担保注意が必要です。 どんな既存のプロトコルもこれらの必要条件を満たすことができません。 次のページのテーブルで概要をします。
Aboba, et al. Informational [Page 46] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[46ページ]のRFC2975序論
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Usage | Intra-domain | Inter-domain | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Capacity | SNMPv3 & | SNMPv3 &<* | | Planning | RADIUS #%@ | | | | TACACS+ @ | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Non-usage | SNMPv3 & | SNMPv3 &<* | | Sensitive | RADIUS #%@ | | | Billing | TACACS+ @ | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Usage | | | | Sensitive | | | | Billing, | SNMPv3 &>$ | SNMPv3 &<>*$ | | Cost | TACACS+ &$@ | | | Allocation & | | | | Auditing | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Time | | | | Sensitive | SNMPv3 &>$ | No existing | | Billing, | | protocol | | fraud | | | | detection, | | | | roaming | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | 用法| イントラドメイン| 相互ドメイン| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | 容量| SNMPv3| SNMPv3と<*| | 計画| 半径#%@| | | | TACACS+@| | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | 非用法| SNMPv3| SNMPv3と<*| | 敏感| 半径#%@| | | 支払い| TACACS+@| | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | 用法| | | | 敏感| | | | 支払い| SNMPv3と>$| SNMPv3と<>*$| | 費用| TACACS+と$@| | | 配分| | | | 監査| | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | 時間| | | | 敏感| SNMPv3と>$| 存在しないこと| | 支払い| | プロトコル| | 詐欺| | | | 検出| | | | ローミング| | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key
# = lacks confidentiality support
* = lacks data object security
% = limited robustness against packet loss
& = lacks application layer acknowledgment (e.g. SNMP InformRequest)
$ = requires non-volatile storage
@ = lacks batching support
< = lacks certificate support (KSM, work in progress)
> = lacks support for large packet sizes (TCP transport mapping,
experimental)
キー#=欠乏秘密性は、パケット損失に対する限られたデータ・オブジェクトセキュリティ%=丈夫さを*=欠乏にサポートして、>=欠乏が大きいパケットサイズのためにサポートする@=が欠いている非揮発性記憶装置バッチングサポート<=欠乏証明書サポート(KSM、処理中の作業)を応用層承認(例えば、SNMP InformRequest)$=が必要とする=欠乏にサポートします。(TCP輸送マッピング的で、実験的)です。
Aboba, et al. Informational [Page 47] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[47ページ]のRFC2975序論
6. Security Considerations
6. セキュリティ問題
Security issues are discussed throughout this memo.
このメモ中で安全保障問題について議論します。
7. Acknowledgments
7. 承認
The authors would like to thank Bert Wijnen (Lucent), Keith McCloghrie (Cisco Systems), Jan Melen (Ericsson) and Jarmo Savolainen (Ericsson) for useful discussions of this problem space.
作者はこの問題スペースの役に立つ議論についてバートWijnen(透明な)、キースMcCloghrie(シスコシステムズ)、1月のメレン(エリクソン)とJarmo Savolainen(エリクソン)に感謝したがっています。
8. References
8. 参照
[1] Aboba, B., Lu J., Alsop J., Ding J. and W. Wang, "Review of
Roaming Implementations", RFC 2194, September 1997.
[1]AbobaとB.とLu J.とAlsop J.と鐘の音J.とW.ワング、「ローミング実装のレビュー」、RFC2194、1997年9月。
[2] Aboba, B. and G. Zorn, "Criteria for Evaluating Roaming
Protocols", RFC 2477, January 1999.
[2]AbobaとB.とG.ゾルン、「ローミングプロトコルを評価する評価基準」、RFC2477、1999年1月。
[3] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2138, April,
1997.
[3]RigneyとC.とルーベンとA.とシンプソン、W.とS.ウィレンス、「ユーザサービス(半径)におけるリモート認証ダイヤル」RFC2138(1997年4月)。
[4] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.
[4]Rigney、C.、「半径会計」、RFC2139、1997年4月。
[5] Shacham, A., Monsour, R., Pereira, R. and M. Thomas, "IP Payload
Compression Protocol (IPComp)", RFC 2393, December 1998.
[5]ShachamとA.とMonsourとR.とペレイラとR.とM.トーマス、「IP有効搭載量圧縮プロトコル(IPComp)」、RFC2393 1998年12月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[6] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[7] Information Sciences Institute, "Transmission Control Protocol",
RFC 793, September 1981.
情報科学が設ける[7]、「通信制御プロトコル」、RFC793、1981年9月。
[8] Aboba, B. and M. Beadles, "The Network Access Identifier",
RFC 2486, January 1999.
[8]AbobaとB.とM.用務員、「ネットワークアクセス識別子」、RFC2486、1999年1月。
[9] McCloghrie, K., Heinanen, J., Greene, W. and A. Prasad,
"Accounting Information for ATM Networks", RFC 2512, February
1999.
[9]McCloghrieとK.とHeinanenとJ.とグリーンとW.とA.プラサード、「気圧ネットワークのための課金情報」、RFC2512、1999年2月。
[10] McCloghrie, K., Heinanen, J., Greene, W., and A. Prasad,
"Managed Objects for Controlling the Collection and Storage of
Accounting Information for Connection-Oriented Networks", RFC
2513, February 1999.
[10]McCloghrie、K.、Heinanen、J.、グリーン、W.、およびA.プラサード、「接続指向のネットワークのために課金情報の収集とストレージを制御するための管理オブジェクト」、RFC2513(1999年2月)。
[11] Frye, R., Levi, D., Routhier, S. and B. Wijnen, "Coexistence
between Version 1, Version 2, and Version 3 of the Internet-
standard Management Framework", RFC 2576, March 2000.
[11] フライとR.とレビとD.、RouthierとS.とB.Wijnen、「インターネットの標準のManagement Frameworkのバージョン1と、バージョン2と、バージョン3の間の共存」RFC2576(2000年3月)。
Aboba, et al. Informational [Page 48] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[48ページ]のRFC2975序論
[12] Fajman, R., "An Extensible Message Format for Message
Disposition Notifications", RFC 2298, March 1998.
[12]Fajman、R.、「メッセージ気質通知のための広げることができるメッセージ・フォーマット」、RFC2298、1998年3月。
[13] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC
2015, October 1996.
[13] エルキンズ、M.、「プリティ・グッド・プライバシ(PGP)があるMIMEセキュリティ」、RFC2015、1996年10月。
[14] Vaudreuil, G., "The Multipart/Report Content Type for the
Reporting of Mail System Administrative Messages", RFC 1892,
January 1996.
[14] ボードルイ、G.、「メールのシステムの管理メッセージの報告のための複合/レポートcontent type」、RFC1892、1996年1月。
[15] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security
Multiparts for MIME: Multi-part/Signed and
Multipart/Encrypted", RFC 1847, October 1995.
[15] ガルビン、J.、マーフィー、S.、クロッカー、S.、および解放されたN.、「MIMEのためのセキュリティMultiparts:」 「署名していて複合の/が暗号化した複合/」、RFC1847、1995年10月。
[16] Crocker, D., "MIME Encapsulation of EDI Objects", RFC 1767,
March 1995.
[16] クロッカー、D.、「EDIオブジェクトのMIMEカプセル化」、RFC1767、1995年3月。
[17] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail
Extensions) Part One: Mechanisms for Specifying and Describing
the Format of Internet Message Bodies", RFC 1521, December 1993.
[17] Borenstein、N.、およびN.フリード、「パート1をまねてください(マルチパーパスインターネットメールエクステンション)」 「インターネットメッセージ本体の形式を指定して、説明するためのメカニズム」、RFC1521、1993年12月。
[18] Rose, M.T., The Simple Book, Second Edition, Prentice Hall,
Upper Saddle River, NJ, 1996.
[18] ローズ、M.T.、簡単な本、第2版、新米のホール、上側のサドル川、ニュージャージー、1996。
[19] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction
to Version 3 of the Internet-standard Network Management
Framework", RFC 2570, April 1999.
[19] ケースとJ.とマンディとR.、パーテインとD.とB.スチュワート、「インターネット標準ネットワークマネージメントフレームワークのバージョン3への序論」RFC2570(1999年4月)。
[20] Klyne, G., "Timely Delivery for Facsimile Using Internet Mail",
Work in Progress.
[20] G.、「インターネットメールを使用するファクシミリのためのタイムリーな配送」というKlyneは進行中で働いています。
[21] Johnson, H. T., Kaplan, R. S., Relevance Lost: The Rise and Fall
of Management Accounting, Harvard Business School Press, Boston,
Massachusetts, 1987.
[21] ジョンソン、H.T.、キャプラン、R.S.、失われた関連性: 管理会計、ハーバードビジネス・スクールプレス、ボストン(マサチューセッツ)1987年の消長。
[22] Horngren, C. T., Foster, G., Cost Accounting: A Managerial
Emphasis. Prentice Hall, Englewood Cliffs, New Jersey, 1991.
Horngren(C.T.)が伸ばす[22]、G.、原価計算: 経営者の強調。 新米のホール、イングルウッドがけ、ニュージャージー、1991。
[23] Kaplan, R. S., Atkinson, Anthony A., Advanced Management
Accounting, Prentice Hall, Englewood Cliffs, New Jersey, 1989.
[23] キャプラン(R.S.、アトキンソン、アンソニーA.)は管理会計、新米のホール、イングルウッドがけ、ニュージャージー、1989を進めました。
[24] Cooper, R., Kaplan, R. S., The Design of Cost Management
Systems. Prentice Hall, Englewood Cliffs, New Jersey, 1991.
[24] クーパー、R.、キャプラン、R.S.、原価管理システム新米のホール、イングルウッドがけ、ニュージャージー、1991年のデザイン。
[25] Rigney, C., Willats, S. and P. Calhoun, "RADIUS Extensions", RFC
2869, June 2000.
[25]RigneyとC.とWillatsとS.とP.カルフーン、「半径拡大」、RFC2869、2000年6月。
Aboba, et al. Informational [Page 49] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[49ページ]のRFC2975序論
[26] Stewart, R., et al., "Simple Control Transmission Protocol", RFC
2960, October 2000.
[26] スチュワート、R.、他、「簡単な制御伝動プロトコル」、RFC2960、2000年10月。
[27] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for
Describing SNMP Management Frameworks", RFC 2571, April 1999.
[27] ハリントン、D.、Presuhn、R.、およびB.Wijnen、「SNMP管理フレームワークについて説明するためのアーキテクチャ」、RFC2571、1999年4月。
[28] Rose, M., and K. McCloghrie, "Structure and Identification of
Management Information for TCP/IP-based Internets", STD 16, RFC
1155, May 1990.
[28] ローズ、M.、およびK.McCloghrie、「TCP/IPベースのインターネットのための経営情報の構造と識別」(STD16、RFC1155)は1990がそうするかもしれません。
[29] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16,
RFC 1212, March 1991.
[29] ローズとM.とK.McCloghrie、「簡潔なMIB定義」、STD16、RFC1212、1991年3月。
[30] Rose, M., "A Convention for Defining Traps for use with the
SNMP", RFC 1215, March 1991.
[30] ローズ、1991年3月、M.、「SNMPとの使用のためのDefining TrapsのためのConvention」RFC1215。
[31] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of
Management Information Version 2 (SMIv2)", STD 58, RFC 2578,
April 1999.
[31]McCloghrieとK.、パーキンスとD.とJ.Schoenwaelder、「経営情報バージョン2(SMIv2)の構造」STD58、RFC2578(1999年4月)。
[32] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual
Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[32]McCloghrieとK.とパーキンスとD.とJ.Schoenwaelder、「SMIv2"、STD58、RFC2579、1999年4月の原文のコンベンション。」
[33] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Conformance
Statements for SMIv2", STD 58, RFC 2580, April 1999.
[33]McCloghrieとK.とパーキンスとD.とJ.Schoenwaelder、「SMIv2"、STD58、RFC2580、1999年4月のための順応声明。」
[34] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple
Network Management Protocol", STD 15, RFC 1157, May 1990.
[34] ケース、J.、ヒョードル、M.、Schoffstall、M.、およびJ.デーヴィン(「簡単なネットワーク管理プロトコル」、STD15、RFC1157)は1990がそうするかもしれません。
[35] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Introduction to Community-based SNMPv2", RFC 1901, January
1996.
[35]ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「地域密着型のSNMPv2"への紹介、RFC1901、1996年1月。」
[36] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport
Mappings for Version 2 of the Simple Network Management Protocol
(SNMPv2)", RFC 1906, January 1996.
[36]ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「簡単なネットワークマネージメントのバージョン2のための輸送マッピングは(SNMPv2)について議定書の中で述べます」、RFC1906、1996年1月。
[37] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message
Processing and Dispatching for the Simple Network Management
Protocol (SNMP)", RFC 2572, April 1999.
[37]ケース、J.、ハリントンD.、Presuhn R.、およびB.Wijnen、「メッセージ処理と簡単なネットワークマネージメントのために急いでいるのは(SNMP)について議定書の中で述べます」、RFC2572、1999年4月。
[38] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM)
for version 3 of the Simple Network Management Protocol
(SNMPv3)", RFC 2574, April 1999.
[38] ブルーメンソルとU.とB.Wijnen、「Simple Network Managementプロトコル(SNMPv3)のバージョン3のためのユーザベースのSecurity Model(USM)」、RFC2574、1999年4月。
[39] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC
2573, April 1999.
[39] レビとD.とマイヤーとP.とB.スチュワート、「SNMPv3アプリケーション」、RFC2573、1999年4月。
Aboba, et al. Informational [Page 50] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[50ページ]のRFC2975序論
[40] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access
Control Model (VACM) for the Simple Network Management Protocol
(SNMP)", RFC 2575, April 1999.
[40] Wijnen、B.、Presuhn、R.、およびK.McCloghrie、「簡単なネットワークマネージメントのための視点ベースのアクセス制御モデル(VACM)は(SNMP)について議定書の中で述べます」、RFC2575、1999年4月。
[41] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol
Operations for Version 2 of the Simple Network Management
Protocol (SNMPv2)", RFC 1905, January 1996.
[41] ケース、J.、McCloghrie(K.、ローズ、M.、およびS.Waldbusser)は「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のための操作について議定書の中で述べます」、RFC1905、1996年1月。
[42] Tung, B., Neuman, C., Hur, M., Medvinsky, A., Medvinsky, S.,
Wray, J. and J. Trostle, "Public Key Cryptography for Initial
Authentication in Kerberos", Work in Progress.
[42] 「ケルベロスにおける初期の認証のための公開鍵暗号」というタン、B.、ヌーマン、C.、Hur、M.、Medvinsky、A.、Medvinsky、S.、レイ、J.、およびJ.Trostleは進行中で働いています。
[43] Tung, B., Ryutov, T., Neuman, C., Tsudik, G., Sommerfeld, B.,
Medvinsky, A. and M. Hur, "Public Key Cryptography for Cross-
Realm Authentication in Kerberos", Work in Progress.
[43] 「ケルベロスにおける十字分野認証のための公開鍵暗号」というタン、B.、Ryutov、T.、ヌーマン、C.、Tsudik、G.、ゾンマーフェルト、B.、Medvinsky、A.、およびM.Hurは進行中で働いています。
[44] Hornstein, K. and W. Hardaker, "A Kerberos Security Model for
SNMPv3", Work in Progress.
[44] ホーンスタイン、K.、およびW.Hardaker、「ケルベロスセキュリティはSNMPv3"、進行中の仕事のためにモデル化します」。
[45] Brownlee, N. and A. Blount, "Accounting Attributes and Record
Formats", RFC 2924, September 2000.
[45] ブラウンリーとN.とA.ブラント、「属性とレコード形式を説明します」、RFC2924、2000年9月。
[46] Network Management Research Group Web page,
http://www.ibr.cs.tu-bs.de/projects/nmrg/
[46] ネットワークManagement Research Groupウェブページ、 http://www.ibr.cs.tu-bs.de/projects/nmrg/
[47] Schoenwaelder, J.,"SNMP-over-TCP Transport Mapping", Work in
Progress.
[47] J.、「SNMP過剰TCP輸送マッピング」というSchoenwaelderは進行中で働いています。
[48] Schoenwaelder, J., "SNMP Payload Compression", Work in Progress.
[48] J.、「SNMP有効搭載量圧縮」というSchoenwaelderは進行中で働いています。
[49] Sprenkels, R., Martin-Flatin, J.,"Bulk Transfers of MIB Data",
Simple Times, http://www.simple-times.org/pub/simple-
times/issues/7-1.html, March 1999.
[49]Sprenkels、R.、マーチン-Flatin、J.、「MIB Dataの大量Transfers」、Simpleタイムズ、 http://www.simple-times.org/pub/simple- 回/問題/7-1.html、1999年3月。
[50] Thaler, D., "Get Subtree Retrieval MIB", Work in Progress.
[50] D.、「下位木検索MIBを手に入れてください」というターレルは進行中で動作します。
[51] Daniele, M., Wijnen, B., Ellison, M. and D. Francisco, "Agent
Extensibility (AgentX) Protocol Version 1", RFC 2741, January
2000.
[51] ダニエルとM.とWijnenとB.とエリソンとM.とD.フランシスコ、「エージェント伸展性(AgentX)プロトコルバージョン1インチ、RFC2741、2000年1月。」
Aboba, et al. Informational [Page 51] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[51ページ]のRFC2975序論
9. Authors' Addresses
9. 作者のアドレス
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
バーナードAbobaマイクロソフト社1マイクロソフト、道のワシントン98052レッドモンド(米国)
Phone: +1 425 936 6605 EMail: bernarda@microsoft.com
以下に電話をしてください。 +1 6605年の425 936メール: bernarda@microsoft.com
Jari Arkko Oy LM Ericsson Ab 02420 Jorvas Finland
ヤリArkko Oy LMエリクソンAb02420Jorvasフィンランド
Phone: +358 40 5079256 EMail: Jari.Arkko@ericsson.com
以下に電話をしてください。 +358 40 5079256はメールされます: Jari.Arkko@ericsson.com
David Harrington Cabletron Systems Inc. P.O.Box 5005 Rochester NH 03867-5005 USA
デヴィッドハリントンCabletron Systems株式会社私書箱5005ロチェスターニューハンプシャー03867-5005米国
Phone: +1 603 337 7357 EMail: dbh@cabletron.com
以下に電話をしてください。 +1 7357年の603 337メール: dbh@cabletron.com
Aboba, et al. Informational [Page 52] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[52ページ]のRFC2975序論
10. Intellectual Property Statement
10. 知的所有権声明
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETFはどんな知的所有権の正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。どんなそのような権利も特定するためにいずれも取り組みにしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFはこの規格を練習するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 IETF専務に情報を扱ってください。
Aboba, et al. Informational [Page 53] RFC 2975 Introduction to Accounting Management October 2000
Aboba、他 管理10月が2000であることを説明することへの情報[53ページ]のRFC2975序論
11. Full Copyright Statement
11. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 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機能のための基金は現在、インターネット協会によって提供されます。
Aboba, et al. Informational [Page 54]
Aboba、他 情報[54ページ]
一覧
スポンサーリンク
