Network Working Group B. Aboba
Request for Comments: 2975 Microsoft Corporation
Category: Informational J. Arkko
Ericsson
D. Harrington
Cabletron Systems Inc.
October 2000
Network Working Group B. Aboba
Request for Comments: 2975 Microsoft Corporation
Category: Informational J. Arkko
Ericsson
D. Harrington
Cabletron Systems Inc.
October 2000
Introduction to Accounting Management
会计管理概论
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
The field of Accounting Management is concerned with the collection of resource consumption data for the purposes of capacity and trend analysis, cost allocation, auditing, and billing. This document describes each of these problems, and discusses the issues involved in design of modern accounting systems.
会计管理领域涉及收集资源消耗数据，用于容量和趋势分析、成本分配、审计和计费。本文件描述了这些问题中的每一个，并讨论了现代会计系统设计中涉及的问题。
Since accounting applications do not have uniform security and reliability requirements, it is not possible to devise a single accounting protocol and set of security services that will meet all needs. Thus the goal of accounting management is to provide a set of tools that can be used to meet the requirements of each application. This document describes the currently available tools as well as the state of the art in accounting protocol design. A companion document, RFC 2924, reviews the state of the art in accounting attributes and record formats.
由于会计应用程序没有统一的安全性和可靠性要求，因此不可能设计出满足所有需求的单一会计协议和安全服务集。因此，会计管理的目标是提供一套可用于满足每个应用程序要求的工具。本文档描述了当前可用的工具以及记帐协议设计的最新技术。配套文件RFC 2924回顾了会计属性和记录格式的最新发展。
Table of Contents
目录
1. Introduction 2 1.1 Requirements language 3 1.2 Terminology 3 1.3 Accounting management architecture 5 1.4 Accounting management objectives 7 1.5 Intra-domain and inter-domain accounting 10 1.6 Accounting record production 11 1.7 Requirements summary 13 2. Scaling and reliability 14 2.1 Fault resilience 14 2.2 Resource consumption 23 2.3 Data collection models 26 3. Review of Accounting Protocols 32 3.1 RADIUS 32 3.2 TACACS+ 33 3.3 SNMP 33 4. Review of Accounting Data Transfer 43 4.1 SMTP 44 4.2 Other protocols 44 5. Summary 45 6. Security Considerations 48 7. Acknowledgments 48 8. References 48 9. Authors' Addresses 52 10. Intellectual Property Statement 53 11. Full Copyright Statement 54
1. 导言2 1.1需求语言3 1.2术语3 1.3会计管理架构5 1.4会计管理目标7 1.5域内和域间会计10 1.6会计记录制作11 1.7需求摘要13 2。扩展和可靠性14 2.1故障恢复14 2.2资源消耗23 2.3数据收集模型26 3。审核记帐协议32 3.1 RADIUS 32 3.2 TACACS+33 3.3 SNMP 33 4。审核会计数据传输43 4.1 SMTP 44 4.2其他协议44 5。摘要45 6。安全考虑48 7。致谢48 8。参考文献48 9。作者地址52 10。知识产权声明53 11。完整版权声明54
The field of Accounting Management is concerned with the collection of resource consumption data for the purposes of capacity and trend analysis, cost allocation, auditing, and billing. This document describes each of these problems, and discusses the issues involved in design of modern accounting systems.
会计管理领域涉及收集资源消耗数据，用于容量和趋势分析、成本分配、审计和计费。本文件描述了这些问题中的每一个，并讨论了现代会计系统设计中涉及的问题。
Since accounting applications do not have uniform security and reliability requirements, it is not possible to devise a single accounting protocol and set of security services that will meet all needs. Thus the goal of accounting management is to provide a set of tools that can be used to meet the requirements of each application. This document describes the currently available tools as well as the state of the art in accounting protocol design. A companion document, RFC 2924, reviews the state of the art in accounting attributes and record formats.
由于会计应用程序没有统一的安全性和可靠性要求，因此不可能设计出满足所有需求的单一会计协议和安全服务集。因此，会计管理的目标是提供一套可用于满足每个应用程序要求的工具。本文档描述了当前可用的工具以及记帐协议设计的最新技术。配套文件RFC 2924回顾了会计属性和记录格式的最新发展。
In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [6].
在本文件中，关键词“可能”、“必须”、“不得”、“可选”、“建议”、“应该”和“不应该”的解释如[6]所述。
This document frequently uses the following terms:
本文件经常使用以下术语：
Accounting The collection of resource consumption data for the purposes of capacity and trend analysis, cost allocation, auditing, and billing. Accounting management requires that resource consumption be measured, rated, assigned, and communicated between appropriate parties.
核算为容量和趋势分析、成本分配、审核和计费而收集的资源消耗数据。会计管理要求对资源消耗进行计量、评级、分配，并在相关方之间进行沟通。
Archival accounting In archival accounting, the goal is to collect all accounting data, to reconstruct missing entries as best as possible in the event of data loss, and to archive data for a mandated time period. It is "usual and customary" for these systems to be engineered to be very robust against accounting data loss. This may include provisions for transport layer as well as application layer acknowledgments, use of non-volatile storage, interim accounting capabilities (stored or transmitted over the wire), etc. Legal or financial requirements frequently mandate archival accounting practices, and may often dictate that data be kept confidential, regardless of whether it is to be used for billing purposes or not.
档案会计在档案会计中，目标是收集所有会计数据，在数据丢失的情况下尽可能地重建丢失的分录，并在规定的时间段内归档数据。这些系统的设计“通常和习惯”是非常稳健地防止会计数据丢失。这可能包括传输层和应用层确认的规定、非易失性存储的使用、临时会计功能（通过线路存储或传输）等。法律或财务要求通常要求存档会计实践，并且通常要求数据保密，无论是否用于计费目的。
Rating The act of determining the price to be charged for use of a resource.
确定资源使用价格的行为。
Billing The act of preparing an invoice.
开票准备发票的行为。
Usage sensitive billing A billing process that depends on usage information to prepare an invoice can be said to be usage-sensitive. In contrast, a process that is independent of usage information is said to be non-usage-sensitive.
使用敏感计费依赖于使用信息来准备发票的计费过程可以说是使用敏感的。与此相反，独立于使用信息的流程被称为非使用敏感流程。
Auditing The act of verifying the correctness of a procedure. In order to be able to conduct an audit it is necessary to be able to definitively determine what procedures were actually carried out so as to be able to compare this to
审核验证程序正确性的行为。为了能够进行审计，必须能够确定实际执行的程序，以便能够将其与
the recommended process. Accomplishing this may require security services such as authentication and integrity protection.
建议的过程。实现这一点可能需要安全服务，如身份验证和完整性保护。
Cost Allocation The act of allocating costs between entities. Note that cost allocation and rating are fundamentally different processes. In cost allocation the objective is typically to allocate a known cost among several entities. In rating the objective is to determine the amount to be charged for use of a resource. In cost allocation, the cost per unit of resource may need to be determined; in rating, this is typically a given.
成本分配在实体之间分配成本的行为。请注意，成本分配和评级是根本不同的过程。在成本分配中，目标通常是在多个实体之间分配已知成本。评级的目的是确定资源使用的收费金额。在成本分配中，可能需要确定每单位资源的成本；在评级中，这通常是给定的。
Interim accounting Interim accounting provides a snapshot of usage during a user's session. This may be useful in the event of a device reboot or other network problem that prevents the reception or generation of a session summary packet or session record. Interim accounting records can always be summarized without the loss of information. Note that interim accounting records may be stored internally on the device (such as in non-volatile storage) so as to survive a reboot and thus may not always be transmitted over the wire.
临时记帐临时记帐提供用户会话期间使用情况的快照。这在设备重新启动或其他网络问题阻止接收或生成会话摘要数据包或会话记录时可能有用。中期会计记录总是可以在不丢失信息的情况下进行汇总。请注意，临时会计记录可能存储在设备内部（如非易失性存储器中），以便在重新启动后继续存在，因此可能不会始终通过有线传输。
Session record A session record represents a summary of the resource consumption of a user over the entire session. Accounting gateways creating the session record may do so by processing interim accounting events or accounting events from several devices serving the same user.
会话记录会话记录表示整个会话中用户资源消耗的摘要。创建会话记录的记帐网关可以通过处理临时记帐事件或来自服务于同一用户的多个设备的记帐事件来实现。
Accounting Protocol A protocol used to convey data for accounting purposes.
记帐协议为记帐目的传送数据的协议。
Intra-domain accounting Intra-domain accounting involves the collection of information on resource usage within an administrative domain, for use within that domain. In intra-domain accounting, accounting packets and session records typically do not cross administrative boundaries.
域内核算域内核算涉及收集管理域内资源使用情况的信息，以便在该域内使用。在域内记帐中，记帐数据包和会话记录通常不跨越管理边界。
Inter-domain accounting Inter-domain accounting involves the collection of information on resource usage within an administrative
域间会计域间会计涉及收集管理系统内资源使用情况的信息
domain, for use within another administrative domain. In inter-domain accounting, accounting packets and session records will typically cross administrative boundaries.
域，以便在另一个管理域中使用。在域间记帐中，记帐数据包和会话记录通常会跨越管理边界。
Real-time accounting Real-time accounting involves the processing of information on resource usage within a defined time window. Time constraints are typically imposed in order to limit financial risk.
实时会计实时会计包括在规定的时间窗口内处理有关资源使用情况的信息。时间限制通常是为了限制金融风险。
Accounting server The accounting server receives accounting data from devices and translates it into session records. The accounting server may also take responsibility for the routing of session records to interested parties.
记帐服务器记帐服务器从设备接收记帐数据并将其转换为会话记录。记帐服务器还可以负责将会话记录路由到相关方。
The accounting management architecture involves interactions between network devices, accounting servers, and billing servers. The network device collects resource consumption data in the form of accounting metrics. This information is then transferred to an accounting server. Typically this is accomplished via an accounting protocol, although it is also possible for devices to generate their own session records.
会计管理体系结构涉及网络设备、会计服务器和计费服务器之间的交互。网络设备以记帐度量的形式收集资源消耗数据。然后，此信息被传输到记帐服务器。通常，这是通过记帐协议实现的，尽管设备也可以生成自己的会话记录。
The accounting server then processes the accounting data received from the network device. This processing may include summarization of interim accounting information, elimination of duplicate data, or generation of session records.
然后，记帐服务器处理从网络设备接收的记帐数据。该处理可能包括中期会计信息的汇总、重复数据的消除或会话记录的生成。
The processed accounting data is then submitted to a billing server, which typically handles rating and invoice generation, but may also carry out auditing, cost allocation, trend analysis or capacity planning functions. Session records may be batched and compressed by the accounting server prior to submission to the billing server in order to reduce the volume of accounting data and the bandwidth required to accomplish the transfer.
处理后的会计数据随后提交给计费服务器，该服务器通常处理评级和发票生成，但也可以执行审计、成本分配、趋势分析或容量规划功能。会话记录可以在提交到计费服务器之前由计费服务器进行批处理和压缩，以减少计费数据量和完成传输所需的带宽。
One of the functions of the accounting server is to distinguish between inter and intra-domain accounting events and to route them appropriately. For session records containing a Network Access Identifier (NAI), described in [8], the distinction can be made by examining the domain portion of the NAI. If the domain portion is absent or corresponds to the local domain, then the session record is treated as an intra-domain accounting event. Otherwise, it is treated as an inter-domain accounting event.
记帐服务器的功能之一是区分域间和域内记帐事件，并适当地路由它们。对于[8]中描述的包含网络访问标识符（NAI）的会话记录，可以通过检查NAI的域部分来进行区分。如果域部分不存在或对应于本地域，则会话记录被视为域内记帐事件。否则，它将被视为域间记帐事件。
Intra-domain accounting events are typically routed to the local billing server, while inter-domain accounting events will be routed to accounting servers operating within other administrative domains. While it is not required that session record formats used in inter and intra-domain accounting be the same, this is desirable, since it eliminates translations that would otherwise be required.
域内记帐事件通常路由到本地计费服务器，而域间记帐事件将路由到在其他管理域内运行的记帐服务器。虽然不要求域间和域内记帐中使用的会话记录格式相同，但这是可取的，因为它消除了原本需要的翻译。
Where a proxy forwarder is employed, domain-based access controls may be employed by the proxy forwarder, rather than by the devices themselves. The network device will typically speak an accounting protocol to the proxy forwarder, which may then either convert the accounting packets to session records, or forward the accounting packets to another domain. In either case, domain separation is typically achieved by having the proxy forwarder sort the session records or accounting messages by destination.
在使用代理转发器的情况下，基于域的访问控制可由代理转发器使用，而不是由设备本身使用。网络设备通常将向代理转发器说出记帐协议，代理转发器随后可以将记帐分组转换为会话记录，或者将记帐分组转发到另一个域。在这两种情况下，域分离通常是通过让代理转发器按目的地对会话记录或记帐消息进行排序来实现的。
Where the accounting proxy is not trusted, it may be difficult to verify that the proxy is issuing correct session records based on the accounting messages it receives, since the original accounting messages typically are not forwarded along with the session records. Therefore where trust is an issue, the proxy typically forwards the accounting packets themselves. Assuming that the accounting protocol supports data object security, this allows the end-points to verify that the proxy has not modified the data in transit or snooped on the packet contents.
在不信任记帐代理的情况下，可能很难根据代理接收到的记帐消息验证代理是否发出了正确的会话记录，因为原始记帐消息通常不会与会话记录一起转发。因此，当信任是一个问题时，代理通常自己转发记帐数据包。假设记帐协议支持数据对象安全性，这允许端点验证代理没有修改传输中的数据或窥探数据包内容。
The diagram below illustrates the accounting management architecture:
下图说明了会计管理体系结构：
+------------+
| |
| Network |
| Device |
| |
+------------+
|
Accounting |
Protocol |
|
V
+------------+ +------------+
| | | |
| Org B | Inter-domain session records | Org A |
| Acctg. |<----------------------------->| Acctg. |
|Proxy/Server| or accounting protocol | Server |
| | | |
+------------+ +------------+
| |
| |
Transfer | Intra-domain |
Protocol | Session records |
| |
V V
+------------+ +------------+
| | | |
| Org B | | Org A |
| Billing | | Billing |
| Server | | Server |
| | | |
+------------+ +------------+
+------------+
| |
| 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.
大部分关于会计管理的初始工作都集中在域内会计应用程序上。然而，随着拨号漫游、Internet传真、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.
时间不是需要这种方法的唯一因素。例如，在移动接入网络中，用户可以从一个地方漫游到另一个地方，同时仍然在同一会话中连接。如果漫游导致收费发生变化，则有必要考虑第一和第二区域消耗的资源。另一个例子是允许对正在进行的会话进行修改。例如，可以使用改进的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.
这些示例可以通过使用向量或多维数组来表示单个会话记录中的资源消耗来解决。例如，向量或数组可以描述每个因素组合的资源消耗，例如，一个数据项可以是家庭运营商所在区域在高峰时间的分组数量。然而，这种方法似乎复杂且不灵活，因此，大多数当前系统从一个会话生成一组记录。会话标识符需要存在于记录中，以允许会计系统将记录绑定在一起。
In most cases, the network device will determine when multiple session records are needed, as the local device is aware of factors affecting local tariffs, such as QoS changes and roaming. However, future systems are being designed that enable the home domain to
在大多数情况下，网络设备将确定何时需要多个会话记录，因为本地设备知道影响本地费率的因素，例如QoS更改和漫游。然而，正在设计未来的系统，使主域能够
control the generation of accounting records. This is of importance in inter-domain accounting or when network devices do not have tariff information. The centralized control of accounting record production can be realized, for instance, by having authorization servers require re-authorization at certain times and requiring the production of accounting records upon each re-authorization.
控制会计记录的生成。这在域间计费或网络设备没有资费信息时非常重要。可以实现对会计记录生成的集中控制，例如，授权服务器在特定时间需要重新授权，并且每次重新授权时都需要生成会计记录。
In conclusion, in some cases it is necessary to produce multiple accounting records from a single session. It must be possible to do this without requiring the user to start a new session or to re-authenticate. The production of multiple records can be controlled either by the network device or by the AAA server. The requirements for timeliness, security and reliability in multiple record sessions are the same as for single-record sessions.
总之，在某些情况下，有必要从一个会话生成多个会计记录。必须能够做到这一点，而无需用户启动新会话或重新验证。多个记录的生成可以由网络设备或AAA服务器控制。多个记录会话的及时性、安全性和可靠性要求与单记录会话相同。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Usage | Intra-domain | Inter-domain |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Robustness vs. | Robustness vs. |
| | packet loss | packet loss |
| Capacity | | |
| Planning | Integrity, | Integrity, |
| | authentication, | authentication, |
| | replay protection | replay prot. |
| | [confidentiality] | confidentiality |
| | | [data object sec.]|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Non-usage | Integrity, | Integrity, |
| Sensitive | authentication, | authentication, |
| Billing | replay protection | replay protection |
| | [confidentiality] | confidentiality |
| | | [data object sec.]|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Archival | Archival |
| Usage | accounting | accounting |
| Sensitive | Integrity, | Integrity, |
| Billing, | authentication, | authentication, |
| Cost | replay protection | replay prot. |
| Allocation & | [confidentiality] | confidentiality |
| Auditing | [Bounds on | [data object sec.]|
| | processing delay] | [Bounds on |
| | | processing delay] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Archival | Archival |
| Time | accounting | accounting |
| Sensitive | Integrity, | Integrity, |
| Billing, | authentication, | authentication, |
| fraud | replay protection | replay prot. |
| detection, | [confidentiality] | confidentiality |
| roaming | | [Data object |
| | Bounds on | security and |
| | processing delay | receipt support] |
| | | Bounds on |
| | | processing delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key [] = optional
键[]=可选
With the continuing growth of the Internet, it is important that accounting management systems be scalable and reliable. This section discusses the resources consumed by accounting management systems as well as the scalability and reliability properties exhibited by various data collection and transport models.
随着互联网的不断发展，会计管理系统的可扩展性和可靠性至关重要。本节讨论会计管理系统消耗的资源，以及各种数据收集和传输模型显示的可伸缩性和可靠性特性。
As noted earlier, in applications such as usage-sensitive billing, cost allocation and auditing, an archival approach to accounting is frequently mandated, due to financial and legal requirements. Since in such situations loss of accounting data can translate to revenue loss, there is incentive to engineer a high degree of fault resilience. Faults which may be encountered include:
如前所述，在对使用情况敏感的计费、成本分配和审计等应用中，由于财务和法律要求，经常强制要求采用会计归档方法。由于在这种情况下，会计数据的丢失会转化为收入损失，因此有动机设计高度的故障恢复能力。可能遇到的故障包括：
Packet loss Accounting server failures Network failures Device reboots
丢包计费服务器故障网络故障设备重新启动
To date, much of the debate on accounting reliability has focused on resilience against packet loss and the differences between UDP, SCTP and TCP-based transport. However, it should be understood that resilience against packet loss is only one aspect of meeting archival accounting requirements.
到目前为止，关于计费可靠性的争论主要集中在对数据包丢失的恢复能力以及UDP、SCTP和基于TCP的传输之间的差异上。但是，应该理解，对数据包丢失的恢复能力只是满足归档记帐要求的一个方面。
As noted in [18], "once the cable is cut you don't need more retransmissions, you need a *lot* more voltage." Thus, the choice of transport has no impact on resilience against faults such as network partition, accounting server failures or device reboots. What does provide resilience against these faults is non-volatile storage.
如[18]中所述，“一旦电缆断开，您就不需要更多的重新传输，您需要*更多*的电压。”因此，传输的选择不会影响对故障（如网络分区、计费服务器故障或设备重新启动）的恢复能力。非易失性存储提供了针对这些故障的恢复能力。
The importance of non-volatile storage in design of reliable accounting systems cannot be over-emphasized. Without non-volatile storage, event-driven systems will lose data once the transmission timeout has been exceeded, and batching designs will experience data loss once the internal memory used for accounting data storage has been exceeded. Via use of non-volatile storage, and internally stored interim records, most of these data losses can be avoided.
非易失性存储在设计可靠的会计系统中的重要性怎么强调都不过分。如果没有非易失性存储，一旦超过传输超时，事件驱动系统将丢失数据，而一旦超过用于记帐数据存储的内部内存，批处理设计将经历数据丢失。通过使用非易失性存储和内部存储的临时记录，可以避免大部分数据丢失。
It may even be argued that non-volatile storage is more important to accounting reliability than network connectivity, since for many years reliable accounting systems were implemented based solely on physical storage, without any network connectivity. For example,
甚至可能有人认为，非易失性存储对记帐可靠性比网络连接更重要，因为多年来，可靠的记帐系统仅基于物理存储实现，没有任何网络连接。例如
phone usage data used to be stored on paper, film, or magnetic media and carried from the place of collection to a central location for bill processing.
手机使用数据通常存储在纸张、胶片或磁性介质上，并从收集地点传送到中心位置进行账单处理。
Interim accounting provides protection against loss of session summary data by providing checkpoint information that can be used to reconstruct the session record in the event that the session summary information is lost. This technique may be applied to any data collection model (i.e. event-driven or polling) and is supported in both RADIUS [25] and in TACACS+.
临时记帐通过提供检查点信息来防止会话摘要数据丢失，这些检查点信息可用于在会话摘要信息丢失时重建会话记录。此技术可应用于任何数据采集模型（即事件驱动或轮询），RADIUS[25]和TACACS+均支持此技术。
While interim accounting can provide resilience against packet loss, server failures, short-duration network failures, or device reboot, its applicability is limited. Transmission of interim accounting data over the wire should not be thought of as a mainstream reliability improvement technique since it increases use of network bandwidth in normal operation, while providing benefits only in the event of a fault.
虽然临时记帐可以提供针对数据包丢失、服务器故障、短时网络故障或设备重新启动的恢复能力，但其适用性有限。不应将通过电线传输临时会计数据视为主流可靠性改进技术，因为它增加了正常运行中网络带宽的使用，同时仅在发生故障时提供好处。
Since most packet loss on the Internet is due to congestion, sending interim accounting data over the wire can make the problem worse by increasing bandwidth usage. Therefore on-the-wire interim accounting is best restricted to high-value accounting data such as information on long-lived sessions. To protect against loss of data on such sessions, the interim reporting interval is typically set several standard deviations larger than the average session duration. This ensures that most sessions will not result in generation of interim accounting events and the additional bandwidth consumed by interim accounting will be limited. However, as the interim accounting interval decreases toward the average session time, the additional bandwidth consumed by interim accounting increases markedly, and as a result, the interval must be set with caution.
由于互联网上的大多数数据包丢失都是由于拥塞造成的，因此通过有线发送临时记帐数据会增加带宽使用，从而使问题变得更糟。因此，在线中期会计最好仅限于高价值的会计数据，如关于长期会话的信息。为了防止此类会话上的数据丢失，临时报告间隔通常设置为大于平均会话持续时间的几个标准偏差。这确保了大多数会话不会导致生成临时记帐事件，并且临时记帐所消耗的额外带宽将受到限制。但是，随着临时记帐间隔朝着平均会话时间的方向减小，临时记帐所消耗的额外带宽显著增加，因此，必须谨慎地设置该间隔。
Where non-volatile storage is unavailable, interim accounting can also result in excessive consumption of memory that could be better allocated to storage of session data. As a result, implementors should be careful to ensure that new interim accounting data overwrites previous data rather than accumulating additional interim records in memory, thereby worsening the buffer exhaustion problem.
在非易失性存储不可用的情况下，临时记帐还可能导致过度消耗内存，而这些内存可以更好地分配给会话数据的存储。因此，实现者应该小心确保新的临时记帐数据覆盖以前的数据，而不是在内存中累积额外的临时记录，从而恶化缓冲区耗尽问题。
Given the increasing popularity of non-volatile storage for use in consumer devices such as digital cameras, such devices are rapidly declining in price. This makes it increasingly feasible for network devices to include built-in support for non-volatile storage. This can be accomplished, for example, by support for compact PCMCIA cards.
考虑到非易失性存储器在数码相机等消费类设备中的应用日益普及，此类设备的价格正在迅速下降。这使得网络设备越来越有可能包括对非易失性存储的内置支持。例如，这可以通过支持紧凑型PCMCIA卡来实现。
Where non-volatile storage is available, this can be used to store interim accounting data. Stored interim events are then replaced by updated interim events or by session data when the session completes. The session data can itself be erased once the data has been transmitted and acknowledged at the application layer. This approach avoids interim data being transmitted over the wire except in the case of a device reboot. When a device reboots, internally stored interim records are transferred to the accounting server.
在非易失性存储可用的情况下，这可用于存储临时记帐数据。当会话完成时，存储的临时事件将替换为更新的临时事件或会话数据。一旦在应用层传输和确认了数据，会话数据本身就可以被擦除。这种方法避免了通过导线传输临时数据，除非设备重新启动。设备重新启动时，内部存储的临时记录将传输到记帐服务器。
Generation of multiple accounting records within a session can introduce scalability problems that cannot be controlled using the techniques available in interim accounting.
在一个会话中生成多个记帐记录可能会带来可伸缩性问题，使用临时记帐中可用的技术无法控制这些问题。
For example, in the case of interim records kept in non-volatile storage, it is possible to overwrite previous interim records with the most recent one or summarize them to a session record. Where interim updates are sent over the wire, it is possible to control bandwidth usage by adjusting the interim accounting interval.
例如，对于保存在非易失性存储器中的临时记录，可以用最新的临时记录覆盖以前的临时记录或将其汇总为会话记录。在通过线路发送临时更新的情况下，可以通过调整临时记帐间隔来控制带宽使用。
These measures are not applicable where multiple session records are produced from a single session, since these records cannot be summarized or overwritten without loss of information. As a result, multiple record production can result in increased consumption of bandwidth and memory. Implementors should be careful to ensure that worst-case multiple record processing requirements do not exceed the capabilities of their systems.
这些措施不适用于从单个会话生成多个会话记录的情况，因为在不丢失信息的情况下，无法汇总或覆盖这些记录。因此，多记录生产可能导致带宽和内存消耗增加。实施者应小心确保最坏情况下的多记录处理需求不会超过其系统的能力。
As an example, a tariff change at a particular time of day could, if implemented carelessly, create a sudden peak in the consumption of memory and bandwidth as the records need to be stored and/or transported. Rather than attempting to send all of the records at once, it may be desirable to keep them in non-volatile storage and send all of the related records together in a batch when the session completes. It may also be desirable to shape the accounting traffic flow so as to reduce the peak bandwidth consumption. This can be accomplished by introduction of a randomized delay interval. If the home domain can also control the generation of multiple accounting records, the estimation of the worst-case processing requirements can be very difficult.
例如，如果一天中某个特定时间的电价变化不小心实施，可能会在需要存储和/或传输记录时造成内存和带宽消耗的突然峰值。与其试图一次发送所有记录，不如将它们保存在非易失性存储器中，并在会话完成时批量发送所有相关记录。还可能希望对记帐业务流进行整形，以减少峰值带宽消耗。这可以通过引入随机延迟间隔来实现。如果主域还可以控制多个会计记录的生成，则估计最坏情况下的处理要求可能非常困难。
As packet loss is a fact of life on the Internet, accounting protocols dealing with session data need to be resilient against packet loss. This is particularly important in inter-domain accounting, where packets often pass through Network Access Points
由于数据包丢失是互联网上的一个事实，处理会话数据的计费协议需要具有抗数据包丢失的弹性。这在域间计费中尤其重要，因为数据包通常通过网络接入点
(NAPs) where packet loss may be substantial. Resilience against packet loss can be accomplished via implementation of a retry mechanism on top of UDP, or use of TCP [7] or SCTP [26]. On-the-wire interim accounting provides only limited benefits in mitigating the effects of packet loss.
（NAPs）数据包丢失可能很严重的情况。通过在UDP之上实现重试机制，或者使用TCP[7]或SCTP[26]，可以实现对数据包丢失的恢复能力。在线临时计费在减轻数据包丢失的影响方面仅提供有限的好处。
UDP-based transport is frequently used in accounting applications. However, this is not appropriate in all cases. Where accounting data will not fit within a single UDP packet without fragmentation, use of TCP or SCTP transport may be preferred to use of multiple round-trips in UDP. As noted in [47] and [49], this may be an issue in the retrieval of large tables.
基于UDP的传输经常用于记帐应用程序。然而，这并不适用于所有情况。如果记帐数据不适合单个UDP数据包而没有碎片，则使用TCP或SCTP传输可能比在UDP中使用多个往返更好。如[47]和[49]所述，这可能是检索大型表时的一个问题。
In addition, in cases where congestion is likely, such as in inter-domain accounting, TCP or SCTP congestion control and round-trip time estimation will be very useful, optimizing throughput. In applications which require maintenance of session state, such as simultaneous usage control, TCP and application-layer keep alive packets or SCTP with its built-in heartbeat capabilities provide a mechanism for keeping track of session state.
此外，在可能出现拥塞的情况下，例如在域间计费中，TCP或SCTP拥塞控制和往返时间估计将非常有用，从而优化吞吐量。在需要维护会话状态的应用程序中，例如同步使用控制，TCP和应用层保持活动数据包或具有内置心跳功能的SCTP提供了跟踪会话状态的机制。
When implementing UDP retransmission, there are a number of issues to keep in mind:
在实施UDP重传时，需要记住一些问题：
Data model Retry behavior Congestion control Timeout behavior
数据模型重试行为拥塞控制超时行为
Accounting reliability can be influenced by how the data is modeled. For example, it is almost always preferable to use cumulative variables rather than expressing accounting data in terms of a change from a previous data item. With cumulative data, the current state can be recovered by a successful retrieval, even after many packets have been lost. However, if the data is transmitted as a change then the state will not be recovered until the next cumulative update is sent. Thus, such implementations are much more vulnerable to packet loss, and should be avoided wherever possible.
会计可靠性可能受到数据建模方式的影响。例如，几乎总是最好使用累积变量，而不是根据以前数据项的变化来表示会计数据。使用累积数据，即使在许多数据包丢失后，通过成功检索也可以恢复当前状态。但是，如果数据作为更改传输，则在发送下一次累积更新之前，状态将不会恢复。因此，这样的实现更容易发生数据包丢失，应该尽可能避免。
In designing a UDP retry mechanism, it is important that the retry timers relate to the round-trip time, so that retransmissions will not typically occur within the period in which acknowledgments may be expected to arrive. Accounting bandwidth may be significant in some circumstances, so that the added traffic due to unnecessary retransmissions may increase congestion levels.
在设计UDP重试机制时，重试计时器与往返时间相关非常重要，这样通常不会在预期确认到达的时间段内发生重传。计费带宽在某些情况下可能非常重要，因此由于不必要的重新传输而增加的流量可能会增加拥塞级别。
Congestion control in accounting data transfer is a somewhat controversial issue. Since accounting traffic is often considered mission-critical, it has been argued that congestion control is not a requirement; better to let other less-critical traffic back off in response to congestion. Moreover, without non-volatile storage, congestive back-off in accounting applications can result in data loss due to buffer exhaustion.
计费数据传输中的拥塞控制是一个有争议的问题。由于计算流量通常被认为是关键任务，有人认为拥塞控制不是一项要求；更好的办法是让其他不太重要的流量后退，以应对拥堵。此外，如果没有非易失性存储，记帐应用程序中的拥塞回退可能会由于缓冲区耗尽而导致数据丢失。
However, it can also be argued that in modern accounting implementations, it is possible to implement congestion control while improving throughput and maintaining high reliability. In circumstances where there is sustained packet loss, there simply is not sufficient capacity to maintain existing transmission rates. Thus, aggregate throughput will actually improve if congestive back-off is implemented. This is due to elimination of retransmissions and the ability to utilize techniques such as RED to desynchronize flows. In addition, with QoS mechanisms such as differentiated services, it is possible to mark accounting packets for preferential handling so as to provide for lower packet loss if desired. Thus considerable leeway is available to the network administrator in controlling the treatment of accounting packets and hard coding inelastic behavior is unnecessary. Typically, systems implementing non-volatile storage allow for backlogged accounting data to be placed in non-volatile storage pending transmission, so that buffer exhaustion resulting from congestive back-off need not be a concern.
然而，也可以认为，在现代计费实现中，在提高吞吐量和保持高可靠性的同时实现拥塞控制是可能的。在存在持续数据包丢失的情况下，根本没有足够的容量来维持现有的传输速率。因此，如果实施拥塞退避，则总吞吐量实际上会提高。这是由于消除了重传，并且能够利用诸如RED之类的技术来取消流的同步。此外，利用诸如区分服务之类的QoS机制，可以标记用于优先处理的计费分组，以便在需要时提供较低的分组丢失。因此，网络管理员在控制计费数据包的处理方面有很大的回旋余地，不需要硬编码非弹性行为。通常，实现非易失性存储的系统允许在传输期间将积压的记帐数据放置在非易失性存储中，因此不必担心因拥塞退避而导致的缓冲区耗尽。
Since UDP is not really a transport protocol, UDP-based accounting protocols such as [4] often do not prescribe timeout behavior. Thus implementations may exhibit widely different behavior. For example, one implementation may drop accounting data after three constant duration retries to the same server, while another may implement exponential back-off to a given server, then switch to another server, up to a total timeout interval of twelve hours, while storing the untransmitted data on non-volatile storage. The practical difference between these approaches is substantial; the former approach will not satisfy archival accounting requirements while the latter may. More predictable behavior can be achieved via use of SCTP or TCP transport.
由于UDP并非真正的传输协议，因此基于UDP的记帐协议（如[4]）通常不会规定超时行为。因此，实现可能表现出大不相同的行为。例如，一个实现可能会在对同一服务器进行三次持续时间不变的重试后丢弃记帐数据，而另一个实现可能会对给定的服务器执行指数回退，然后切换到另一个服务器，总超时间隔为12小时，同时将未传输的数据存储在非易失性存储器上。这些方法之间的实际差异很大；前者不能满足档案会计的要求，而后者则可能。通过使用SCTP或TCP传输，可以实现更可预测的行为。
In the event of a failure of the primary accounting server, it is desirable for the device to failover to a secondary server. Providing one or more secondary servers can remove much of the risk of accounting server failure, and as a result use of secondary servers has become commonplace.
在主记帐服务器发生故障的情况下，最好将设备故障切换到辅助服务器。提供一个或多个辅助服务器可以消除记帐服务器故障的大部分风险，因此，辅助服务器的使用已变得司空见惯。
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".
在这种情况下，需要区分传输层确认和应用层确认。即使两个确认可以在同一个数据包内发送（例如，携带应用层确认和背驮式应答的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".
例如，记帐服务器可能从传输层接收数据，但由于后端数据库问题或磁盘故障而无法存储数据。在这种情况下，它不应该发送应用层确认，即使传输层确认是合适的。相反，应该发送一条应用层错误消息，指出问题的根源，例如“后端存储不可用”。
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
记帐代理向设备发送传输层或应用层ACK而不从记帐服务器接收ACK，这会使设备误以为记帐请求已被记帐服务器接受，但事实并非如此。因此，设备可以在记帐服务器接受记帐数据包之前，将其从非易失性存储器中删除。树叶
accounting proxy responsible for delivering accounting packets. If the accounting proxy involves moving parts (e.g. a disk drive) while the devices do not, overall system reliability can be reduced.
负责传递记帐数据包的记帐代理。如果记帐代理涉及移动部件（如磁盘驱动器），而设备不涉及移动部件，则会降低整个系统的可靠性。
Store and forward accounting proxies only add value in situations where the accounting subsystem is unreliable. For example, where devices do not implement non-volatile storage and the accounting protocol lacks transport and application layer reliability, locating the accounting proxy (with its stable storage) close to the device can reduce the risk of data loss.
存储和转发会计代理仅在会计子系统不可靠的情况下增加价值。例如，当设备未实现非易失性存储且记帐协议缺乏传输层和应用层可靠性时，将记帐代理（及其稳定存储）放置在设备附近可以降低数据丢失的风险。
However, such systems are inherently unreliable so that they are only appropriate for use in capacity planning or non-usage sensitive billing applications. If archival accounting reliability is desired, it is necessary to engineer a reliable accounting system from the start using the techniques described in this document, rather than attempting to patch an inherently unreliable system by adding store and forward accounting proxies.
然而，这样的系统本质上是不可靠的，因此它们仅适用于容量规划或非使用敏感计费应用。如果需要档案会计可靠性，则有必要从一开始就使用本文档中描述的技术设计一个可靠的会计系统，而不是试图通过添加存储和转发会计代理来修补固有的不可靠系统。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
| 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 |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
| Fault | Counter-measures |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
| Packet | Retransmission based on RTT |
| loss | Congestion control |
| | Well-defined timeout behavior |
| | Duplicate elimination |
| | Interim accounting* |
| | Non-volatile storage |
| | Cumulative variables |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
| Accounting | Primary-secondary servers |
| server & net | Duplicate elimination |
| failures | Interim accounting* |
| | Application layer ACK & error msgs. |
| | Non-volatile storage |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
| Device | Interim accounting* |
| reboots | Non-volatile storage |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key * = limited usefulness without non-volatile storage
密钥*=没有非易失性存储的有限用途
Note: Accounting proxies are not a reliability enhancement mechanism.
注：会计代理不是一种可靠性增强机制。
In the process of growing to meet the needs of providers and customers, accounting management systems consume a variety of resources, including:
在不断发展以满足提供商和客户需求的过程中，会计管理系统消耗了各种资源，包括：
Network bandwidth Memory Non-volatile storage State on the accounting management system CPU on the management system and managed devices
网络带宽内存会计管理系统CPU上的非易失性存储状态管理系统和受管设备上的
In order to understand the limits to scaling, we examine each of these resources in turn.
为了理解扩展的限制，我们依次检查这些资源。
Accounting management systems consume network bandwidth in transferring accounting data. The network bandwidth consumed is proportional to the amount of data transferred, as well as required network overhead. Since accounting data for a given event may be 100 octets or less, if each event is transferred individually, overhead can represent a considerable proportion of total bandwidth consumption. As a result, it is often desirable to transfer accounting data in batches, enabling network overhead to be spread over a larger payload, and enabling efficient use of compression. As noted in [48], compression can be enabled in the accounting protocol, or can be done at the IP layer as described in [5].
会计管理系统在传输会计数据时消耗网络带宽。所消耗的网络带宽与传输的数据量以及所需的网络开销成正比。由于给定事件的记帐数据可能为100个八位字节或更少，如果每个事件单独传输，开销可能占总带宽消耗的相当大比例。因此，通常希望成批传输记帐数据，使网络开销能够分布在更大的有效负载上，并使压缩得到有效利用。如[48]所述，压缩可以在记帐协议中启用，也可以在IP层进行，如[5]所述。
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
非易失性存储器可用于存储临时或会话记录。与内存利用率一样，需要临时记帐覆盖，以防止过度的存储消耗。请注意，使用ASCII数据表示可以使用高效的文本压缩算法，从而最大限度地减少存储需求。这样的
compression algorithms are only typically applied to session records so as to enable implementation of interim data overwrite.
压缩算法通常只应用于会话记录，以便实现临时数据覆盖。
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 |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
| Resource | Efficiency measures |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
| Network | Batching |
| Bandwidth | Compression |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
| Memory | Compression |
| | Interim accounting overwrite |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
| Non-volatile | Compression |
| Storage | Interim accounting overwrite |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
| System | Per-device state |
| state | |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
| CPU | Hardware assisted |
| requirements | compression/encryption |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Several data collection models are currently in use today for the purposes of accounting data collection. These include:
目前有几种数据收集模型用于会计数据收集。这些措施包括：
Polling model Event-driven model without batching Event-driven model with batching Event-driven polling model
轮询模型不带批处理的事件驱动模型带批处理事件驱动轮询模型的事件驱动模型
In the polling model, an accounting manager will poll devices for accounting information at regular intervals. In order to ensure against loss of data, the polling interval will need to be shorter than the maximum time that accounting data can be stored on the polled device. For devices without non-volatile stage, this is typically determined by available memory; for devices with non-volatile storage the maximum polling interval is determined by the size of non-volatile storage.
在轮询模型中，会计管理器将定期轮询设备以获取会计信息。为了防止数据丢失，轮询间隔需要短于计费数据可存储在轮询设备上的最长时间。对于没有非易失性阶段的设备，这通常由可用内存决定；对于具有非易失性存储的设备，最大轮询间隔由非易失性存储的大小决定。
The polling model results in an accumulation of data within individual devices, and as a result, data is typically transferred to the accounting manager in a batch, resulting in an efficient transfer process. In terms of Accounting Manager state, polling systems scale with the number of managed devices, and system bandwidth usage scales with the amount of data transferred.
轮询模型会导致单个设备内的数据积累，因此，数据通常会批量传输到记帐管理器，从而产生高效的传输过程。就记帐管理器状态而言，轮询系统随受管设备的数量而扩展，系统带宽使用随传输的数据量而扩展。
Without non-volatile storage, the polling model results in loss of accounting data due to device reboots, but not due to packet loss or network failures of sufficiently short duration to be handled within available memory. This is because the Accounting Manager will continue to poll until the data is received. In situations where operational difficulties are encountered, the volume of accounting data will frequently increase so as to make data loss more likely. However, in this case the polling model will detect the problem since attempts to reach the managed devices will fail.
如果没有非易失性存储，轮询模型会由于设备重新启动而导致记帐数据丢失，但不会由于数据包丢失或持续时间足够短的网络故障而导致在可用内存中处理。这是因为会计经理将继续轮询，直到收到数据。在遇到操作困难的情况下，会计数据量会经常增加，从而使数据丢失的可能性更大。但是，在这种情况下，轮询模型将检测到问题，因为尝试访问受管设备将失败。
The polling model scales poorly for implementation of shared use or roaming services, including wireless data, Internet telephony, QoS provisioning or Internet access. This is because in order to retrieve accounting data for users within a given domain, the Accounting Management station would need to periodically poll all devices in all domains, most of which would not contain any relevant data. There are also issues with processing delay, since use of a polling interval also implies an average processing delay of half the polling interval. This may be too high for accounting data that requires low processing delay. Thus the event-driven polling or the pure event-driven approach is more appropriate for usage sensitive billing applications such as shared use or roaming implementations.
轮询模型在实现共享使用或漫游服务（包括无线数据、互联网电话、QoS供应或互联网接入）时伸缩性较差。这是因为为了检索给定域内用户的记帐数据，记帐管理站需要定期轮询所有域中的所有设备，其中大多数设备不包含任何相关数据。处理延迟也存在问题，因为使用轮询间隔也意味着平均处理延迟为轮询间隔的一半。这对于需要低处理延迟的记帐数据来说可能过高。因此，事件驱动轮询或纯事件驱动方法更适合于使用敏感的计费应用程序，如共享使用或漫游实现。
Per-device state is typical of polling-based network management systems, which often also carry out accounting management functions, since network management systems need to keep track of the state of network devices for operational purposes. These systems offer average processing delays equal to half the polling interval.
每设备状态是基于轮询的网络管理系统的典型状态，该系统通常还执行记帐管理功能，因为网络管理系统需要跟踪网络设备的状态以用于操作目的。这些系统提供的平均处理延迟等于轮询间隔的一半。
In the event-driven model, a device will contact the accounting server or manager when it is ready to transfer accounting data. Most event-driven accounting systems, such as those based on RADIUS accounting, described in [4], transfer only one accounting event per packet, which is inefficient.
在事件驱动模型中，当设备准备好传输记帐数据时，它将联系记帐服务器或管理器。大多数事件驱动的记帐系统，例如[4]中描述的基于RADIUS记帐的系统，每个数据包只传输一个记帐事件，这是低效的。
Without non-volatile storage, a pure event-driven model typically stores accounting events that have not yet been delivered only until the timeout interval expires. As a result this model has the smallest memory requirements. Once the timeout interval has expired, the accounting event is lost, even if the device has sufficient buffer space to continue to store it. As a result, the event-driven model is the least reliable, since accounting data loss will occur due to device reboots, sustained packet loss, or network failures of duration greater than the timeout interval. In event-driven protocols without a "keep alive" message, accounting servers cannot assume a device failure should no messages arrive for an extended period. Thus, event-driven accounting systems are typically not useful in monitoring of device health.
如果没有非易失性存储，纯事件驱动模型通常只存储在超时时间间隔到期之前尚未交付的记帐事件。因此，该模型的内存需求最小。超时间隔过期后，即使设备有足够的缓冲区空间继续存储记帐事件，记帐事件也会丢失。因此，事件驱动模型最不可靠，因为记帐数据丢失将由于设备重新启动、持续数据包丢失或持续时间大于超时间隔的网络故障而发生。在没有“保持活动”消息的事件驱动协议中，如果长时间没有消息到达，记帐服务器不能假定设备出现故障。因此，事件驱动的记帐系统在设备健康监控中通常没有用处。
The event-driven model is frequently used in shared use networks and roaming, since this model sends data to the recipient domains without requiring them to poll a large number of devices, most of which have no relevant data. Since the event-driven model typically does not support batching, it permits accounting records to be sent with low processing delay, enabling application of fraud prevention techniques. However, because roaming accounting events are frequently of high value, the poor reliability of this model is an issue. As a result, the event-driven polling model may be more appropriate.
事件驱动模型经常用于共享使用网络和漫游，因为此模型将数据发送到收件人域，而无需他们轮询大量设备，其中大多数设备没有相关数据。由于事件驱动模型通常不支持批处理，因此它允许以较低的处理延迟发送会计记录，从而能够应用欺诈预防技术。然而，由于漫游计费事件经常具有较高的价值，因此该模型的可靠性较差是一个问题。因此，事件驱动的轮询模型可能更合适。
Per-session state is typical of event-driven systems without batching. As a result, the event-driven approach scales poorly. However, event-driven systems offer the lowest processing delay since events are processed immediately and there is no possibility of an event requiring low processing delay being caught behind a batch transfer.
每会话状态是没有批处理的事件驱动系统的典型状态。因此，事件驱动方法的可扩展性较差。但是，事件驱动系统提供最低的处理延迟，因为事件会立即处理，并且不可能在批处理传输之后捕获需要低处理延迟的事件。
In the event-driven model with batching, a device will contact the accounting server or manager when it is ready to transfer accounting data. The device can contact the server when a batch of a given size has been gathered, when data of a certain type is available or after a minimum time period has elapsed. Such systems can transfer more than one accounting event per packet and are thus more efficient.
在具有批处理的事件驱动模型中，设备在准备传输记帐数据时将联系记帐服务器或管理器。当收集到一批给定大小的数据时，当某一类型的数据可用时，或在经过最短时间后，设备可以与服务器联系。这样的系统可以在每个数据包中传输多个记帐事件，因此效率更高。
An event-driven system with batching will store accounting events that have not yet been delivered up to the limits of memory. As a result, accounting data loss will occur due to device reboots, but not due to packet loss or network failures of sufficiently short duration to be handled within available memory. Note that while transfer efficiency will increase with batch size, without non-volatile storage, the potential data loss from a device reboot will also increase.
带有批处理的事件驱动系统将存储尚未传递到内存限制的记帐事件。因此，记帐数据丢失将由于设备重新启动而发生，而不是由于数据包丢失或持续时间足够短的网络故障而发生，以便在可用内存中进行处理。请注意，在没有非易失性存储的情况下，虽然传输效率会随着批处理大小的增加而提高，但设备重新启动导致的潜在数据丢失也会增加。
Where event-driven systems with batching have a keep-alive interval and run over reliable transport, the accounting server can assume that a failure has occurred if no messages are received within the keep-alive interval. Thus, such implementations can be useful in monitoring of device health. When used for this purpose the average time delay prior to failure detection is one half the keep-alive interval.
如果具有批处理的事件驱动系统具有保持活动时间间隔并在可靠传输上运行，则记帐服务器可以假设如果在保持活动时间间隔内未收到任何消息，则发生了故障。因此，这样的实现可用于监测设备健康状况。当用于此目的时，故障检测前的平均时间延迟为保持活动间隔的一半。
Through implementation of a scheduling algorithm, event-driven systems with batching can deliver appropriate service to accounting events that require low processing delay. For example, high-value inter-domain accounting events could be sent immediately, thus enabling use of fraud-prevention techniques, while all other events would be batched. However, there is a possibility that an event requiring low processing delay will be caught behind a batch transfer in progress. Thus the maximum processing delay is proportional to the maximum batch size divided by the link speed.
通过实现调度算法，具有批处理的事件驱动系统可以为需要低处理延迟的记帐事件提供适当的服务。例如，可以立即发送高价值的域间会计事件，从而启用欺诈预防技术，而所有其他事件都将成批处理。但是，在进行中的批处理传输之后，可能会捕获到需要低处理延迟的事件。因此，最大处理延迟与最大批量大小除以链路速度成正比。
Event-driven systems with batching scale with the number of active devices. As a result this approach scales better than the pure event-driven approach, or even the polling approach, and is equivalent in terms of scaling to the event-driven polling approach. However, the event-driven batching approach has lower processing delay than the event-driven polling approach, since delivery of accounting data requires fewer round-trips and events requiring low processing delay can be accommodated if a scheduling algorithm is employed.
事件驱动系统，具有与活动设备数量成比例的批处理。因此，这种方法比纯事件驱动方法，甚至是轮询方法具有更好的扩展性，并且在扩展到事件驱动轮询方法方面是等效的。然而，事件驱动的批处理方法比事件驱动的轮询方法具有更低的处理延迟，因为会计数据的传递需要更少的往返，并且如果采用调度算法，则可以容纳需要低处理延迟的事件。
In the event-driven polling model an accounting manager will poll the device for accounting data only when it receives an event. The accounting client can generate an event when a batch of a given size has been gathered, when data of a certain type is available or after a minimum time period has elapsed. Note that while transfer efficiency will increase with batch size, without non-volatile storage, the potential data loss from a device reboot will also increase.
在事件驱动轮询模型中，记帐管理器仅在收到事件时才会轮询设备以获取记帐数据。当收集到给定大小的批时，当某一类型的数据可用时，或在经过最短时间段后，记帐客户端可以生成事件。请注意，在没有非易失性存储的情况下，虽然传输效率会随着批处理大小的增加而提高，但设备重新启动导致的潜在数据丢失也会增加。
Without non-volatile storage, an event-driven polling model will lose data due to device reboots, but not due to packet loss, or network partitions of short-duration. Unless a minimum delivery interval is set, event-driven polling systems are not useful in monitoring of device health.
如果没有非易失性存储，事件驱动的轮询模型将由于设备重新启动而丢失数据，但不会因为数据包丢失或持续时间短的网络分区而丢失数据。除非设置了最小传递间隔，否则事件驱动的轮询系统在监视设备运行状况方面没有用处。
The event-driven polling model can be suitable for use in roaming since it permits accounting data to be sent to the roaming partners with low processing delay. At the same time non-roaming accounting can be handled via more efficient polling techniques, thereby providing the best of both worlds.
事件驱动的轮询模型适用于漫游，因为它允许以较低的处理延迟将记帐数据发送给漫游伙伴。同时，可以通过更高效的轮询技术处理非漫游记帐，从而实现两全其美。
Where batching can be implemented, the state required in event-driven polling can be reduced to scale with the number of active devices. If portions of the network vary widely in usage, then this state may actually be less than that of the polling approach. Note that processing delay in this approach is higher than in event-driven accounting with batching since at least two round-trips are required to deliver data: one for the event notification, and one for the resulting poll.
在可以实现批处理的情况下，事件驱动轮询中所需的状态可以减少到与活动设备的数量成比例。如果网络的某些部分在使用上差异很大，那么该状态实际上可能比轮询方法的状态小。请注意，这种方法中的处理延迟高于使用批处理的事件驱动记帐中的处理延迟，因为至少需要两次往返来传递数据：一次用于事件通知，另一次用于结果轮询。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Model | Pros | Cons |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Polling | Per-device state | Not robust |
| | Robust against | against device |
| | packet loss | reboot, server |
| | Batch transfers | or network |
| | | failures* |
| | | Polling interval |
| | | determined by |
| | | storage limit |
| | | High processing |
| | | delay |
| | | Unsuitable for |
| | | use in roaming |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event-driven, | Lowest processing | Not robust |
| no batching | delay | against packet |
| | Suitable for | loss, device |
| | use in roaming | reboot, or |
| | | network |
| | | failures* |
| | | Low efficiency |
| | | Per-session state |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event-driven, | Single round-trip | Not robust |
| with batching | latency | against device |
| and | Batch transfers | reboot, network |
| scheduling | Suitable for | failures* |
| | use in roaming | |
| | Per active device | |
| | state | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event-driven | Batch transfers | Not robust |
| polling | Suitable for | against device |
| | use in roaming | reboot, network |
| | Per active device | failures* |
| | state | Two round-trip |
| | | latency |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key * = addressed by non-volatile storage
密钥*=由非易失性存储器寻址
Accounting systems have been successfully implemented using protocols such as RADIUS, TACACS+, and SNMP. This section describes the characteristics of each of these protocols.
已使用RADIUS、TACACS+和SNMP等协议成功实现了计费系统。本节描述了每种协议的特点。
RADIUS accounting, described in [4], was developed as an add-on to the RADIUS authentication protocol, described in [3]. As a result, RADIUS accounting shares the event-driven approach of RADIUS authentication, without support for batching or polling. As a result, RADIUS accounting scales with the number of accounting events instead of the number of devices, and accounting transfers are inefficient.
[4]中描述的RADIUS记帐是作为[3]中描述的RADIUS身份验证协议的附加组件开发的。因此，RADIUS accounting共享RADIUS身份验证的事件驱动方法，而不支持批处理或轮询。因此，RADIUS记帐根据记帐事件的数量而不是设备的数量进行缩放，记帐传输效率低下。
Since RADIUS accounting is based on UDP and timeout and retry parameters are not specified, implementations vary widely in their approach to reliability, with some implementations retrying until delivery or buffer exhaustion, and others losing accounting data after a few retries. Since RADIUS accounting does not provide for application-layer acknowledgments or error messages, a RADIUS Accounting-Response is equivalent to a transport-layer acknowledgment and provides no protection against application layer malfunctions. Due to the lack of reliability, it is not possible to do simultaneous usage control based on RADIUS accounting alone. Typically another device data source is required, such as polling of a session MIB or a command-line session over telnet.
由于RADIUS记帐基于UDP，并且未指定超时和重试参数，因此实现的可靠性方法差异很大，有些实现会一直重试直到传递或缓冲区耗尽，而有些实现会在几次重试后丢失记帐数据。由于RADIUS记帐不提供应用层确认或错误消息，因此RADIUS记帐响应相当于传输层确认，不提供防止应用层故障的保护。由于缺乏可靠性，无法单独基于RADIUS记帐进行同时使用控制。通常需要另一个设备数据源，例如通过telnet轮询会话MIB或命令行会话。
RADIUS accounting implementations are vulnerable to packet loss as well as application layer failures, network failures and device reboots. These deficiencies are magnified in inter-domain accounting as is required in roaming ([1],[2]). On the other hand, the event-driven approach of RADIUS accounting is useful where low processing delay is required, such as credit risk management or fraud detection.
RADIUS计费实施易受数据包丢失、应用层故障、网络故障和设备重新启动的影响。这些缺陷在域间计费中被放大，正如漫游（[1]、[2]）中所要求的那样。另一方面，RADIUS会计的事件驱动方法在需要低处理延迟的情况下非常有用，如信贷风险管理或欺诈检测。
While RADIUS accounting does provide hop-by-hop authentication and integrity protection, and IPSEC can be employed to provide hop-by-hop confidentiality, data object security is not supported, and thus systems based on RADIUS accounting are not capable of being deployed with untrusted proxies, or in situations requiring auditability, as noted in [2].
虽然RADIUS记帐提供逐跳身份验证和完整性保护，并且IPSEC可用于提供逐跳机密性，但不支持数据对象安全性，因此基于RADIUS记帐的系统无法部署不受信任的代理，或在需要可审核性的情况下，如中所述[2].
While RADIUS does not support compression, IP compression, described in [5], can be employed to provide this. While in principle extensible with the definition of new attributes, RADIUS suffers from the very small standard attribute space (256 attributes).
虽然RADIUS不支持压缩，但可以使用[5]中描述的IP压缩来提供此功能。虽然原则上可通过定义新属性进行扩展，但RADIUS的标准属性空间（256个属性）非常小。
TACACS+ offers an accounting model with start, stop, and interim update messages. Since TACACS+ is based on TCP, implementations are typically resilient against packet loss and short-lived network partitions, and TACACS+ scales with the number of devices. Since TACACS+ runs over TCP, it offers support for both transport layer and application layer acknowledgments, and is suitable for simultaneous usage control and handling of accounting events that require moderate though not the lowest processing delay.
TACACS+提供了一个包含开始、停止和临时更新消息的记帐模型。由于TACACS+是基于TCP的，因此实现通常具有抗数据包丢失和短寿命网络分区的能力，并且TACACS+随着设备数量的增加而扩展。由于TACACS+通过TCP运行，因此它提供了对传输层和应用层确认的支持，并且适合于同时使用控制和处理需要中等（但不是最低）处理延迟的记帐事件。
TACACS+ provides for hop-by-hop authentication and integrity protection as well as hop-by-hop confidentiality. Data object security is not supported, and therefore systems based on TACACS+ accounting are not deployable in the presence of untrusted proxies. While TACACS+ does not support compression, IP compression, described in [5], can be employed to provide this.
TACACS+提供逐跳身份验证和完整性保护以及逐跳机密性。不支持数据对象安全性，因此基于TACACS+记帐的系统在存在不受信任的代理时不可部署。虽然TACACS+不支持压缩，但可以使用[5]中描述的IP压缩来提供此功能。
SNMP, described in [19],[27]-[41], has been widely deployed in a wide variety of intra-domain accounting applications, typically using the polling data collection model. Polling allows data to be collected on multiple accounting events simultaneously, resulting in per-device state. Management applications are able to retry requests when a response is not received, providing resiliency against packet loss or even short-lived network partitions. Implementations without non-volatile storage are not robust against device reboots or network failures, but when combined with non-volatile storage they can be made highly reliable.
在[19]、[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具有允许陷阱定向轮询的陷阱，但陷阱未被确认，丢失的陷阱可能导致数据丢失。SMIv2由SNMPv2c和SNMPv3使用，具有作为已确认通知的通知请求。这使得实现更可靠的事件驱动轮询模型或事件驱动批处理模型成为可能。但是，我们不知道目前有任何基于SNMP的计费实现是基于Informs的。
SNMPv1 and SNMPv2c support per-packet authentication and read-only and read-write access profiles, via the community string. This clear-text password approach provides only trivial authentication, and no per-packet integrity checks, replay protection or confidentiality. View-based access control [40] can be supported using the snmpCommunityMIB, defined in [11], and SNMPv1 or SNMPv2c
SNMPv1和SNMPv2c通过社区字符串支持每包身份验证以及只读和读写访问配置文件。这种明文密码方法只提供微不足道的身份验证，并且不提供每个数据包的完整性检查、重播保护或机密性。使用[11]中定义的snmpCommunityMIB和SNMPv1或SNMPv2c可以支持基于视图的访问控制[40]
messages. The updated SNMP architecture [rfc2571] supports per-packet hop-by-hop authentication, integrity and replay protection, confidentiality and access control.
信息。更新的SNMP体系结构[rfc2571]支持逐包逐跳身份验证、完整性和重播保护、机密性和访问控制。
The SNMP User Security Model (USM) [38] uses shared secrets, and when the product of the number of domains and devices is large, such as in inter-domain accounting applications, the number of shared secrets can get out of hand. The localized key capability in USM allows a manager to have one central key, sharing it with many SNMP entities in a localized way while preventing the other entities from getting at each other's data. This can assist in cross-domain security if deployed properly.
SNMP用户安全模型（USM）[38]使用共享机密，当域和设备数量的乘积较大时，例如在域间计费应用程序中，共享机密的数量可能会失控。USM中的本地化密钥功能允许管理器拥有一个中心密钥，以本地化方式与多个SNMP实体共享，同时防止其他实体获取彼此的数据。如果部署得当，这将有助于跨域安全。
SNMPv3 does not support end-to-end data object integrity and confidentiality; SNMP proxy entities decrypt and re-encrypt the data they forward. In the presence of an untrusted proxy entity, this would be inadequate.
SNMPv3不支持端到端数据对象完整性和机密性；SNMP代理实体对它们转发的数据进行解密和重新加密。在存在不受信任的代理实体的情况下，这是不够的。
SNMP uses application-layer acknowledgment to indicate that data has been processed. SNMP Responses to get, get-next, or get-bulk requests return the requested data, or an error code indicating the nature of the error encountered.
SNMP使用应用层确认来指示数据已被处理。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.
有十八个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代理转发器的引擎不会查看消息的PDU内部，除非确定PDU应转发到哪个SNMP引擎或哪个本地SNMP应用程序应处理PDU。SNMP代理转发器不修改varbind值；它不修改varbind列表，只是在SNMP版本之间进行转换；并且它不提供任何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消息包含社区名称；社区名称和源地址可以通过snmpCommunityTable映射到engineID，如[11]所述。
Contexts are used to identify subsets of objects, within the scope of an engine, that are tied to instrumentation. A contextName refers to a particular subset within an engine.
上下文用于标识引擎范围内与检测关联的对象子集。contextName是指引擎中的特定子集。
Contexts are commonly tied to hardware components, to logical entities related to the hardware components, or to logical services. For example, contextNames might include board5, board7, repeater1, repeater2, etc.
上下文通常与硬件组件、与硬件组件相关的逻辑实体或逻辑服务相关联。例如，上下文名称可能包括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模块可以定义为允许管理器将ContextName分配给检测的逻辑子集。
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模块的一个实例。如果每个引擎需要多个MIB模块实例，则必须定义唯一的ContextName（例如repeater1、repeater2）。默认上下文“”用于仅支持MIB模块的单个实例的引擎，并用于MIB模块，其中在引擎中只有该MIB模块的一个实例是有意义的，并且该实例必须易于定位，例如系统MIB或安全MIB。
SNMPv3 messages contain contextNames which are limited to the scope of the contextEngineID in the message. SNMPv1 and SNMPv2c messages contain communities which can be mapped to contextNames within the local engine, or can be mapped to contextNames within other engines via the snmpCommunityTable, described in [11].
SNMPv3消息包含的ContextName仅限于消息中contextEngineID的范围。SNMPv1和SNMPv2c消息包含社区，这些社区可以映射到本地引擎内的ContextName，或者可以通过snmpCommunityTable映射到其他引擎内的ContextName，如[11]所述。
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）中的所有行，而允许Josephine访问子网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).
视图在名称级别（OID）过滤，而不是在值级别过滤，因此不支持基于非索引数据的值定义视图。在此示例中，如果IP地址仅用作数据项而不是索引，则无法利用基于视图的访问控制来实现预期目标（根据子网委派管理责任）。
View-based access control is independent of message version. It can be utilized by entities using SNMPv1, SNMPv2c, or SNMPv3 message formats.
基于视图的访问控制独立于消息版本。使用SNMPv1、SNMPv2c或SNMPv3消息格式的实体可以使用它。
As the number of network devices within the shared use or roaming network grows, the polling model of data collection becomes increasingly impractical since most devices will not carry data relating to the polling organization. As a result, shared-use networks or roaming associations relying on SNMP-based accounting have generally collected data for all organizations and then sorted the resulting session records for delivery to each organization. While functional, this approach will typically result in increased processing delay as the number of organizations and data records grows.
随着共享使用或漫游网络中的网络设备数量的增加，数据收集的轮询模型变得越来越不切实际，因为大多数设备不会携带与轮询组织相关的数据。因此，依赖基于SNMP的计费的共享使用网络或漫游关联通常会收集所有组织的数据，然后对生成的会话记录进行排序，以交付给每个组织。虽然这种方法很实用，但随着组织和数据记录数量的增加，通常会导致处理延迟增加。
This issue can be addressed in SNMP using the event-driven, event-driven polling or event-driven batching approaches. Traps and Informs permit SNMP-enabled devices to notify domains that have
可以使用事件驱动、事件驱动轮询或事件驱动批处理方法在SNMP中解决此问题。陷阱和通知允许启用SNMP的设备通知具有
accounting data awaiting collection. SNMP Applications [39] defines a standard module for managing notifications.
等待收集的会计数据。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中定义。VacMacAccessTable将组和视图配对。对于从bigco组中的用户接收的消息，将仅提供对允许bigco用户查看的数据的访问，如视图家族树中所定义。这需要为访问数据的每个域指定一个或多个单独的VacMgroupName，定义适当的ViewTable，并为每个组配置VacMacAccessTable。
Views filter at the name (OID) level, not at the data (value) level. When using views to filter by domain it is necessary to use the domain as an index. Standard view-based access control is not designed to filter based on the values on non-indexed fields.
视图过滤器位于名称（OID）级别，而不是数据（值）级别。使用视图按域筛选时，必须将域用作索引。标准的基于视图的访问控制设计为不基于非索引字段上的值进行过滤。
For example, a table of session data could be indexed by record number and domain, allowing a view to be defined that could restrict access to bigco data to the administrators of the bigco domain.
例如，会话数据表可以按记录编号和域进行索引，从而允许定义一个视图，该视图可以限制bigco域的管理员访问bigco数据。
An advantage of using domains as an index is that this technique can be used with SNMPv1 and SNMPv2c agents as well as with SNMPv3 agents. A disadvantage is that the MIB modules must be specifically designed for this purpose. Since existing MIB modules rarely use the domain as an index, domain separation cannot be enabled within legacy MIB modules using this technique.
使用域作为索引的一个优点是，该技术可用于SNMPv1和SNMPv2c代理以及SNMPv3代理。一个缺点是MIB模块必须为此目的专门设计。由于现有MIB模块很少使用域作为索引，因此无法在使用此技术的旧MIB模块中启用域分离。
SNMP does support a RowPointer convention that could be used to define a new table, indexed by domain, which holds tuples between the domain and existing rows of data. This would introduce issues of
SNMP确实支持行指针约定，该约定可用于定义按域索引的新表，该表包含域和现有数据行之间的元组。这将带来一些问题
synchronization between tables.
表之间的同步。
ContextNames can be used to differentiate multiple instances of a MIB module within an engine.
ContextName可用于区分引擎中MIB模块的多个实例。
Individual domains, such as bigco.com, could be mapped to logical contexts, such as a bigco context. The agent would need to create and recognize new contexts and to know which instrumentation is associated with the logical context. The agent needs to collect accounting data by domain and make the data accessible via distinct contexts, so that access control can be applied to the context to prevent disclosure of sensitive information to the wrong domain. The VACM access control views are applied relative to the context, so an operation can be permitted or denied a user based on the context which contains the data.
单个域（如bigco.com）可以映射到逻辑上下文（如bigco上下文）。代理将需要创建和识别新的上下文，并知道哪个工具与逻辑上下文关联。代理需要按域收集会计数据，并通过不同的上下文访问数据，以便对上下文应用访问控制，以防止敏感信息泄露到错误的域。VACM访问控制视图是相对于上下文应用的，因此用户可以基于包含数据的上下文来允许或拒绝操作。
Domain separation is handled by using contextName to differentiate multiple virtual tables. For example, if accounting data has been collected on users with the bigco.com and smallco.com domains, then a separate virtual instance of the accounting session record table would exist for each domain, and each domain would have a corresponding contextName. When a get-bulk request is made with a contextName of bigco, then data from the virtual table in the bigco context, i.e. corresponding to the bigco.com domain, would be returned.
域分离是通过使用contextName来区分多个虚拟表来处理的。例如，如果已在具有bigco.com和smallco.com域的用户上收集了记帐数据，则每个域都将存在记帐会话记录表的单独虚拟实例，并且每个域都将具有相应的contextName。当使用bigco的contextName发出get bulk请求时，将返回来自bigco上下文中虚拟表的数据，即对应于bigco.com域的数据。
There are a number of design approaches to creating new contexts and associating the contexts with appropriate instrumentation, most notably a sub-agent approach and a manager-configured MIB approach.
有许多设计方法可以创建新的上下文并将上下文与适当的工具相关联，最显著的是子代理方法和管理器配置的MIB方法。
AgentX [51], which standardizes a registration protocol between sub-agents and master agents to simplify SNMP agent implementation, allows for the creation and recognition of new contextNames when a subagent registers to provide support for a particular MIB subtree range. The sub-agent knows how to support a particular functionality, e.g. instrumentation exposed via a range of MIB objects. Based on values detected in the data, such as source=bigco.com, the sub-agent could determine that a new domain needed to be tracked and create the appropriate context for the collection of the data, plus the appropriate access control entries. The determination could be table-driven, using MIB configuration.
AgentX[51]标准化了子代理和主代理之间的注册协议，以简化SNMP代理的实现，允许在子代理注册以支持特定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
管理者驱动的方法可以使用MIB模块预定义与感兴趣的域相对应的ContextName，并指示应该收集哪些对象，以及如何根据指定的属性区分数据应该应用到哪个域
condition, and what access control rules apply to the context.
条件，以及应用于上下文的访问控制规则。
Either technique could associate existing MIB modules to domain-specific contexts, so domain separation can be applied to MIB modules not specifically designed with domain separation in mind. Legacy agents would not be designed to do this, so they would need to be updated to support inter-domain separation and VACM access control.
这两种技术都可以将现有的MIB模块与特定于域的上下文相关联，因此域分离可以应用于没有专门设计域分离的MIB模块。遗留代理不会设计为这样做，因此它们需要更新以支持域间分离和VACM访问控制。
The use of contextNames for inter-domain separation represents new territory, so careful consideration would be needed in designing the MIB modules and applications to provide domain to context and context to instrumentation mappings, and to ensure that security is not weakened.
使用contextNames进行域间分离是一个新领域，因此在设计MIB模块和应用程序时需要仔细考虑，以提供域到上下文和上下文到检测的映射，并确保安全性不会受到削弱。
There are issues that arise when using SNMP for transfer of bulk data, including issues of latency, network overhead, and table retrieval, as discussed in [49].
使用SNMP传输批量数据时会出现一些问题，包括延迟、网络开销和表检索问题，如[49]中所述。
In accounting applications, management stations often must retrieve large tables. Latency can be high, even with the get-bulk operation, because the response must fit into the largest supported packet size, requiring multiple round-trips. Transfers may be serialized and the resulting latency will be a combination of multiple round-trip times, possible timeout and re-transmission delays and processing overhead, which may result in unacceptable performance. Since data may change during the course of multiple retrievals, it can be difficult to get a consistent snapshot.
在会计应用程序中，管理站通常必须检索大型表。即使使用get bulk操作，延迟也可能很高，因为响应必须适合支持的最大数据包大小，需要多次往返。传输可能被序列化，由此产生的延迟将是多个往返时间、可能的超时和重新传输延迟以及处理开销的组合，这可能导致不可接受的性能。由于数据可能在多次检索过程中发生更改，因此很难获得一致的快照。
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.
对于批量传输，由于缺乏压缩、BER编码效率低下、冗余OID前缀的传输以及“获取批量超调问题”，SNMP网络开销可能会很高。在表的大容量传输中，传输的OID是冗余的：列号之前的所有OID前缀都是相同的，单个表行的所有条目的实例标识符后缀也是相同的。因此，可以通过压缩OID或不使用每个变量传输OID来减少这种冗余。
The "get-bulk overshoot problem", described in reference [50], occurs when using the get-bulk PDU. The problem is that the manager typically does not know the number of rows in the table. As a result, it must either request too many rows, retrieving unneeded data, or too few, resulting in the need for multiple get-bulk requests. Note that the "get-bulk overshoot" problem may be preventable on the agent side. Reference [41] states that an agent can terminate the get-bulk because of "local constraints" (see items 1 and 3 on pages 15/16 of [41]). This could be interpreted to mean
参考文献[50]中描述的“get bulk overshoot问题”发生在使用get bulk PDU时。问题是管理器通常不知道表中的行数。因此，它必须要么请求太多行，检索不需要的数据，要么请求太少，导致需要多个get批量请求。请注意，“获取批量超调”问题在代理端是可以预防的。参考文献[41]指出，由于“局部约束”（参见[41]第15/16页的第1项和第3项），代理可以终止get批量。这可以解释为
that it is possible to stop at the end of a table.
在桌子的尽头停下来是可能的。
To address issues of latency and efficiency, the Network Management Research Group (NMRG) was formed within the Internet Research Task Force (IRTF). Since the NMRG work is research and is not on the standards track, it should be understood that the NMRG proposals may never be standardized, or may change substantially during the standardization process. As a result, these proposals represent works in progress and are not readily available for use.
为了解决延迟和效率问题，互联网研究工作队（IRTF）内部成立了网络管理研究小组（NMRG）。由于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 over TCP传输映射；SNMP有效负载压缩，如[48]所述；以及添加“获取子树”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 over TCP传输映射可能会大大减少表检索的延迟。SNMP over TCP传输映射的延迟减少可能主要表现在轮询、事件驱动轮询和事件驱动批处理模式中。
Payload compression methods include compression of the IP packet, as described in [5] or compression of the SNMP payload, described in [48].
有效负载压缩方法包括[5]中所述的IP数据包压缩或[48]中所述的SNMP有效负载压缩。
Proposed improvements to table retrieval include a subtree retrieval MIB and the addition of a get-subtree PDU. The subtree retrieval MIB [50] requires no changes to the SNMP protocol or SNMP protocol engine, so it can be implemented and deployed more easily than a change to the protocol. The addition of a get-subtree PDU implies changes to the protocol and to the engines of all SNMP entities which would support it. Since it may be possible to address the "get-bulk overshoot problem" without changes to the SNMP protocol, the necessity of this modification is controversial.
建议的表检索改进包括子树检索MIB和添加get子树PDU。子树检索MIB[50]不需要更改SNMP协议或SNMP协议引擎，因此它比更改协议更容易实现和部署。添加get子树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进行批量传输。这种方法需要实现额外的MIB模块和FTP，并且需要单独的安全机制，如IPSEC，以为传输中的数据提供身份验证、重播、完整性保护和机密性。基于文件的传输方法有一个重要的好处——与非易失性存储兼容。
Issues of legacy support exist with the NMRG proposals. Devices which do not implement the new functionality would need to be accommodated. This is especially problematic for proxy forwarders, which may need to act as translators between new and legacy entities. In these situations, the overhead of translation may offset the benefits of the new technologies.
NMRG提案中存在遗留支持问题。需要容纳未实现新功能的设备。这对于代理转发器尤其有问题，因为代理转发器可能需要充当新实体和旧实体之间的转换器。在这些情况下，翻译的开销可能会抵消新技术的好处。
In order to simplify key management and enable use of certificate-based security in SNMPv3, a Kerberos Security Model (KSM) for SNMPv3 has been proposed in [44]. This memo is not on the standards track, and therefore is not yet readily available for use.
为了简化密钥管理并在SNMPv3中使用基于证书的安全性，在[44]中提出了SNMPv3的Kerberos安全模型（KSM）。本备忘录不在标准轨道上，因此尚未随时可用。
Use of Kerberos with SNMPv3 requires storage of a key on the KDC for each device and domain, while dynamically generating a session key for conversations between domains and devices. In terms of stored keys, the KSM approach scales with the sum of devices and domains; in terms of dynamic session keys, it scales as the product of domains and devices.
在SNMPv3中使用Kerberos需要在KDC上为每个设备和域存储密钥，同时为域和设备之间的对话动态生成会话密钥。就存储密钥而言，KSM方法随设备和域的总和而扩展；就动态会话密钥而言，它可以作为域和设备的产品进行扩展。
As Kerberos is extended to allow initial authentication via public key, as described in [42], and cross-realm authentication, as described in [43], the KSM inherits these capabilities. As a result, this approach may have potential to reduce or even eliminate the shared secret management problem. However, it should also be noted that certificate-based authentication can strain the limits of UDP packet sizes supported in SNMP implementations, so that alternate transport mappings may be required to support this.
由于Kerberos被扩展为允许通过公钥进行初始身份验证（如[42]所述），以及跨领域身份验证（如[43]所述），KSM继承了这些功能。因此，这种方法可能有可能减少甚至消除共享秘密管理问题。但是，还应注意，基于证书的身份验证可能会限制SNMP实现中支持的UDP数据包大小限制，因此可能需要备用传输映射来支持这一点。
An IPSEC-based security model for SNMPv3 has been discussed. Implementation of such a security model would require the SNMPv3 engine to be able to retrieve the properties of the IPSEC security association used to protect the SNMPv3 traffic. This would include the security services invoked, as well as information relating to the other endpoint, such as the authentication method and presented identity and certificate. To date such APIs have not been widely implemented, and in addition, most IPSEC implementations only support machine certificates, which may not provide the required granularity of identification. Thus, an IPSEC-based security model for SNMPv3 would probably take several years to come to fruition.
讨论了基于IPSEC的SNMPv3安全模型。实现这种安全模型需要SNMPv3引擎能够检索用于保护SNMPv3流量的IPSEC安全关联的属性。这将包括调用的安全服务，以及与其他端点相关的信息，例如身份验证方法和提供的身份和证书。迄今为止，此类API尚未得到广泛实施，此外，大多数IPSEC实施仅支持机器证书，这可能无法提供所需的标识粒度。因此，基于IPSEC的SNMPv3安全模型可能需要几年才能实现。
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）正在讨论的提案来解决。实验性的SNMP over TCP传输映射可能有助于减少延迟。根据数据量的不同，某些形式的压缩也值得考虑。然而，由于这些建议仍处于研究阶段，且不在标准轨道上，因此这些功能并不容易获得，规范可能在达到最终形式之前发生重大变化。
SNMP supports separation of accounting data by domain, using either of two general approaches with the VACM access control model. The domain as index approach can be used if the desired MIB module supports domain indexing, or it can implemented using an additional table. The domain-context approach can be used in agents which support dynamic logical contexts and a domain-to-context and context-to-instrumentation mapping mechanism. Either approach can be supported using SNMPv1, SNMPv2c, or SNMPv3 messages, by utilizing the snmpCommunitytable [11] to provide a community-to-context mapping.
SNMP支持使用VACM访问控制模型的两种通用方法之一，按域分离记帐数据。如果所需的MIB模块支持域索引，或者可以使用附加表实现，则可以使用域作为索引方法。域上下文方法可用于支持动态逻辑上下文以及域到上下文和上下文到检测映射机制的代理。通过使用SNMPv1、SNMPv2c或SNMPv3消息，通过利用snmpCommunitytable[11]提供社区到上下文的映射，可以支持这两种方法。
In order for session records to be transmitted between accounting servers, a transfer protocol is required. Transfer protocols in use today include SMTP, FTP, and HTTP. For a review of accounting attributes and record formats, see [45].
为了在记帐服务器之间传输会话记录，需要一个传输协议。目前使用的传输协议包括SMTP、FTP和HTTP。有关会计属性和记录格式的审查，请参见[45]。
Reference [49] contains a discussion of alternative encodings for SMI data types, as well as alternative protocols for transmission of accounting data. For example, [49] describes how MIME tags and XML DTDs may be used for encoding of SNMP messages or SMI data types. This enables data from SNMP MIBs to be transported using any protocol that can encapsulate MIME or XML, including SMTP and HTTP.
参考文献[49]讨论了SMI数据类型的替代编码，以及会计数据传输的替代协议。例如，[49]描述了MIME标记和XML DTD如何用于SNMP消息或SMI数据类型的编码。这使来自SNMP MIB的数据能够使用任何可以封装MIME或XML的协议（包括SMTP和HTTP）进行传输。
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.
如果能够访问足够的非易失性存储，基于记录格式和传输协议的记帐系统可以避免由于长时间的网络分区、服务器故障或设备重新启动而导致的数据丢失。由于可以从收集站点驱动传输，因此收集器可以重试传输直到成功，或者使用HTTP甚至可以重新启动部分完成的传输。因此，基于文件传输的系统可以变得高度可靠，而会计记录的批处理使高效传输和应用所需的安全服务成为可能，同时减少了开销。
As noted previously in this document, accounting applications vary in their security and reliability requirements. Some uses such as capacity planning may only require authentication, integrity and replay protection, and modest reliability. Other applications such as inter-domain usage-sensitive billing may require the highest degree of security and reliability, since in these cases the transfer of accounting data will lead directly to the transfer of funds.
如本文件前面所述，会计应用程序的安全性和可靠性要求各不相同。某些用途（如容量规划）可能只需要身份验证、完整性和重播保护以及适度的可靠性。其他应用程序，如域间使用敏感计费，可能需要最高程度的安全性和可靠性，因为在这些情况下，会计数据的转移将直接导致资金的转移。
Since accounting applications do not have uniform security and reliability requirements, it is not possible to devise a single accounting protocol and set of security services that will meet all needs. Rather, the goal of accounting management should be to provide a set of tools that can be used to construct accounting systems meeting the requirements of an individual application. As a result, it is important to analyze a given accounting application to ensure that the methods chosen meet the security and reliability requirements of the application.
由于会计应用程序没有统一的安全性和可靠性要求，因此不可能设计出满足所有需求的单一会计协议和安全服务集。相反，会计管理的目标应该是提供一套工具，用于构建满足单个应用程序要求的会计系统。因此，分析给定的会计应用程序以确保选择的方法满足应用程序的安全性和可靠性要求非常重要。
Based on an analysis of the requirements, it appears that existing deployed protocols are capable of meeting the requirements for intra-domain capacity planning and non-usage sensitive billing. In these applications efficient transfer of bulk data is useful although not critical. Thus, it is possible to use SNMPv3 to satisfy these requirements, without the NMRG extensions. These include TCP transport mapping, sub-tree retrieval, and OID compression.
根据对需求的分析，现有部署的协议似乎能够满足域内容量规划和非使用敏感计费的需求。在这些应用程序中，大容量数据的有效传输是有用的，但并不重要。因此，可以使用SNMPv3来满足这些需求，而无需NMRG扩展。这些包括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).
对于使用敏感的计费以及成本分配和审核应用程序，可靠性要求更高。这里需要传输层可靠性来提供对数据包丢失的鲁棒性，以及应用层确认来提供对记帐服务器故障的鲁棒性。SNMP操作（InforRequest除外）提供应用层确认，NMRG提出的TCP传输映射提供了抗数据包丢失的健壮性。域间操作可以从数据对象安全性（现有协议不提供）以及域间安全模型增强（如KSM）中获益。
Where high-value sessions are involved, such as in roaming, Mobile IP, or telephony, it may be necessary to put bounds on processing delay. This implies the need to reduce latency. As a result, the NMRG extensions are required in time sensitive billing applications, including TCP transport mapping, get-subtree capabilities and OID compression. High reliability is also required in this application, implying the need for application layer as well as transport layer acknowledgments. SNMPv3 with the NMRG extensions and security scalability improvements such as the KSM can satisfy the requirements in intra-domain use.
在涉及高价值会话的情况下，如漫游、移动IP或电话，可能需要对处理延迟进行限制。这意味着需要减少延迟。因此，时间敏感的计费应用程序需要NMRG扩展，包括TCP传输映射、get子树功能和OID压缩。此应用程序还需要高可靠性，这意味着需要应用层和传输层确认。SNMPv3具有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 | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| 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)
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（朗讯）、Keith McCloghrie（思科系统）、Jan Melen（爱立信）和Jarmo Savolainen（爱立信）对这一问题空间的有益讨论。
[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，“漫游实现的回顾”，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 21381997年4月。
[4] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.
[4] 里格尼，C.，“半径会计”，RFC 21391997年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 23931998年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] 信息科学研究所，“传输控制协议”，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 25112999年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，“用于控制面向连接网络会计信息收集和存储的托管对象”，RFC 2513，1999年2月。
[11] Frye, R., Levi, D., Routhier, S. and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Management Framework", RFC 2576, March 2000.
[11] 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.，“具有良好隐私的MIME安全性（PGP）”，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封装”，RFC17671995年3月。
[17] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, December 1993.
[17] Borenstein，N.和N.Freed，“MIME（多用途Internet邮件扩展）第一部分：指定和描述Internet邮件正文格式的机制”，RFC 15211993年12月。
[18] Rose, M.T., The Simple Book, Second Edition, Prentice Hall, Upper Saddle River, NJ, 1996.
[18] Rose，M.T.，简单的书，第二版，普伦蒂斯大厅，上鞍河，新泽西州，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 25701999年4月。
[20] Klyne, G., "Timely Delivery for Facsimile Using Internet Mail", Work in Progress.
[20] Klyne，G.“使用互联网邮件及时发送传真”，正在进行的工作。
[21] Johnson, H. T., Kaplan, R. S., Relevance Lost: The Rise and Fall of Management Accounting, Harvard Business School Press, Boston, Massachusetts, 1987.
[21] 约翰逊，H.T.，卡普兰，R.S.，相关性丧失：管理会计的兴衰，哈佛商学院出版社，马萨诸塞州波士顿，1987年。
[22] Horngren, C. T., Foster, G., Cost Accounting: A Managerial Emphasis. Prentice Hall, Englewood Cliffs, New Jersey, 1991.
[22] 霍恩格伦，C.T.，福斯特，G.，成本会计：管理重点。普伦蒂斯大厅，恩格尔伍德悬崖，新泽西州，1991年。
[23] Kaplan, R. S., Atkinson, Anthony A., Advanced Management Accounting, Prentice Hall, Englewood Cliffs, New Jersey, 1989.
[23] 卡普兰，R.S.，阿特金森，安东尼A.，高级管理会计，普伦蒂斯大厅，恩格尔伍德悬崖，新泽西州，1989年。
[24] Cooper, R., Kaplan, R. S., The Design of Cost Management Systems. Prentice Hall, Englewood Cliffs, New Jersey, 1991.
[24] 库珀，R.，卡普兰，R.S.，成本管理系统的设计。普伦蒂斯大厅，恩格尔伍德悬崖，新泽西州，1991年。
[25] Rigney, C., Willats, S. and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000.
[25] 里格尼，C.，威拉斯，S.和P.卡尔霍恩，“半径延伸”，RFC 28692000年6月。
[26] Stewart, R., et al., "Simple Control Transmission Protocol", RFC 2960, October 2000.
[26] Stewart，R.等人，“简单控制传输协议”，RFC 2960，2000年10月。
[27] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999.
[27] 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.和K.McCloghrie，“简明MIB定义”，STD 16，RFC 1212，1991年3月。
[30] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991.
[30] Rose，M.“定义用于SNMP的陷阱的约定”，RFC1215，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.Schoenwaeld，“管理信息的结构版本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.Schoenwaeld，“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.Schoenwaeld，“SMIv2的一致性声明”，STD 58，RFC 25801999年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.和J.Davin，“简单网络管理协议”，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 19011996年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.，Presohn R.和B.Wijnen，“简单网络管理协议（SNMP）的消息处理和调度”，RFC 2572，1999年4月。
[38] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999.
[38] 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.和B.Stewart，“SNMPv3应用”，RFC2573，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）”，RFC2575，1999年4月。
[41] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
[41] 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.和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.和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 29242000年9月。
[46] Network Management Research Group Web page,
http://www.ibr.cs.tu-bs.de/projects/nmrg/
[46] Network Management Research Group Web page,
http://www.ibr.cs.tu-bs.de/projects/nmrg/
[47] Schoenwaelder, J.,"SNMP-over-TCP Transport Mapping", Work in Progress.
[47] Schoenwaeld，J.，“SNMP over TCP传输映射”，正在进行中。
[48] Schoenwaelder, J., "SNMP Payload Compression", Work in Progress.
[48] Schoenwaeld，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数据的批量传输”，简单时间，http://www.simple-times.org/pub/simple-times/issues/7-1.html，1999年3月。
[50] Thaler, D., "Get Subtree Retrieval MIB", Work in Progress.
[50] Thaler，D.，“获取子树检索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，“代理可扩展性（AgentX）协议版本1”，RFC 27412000年1月。
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
伯纳德·阿博巴微软公司美国华盛顿州雷德蒙微软大道一号，邮编：98052
Phone: +1 425 936 6605
EMail: bernarda@microsoft.com
Phone: +1 425 936 6605
EMail: bernarda@microsoft.com
Jari Arkko Oy LM Ericsson Ab 02420 Jorvas Finland
Jari Arkko Oy LM爱立信Ab 02420 Jorvas芬兰公司
Phone: +358 40 5079256
EMail: Jari.Arkko@ericsson.com
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.美国NH 03867-5005罗彻斯特邮政信箱5005
Phone: +1 603 337 7357
EMail: dbh@cabletron.com
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.
版权所有（C）互联网协会（2000年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。