Network Working Group B. Aboba
Request for Comments: 2975 Microsoft Corporation
Category: Informational J. Arkko
Ericsson
D. Harrington
Cabletron Systems Inc.
October 2000
Introduction to Accounting Management
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
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.
会計管理の分野では、容量と傾向分析、コスト配分、監査、および請求の目的のためのリソース消費データの収集と懸念しています。この文書では、これらの問題のそれぞれについて説明し、現代の会計システムの設計に関わる問題について説明します。
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.
会計アプリケーションは、統一されたセキュリティと信頼性の要件を持っていないので、すべてのニーズを満たすセキュリティ・サービスの単一の会計プロトコルとセットを考案することはできません。したがって、会計管理の目標は、各アプリケーションの要件を満たすために使用することができるツールのセットを提供することです。この文書では、現在利用可能なツールだけでなく、アカウンティングプロトコルの設計における技術の状況を説明しています。仲間の文書、RFC 2924には、会計属性とレコード形式での最先端技術をレビュー。
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.1要件言語3 1.2用語3 1.3会計管理アーキテクチャ5つの1.4会計管理目標7 1.5イントラドメインとインタードメイン占め10の1.6レコード生産会計11の1.7要件要約13 2.スケーリングと信頼性14 2.1障害回復力14 2.2リソース消費23 2.3データ収集モデルアカウンティングプロトコルの26 3レビュー32 3.1 RADIUS 32の3.2 TACACS + 33 3.3 SNMP 33 4レビュー会計のデータ転送43 4.1 SMTP 44の4.2他のプロトコル44 5.まとめ45の6.セキュリティの考慮事項48 7 。謝辞48 8.参考文献48 9著者のアドレス52 10知的財産権に関する声明53 11全著作権ステートメント54
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.
会計管理の分野では、容量と傾向分析、コスト配分、監査、および請求の目的のためのリソース消費データの収集と懸念しています。この文書では、これらの問題のそれぞれについて説明し、現代の会計システムの設計に関わる問題について説明します。
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.
会計アプリケーションは、統一されたセキュリティと信頼性の要件を持っていないので、すべてのニーズを満たすセキュリティ・サービスの単一の会計プロトコルとセットを考案することはできません。したがって、会計管理の目標は、各アプリケーションの要件を満たすために使用することができるツールのセットを提供することです。この文書では、現在利用可能なツールだけでなく、アカウンティングプロトコルの設計における技術の状況を説明しています。仲間の文書、RFC 2924には、会計属性とレコード形式での最先端技術をレビュー。
In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [6].
この文書に記載されている、キーワード "MAY"、「MUST、 "MUST NOT"、 "オプション"、 "推奨"、 "SHOULD"、および "the" はならない、[6]に記載のように解釈されるべきです。
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.
アーカイブ会計でアーカイブ会計、目標は、すべての会計データを収集するために、データの損失が発生した場合に可能な限り最善のように不足しているエントリを再構築するために、と命じた期間のデータをアーカイブすることです。これらのシステムは、会計データの損失に対して非常に堅牢であるように操作されることが、「通常の慣習的」です。これは、トランスポート層とアプリケーション層の確認応答、不揮発性記憶装置の使用、中間アカウンティング機能（ワイヤー上で保存または送信）などの法律や金融の要件に関する規定が頻繁にアーカイブ会計慣行を強制含むことができ、そして頻繁にあることを指示することができますデータは関係なく、課金目的かどうかのために使用されるかどうかの、機密保持します。
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.
請求書を準備するために使用する情報に依存して課金処理を課金敏感な使用は、使用に敏感であるということができます。対照的に、使用情報とは独立しているプロセスは、非使用に敏感であると言われています。
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 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.
配分にエンティティ間のコストを割り当てる行為を要します。コスト配分と評価は根本的に異なるプロセスであることに注意してください。コスト配分の目的は、いくつかのエンティティの間で知られているコストを割り当てることが一般的です。客観的に評価するリソースの使用のために充電される量を決定することです。コスト配分では、リソースの単位当たりのコストを決定する必要があるかもしれません。評価では、これは一般的に与えられています。
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.
中間会計中間会計は、ユーザーのセッション中に使用状況のスナップショットを提供します。これは、セッションサマリーパケット又はセッション・レコードの受信又は発生を防止デバイスのリブートまたは他のネットワーク問題が発生した場合に有用であり得ます。中間会計記録は、常に情報の損失なしにまとめることができます。中間アカウンティングレコードが再起動を生き残るように（例えば、不揮発性記憶装置のように）デバイスに内部的に格納することができるので、常にワイヤを介して送信されなくてもよいことに留意されたいです。
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.
セッション記録セッションレコードは、セッション全体にわたるユーザーのリソース消費の要約を表しています。セッション・レコードを作成する会計ゲートウェイは、同じユーザーにサービスを提供する複数のデバイスから中間会計イベントや会計事象を処理することによってそれを行うことができます。
Accounting Protocol A protocol used to convey data for accounting purposes.
議定書に会計目的のためにデータを伝達するために使用されるプロトコルを占めています。
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.
イントラドメイン会計イントラドメイン会計は、そのドメイン内で使用するために、管理ドメイン内のリソースの使用状況に関する情報の収集を必要とします。ドメイン内の会計では、会計パケットとセッション記録は、一般的に管理境界を越えることはありません。
Inter-domain accounting Inter-domain accounting involves the collection of information on resource usage within an administrative 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.
会計サーバは、アカウンティングサーバがデバイスから会計データを受信して、セッションレコードに変換します。アカウンティングサーバも、利害関係者へのセッションレコードのルーティングのための責任を取ってもよいです。
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.
処理された会計データは、その後、典型的評価と請求書生成を処理課金サーバに提出されたが、また、監査、コスト配分、傾向分析やキャパシティプランニング機能を実行することができます。セッションレコードはバッチ処理と会計データの量と転送を達成するために必要な帯域幅を削減するために、課金サーバに提出する前に、アカウンティングサーバによって圧縮することができます。
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〕に記載のネットワークアクセス識別子（NAI）を含むセッション・レコードのために、区別はNAIのドメイン部分を調べることによって行うことができます。ドメイン部分が存在しないか、またはローカル・ドメインに対応する場合、セッション・レコードは、ドメイン内課金イベントとして扱われます。それ以外の場合は、ドメイン間のアカウンティングイベントとして扱われます。
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.
会計プロキシが信頼されていない場合は、本来のアカウンティングメッセージは通常、セッションレコードと一緒に転送されないので、プロキシは、それが受信するアカウンティングメッセージに基づいて、正しいセッションレコードを発行していることを確認することは困難です。信頼が問題ですので、プロキシは、通常、アカウンティングパケット自体を転送します。アカウンティングプロトコルは、データオブジェクトのセキュリティをサポートしていると仮定すると、これは、エンドポイントがプロキシが通過中のデータを変更したり、パケットの内容にスヌープしていないことを検証することを可能にします。
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 |
| | | |
+------------+ +------------+
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.
会計管理は、容量と傾向分析、コスト配分、監査、課金の目的のためのリソース消費データの収集を必要とします。これらの各タスクには、さまざまな要件があります。
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 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.
傾向分析および容量計画のためのセキュリティ要件は、データ収集とデータの機密性の状況に依存します。データは、管理ドメイン間で転送されている場合は、追加のセキュリティサービスが必要な場合があります。情報は、同じ管理ドメイン内で収集し、分析されているとき、例えば、完全性保護と認証は、無効なデータの収集を防ぐために使用することができます。ドメイン間でのアプリケーションの機密性は、第三者がスヌーピングを防ぐことが望ましいかもしれません。
When accounting data is used for billing purposes, the requirements depend on whether the billing process is usage-sensitive or not.
会計データは、課金目的のために使用されている場合、要件は、課金処理を利用敏感であるかどうかによって異なります。
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.
定義によるので、不使用に敏感な課金は理論的にはすべての会計データは、課金処理に影響を与えずに失われることが、使用情報を必要としません。こうした卸売データ損失がまだ受け入れられないように、もちろん、これはまた、そのような傾向分析や監査などの他のタスクに影響を与えます。
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.
使用に敏感なシステムは、低処理遅延を必要とするかもしれません。今日の信用リスクは、一般的に異常な活動を検出するように設計されているコンピュータ化された不正検出システムによって管理されています。詐欺の危険性がある場合、効率の懸念がそうでなければ、会計データのバッチ送信を指示するかもしれませんが、金融エクスポージャーは、処理遅延に伴って増加します。したがって、バッチ・サイズを最小にするために、あるいはキューイング遅延を最小限にするためにサービス技術の品質を利用する個々のイベントを送信するのが望ましいことがあります。承認は支払能力に依存するために加えて、それが必要な場合があります。
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.
使用状況に敏感なシステムでは、会計データが収入につながりますので、セキュリティと信頼性の要件が大きくなります。財政的および法的要件にこのようなシステムは、監査を乗り切ることができるようにする必要があります。従って、このような認証、完全性、リプレイ保護などのセキュリティサービスが頻繁に必要とされており、機密性とデータオブジェクトの整合性も望ましいかもしれません。アカウンティングサーバの障害から保護するために、アプリケーション層の確認応答もしばしば必要とされています。
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.
監査手続は、使用状況やセキュリティポリシーへの適合性を検証するために使用される場合、セキュリティサービスが望まれてもよいです。これは通常、認証、完全性、リプレイ保護だけでなく、機密性とデータオブジェクトの整合性が含まれます。進行中のセキュリティインシデントへの対応を可能にするためには、監査アプリケーションが頻繁に低処理遅延で動作するように構築されています。
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]に記載の活動基準原価計算技術は、典型的には、使用量データの詳細な分析に基づいて、結果としてそれらはほとんど常に利用敏感されています。これらの技術はベンチャーで、または単一の会社での部門間の費用の配分にパートナー間のコストの割り当てに適用されるかどうかは、コスト配分モデルは、多くの場合、深遠な行動や財務への影響を持っています。課金アプリケーションである結果として、この目的のために開発されたシステムは、一般的に信頼性の高いデータ収集やセキュリティのように心配しています。財政的および法的要件に、アーカイブ会計慣行は、頻繁にこのアプリケーションで必要とされています。
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を超える音声やビデオなどのサービスの増加展開で、ドメイン間の会計処理を必要とするアプリケーションは、ますます一般的になっています。
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.
これとは対照的に、ドメイン間の会計処理は、別の管理ドメイン内で使用するために、管理ドメイン内のリソース消費に関する情報の収集を必要とします。ドメイン間の会計では、会計パケットとセッション記録は、一般的に管理境界を横切ることになります。その結果、ドメイン間の会計アプリケーションでは、かなりのパケット損失が発生することがあります。また、転送に関与するエンティティは互いを信頼すると仮定することはできません。
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.
ドメイン間の会計アプリケーションは、ドメイン間の会計データの転送を必要とするので、追加のセキュリティ対策が望ましいことがあります。認証、リプレイと完全性の保護に加えて、そのような機密性とデータオブジェクトの整合性などのセキュリティサービスを展開することが望ましい場合があります。各当事者を占め、ドメイン間でも一般的に、請求書作成と監査のための各会計イベントのコピーが必要です。
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.
典型的には、単一のアカウンティング・レコードは、セッションごとに生成されるか、またはいくつかの場合には、課金目的のために単一のレコードにまとめることができる中間レコードのセット。しかし、そのような無線アクセスや複雑な課金制度などのサービスの展開をサポートするために、より洗練されたアプローチが必要とされます。
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つのセッションからレコードのセットを生成します。セッション識別子は、一緒にレコードを結びつけるために会計システムを可能にするために、レコードに存在する必要があります。
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 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.
ローカルデバイスは、QoSの変更やローミングなど地元の関税を、影響を与える要因を認識しているように、複数のセッションレコードが、必要な場合、ほとんどのケースでは、ネットワークデバイスが決定されます。しかし、将来のシステムは、アカウンティングレコードの生成を制御するためにホームドメインを有効にするように設計されています。これは、ドメイン間の会計場合や、ネットワークデバイスが関税の情報を持っていない中で重要です。アカウンティングレコードの生産の集中制御は、例えば、認可サーバは、特定の時間に再認証を必要有し、各再認証時にアカウンティングレコードの生成を要求することによって、実現することができます。
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サーバのいずれかによって制御することができます。複数のレコード・セッションで適時性、セキュリティおよび信頼性の要件は、単一レコードのセッションと同じです。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key [] = optional
キー[] =オプション
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.
インターネットの継続的な成長と、会計管理システムは、拡張性と信頼性があることが重要です。このセクションでは、会計管理システムだけでなく、様々なデータ収集と輸送モデルによって示され、スケーラビリティと信頼性の特性によって消費されるリソースについて説明します。
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
パケットロス会計サーバの障害ネットワークの障害デバイスの再起動
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ベースのトランスポート間の違いに焦点を当てています。しかし、パケット損失に対する回復力がアーカイブ会計要件を満たす唯一の一つの側面であることを理解すべきです。
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, 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.
それも、長年にわたって信頼性の高い会計システムは、任意のネットワーク接続せずに、単に物理的な記憶に基づいて実施されたため、不揮発性記憶装置は、ネットワーク接続よりも会計の信頼性にとってより重要であると主張することができます。例えば紙、フィルム、又は磁気媒体上に格納され、紙幣を処理するための中央の場所にコレクションの場所から運ばれ使用される、携帯電話の使用状況データ。
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カードのサポートにより、達成することができます。
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.
不揮発性ストレージが利用可能である場合、これは中間会計データを格納するために使用することができます。セッションが完了したときに保存された中間イベントは、更新された暫定的な事象またはセッションデータに置き換えられます。データが送信され、アプリケーション層で認知された後、セッションデータ自体を消去することができます。このアプローチは、デバイスの再起動の場合を除いて、ワイヤを介して送信される中間データを回避します。デバイスを再起動すると、内部に格納されている暫定レコードがアカウンティングサーバに転送されます。
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.
レコードが格納され、および/または搬送する必要があるように、一例として、一日の特定の時間に関税変化が、不用意に実装されている場合、メモリと帯域幅の消費の急激なピークを作成することができます。むしろ、一度にすべてのレコードを送信しようとするよりも、不揮発性ストレージに保管し、セッションが完了したときにバッチで一緒に関連するすべてのレコードを送信することが望ましい場合があります。ピーク帯域幅の消費量を低減するように、また、会計トラフィックフローを形成することが望ましいかもしれません。これは、無作為化遅延間隔を導入することによって達成することができます。ホームドメインは、複数のアカウンティングレコードの生成を制御することができた場合は、最悪の場合の処理要件の推定は非常に難しいことができます。
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 (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.
パケットロスがインターネット上の生命の事実であるとして、セッションデータを扱う会計プロトコルは、パケット損失に対して弾力的にする必要があります。これは、パケットが、多くの場合、パケットロスがかなりのかもしれネットワークアクセスポイント（NAPの）通過ドメイン間会計、特に重要です。パケット損失に対する回復力は、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とアプリケーション層は、その内蔵のハートビート機能とaliveパケットまたはSCTPを保つセッション状態を追跡するためのメカニズムを提供します。
When implementing UDP retransmission, there are a number of issues to keep in mind:
UDP再送を実装するときは、心に留めておくべき問題がいくつかあります：
Data model Retry behavior Congestion control Timeout behavior
データモデルは、行動輻輳制御タイムアウトの動作を再試行します
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再試行メカニズムを設計する際には、再送信は、典型的には、確認応答が到着すると予想することができる期間内に発生しないようにリトライタイマーは、往復時間に関連することが重要です。不要な再送信のために追加のトラフィックが輻輳レベルを上げることができるように会計帯域幅は、いくつかの状況では重要となり得ます。
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回の定常期間試行の後に会計データを削除でき、次いで、12時間の総タイムアウト時間まで、別のサーバに切り替えます不揮発性記憶装置上の未送信のデータ。これらのアプローチの間の実用的な差は相当なものです。前者のアプローチは、後者のかもしれないが、アーカイブ会計要件を満たしています。より予測可能な動作は、SCTPまたはTCPトランスポートの使用を介して達成することができます。
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つ以上のセカンダリサーバを提供することは、アカウンティングサーバの障害のリスクの大部分を削除することができ、サーバとセカンダリサーバの結果用として一般的になっています。
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.
任意のトランスポートでは、プライマリとセカンダリアカウンティングサーバが重複パケットを受信することも可能であるので、重複排除のためのサポートが必要です。アカウンティングサーバの障害は、会計上のクライアント上のデータの蓄積をもたらすことができるので、不揮発性記憶装置の使用は、伝送タイムアウトにデータの損失を防ぐには、または枯渇をバッファリングすることができます。オン・ワイヤー中間会計は、アカウンティングサーバの障害の影響の緩和にのみ限定された利点を提供します。
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.
アカウンティングサーバは、部分的な障害を体験することが可能です。例えば、データベースバックエンドの障害は、課金検索処理を残すことができるか、処理しながら操作可能なスレッドまたはデータが非機能的である格納する責任スレッド。会計アプリケーションは、着信セッションレコードを格納継続することができなくなって、ディスク領域が不足するために同様に、それが可能です。
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トランスポート・保証の利用です。しかし、RFC 793で述べたように[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.
そのため、TCPはACKを送信した後に失敗した受信すると、アプリケーションがデータを受信できないことがあります。アプリケーションが安定したストレージにデータをコミットする前に失敗した場合も同様に、データが失われる可能性があります。ために送信側アプリケーションは、それが送信されたデータは、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".
例えば、課金サーバは、トランスポート層からデータを受信し、それをバックエンド・データベースの問題やディスク障害に起因するデータを格納することができないかもしれません。このケースでは、トランスポート層の承認が適切であっても、アプリケーション層の確認応答を送信するべきではありません。むしろ、アプリケーション層のエラーメッセージは、「バックエンドストア利用できない」として、問題の原因を示す送信されるべきです。
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.
したがって、アプリケーション層の確認機能は、アプリケーションがデータの責任を取った時に認識させる能力だけでなく、アプリケーションがデータの責任を取り、そしてなぜしていないときを示すための能力だけでなく、必要とされます。
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.
アカウンティングサーバの障害と同様に、オン・ワイヤー中間会計は、ネットワーク障害の影響の緩和にのみ限定された利点を提供します。
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.
デバイスの再起動の場合には、進行中のセッションのデータの損失を最小限にすることが望ましいです。このような損失は、デバイス自体は非常に信頼性がある場合でも、総リソース消費のかなりの部分を含むことができ、長寿命のセッションに起因する重要かもしれません。これらの高価値セッションの損失を防ぐために、中間アカウンティングデータは、典型的には、ワイヤを介して送信されます。インプレース中間会計は、不揮発性記憶装置と組み合わされた場合、それははるかに短いセッションでデータの損失を防ぐことが可能となります。中間会計データは、セッションは暫定データは、セッションレコードで置き換えられてもよい時点で、完了するまで唯一の非揮発性メモリに保存することが必要なので、これは可能です。その結果、当中間会計データは、ワイヤを介して送信されません必要があり、データ損失に対する保護の非常に高度を提供するように、暫定間隔を小さくすることができます。
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 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.
これがそうでないときアカウンティング要求は、アカウンティングサーバによって受け入れられていたことを考えることにデバイスをだます会計サーバから1つを受信することなく、デバイスへの輸送やアプリケーション層のACKを送信する会計プロキシ。それはアカウンティングサーバによって承認された前の結果として、デバイスは、不揮発性ストレージから会計パケットを削除することができます。アカウンティングパケットを提供する責任会計プロキシを残します。課金プロキシは可動部品（例えば、ディスクドライブ）を含む場合のデバイスはないが、システム全体の信頼性を低減させることができます。
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.
彼らは唯一のキャパシティプランニングや不使用に敏感な課金アプリケーションでの使用に適しているように、しかし、そのようなシステムは、本質的に信頼できません。アーカイブ会計の信頼性が要求される場合、むしろストアアンドフォワード会計プロキシを追加することによって、本質的に信頼できないシステムにパッチを適用しようとするよりも、この文書に記載された技術を用いて最初から信頼性の高い会計システムを設計する必要があります。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
| 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 |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key * = limited usefulness without non-volatile storage
不揮発性記憶装置のないキー* =限られた有用性
Note: Accounting proxies are not a reliability enhancement mechanism.
注意：会計プロキシが信頼性強化メカニズムではありません。
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および管理対象デバイス上のネットワーク帯域幅のメモリの不揮発性記憶状態
In order to understand the limits to scaling, we examine each of these resources in turn.
スケーリングの限界を理解するために、我々は、順番にこれらの各リソースを調べます。
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層で行うことができます。
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.
先に述べたように、中間会計の実装は、同じセッションのために新しいデータと古い中間会計データを上書きするのではなく、バッファ内の中間データを蓄積することにより、過度のメモリ使用量に対して保証するために注意する必要があります。
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 compression algorithms are only typically applied to session records so as to enable implementation of interim data overwrite.
不揮発性記憶装置は、中間またはセッションレコードを格納するために使用することができます。過度なストレージ消費を防止するために、メモリの使用率と同様に、中間会計上書きが望ましいです。 ASCIIデータ表現の使用は、ストレージ要件を最小化することができる高効率のテキスト圧縮アルゴリズムの使用を可能にすることに留意されたいです。中間データの上書きの実装を可能にするように、このような圧縮アルゴリズムは、典型的には、セッション・レコードに適用されます。
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.
受け取った会計データを追跡するためには、管理システムを占めることは、管理対象デバイスまたは同時セッションに状態を維持する必要があるかもしれません。デバイスの数は、一般的に、同時セッションの数よりもはるかに小さいので、可能な場合のみ、デバイスごとの状態を維持することが望ましいです。
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リソースを持つデバイスの場合には、過小推定すべきではありません。デバイスは過課税会計タスクである場合には、全体的なデバイスの信頼性が苦しむことになると思われます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
| 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 |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
バッチ処理のイベント駆動型ポーリングモデルとバッチ処理のイベント駆動型モデルなしのポーリングモデルイベント駆動型モデル
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.
ポーリング・モデルは、個々のデバイス内のデータの蓄積をもたらし、その結果として、データは、典型的には、効率的な転写工程において得られた、バッチの会計管理に転送されます。経理マネージャーの状態に関しては、ポーリング・システムは、転送されるデータの量と管理対象デバイスの数、およびシステム帯域幅の使用率スケールとスケール。
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.
不揮発性記憶せずに、デバイスの再起動に起因するが、十分に短い持続時間のパケット損失またはネットワーク障害に起因しない会計データの損失ポーリングモデルの結果は、使用可能なメモリ内で処理されます。経理マネージャーは、データが受信されるまでポーリングし続けるためです。運用の困難に遭遇している状況では、会計データの量は、頻繁にデータの損失可能性が高くなるように増加します。管理対象デバイスに到達するための試みが失敗しますので、この場合には、ポーリングモデルは、問題を検出します。
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のプロビジョニングやインターネット接続などのローミングサービスの実現のために不十分なスケール。特定のドメイン内のユーザーのための会計データを取得するために、会計管理ステーションが定期的に関連するすべてのデータが含まれていないだろうほとんどがすべてのドメイン内のすべてのデバイスをポーリングする必要があるためです。ポーリング間隔の使用も半分ポーリング間隔の平均処理遅延を意味するので、処理遅延の問題もあります。これは、低処理遅延を必要とする会計データには高すぎるかもしれません。こうしてイベントドリブンポーリングまたは純粋なイベント駆動型のアプローチは、共有の使用またはローミングの実装として使用敏感課金アプリケーションにとってより適切です。
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.
デバイスごとの状態は、ネットワーク管理システムは、運用の目的のためにネットワーク機器の状態を追跡する必要があるため、多くの場合にも、会計管理機能を実行するポーリングベースのネットワーク管理システムの典型的なものです。これらのシステムは半分のポーリング間隔に等しい平均処理遅延を提供します。
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つだけのアカウンティングイベントを転送します。
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.
セッションごとの状態はバッチ処理せずにイベント駆動型システムの典型的なものです。その結果、イベント駆動型アプローチが不十分スケール。しかし、イベント駆動型システムは、イベントがすぐに処理され、一括転送の背後に引っ掛かる低処理遅延を必要とするイベントの可能性がないので、最も低い処理遅延を提供します。
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.
会計データを転送する準備ができたときにバッチ処理とイベント駆動型モデルでは、デバイスは、アカウンティングサーバまたは管理者に連絡します。装置は、特定のタイプのデータが利用可能であるか、または期間が経過した最小時間の後である場合、所与のサイズのバッチは、収集されたサーバーに接続することができます。このようなシステムは、パケットごとに複数のアカウンティングイベントを転送するため、より効率的であることができます。
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.
スケジューリングアルゴリズムの実装により、バッチ処理とイベント駆動型システムは、低処理遅延を必要とアカウンティングイベントに適切なサービスを提供することができます。他のすべてのイベントがバッチ処理されるだろうしながら、例えば、高価値ドメイン間の会計事象は、これ詐欺防止技術の使用を可能にする、すぐに送ることができます。しかしながら、低処理遅延を必要とするイベントが進行中の一括転送の後ろに捕捉される可能性があります。したがって、最大処理遅延は、リンク速度で割った最大バッチサイズに比例します。
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.
アクティブデバイスの数とバッチ処理の規模を持つイベント駆動型システム。結果として、このアプローチは、純粋なイベント駆動型のアプローチ、あるいはポーリングアプローチよりも良好なスケール、およびイベント駆動型ポーリングのアプローチへのスケーリングの点で同等です。会計データの配信がスケジューリングアルゴリズムが使用される場合、低処理遅延を必要とするより少ないラウンドトリップとイベントを収容することができる必要があるためしかし、イベント駆動型バッチアプローチは、イベント駆動型ポーリングアプローチよりも低い処理遅延を有しています。
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.
それがイベントを受信した場合にのみ、イベント駆動型ポーリングモデルでは、会計管理者は、会計データのためにデバイスをポーリングします。会計クライアントは、特定のタイプのデータが利用可能か、期間が経過した最小時間後であるとき、指定されたサイズのバッチは、収集されたイベントを生成することができます。転写効率は、バッチサイズに伴って増加する一方、不揮発性記憶せずに、デバイスの再起動からの潜在的なデータ損失も増加することに注意してください。
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.
バッチ処理を実現することができる場合、イベント駆動型ポーリングに必要な状態は、能動素子の数と規模を小さくすることができます。ネットワークの一部は、使用中に広く変化する場合、この状態は、実際のポーリングアプローチよりも小さくてもよいです。少なくとも二つの往復は、データを配信するために必要とされるので、このアプローチで遅延を処理するバッチ処理とイベントドリブン会計よりも高いことに注意：イベント通知のための1つの、そして得られた投票のための1つ。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key * = addressed by non-volatile storage
キー* =不揮発性記憶装置によって対処
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などのプロトコルを使用して実装されています。このセクションでは、これらのプロトコルのそれぞれの特性を記述する。
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アカウンティング - 応答トランスポート層の承認に相当し、アプリケーション層の誤動作を防ぐ機能はありません。信頼性の不足のために、それだけでは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の属性）に苦しんでいます。
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 +のスケールに対する弾力性です。 TACACS +は、TCP上で実行されるため、それは両方のトランスポート層とアプリケーション層の確認応答のためのサポートを提供し、最低の処理遅延はありませんが、中程度必要とアカウンティングイベントの同時利用制御および取り扱いに適しています。
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圧縮は、これを提供するために使用することができます。
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ののデータモデリング言語は、トラップ指向ポーリングを可能にするために、トラップを持っていますが、トラップは認めていない、と失われたトラップは、データの損失につながることができます。 SMIv2のは、SNMPv2cのおよびSNMPv3で使用される、認め通知される要求を通知しています。これは、より信頼性の高いイベント駆動型ポーリングモデルやイベント駆動型バッチモデルを実装することが可能となります。しかし、我々は現在、応答要求の使用上に構築された任意のSNMPベースの会計の実装を認識していません。
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のサポートパケットごとの認証および読み取り専用および読み書きコミュニティストリングを経由して、アクセスプロファイルを。このクリアテキストのパスワードのアプローチは、些細な認証、および無パケットごとの整合性チェック、再生保護や機密性を提供します。ビューベースのアクセス制御[40] [11]で定義されsnmpCommunityMIB、およびSNMPv1またはSNMPv2cのを使用してサポートすることができます
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ユーザーセキュリティモデル（USM）[38]は、共有秘密を使用し、ドメインとデバイスの数の積は、そのようなドメイン間の会計アプリケーションのように、大きい場合は、共有秘密の数が手に負えなくなることができます。 USMでのローカライズされた重要な機能は、管理者が互いのデータになってから、他のエンティティを防止しながら、ローカライズされた方法で、多くの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プロキシエンティティは、彼らが前方にデータを復号化し、再暗号化。信頼できないプロキシエンティティの存在下では、これは不十分であろう。
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レスポンスは、ゲット-次、またはget-バルクへの要求は、要求されたデータを返すか、エラーの性質を示すエラーコードが発生しました。
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の応答要求された割り当ては、アプリケーションによって行われたことを示しています。 SNMPセットはアトミックです。コマンドが成功するか失敗します。エラー応答は、企業が要求を受信し、それを実行するには成功しなかったことを示しています。
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.
通知は、データが処理されたことを示すために確認応答を使用しないでください。通知は、設計により、レシートのではなく、処理の確認応答を返し知らせます。更新されたSNMPアーキテクチャは、機能のさまざまなレベルを持つピアとしてエンティティを扱うので、処理の確認応答を達成するために、協働するエンティティ間でどちらの方向にもセットを使用することが可能です。
There are eighteen SNMP error codes. The design of SNMP makes service-specific error codes unnecessary and undesirable.
18のSNMPエラーコードがあります。 SNMPの設計は不要と望ましくないサービス固有のエラーコードになります。
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.
会計管理アーキテクチャでは、プロキシフォワーダは、正しい宛先に内およびドメイン間のアカウンティングイベントを転送し、重要な役割を果たしています。プロキシフォワーダはまた、ポーリングまたはイベント駆動型ポーリングアーキテクチャにおいて役割を果たし得ます。
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プロキシフォワーダの機能性は[39]で定義されています。例えば、ネットワークデバイスは、プロキシフォワーダにすべてのドメインの通知を送信するように構成することができる、およびデバイスは、プロキシフォワーダは、すべての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.
プロキシフォワーダの使用は、ドメイン間の会計処理のために必要な共有秘密の数を減らすことができます。プロキシフォワーダを使用すると、ドメインがプロキシフォワーダと秘密を共有することができ、ひいては、プロキシフォワーダは、デバイスのそれぞれに秘密を共有することができます。従って、共有秘密の数は、デバイスとドメインの数ではなく、積の和でスケーリングします。
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.
PDUが転送されるべきSNMPエンジン又はそのローカルSNMPアプリケーションがPDUを処理すべきかを決定することを除いてSNMPプロキシフォワーダのエンジンは、メッセージのPDUの内部には見えません。 SNMPプロキシフォワーダはVARBIND値を変更しません。 SNMPのバージョン間で変換するため以外にはvarbindリストは変更されません。そして、それはどのVARBINDレベルのアクセス制御を提供していません。
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のデータのサブセットを識別するために使用されます。これらはエンジン、コンテキスト、およびビューが含まれます。このセクションでは、この機能がイントラとドメイン間の会計処理に適用することができる方法を説明します。
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エンジンが含まれています。エンジンIDは、それがネットワークに接続されているアドレスとは無関係に、SNMPエンジンは一意に識別されることを可能にします。
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を介してエンジンIDにマッピングすることができます。
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エージェントは、それが認識してコンテキスト何マネージャーに伝えるために、読み取り専用の動的テーブルに移入されます。管理者は、それらを定義した場合、エージェントは基本的な計測にコンテキストを結びつける方法を知ることはできませんので、通常の状況は、エージェントではなく、管理者によって定義されています。 MIBモジュールマネージャは計装の論理サブセットのcontextNamesを割り当てることができるように定義されることが可能です。
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モジュールのインスタンスを1つ持っていることは理にかなって、そのインスタンスを見つけるのは簡単でなければならないMIBモジュールのために使用されていますこのようなシステムMIBやセキュリティのMIBとして。
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にマッピングすることができるコミュニティを含みます。
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.
ビューは、ビューベースアクセス制御モデルで定義されています。ビューは、特定のコンテキスト内の管理オブジェクトへのアクセスを決定するために使用されるマスクです。サブツリーのOIDを指定してオブジェクトが表示されているビューを識別は、含まれて除外しました。 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セキュリティ関連テーブルを含む別のビューを定義することが可能です。これらのビューを使用すると、利用者のアダム（SNMPセキュリティ管理者）のためのユーザジョーとジョセフィン（RMON管理者）のためのRMONビューへのアクセス、および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.
ビューには、ワイルドカードを使用して設定することができます。ジョセフィンサブネット10.200.x.x.ためにすべての行へのアクセスを与えている間にIPアドレスを使用して索引付けされたテーブルのため、ジョーは、サブネット10.2.x.xにある所定のRMONテーブルのすべての行（例えばRMONホストテーブル）へのアクセスを許可することができます
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).
名前レベル（のOID）にビューフィルタ、値のレベルで、非インデックスデータの値に基づくので、定義ビューがサポートされていませんではありません。この例では、データ項目ではなく指標として単に使用されているため、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のメッセージ形式を使用してエンティティによって利用することができます。
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 accounting data awaiting collection. SNMP Applications [39] defines a standard module for managing notifications.
この問題は、イベント・ドリブン、イベントドリブンのポーリングやイベント駆動型バッチアプローチを使用してSNMPで対処することができます。トラップおよびインフォームコレクションを待っている会計データを持っているドメインを通知するSNMP対応デバイスを許可します。 SNMPアプリケーション[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エージェントのレベルで区別することができます。
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のすべてのユーザは、ユーザベースのセキュリティMIBモジュール（または他のセキュリティモデルMIBモジュール）において定義されるであろう。アクセスコントロールを投与を簡単にするため、ユーザは、例えば、vacmGroupNameを使用してグループ化することができますbigco。 MIB内のデータ・オブジェクトのサブセットのビューがvacmViewFamilyTreeTableで定義することができます。するvacmAccessTableペア・グループとビュー。 bigcoグループ内のユーザから受信したメッセージについては、アクセスデータのみに提供されるビューファミリーツリーで定義されているように、bigcoユーザが見ることを許可さ。これは、データにアクセスする各ドメインが適切なViewTableを定義する、1つまたは複数の別個vacmGroupNamesを与えられ、そしてする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 synchronization between tables.
SNMPは、ドメインとデータの既存の行の間でタプルを保持するドメインによってインデックス新しいテーブルを定義するために使用することができRowPointer規則を、サポートしています。これは、テーブル間の同期の問題を紹介します。
ContextNames can be used to differentiate multiple instances of a MIB module within an engine.
contextNamesは、エンジン内のMIBモジュールの複数のインスタンスを区別するために使用することができます。
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.comなどの個々のドメインは、例えばbigcoコンテキストなどの論理コンテキストにマッピングすることができます。エージェントが作成し、新しいコンテキストを認識し、論理的なコンテキストに関連付けられている計装知っておく必要があるだろう。エージェントは、アクセス制御が間違ったドメインに機密情報の開示を防ぐために、コンテキストに適用することができるように、ドメインによって会計データを収集し、個別のコンテキストを介してデータにアクセスできるようにする必要があります。 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を有するであろう。 GET-バルク要求がbigco文脈における仮想テーブルからのデータ、すなわちbigco.comドメインに対応し、その後、bigcoののcontextNameで作られている場合、返されます。
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.
サブエージェントは、特定のMIBサブツリーの範囲のサポートを提供するために登録したときにSNMPエージェントの実装を簡素化するために、サブエージェントとマスターエージェントとの間の登録プロトコルを標準のAgentX [51]は、新規のcontextNamesの作成および認識を可能にします。サブエージェントは、例えば、特定の機能をサポートする方法を知っています計装は、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 condition, and what access control rules apply to the context.
管理者主導のアプローチは、目的のドメインに対応するのcontextNamesを事前定義するMIBモジュールを使用することができ、データが指定された条件に基づいて適用され、どのようなアクセス制御すべきドメインへの分化方法、収集すべきオブジェクトを示すためにルールは、コンテキストに適用されます。
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モジュールとアプリケーションを設計する上で必要とされるであろう、新しい領域を表します。
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.
会計アプリケーションでは、管理ステーションは、多くの場合、大きなテーブルを取得する必要があります。応答は、複数のラウンドトリップを必要とする、サポートされる最大パケットサイズに収まらなければならないので、待ち時間は、さえGET-バルク操作で、高くなることがあります。転送がシリアル化されていてもよく、得られた待ち時間が許容できない性能をもたらし得る複数の往復時間、可能なタイムアウト及び再送信遅延と処理オーバーヘッドの組み合わせ、であろう。データが複数の回収の過程の間に変更されることがありますので、一貫性のあるスナップショットを取得することは困難です。
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プレフィックスの送信の非効率、および「取得バルクオーバーシュートの問題」を高くすることができます。テーブルのバルク転送では、転送OIDは冗長である：単一のテーブルの行のすべてのエントリのインスタンス識別子ポストフィックスされているような列数までのすべてのOIDプレフィックスは、同一です。したがって、OIDを圧縮することによって、または各変数に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
文献に記載された「取得バルクオーバーシュートの問題」、[50]、GETバルクPDUを使用する場合に発生します。問題は、管理者は通常、テーブル内の行数を知らないということです。その結果、いずれかの要求あまりにも多くの行、複数のget-バルクリクエストが必要で、その結果、不要なデータ、または少なすぎるを取得する必要があります。 「get-バルクオーバーシュート」問題は、エージェント側で予防可能であってもよいことに注意してください。参考文献[41]は、エージェントが（ページ[41]の15/16の項目1および3を参照）ので、「ローカルな制約」のGET-バルクを終了することができると述べています。これが意味すると解釈することができ
that it is possible to stop at the end of a table.
テーブルの最後に停止することが可能です。
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.
レイテンシと効率性の問題に対処するには、ネットワーク管理研究グループ（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ネットワーク管理研究グループ（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].
記載されているように、ペイロード圧縮方法は、[5]またはSNMPペイロードの圧縮、[48]に記載の、IPパケットの圧縮を含みます。
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.
テーブル検索することが提案改善がサブツリー検索MIBとGet-サブツリーPDUの付加を含みます。サブツリー検索MIB [50] SNMPプロトコルやSNMPプロトコルエンジンへの変更を必要としないので、実装とプロトコルへの変更よりも容易に展開することができます。 GET-サブツリーのPDUの追加は、プロトコルへとそれをサポートするすべてのSNMPエンティティのエンジンへの変更を意味します。それはSNMPプロトコルを変更せずには、「get-バルクオーバーシュートの問題」を解決することが可能であるので、この変更の必要性は議論があります。
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]また、不揮発性記憶装置にSNMPデータの保存、およびFTPを介して後続のバルク転送を可能にするために、SNMPデータ、およびFTP MIBの使用のファイルベースのストレージを論じています。このアプローチは、追加のMIBモジュールの実装だけでなく、FTPを必要とし、転送中のデータの認証、リプレイ、完全性保護と機密性を提供するために、IPsecなどの個別のセキュリティ・メカニズムを必要とします。不揮発性記憶装置との互換性 - ファイルベースの転送アプローチが重要な利点があります。
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の提案で存在します。新しい機能を実装していないデバイスが収容される必要があるだろう。これは、新旧のエンティティ間の翻訳者として行動する必要があり、プロキシフォワーダに特に問題があります。このような状況では、翻訳のオーバーヘッドは、新技術のメリットを相殺します。
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のケルベロスセキュリティ・モデル（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でのKerberosの使用は、各デバイスとドメインの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.
Kerberosは、[42]に記載されているように、公開鍵を介して初期認証を許可するように拡張され、クロスレルム認証は、[43]に記載されているように、KSMは、これらの機能を継承しています。その結果、このアプローチは減らす、あるいは共有秘密管理の問題を解消する可能性を有することができます。しかし、またその代替トランスポートマッピングがこれをサポートするために必要とされ得るように、証明書ベースの認証は、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のトラフィックを保護するために使用するIPSecセキュリティアソシエーションのプロパティを取得できるようにするSNMPv3エンジンを必要とします。これは、このような認証方法などのセキュリティ呼び出されるサービスだけでなく、他のエンドポイントに関連する情報を含み、そしてアイデンティティと証明書を提示します。現在まで、このようなAPIは広く実装されていない、と加えて、ほとんどのIPSECの実装は、識別のみの必要な粒度を提供することはできませんマシン証明書をサポートしています。このように、SNMPv3のIPSECベースのセキュリティモデルは、おそらく結実に来て数年かかるだろう。
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が予見可能な将来のために人気のアカウンティングプロトコル残る可能性が高いです。
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.
SNMPベースのドメイン内の会計実装はSNMPv3のにアップグレードするための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の共有秘密を管理する負担は、ローカライズされたキーの機能を介して、またはプロキシフォワーダーの実装を経由して減少させることができます。長期的には、このようにKerberosセキュリティ・モデルなどの代替セキュリティモデルは、さらにセキュリティを管理し、合理化されたドメイン間の動作を可能にするために必要な作業量を減らすことができます。
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ネットワーク管理研究グループ（NMRG）での議論の下での提案を介してアドレス指定することができます。実験的なSNMP TCPトランスポート上のマッピングは、待ち時間を短縮に役立つことを証明します。データの量によっては、圧縮のいくつかのフォームも検討する価値があるかもしれません。これらの提案は、研究段階にとどまっており、標準化過程の上ではありませんので、しかし、これらの機能は容易に入手できない、と彼らは最終形態に到達する前に仕様が大幅に変更することができます。
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.
SNMPはVACMアクセス制御モデルを持つ2つの一般的なアプローチのいずれかを使用して、ドメインによって会計データの分離をサポートしています。所望のMIBモジュールはドメイン索引付けをサポートしている場合、インデックスアプローチとしてドメインを使用することができ、またはそれは、追加のテーブルを用いて実現することができます。ドメインコンテキストアプローチは、動的論理コンテキストおよびドメインコンテキストおよびコンテキスト・ツー・計装マッピングメカニズムをサポートするエージェントで使用することができます。いずれのアプローチは、コミュニティ・ツー・コンテキストのマッピングを提供するsnmpCommunitytable [11]を利用することによって（SNMPv1、SNMPv2c、またはSNMPv3）メッセージを使用してサポートすることができます。
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]を参照してください。
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データ型の代替エンコーディングのほか、会計データの伝送のための代替プロトコルの議論が含まれています。例えば、[49] MIMEタグとXMLのDTDは、SNMPメッセージまたはSMIデータ型の符号化のために使用することができる方法を記載しています。これは、SNMPのMIBからのデータがSMTPとHTTPなどMIMEまたはXMLを、カプセル化することができる任意のプロトコルを用いて搬送することを可能にします。
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を使用して、会計管理システムは、典型的には、バッチ処理をサポートします。結果として、これらのシステムごとのアクティブデバイス状態をもたらします。彼らは、コレクションのサイトに転送されるまで、転送メカニズムとしてSMTPを使用して会計システムが実質的な不揮発性ストレージへのアクセス権を持っているので、彼らは、生成することができ、必要に応じて圧縮し、店舗の会計記録。その結果、SMTPを使用して実装会計システムは非常に効率的かつスケーラブルなことができます。 IPSEC、TLSまたはKerberosを使用して、認証、完全性保護と機密性としてホップバイホップのセキュリティサービスを提供することができます。
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].
[13]及び[15]に記載されているように、データオブジェクトのセキュリティは、SMTPのために利用可能であり、加えて、[12]に記載の設備には、に記載されているように、否認防止を可能にする、要求することを可能にし、署名された領収書を受け取る[12 ] - [17]。その結果、会計データ転送用のSMTPを利用した会計システムは、最も要求の厳しいセキュリティ要件を満たすことができます。これは[20]に記載の拡張機能によって対処することができるものの、このようなシステムは、典型的には、低処理遅延を提供することができません。
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などのファイル転送プロトコルは、会計データの転送のために使用されています。例えば、参考文献[9]アーカイブ媒体に記憶するためのASN.1ベースのアカウンティングデータを表現するための手段を記載します。バルクファイルMIBの使用を介して、SNMP MIBから会計データは、バルク二元又はバルクASCII形式、ASN.1に格納され、必要に応じてその後FTPクライアントMIBを使用して取得することができます。
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でさえも、部分的に完成し転送を再開することができるかもしれません。その結果、ファイル転送ベースのシステムは、高い信頼性を行うことができ、および会計記録のバッチ処理が可能な、効率的な転送や軽減オーバーヘッドで必要なセキュリティサービスを適用します。
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.
会計アプリケーションは、統一されたセキュリティと信頼性の要件を持っていないので、すべてのニーズを満たすセキュリティ・サービスの単一の会計プロトコルとセットを考案することはできません。むしろ、会計管理の目標は、個々のアプリケーションの要件を満たす会計システムを構築するために使用することができるツールのセットを提供する必要があります。その結果、選ばれたメソッドは、アプリケーションのセキュリティと信頼性の要件を満たしていることを確認するために与えられた会計アプリケーションを分析することが重要です。
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のケルベロスセキュリティモデル（KSM）として、必要とされているドメイン間認証のスケーラビリティを向上させるためのデータオブジェクトセキュリティのサポートと拡張性を欠いています。
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.
ただし、ドメイン間の使用では、このようなデータオブジェクトセキュリティと領収書のサポートなどの追加のセキュリティ対策が必要とされています。既存のプロトコルは、これらの要件を満たすことはできません。概要は次ページの表に与えられています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| 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 | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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)
パケットロス＆=に対するデータオブジェクトのセキュリティ％=限定された堅牢性は、アプリケーション層の応答（例えばSNMP InformRequest）$ =を欠い欠けていることは、不揮発性ストレージ@を必要=バッチ処理のサポートを欠いキー＃=は、機密性のサポートを欠い* = <=は、KSM（証明書のサポートが欠けています進行中の作業）> =が大きいパケットサイズ（TCPトランスポートマッピングのサポートが欠けている、実験）
Security issues are discussed throughout this memo.
セキュリティの問題は、このメモ中で議論されています。
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] Aboba, B., Lu J., Alsop J., Ding J. and W. Wang, "Review of Roaming Implementations", RFC 2194, September 1997.
[1] Aboba、B.、陸J.、オールソップJ.、丁J.およびW.ワング、 "ローミング実装のレビュー"、RFC 2194、1997年9月。
[2] Aboba, B. and G. Zorn, "Criteria for Evaluating Roaming Protocols", RFC 2477, January 1999.
[2] Aboba、B.およびG.ゾルン、 "ローミングプロトコルを評価するための基準"、RFC 2477、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. Willensを、 "リモート認証ダイヤルインユーザーサービス（RADIUS）で"、RFC 2138、1997年4月。
[4] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.
[4] Rigney、C.、 "RADIUSアカウンティング"、RFC 2139、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）"、RFC 2393、1998年12月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[6]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[7] Information Sciences Institute, "Transmission Control Protocol", RFC 793, September 1981.
[7]情報科学研究所、 "伝送制御プロトコル"、RFC 793、1981年9月。
[8] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
[8] Aboba、B.及びM. Beadles、 "ネットワークアクセス識別子"、RFC 2486、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. Prasadの "ATMネットワークのための課金情報"、RFC 2512、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.プラサド、RFC 2513、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の、 "バージョン1、バージョン2、およびインターネット標準の管理フレームワークのバージョン3の間の共存"、RFC 2576、2000年3月。
[12] Fajman, R., "An Extensible Message Format for Message Disposition Notifications", RFC 2298, March 1998.
[12] Fajman、R.、RFC 2298、1998年3月の "メッセージ処分通知のための広げることができるメッセージフォーマット"。
[13] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC 2015, October 1996.
、RFC 2015 [13]エルキンズ、M.、 "プリティグッドプライバシー（PGP）とMIMEセキュリティ"、1996年10月。
[14] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 1892, January 1996.
[14]ヴォードルイユ、G.、RFC 1892「メールシステムの管理メッセージの報告のための複合/レポートのコンテンツタイプ」、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マルチパートのセキュリティ：マルチパート/署名およびマルチパート/暗号化"、RFC 1847、1995年10月。
[16] Crocker, D., "MIME Encapsulation of EDI Objects", RFC 1767, March 1995.
[16]クロッカー、D.、 "EDIオブジェクトのMIMEカプセル化"、RFC 1767、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.フリード、「MIME（多目的インターネットメール拡張）第一部：インターネットメッセージ本体の形式を指定し、説明するためのメカニズム」、RFC 1521、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への序論"、RFC 2570、1999年4月。
[20] Klyne, G., "Timely Delivery for Facsimile Using Internet Mail", Work in Progress.
[20] Klyne、G.、「インターネットメールを使用するファクシミリのためのタイムリーな配信」が進行中で働いています。
[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.
[22] Horngren、C. T.、フォスター、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.カルフーン、 "RADIUS拡張機能"、RFC 2869、2000年6月。
[26] Stewart, R., et al., "Simple Control Transmission Protocol", RFC 2960, October 2000.
[26]スチュワート、R.、ら。、 "簡単な制御伝送プロトコル"、RFC 2960、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の、RFC 2571、1999年4月 "SNMP管理フレームワークを記述するためのアーキテクチャ"。
[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ベースのインターネットのための経営情報の識別"、STD 16、RFC 1155、1990年5月。
[29] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991.
[29]ローズ、M.、およびK. McCloghrie、 "簡潔なMIB定義"、STD 16、RFC 1212、1991年3月。
[30] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991.
[30]ローズ、M.、 "SNMPとの使用のためのDefining Trapsのための条約"、RFC 1215、1991年3月。
[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、STD 58、RFC 2578、1999年4月 "管理情報バージョン2（SMIv2）の構造"。
[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のためのテキストの表記法"、STD 58、RFC 2579、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のための適合性宣言"、STD 58、RFC 2580、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.デーヴィン、 "簡単なネットワーク管理プロトコル"、STD 15、RFC 1157、1990年5月。
[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の概要"、RFC 1901、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、RFC 1906 "簡易ネットワーク管理プロトコル（SNMPv2）のバージョン2のための交通マッピング"、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）のための派遣"、RFC 2572、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の、 "ユーザベースセキュリティモデル（USM）簡易ネットワーク管理プロトコル（SNMPv3の）のバージョン3のために"、RFC 2574、1999年4月。
[39] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999.
[39]レビ、D.、マイヤー、P.とB.スチュワート、 "SNMPv3のアプリケーション"、RFC 2573、1999年4月。
[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）"、RFC 2575、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、 "簡易ネットワーク管理プロトコルのバージョン2のためのプロトコル操作（SNMPv2の）"、RFC 1905、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.、ハー、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.ハー、 "ケルベロスのクロスレルム認証のための公開鍵暗号"、進行中の作業。
[44] Hornstein, K. and W. Hardaker, "A Kerberos Security Model for SNMPv3", Work in Progress.
[44] Hornstein、K.およびW. Hardaker、 "SNMPv3のKerberosのセキュリティモデル" が進行中で働いています。
[45] Brownlee, N. and A. Blount, "Accounting Attributes and Record Formats", RFC 2924, September 2000.
[45]ブラウンリー、N.とA.ブラント、 "会計属性とレコード形式"、RFC 2924、2000年9月。
[46] Network Management Research Group Web page, http://www.ibr.cs.tu-bs.de/projects/nmrg/
[46]ネットワーク管理研究グループのWebページ、http://www.ibr.cs.tu-bs.de/projects/nmrg/
[47] Schoenwaelder, J.,"SNMP-over-TCP Transport Mapping", Work in Progress.
[47] Schoenwaelder、J。、 "SNMP-over-TCPの交通マッピング" が進行中で働いています。
[48] Schoenwaelder, J., "SNMP Payload Compression", Work in Progress.
[48] Schoenwaelder、J.、 "SNMPペイロード圧縮" が進行中で働いています。
[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] Sprenkel、R.、マーティンFlatin、J.、 "MIBデータのバルク転送" シンプル・タイムズ、http://www.simple-times.org/pub/simple-times/issues/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"、RFC 2741、2000年1月。
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
バーナードAbobaマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052 USA
Phone: +1 425 936 6605 EMail: bernarda@microsoft.com
電話：+1 425 936 6605 Eメール：bernarda@microsoft.com
Jari Arkko Oy LM Ericsson Ab 02420 Jorvas Finland
ヤリArkkoオイLMエリクソン・アブ02420 Jorvasフィンランド
Phone: +358 40 5079256 EMail: Jari.Arkko@ericsson.com
電話番号：+358 40 5079256 Eメール：Jari.Arkko@ericsson.com
David Harrington Cabletron Systems Inc. P.O.Box 5005 Rochester NH 03867-5005 USA
デヴィッド・ハリントンCabletronシステムズ社のP.O.Box 5005ロチェスターNH 03867から5005 USA
Phone: +1 603 337 7357 EMail: dbh@cabletron.com
電話：+1 603 337 7357 Eメール：dbh@cabletron.com
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は、そのような権限下で、ライセンスがたりないかもしれない可能性があるためにどの本書または程度に記載されている技術の実装や使用に関係すると主張される可能性があります任意の知的財産やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能。また、そうした権利を特定するために取り組んできたことを表していないん。スタンダードトラックおよび標準関連文書における権利に関するIETFの手続きの情報は、BCP-11に記載されています。権利の主張のコピーは、出版のために利用可能とライセンスの保証が利用できるようにする、または本仕様の実装者または利用者が、そのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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専務に情報を扱ってください。
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。