[要約] RFC 2975は、会計管理の導入に関するガイドラインであり、組織が効果的な会計管理を実施するための手法と目的を提供しています。
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.
Copyright（c）The Internet Society（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半径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].
このドキュメントでは、キーワードは「可能性があります」、「必要はない」、「オプション」、「推奨」、「必要」、「必要はありません」は、[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.
会計サーバーの機能の1つは、インタードメインとドメイン内の会計イベントを区別し、適切にルーティングすることです。[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.
エンタープライズの顧客によるコスト配分とビルバックの方法の適用は、まだ広まっていません。ただし、テレフォニー通信とデータ通信の収束により、現在一般的に通信コストで実践されているように、ネットワーキングコストにコストの割り当てと請求書の手順を適用することに関心が高まっています。
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領域と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
key [] =オプション
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ベースの輸送の違いに対する回復力に焦点を合わせてきました。ただし、パケット損失に対する回復力は、アーカイブ会計要件を満たす1つの側面にすぎないことを理解する必要があります。
As noted in [18], "once the cable is cut you don't need more retransmissions, you need a *lot* more voltage." Thus, the choice of transport has no impact on resilience against faults such as network partition, accounting server failures or device reboots. What does provide resilience against these faults is non-volatile storage.
[18]で述べたように、「ケーブルが切断されると、より多くの再送信を必要としないので、より多くの電圧が必要です。」したがって、輸送の選択は、ネットワークパーティション、会計サーバーの障害、デバイスの再起動などの障害に対する回復力に影響を与えません。これらの障害に対して回復力を提供するのは、不揮発性ストレージです。
The importance of non-volatile storage in design of reliable accounting systems cannot be over-emphasized. Without non-volatile storage, event-driven systems will lose data once the transmission timeout has been exceeded, and batching designs will experience data loss once the internal memory used for accounting data storage has been exceeded. Via use of non-volatile storage, and internally stored interim records, most of these data losses can be avoided.
信頼できる会計システムの設計における不揮発性ストレージの重要性は、強調しすぎることはできません。不揮発性ストレージがなければ、イベント駆動型のシステムは、送信タイムアウトを超えるとデータを失い、バッチ設計は、データストレージを超えている内部メモリを超えるとデータ損失が発生します。不揮発性ストレージ、および内部で保存された暫定記録の使用により、これらのデータ損失のほとんどは回避できます。
It may even be argued that non-volatile storage is more important to accounting reliability than network connectivity, since for many years reliable accounting systems were implemented based solely on physical storage, without any network connectivity. For example, 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+.
暫定会計は、セッションの概要情報が失われた場合にセッションレコードを再構築するために使用できるチェックポイント情報を提供することにより、セッションの概要データの損失に対する保護を提供します。この手法は、任意のデータ収集モデル（つまり、イベント駆動型またはポーリング）に適用され、半径[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パケット内に収まらない場合、UDPでの複数のラウンドトリップの使用には、TCPまたはSCTP輸送の使用が推奨される場合があります。[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、アプリケーションレイヤーKeep 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.
ただし、現代の会計実装では、スループットを改善し、高い信頼性を維持しながら、混雑制御を実装することが可能であると主張することもできます。持続的なパケット損失がある状況では、既存の伝送速度を維持するのに十分な能力がありません。したがって、うっ血性のバックオフが実装されると、集計スループットが実際に改善されます。これは、再送信の排除と、フローを非同期化するための赤などのテクニックを利用する能力によるものです。さらに、差別化されたサービスなどの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ベースの会計プロトコルは、多くの場合、タイムアウトの動作を規定していません。したがって、実装は大きく異なる動作を示す可能性があります。たとえば、1つの実装では、3つの一定の持続時間が同じサーバーに再び取得した後、アカウンティングデータをドロップし、別の実装では特定のサーバーに指数関数的なバックオフを実装し、別のサーバーに切り替えて、12時間の合計タイムアウト間隔まで切り替えることができます。不揮発性ストレージに関するトランスメットされていないデータ。これらのアプローチ間の実際的な違いは実質的です。前者のアプローチは、アーカイブの会計要件を満たすことはありませんが、後者は5月になります。より予測可能な動作は、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.
したがって、ACKを送信した後にTCPの受信が失敗した場合、アプリケーションはデータを受信しない場合があります。同様に、データを安定したストレージにコミットする前にアプリケーションが故障した場合、データが失われる可能性があります。送信アプリケーションが送信されたデータが受信アプリケーションによって受信されたことを確認するために、TCP接続の優雅な閉鎖またはアプリケーションレイヤーの確認が必要です。データの損失から保護するために、アプリケーション層の認識は、データが安定したストレージに書き込まれているか、損失を守るために適切に処理されたことを意味することが必要です。
In the case of partial failures, it is possible for the transport layer to acknowledge receipt via transport layer acknowledgment, without having delivered the data to the application. Similarly, the application may not complete the tasks necessary to take responsibility for the data.
部分的な障害の場合、データをアプリケーションに配信することなく、輸送層が輸送層の確認を介して領収書を確認することが可能です。同様に、アプリケーションは、データの責任を取るために必要なタスクを完了しない場合があります。
For example, an accounting server may receive data from the transport layer but be incapable of storing it data due to a back end database problem or disk fault. In this case it should not send an application layer acknowledgment, even though a a transport layer acknowledgment is appropriate. Rather, an application layer error message should be sent indicating the source of the problem, such as "Backend store unavailable".
たとえば、会計サーバーはトランスポートレイヤーからデータを受信する場合がありますが、バックエンドデータベースの問題やディスク障害のためにITデータを保存することはできません。この場合、輸送レイヤーの確認が適切である場合でも、アプリケーションレイヤーの確認を送信してはなりません。むしろ、「バックエンドストアが利用できない」などの問題の原因を示すアプリケーションレイヤーエラーメッセージを送信する必要があります。
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.
会計サーバーから入手せずにトランスポートまたはアプリケーションレイヤー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
key * =不揮発性ストレージなしの限られた有用性
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]に記載されている半径会計に基づくものなど、ほとんどのイベント駆動型会計システムは、パケットごとに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.
不揮発性ストレージがなければ、純粋なイベント駆動型モデルは通常、タイムアウト間隔が期限切れになるまでまだ配信されていない会計イベントを保存します。その結果、このモデルにはメモリ要件が最小になります。タイムアウト間隔が失効すると、デバイスにそれを保存し続けるのに十分なバッファスペースがある場合でも、会計イベントが失われます。その結果、デバイスの再起動、持続パケット損失、またはタイムアウト間隔よりも大きい持続時間のネットワーク障害により、会計データ損失が発生するため、イベント駆動型モデルは最も信頼性が低いです。「Keep Alive」メッセージのないイベント駆動型プロトコルでは、会計サーバーは、メッセージが長期間届かない場合にデバイスの障害を想定できません。したがって、イベント駆動型の会計システムは、通常、デバイスの健康を監視するのに役立ちません。
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.
バッチングを実装できる場合、イベント駆動型のポーリングに必要な状態は、アクティブなデバイスの数とともにスケーリングするように縮小できます。ネットワークの一部が使用法が大きく異なる場合、この状態は実際にはポーリングアプローチの状態よりも少ない可能性があります。このアプローチでの処理遅延は、データを配信するために少なくとも2つのラウンドトリップが必要であるため、イベント駆動型の会計よりも高くなることに注意してください。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
key * =不揮発性ストレージによってアドレス指定されます
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認証のアプローチを共有します。その結果、デバイスの数ではなく会計イベントの数を持つ半径の会計スケール、および会計転送は非効率的です。
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会計応答は輸送層の謝辞と同等であり、アプリケーション層の誤動作に対する保護を提供しません。信頼性がないため、半径の会計単独に基づいて同時使用制御を行うことはできません。通常、セッション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.
半径の会計実装は、パケットの損失、アプリケーションレイヤーの障害、ネットワークの障害、デバイスの再起動に対して脆弱です。これらの欠陥は、ローミングに必要なドメイン間会計で拡大されています（[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).
半径は圧縮をサポートしていませんが、[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]、[27] - [41]に記載されているSNMPは、通常、ポーリングデータ収集モデルを使用して、さまざまなドメイン内会計アプリケーションに広く展開されています。ポーリングにより、複数の会計イベントで同時にデータを収集することができ、デバイスごとの状態が生じます。管理アプリケーションは、応答が受信されない場合にリクエストを再試行することができ、パケットの損失や短命のネットワークパーティションに対して復元力を提供します。不揮発性ストレージのない実装は、デバイスの再起動やネットワーク障害に対して堅牢ではありませんが、不揮発性ストレージと組み合わせると、信頼性が高くなります。
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.
SNMPV1のデータモデリング言語であるSMIV1には、トラップ指向のポーリングを許可するトラップがありますが、トラップは認められておらず、トラップの失われたトラップはデータの損失につながる可能性があります。SNMPV2CおよびSNMPV3が使用するSMIV2には、通知が認められているリクエストが通知されています。これにより、より信頼性の高いイベント駆動型のポーリングモデルまたはイベント駆動型バッチモデルを実装できます。ただし、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 messages. The updated SNMP architecture [rfc2571] supports per-packet hop-by-hop authentication, integrity and replay protection, confidentiality and access control.
SNMPV1およびSNMPV2Cは、パケットごとの認証と読み取り専用およびREAD-WRITEアクセスプロファイルをコミュニティ文字列を介してサポートします。このクリアテキストパスワードアプローチは、些細な認証のみを提供し、パケットごとの整合性チェック、リプレイ保護、または機密性はありません。ビューベースのアクセス制御[40]は、[11]で定義されているsnmpcommunitymib、およびsnmpv1またはsnmpv2cメッセージを使用してサポートできます。更新された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のローカライズされたキー機能により、マネージャーは1つの中央キーを持つことができ、他のエンティティが互いのデータを取得するのを防ぎながら、ローカライズされた方法で多くのSNMPエンティティと共有できます。これにより、適切に展開すると、ドメインクロスセキュリティを支援できます。
SNMPv3 does not support end-to-end data object integrity and confidentiality; SNMP proxy entities decrypt and re-encrypt the data they forward. In the presence of an untrusted proxy entity, this would be inadequate.
SNMPV3は、エンドツーエンドのデータオブジェクトの完全性と機密性をサポートしていません。SNMPプロキシエンティティは、転送されるデータを復号化および再暗号化します。信頼されていないプロキシエンティティの存在下では、これは不十分です。
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は、アプリケーション層の確認を使用して、データが処理されたことを示します。get、get-next、またはget-bulk要求に対するSNMP応答は、要求されたデータ、または遭遇したエラーの性質を示すエラーコードを返します。
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.
SNMPプロキシフォワーダーのエンジンは、どのSNMPエンジンを転送するか、どのローカルSNMPアプリケーションがPDUを処理するかを判断することを除いて、メッセージの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エンジンが含まれています。EngineIDを使用すると、ネットワークに接続されているアドレスとは無関係に、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を介して、コミュニティ名とソースアドレスをEngineIDにマッピングできます。
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.
コンテキストは、機器に結び付けられたエンジンの範囲内で、オブジェクトのサブセットを識別するために使用されます。コンテキスト名は、エンジン内の特定のサブセットを指します。
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モジュールを定義して、マネージャーがコンテキスト名を計装の論理サブセットに割り当てることができる可能性があります。
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モジュールのインスタンスをサポートする場合がありますが、各コンテキスト名は特定のMIBモジュールの1つのインスタンスに制限されます。エンジンごとにMIBモジュールの複数のインスタンスが必要な場合は、一意のコンテキスト名を定義する必要があります（例：Repeater1、Repeater2）。デフォルトのコンテキスト ""は、MIBモジュールの単一インスタンスのみをサポートするエンジンに使用され、MIBモジュールに使用されます。このモジュールでは、そのMIBモジュールの1つのインスタンスがエンジンにある場合にのみ理にかなっています。システムMIBやセキュリティMIBSなど。
SNMPv3 messages contain contextNames which are limited to the scope of the contextEngineID in the message. SNMPv1 and SNMPv2c messages contain communities which can be mapped to contextNames within the local engine, or can be mapped to contextNames within other engines via the snmpCommunityTable, described in [11].
SNMPV3メッセージには、メッセージ内のContextEngineIDの範囲に限定されたContextNamesが含まれています。SNMPV1およびSNMPV2Cメッセージには、[11]で説明されているSNMPCommunityTableを介して、ローカルエンジン内のコンテキスト名にマッピングできる、または他のエンジン内のコンテキスト名にマッピングできるコミュニティが含まれています。
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セキュリティ関連のテーブルのみを含む別のビューを定義することができます。これらのビューを使用して、ユーザーのJoeとJosephine（RMON管理者）のRMONビューへのアクセス、およびユーザーAdam（SNMPセキュリティ管理者）のSNMPV3セキュリティテーブルへのアクセスを許可することができます。
Views can be set up with wildcards. For a table that is indexed using IP addresses, Joe can be allowed access to all rows in given RMON tables (e.g. the RMON hostTable) that are in the subnet 10.2.x.x, while Josephine is given access to all rows for subnet 10.200.x.x.
ビューはワイルドカードでセットアップできます。IPアドレスを使用してインデックス付けされたテーブルの場合、Joeは、サブネット10.2.x.xにある与えられたRMONテーブル（RMON HostTableなど）のすべての行にアクセスできるようになりますが、ジョセフィンはサブネット10.200.x.xのすべての行にアクセスできます。
Views filter at the name level (OIDs), not at the value level, so defining views based on the values of non-index data is not supported. In this example, were the IP address to have been used merely as a data item rather than an index, it would not be possible to utilize view-based access control to achieve the desired objective (delegation of administrative responsibility according to subnet).
ビューは、値レベルではなく、名前レベル（OIDS）でフィルターをフィルターしているため、非インデックスデータの値に基づいてビューを定義することはサポートされていません。この例では、IPアドレスは単にインデックスではなくデータ項目として使用されていたため、ビューベースのアクセス制御を利用して望ましい目標（サブネットに従って管理責任の委任）を達成することはできません。
View-based access control is independent of message version. It can be utilized by entities using SNMPv1, SNMPv2c, or SNMPv3 message formats.
ビューベースのアクセス制御は、メッセージバージョンに依存しません。SNMPV1、SNMPV2C、またはSNMPV3メッセージ形式を使用してエンティティで利用できます。
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ユーザーが表示することが許可されたデータのみにアクセスが提供されます。これには、データにアクセスする各ドメインに1つまたは複数の個別のvacmgroupNamesが与えられ、適切なビューテーブルが定義され、各グループにvacmacessTableを構成する必要があります。
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ドメインを使用してユーザーに会計データが収集されている場合、各ドメインに会計セッションレコードテーブルの個別の仮想インスタンスが存在し、各ドメインには対応するコンテキスト名があります。Get-BulkリクエストがBigCoのコンテキスト名で作成されると、BigCoコンテキストの仮想テーブルからのデータ、つまりBigco.comドメインに対応するデータが返されます。
There are a number of design approaches to creating new contexts and associating the contexts with appropriate instrumentation, most notably a sub-agent approach and a manager-configured MIB approach.
新しいコンテキストを作成し、コンテキストを適切な計装、特にサブエージェントアプローチとマネージャーが構成したMIBアプローチと関連付けるための多くの設計アプローチがあります。
AgentX [51], which standardizes a registration protocol between sub-agents and master agents to simplify SNMP agent implementation, allows for the creation and recognition of new contextNames when a subagent registers to provide support for a particular MIB subtree range. The sub-agent knows how to support a particular functionality, e.g. instrumentation exposed via a range of MIB objects. Based on values detected in the data, such as source=bigco.com, the sub-agent could determine that a new domain needed to be tracked and create the appropriate context for the collection of the data, plus the appropriate access control entries. The determination could be table-driven, using MIB configuration.
SNMPエージェントの実装を簡素化するためにサブエージェントとマスターエージェント間の登録プロトコルを標準化するAgentX [51]は、サブエージェントが特定のMIBサブツリー範囲のサポートを提供するときに新しいコンテキスト名の作成と認識を可能にします。サブエージェントは、特定の機能をサポートする方法を知っています。さまざまなMIBオブジェクトを介して露出した計装。Source = 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.
マネージャー駆動型のアプローチは、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.
ドメイン間分離にコンテキスト名を使用することは新しい領域を表しているため、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].
[49]で説明したように、潜伏期、ネットワークオーバーヘッド、テーブル検索など、バルクデータの転送にSNMPを使用する場合に発生する問題があります。
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.
会計アプリケーションでは、管理局は多くの場合、大きなテーブルを取得する必要があります。応答は最大のサポートされているパケットサイズに適合する必要があり、複数のラウンドトリップが必要であるため、ゲットバルク操作であっても、遅延が高くなる可能性があります。転送はシリアル化される可能性があり、結果として生じるレイテンシは、複数の往復時間、可能なタイムアウトと再送信の遅延、およびオーバーヘッドの処理の組み合わせになり、その結果、容認できないパフォーマンスが発生する可能性があります。データが複数の検索の過程で変更される可能性があるため、一貫したスナップショットを取得することは困難です。
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プレフィックスの伝達、および「Get-Bulk Overshootの問題」のために高くなる可能性があります。テーブルの一括転送では、転送されるOIDSは冗長です。列番号までのすべての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 that it is possible to stop at the end of a table.
参考文献[50]で説明されている「Get-Bulk Overshoot問題」は、Get-Bulk PDUを使用するときに発生します。問題は、マネージャーが通常、テーブル内の行の数を知らないことです。その結果、あまりにも多くの行を要求するか、不要なデータを取得するか、少なすぎるため、複数のゲットバルクリクエストが必要になる必要があります。「Get-Bulk Overshoot」の問題は、エージェント側で予防可能になる可能性があることに注意してください。参照[41]は、エージェントが「ローカルの制約」のためにゲットバルクを終了できることを示しています（[41]の15/16ページの項目1と3を参照）。これは、テーブルの端で停止できることを意味すると解釈できます。
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）がインターネットリサーチタスクフォース（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ペイロード圧縮。「Subtree」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]で説明されているように、[48]で説明されているSNMPペイロードの圧縮に記載されている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-subtree PDUの追加が含まれます。サブツリー検索MIB [50]では、SNMPプロトコルまたはSNMPプロトコルエンジンに変更を変更する必要はないため、プロトコルの変更よりも簡単に実装および展開できます。Get-Subtree PDUを追加することは、それをサポートするすべてのSNMPエンティティのプロトコルとエンジンの変更を意味します。SNMPプロトコルを変更せずに「Get-Bulk Overshootの問題」に対処することが可能かもしれないため、この変更の必要性は議論の余地があります。
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 MIBの使用についても説明し、不揮発性ストレージでSNMPデータを保存し、FTPを介したその後のバルク転送を可能にします。このアプローチでは、FTPと同様に追加のMIBモジュールの実装が必要であり、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のKerberosセキュリティモデル（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.
KerberosをSNMPV3で使用するには、各デバイスとドメインのKDCにキーを保存する必要があり、ドメインとデバイス間の会話のセッションキーを動的に生成します。保存されたキーに関しては、KSMアプローチは、デバイスとドメインの合計を備えたスケールです。動的なセッションキーに関しては、ドメインとデバイスの製品として拡大します。
As Kerberos is extended to allow initial authentication via public key, as described in [42], and cross-realm authentication, as described in [43], the KSM inherits these capabilities. As a result, this approach may have potential to reduce or even eliminate the shared secret management problem. However, it should also be noted that certificate-based authentication can strain the limits of UDP packet sizes supported in SNMP implementations, so that alternate transport mappings may be required to support this.
[42]で説明されているように、[43]で説明されているように、KSMがこれらの機能を継承するように、Kerberosは[42]で説明されているように、公開キーを介した初期認証を許可するように拡張されているためです。その結果、このアプローチは、共有された秘密管理の問題を軽減または排除する可能性を秘めている可能性があります。ただし、証明書ベースの認証は、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エンジンが取得できる必要があります。これには、呼び出されたセキュリティサービス、および認証方法や提示されたIDおよび証明書など、他のエンドポイントに関連する情報が含まれます。このような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.
SNMPV3セキュリティの強化を考えると、SNMPベースのドメイン内の会計実装がSNMPV3にアップグレードすることが望ましいです。このようなアップグレードは、ドメイン間アプリケーションに事実上必須です。
In inter-domain accounting, the burden of managing SNMPv3 shared secrets can be reduced via the localized key capability or via implementation of a Proxy Forwarder. In the long term, alternative security models such as the Kerberos Security Model may further reduce the effort required to manage security and enable streamlined inter-domain operation.
ドメイン間会計では、SNMPV3の共有秘密を管理する負担は、ローカライズされたキー機能を介して、またはプロキシ転送業者の実装により減らすことができます。長期的には、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）で議論されている提案を介して対処できます。TCPトランスポートマッピングを介した実験的なSNMPは、遅延を減らすのに役立つ可能性があります。データの量に応じて、何らかの形の圧縮も検討する価値があります。ただし、これらの提案は依然として研究段階にあり、標準の軌跡に載っていないため、これらの機能は容易に利用できず、最終的なフォームに到達する前に仕様はかなり変化する可能性があります。
SNMP supports separation of accounting data by domain, using either of two general approaches with the VACM access control model. The domain as index approach can be used if the desired MIB module supports domain indexing, or it can implemented using an additional table. The domain-context approach can be used in agents which support dynamic logical contexts and a domain-to-context and context-to-instrumentation mapping mechanism. Either approach can be supported using SNMPv1, SNMPv2c, or SNMPv3 messages, by utilizing the snmpCommunitytable [11] to provide a community-to-context mapping.
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 MIBSのデータは、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の会計データをASN.1、バルクバイナリまたはバルクASCII形式に保存し、その後、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.
十分な不揮発性ストレージへのアクセスを考えると、レコード形式と転送プロトコルに基づく会計システムは、長期のネットワークパーティション、サーバーの障害、またはデバイスの再起動によるデータの損失を回避できます。転送をコレクションサイトから駆動することが可能であるため、コレクターは成功するまで転送を再試行することができます。その結果、ファイル転送ベースのシステムは非常に信頼性を高めることができ、会計記録のバッチングにより、オーバーヘッドを軽減した必要なセキュリティサービスの効率的な転送と適用が可能になります。
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のKerberosセキュリティモデル（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、テレフォニーなど、高価値セッションが関係している場合、処理遅延に境界を設定する必要がある場合があります。これは、遅延を減らす必要性を意味します。その結果、TCPトランスポートマッピング、Get-Subtree機能、OID圧縮など、時間のかかる請求アプリケーションでNMRG拡張機能が必要です。このアプリケーションでも高い信頼性が必要であり、アプリケーション層と輸送層の謝辞の必要性を意味します。NMRG拡張機能とセキュリティスケーラビリティの改善により、KSMなどのセキュリティスケーラビリティの改善により、ドメイン内使用の要件を満たすことができます。
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)
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.
著者は、この問題空間の有用な議論について、Bert Wijnen（Lucent）、Keith McCloghrie（Cisco Systems）、Jan Melen（Ericsson）、Jarmo Savolainen（Ericsson）に感謝したいと思います。
[1] Aboba, B., Lu J., Alsop J., Ding J. and W. Wang, "Review of Roaming Implementations", RFC 2194, September 1997.
[1] Aboba、B.、Lu J.、Alsop J.、Ding J.およびW. Wang、「Review of Roaming Informations」、RFC 2194、1997年9月。
[2] Aboba, B. and G. Zorn, "Criteria for Evaluating Roaming Protocols", RFC 2477, January 1999.
[2] Aboba、B。およびG. Zorn、「ローミングプロトコルを評価するための基準」、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.、Rubens、A.、Simpson、W.およびS. Willens、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2138、1997年4月。
[4] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.
[4] Rigney、C。、「Radius Accounting」、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.、Pereira、R。、およびM. Thomas、「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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[7] Information Sciences Institute, "Transmission Control Protocol", RFC 793, September 1981.
[7] Information Sciences Institute、「Transmission Control Protocol」、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.、Greene、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.、Greene、W。、およびA. Prasad、「接続指向ネットワークの会計情報の収集と保存を制御するための管理オブジェクト」、1999年2月、RFC 2513。
[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] Frye、R.、Levi、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.
[13] Elkins、M。、「Pretty Good Privacy（PGP）のMime Security」、RFC 2015、1996年10月。
[14] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 1892, January 1996.
[14] Vaudreuil、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] Galvin、J.、Murphy、S.、Crocker、S。、およびN. Freed、「MIME用のセキュリティマルチパート：マルチパート/署名およびマルチパート/暗号化」、RFC 1847、1995年10月。
[16] Crocker, D., "MIME Encapsulation of EDI Objects", RFC 1767, March 1995.
[16] Crocker、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。and N. Freed、「Mime（多目的インターネットメール拡張）パート1：インターネットメッセージボディの形式を指定および説明するためのメカニズム」、RFC 1521、1993年12月。
[18] Rose, M.T., The Simple Book, Second Edition, Prentice Hall, Upper Saddle River, NJ, 1996.
[18] Rose、M.T.、The Simple Book、Second Edition、Prentice Hall、アッパーサドルリバー、ニュージャージー州、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] Case、J.、Mundy、R.、Partain、D。およびB. Stewart、「インターネット標準ネットワーク管理フレームワークのバージョン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] Johnson、H。T.、Kaplan、R。S.、関連性が失われました：マサチューセッツ州ボストン、ハーバードビジネススクールプレスの管理会計の台頭と下降、1987年。
[22] Horngren, C. T., Foster, G., Cost Accounting: A Managerial Emphasis. Prentice Hall, Englewood Cliffs, New Jersey, 1991.
[22] ホーングレン、C。T。、フォスター、G。、コスト会計：管理上の強調。Prentice Hall、Englewood Cliffs、ニュージャージー、1991年。
[23] Kaplan, R. S., Atkinson, Anthony A., Advanced Management Accounting, Prentice Hall, Englewood Cliffs, New Jersey, 1989.
[23] Kaplan、R。S.、Atkinson、Anthony A.、Advanced Management Accounting、Prentice Hall、Englewood Cliffs、ニュージャージー、1989年。
[24] Cooper, R., Kaplan, R. S., The Design of Cost Management Systems. Prentice Hall, Englewood Cliffs, New Jersey, 1991.
[24] Cooper、R.、Kaplan、R。S.、コスト管理システムの設計。Prentice Hall、Englewood Cliffs、ニュージャージー、1991年。
[25] Rigney, C., Willats, S. and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000.
[25] Rigney、C.、Willats、S。、およびP. Calhoun、「Radius Extensions」、RFC 2869、2000年6月。
[26] Stewart, R., et al., "Simple Control Transmission Protocol", RFC 2960, October 2000.
[26] Stewart、R.、et al。、「Simple Control Transmission Protocol」、RFC 2960、2000年10月。
[27] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999.
[27] Harrington、D.、Presuhn、R。、およびB. Wijnen、「SNMP管理フレームワークを説明するためのアーキテクチャ」、RFC 2571、1999年4月。
[28] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990.
[28] Rose、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] Rose、M。and K. McCloghrie、「Scise MIB Definitions」、STD 16、RFC 1212、1991年3月。
[30] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991.
[30] Rose、M。、「SNMPで使用するトラップを定義するための慣習」、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.、Perkins、D。、およびJ. Schoenwaelder、「管理情報の構造バージョン2（SMIV2）」、STD 58、RFC 2578、1999年4月。
[32] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[32] McCloghrie、K.、Perkins、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.、Perkins、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] Case、J.、Fedor、M.、Schoffstall、M。and J. Davin、「Simple Network Management Protocol」、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] Case、J.、McCloghrie、K.、Rose、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] Case、J.、McCloghrie、K.、Rose、M。、およびS. Waldbusser、「単純なネットワーク管理プロトコル（SNMPV2）のバージョン2の輸送マッピング」、RFC 1906、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] Case、J.、Harrington D.、Presuhn R.およびB. Wijnen、「Simple Network Management Protocol（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] Blumenthal、U.およびB. Wijnen、「シンプルネットワーク管理プロトコル（SNMPV3）のバージョン3のユーザーベースのセキュリティモデル（USM）」、RFC 2574、1999年4月。
[39] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999.
[39] Levi、D.、Meyer、P。and B. Stewart、「SNMPV3 Applications」、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、「シンプルネットワーク管理プロトコル（SNMP）のビューベースのアクセス制御モデル（VACM）」、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] Case、J.、McCloghrie、K.、Rose、M。、およびS. Waldbusser、「単純ネットワーク管理プロトコル（SNMPV2）のバージョン2のプロトコル操作」、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] Tung、B.、Neuman、C.、Hur、M.、Medvinsky、A.、Medvinsky、S.、Wray、J。and J. Trostle、「Kerberosでの初期認証のための公開鍵暗号」、進行中の作業。
[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] Tung、B.、Ryutov、T.、Neuman、C.、Tsudik、G.、Sommerfeld、B.、Medvinsky、A。and M. Hur、「Kerberosのクロスリアム認証のための公開キー暗号」、進行中の作業。
[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] Brownlee、N。およびA. Blount、「会計属性とレコード形式」、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 Transport Mapping」、進行中の作業。
[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] Sprenkels、R.、Martin-Flatin、J。、「MIBデータのバルク転送」、Simple Times、http：//www.simple-times.org/pub/simple-times/issues/7-1.html、3月1999年。
[50] Thaler, D., "Get Subtree Retrieval MIB", Work in Progress.
[50] Thaler、D。、「Subtree検索MIBを取得」、進行中の作業。
[51] Daniele, M., Wijnen, B., Ellison, M. and D. Francisco, "Agent Extensibility (AgentX) Protocol Version 1", RFC 2741, January 2000.
[51] Daniele、M.、Wijnen、B.、Ellison、M。、およびD. Francisco、「Agent Extensibility（AgentX）プロトコルバージョン1」、RFC 2741、2000年1月。
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
バーナード・アボバ・マイクロソフト・コーポレーションワン・マイクロソフト・ウェイ・レドモンド、ワシントン州98052 USA
Phone: +1 425 936 6605
EMail: bernarda@microsoft.com
Jari Arkko Oy LM Ericsson Ab 02420 Jorvas Finland
Jari Arkko Oy LM Ericsson AB 02420 Jorvas Finland
Phone: +358 40 5079256
EMail: Jari.Arkko@ericsson.com
David Harrington Cabletron Systems Inc. P.O.Box 5005 Rochester NH 03867-5005 USA
David Harrington Cabletron Systems Inc. P.O.Box 5005 Rochester NH 03867-5005 USA
Phone: +1 603 337 7357
EMail: 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.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。