Network Working Group N. Brownlee
Request for Comments: 2924 The University of Auckland
Category: Informational A. Blount
MetraTech Corp.
September 2000
Network Working Group N. Brownlee
Request for Comments: 2924 The University of Auckland
Category: Informational A. Blount
MetraTech Corp.
September 2000
Accounting Attributes and Record Formats
会计属性和记录格式
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
摘要
This document summarises Internet Engineering Task Force (IETF) and International Telecommunication Union (ITU-T) documents related to Accounting. A classification scheme for the Accounting Attributes in the summarised documents is presented. Exchange formats for Accounting data records are discussed, as are advantages and disadvantages of integrated versus separate record formats and transport protocols. This document discusses service definition independence, extensibility, and versioning. Compound service definition capabilities are described.
本文件总结了互联网工程任务组（IETF）和国际电信联盟（ITU-T）与会计相关的文件。提出了汇总文件中会计属性的分类方案。讨论了会计数据记录的交换格式，以及集成与分离记录格式和传输协议的优缺点。本文档讨论服务定义独立性、可扩展性和版本控制。描述了复合服务定义功能。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology and Notation . . . . . . . . . . . . . . . . . . . 3
3. Architecture Model . . . . . . . . . . . . . . . . . . . . . . 4
4. IETF Documents . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1.1. RADIUS Attributes . . . . . . . . . . . . . . . . . . . . 5
4.2. DIAMETER . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2.1. DIAMETER Attributes . . . . . . . . . . . . . . . . . . . 7
4.3. ROAMOPS . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.4. RTFM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.4.1. RTFM Attributes . . . . . . . . . . . . . . . . . . . . . 9
4.5. ISDN MIB . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.5.1. ISDN Attributes . . . . . . . . . . . . . . . . . . . . . 10
4.6. AToMMIB . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.6.1. AToMMIB Attributes . . . . . . . . . . . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology and Notation . . . . . . . . . . . . . . . . . . . 3
3. Architecture Model . . . . . . . . . . . . . . . . . . . . . . 4
4. IETF Documents . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1.1. RADIUS Attributes . . . . . . . . . . . . . . . . . . . . 5
4.2. DIAMETER . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2.1. DIAMETER Attributes . . . . . . . . . . . . . . . . . . . 7
4.3. ROAMOPS . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.4. RTFM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.4.1. RTFM Attributes . . . . . . . . . . . . . . . . . . . . . 9
4.5. ISDN MIB . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.5.1. ISDN Attributes . . . . . . . . . . . . . . . . . . . . . 10
4.6. AToMMIB . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.6.1. AToMMIB Attributes . . . . . . . . . . . . . . . . . . . . 11
4.7. QoS: RSVP and DIFFSERV . . . . . . . . . . . . . . . . . . . 12
4.7.1. QoS: RSVP and DIFFSERV Attributes . . . . . . . . . . . . 13
5. ITU-T Documents . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Q.825: Call Detail Recording . . . . . . . . . . . . . . . . 13
5.2. Q.825 Attributes . . . . . . . . . . . . . . . . . . . . . . 14
6. Other Documents . . . . . . . . . . . . . . . . . . . . . . . 18
6.1. TIPHON: ETSI TS 101 321 . . . . . . . . . . . . . . . . . . 18
6.2. MSIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7. Accounting File and Record Formats . . . . . . . . . . . . . . 19
7.1. ASN.1 Records . . . . . . . . . . . . . . . . . . . . . . . 19
7.1.1. RTFM and AToMMIB . . . . . . . . . . . . . . . . . . . . . 19
7.1.2. Q.825 . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.2. Binary Records . . . . . . . . . . . . . . . . . . . . . . . 20
7.2.1. RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.2.2. DIAMETER . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.3. Text Records . . . . . . . . . . . . . . . . . . . . . . . . 21
7.3.1. ROAMOPS . . . . . . . . . . . . . . . . . . . . . . . . . 21
8. AAA Requirements . . . . . . . . . . . . . . . . . . . . . . . 22
8.1. A Well-defined Set of Attributes . . . . . . . . . . . . . . 22
8.2. A Simple Interchange Format . . . . . . . . . . . . . . . . 23
9. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Record Format vs. Protocol . . . . . . . . . . . . . . . . . 24
9.2. Tagged, Typed Data . . . . . . . . . . . . . . . . . . . . . 24
9.2.1. Standard Type Definitions . . . . . . . . . . . . . . . . 25
9.3. Transaction Identifiers . . . . . . . . . . . . . . . . . . 26
9.4. Service Definitions . . . . . . . . . . . . . . . . . . . . 26
9.4.1. Service Independence . . . . . . . . . . . . . . . . . . . 27
9.4.2. Versioned Service Definitions . . . . . . . . . . . . . . 29
9.4.3. Relationships Among Usage Events . . . . . . . . . . . . . 29
9.4.4. Service Namespace Management . . . . . . . . . . . . . . . 30
10. Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . 30
11. Security Considerations . . . . . . . . . . . . . . . . . . . 31
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 35
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . 36
4.7. QoS: RSVP and DIFFSERV . . . . . . . . . . . . . . . . . . . 12
4.7.1. QoS: RSVP and DIFFSERV Attributes . . . . . . . . . . . . 13
5. ITU-T Documents . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Q.825: Call Detail Recording . . . . . . . . . . . . . . . . 13
5.2. Q.825 Attributes . . . . . . . . . . . . . . . . . . . . . . 14
6. Other Documents . . . . . . . . . . . . . . . . . . . . . . . 18
6.1. TIPHON: ETSI TS 101 321 . . . . . . . . . . . . . . . . . . 18
6.2. MSIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7. Accounting File and Record Formats . . . . . . . . . . . . . . 19
7.1. ASN.1 Records . . . . . . . . . . . . . . . . . . . . . . . 19
7.1.1. RTFM and AToMMIB . . . . . . . . . . . . . . . . . . . . . 19
7.1.2. Q.825 . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.2. Binary Records . . . . . . . . . . . . . . . . . . . . . . . 20
7.2.1. RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.2.2. DIAMETER . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.3. Text Records . . . . . . . . . . . . . . . . . . . . . . . . 21
7.3.1. ROAMOPS . . . . . . . . . . . . . . . . . . . . . . . . . 21
8. AAA Requirements . . . . . . . . . . . . . . . . . . . . . . . 22
8.1. A Well-defined Set of Attributes . . . . . . . . . . . . . . 22
8.2. A Simple Interchange Format . . . . . . . . . . . . . . . . 23
9. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Record Format vs. Protocol . . . . . . . . . . . . . . . . . 24
9.2. Tagged, Typed Data . . . . . . . . . . . . . . . . . . . . . 24
9.2.1. Standard Type Definitions . . . . . . . . . . . . . . . . 25
9.3. Transaction Identifiers . . . . . . . . . . . . . . . . . . 26
9.4. Service Definitions . . . . . . . . . . . . . . . . . . . . 26
9.4.1. Service Independence . . . . . . . . . . . . . . . . . . . 27
9.4.2. Versioned Service Definitions . . . . . . . . . . . . . . 29
9.4.3. Relationships Among Usage Events . . . . . . . . . . . . . 29
9.4.4. Service Namespace Management . . . . . . . . . . . . . . . 30
10. Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . 30
11. Security Considerations . . . . . . . . . . . . . . . . . . . 31
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 35
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . 36
This document summarises IETF and ITU-T documents related to Accounting. For those documents which describe Accounting Attributes (i.e. quantities which can be measured and reported), an Attribute Summary is given. Although several of the documents describe Attributes which are similar, no attempt is made to identify those which are the same in several documents. An extensible classification scheme for AAA Accounting Attributes is proposed; it is a superset of the attributes in all the documents summarised.
本文件总结了与会计相关的IETF和ITU-T文件。对于描述会计属性（即可计量和报告的数量）的文件，给出了属性摘要。虽然有几个文档描述了相似的属性，但没有尝试识别几个文档中相同的属性。提出了一种可扩展的AAA会计属性分类方案；它是总结的所有文档中属性的超集。
Many existing accounting record formats and protocols [RAD-ACT] [TIPHON] are of limited use due to their single-service descriptive facilities and lack of extensibility. While some record formats and protocols support extensible attributes [RAD-ACT], none provide identification, type checking, or versioning support for defined groupings of attributes (service definitions). This document makes a case for well-defined services.
许多现有的会计记录格式和协议[RAD-ACT][TIPHON]由于其单一的服务描述功能和缺乏可扩展性而使用有限。虽然一些记录格式和协议支持可扩展属性[RAD-ACT]，但没有一种为已定义的属性分组（服务定义）提供标识、类型检查或版本控制支持。本文档为定义良好的服务提供了一个案例。
Advantages and disadvantages of integrated versus separate record formats and transport protocols are discussed. This document discusses service definition independence, extensibility, and versioning. Compound service definition capabilities are described.
讨论了集成与分离记录格式和传输协议的优缺点。本文档讨论服务定义独立性、可扩展性和版本控制。描述了复合服务定义功能。
The following terms are used throughout the document.
本文件中使用了以下术语。
Accounting Server A network element that accepts Usage Events from Service Elements. It acts as an interface to back-end rating, billing, and operations support systems.
记帐服务器从服务元素接受使用事件的网络元素。它充当后端评级、计费和操作支持系统的接口。
Attribute-Value Pair (AVP) A representation for a Usage Attribute consisting of the name of the Attribute and a value.
属性-值对（AVP）由属性名称和值组成的使用属性的表示形式。
Property A component of a Usage Event. A Usage Event describing a phone call, for instance, might have a "duration" Property.
属性是使用情况事件的组件。例如，描述电话呼叫的使用事件可能具有“duration”属性。
Service A type of task that is performed by a Service Element for a Service Consumer.
服务由服务元素为服务使用者执行的任务类型。
Service Consumer Client of a Service Element. End-user of a network service.
服务元素的服务使用者客户端。网络服务的最终用户。
Service Definition A specification for a particular service. It is composed of a name or other identifier, versioning information, and a collection of Properties.
服务定义特定服务的规范。它由名称或其他标识符、版本控制信息和属性集合组成。
Service Element A network element that provides a service to Service Consumers. Examples include RAS devices, voice and fax gateways, conference bridges.
服务元素向服务使用者提供服务的网络元素。示例包括RAS设备、语音和传真网关、会议网桥。
Usage Attribute A component of a Usage Event that describes some metric of service usage.
使用情况属性使用情况事件的组件，用于描述服务使用情况的某些度量。
Usage Event The description of an instance of service usage.
Usage Event服务使用实例的描述。
Service Elements provide Services to Service Consumers. Before, while, and/or after services are provided, the Service Element reports Usage Events to an Accounting Server. Alternately, the Accounting Server may query the Service Element for Usage Events. Usage events are sent singly or in bulk.
服务元素向服务使用者提供服务。在提供服务之前、期间和/或之后，服务元素向记帐服务器报告使用事件。或者，记帐服务器可以查询服务元素中的使用事件。使用情况事件单独或批量发送。
+------------+ +-----------+ +------------+
| Service |<----->| Service | Usage Events | Accounting |
| Consumer | +-->| Element |------------->| Server |
+------------+ | +-----------+ +------------+
|
+------------+ |
| Service |<--+
| Consumer |
+------------+
+------------+ +-----------+ +------------+
| Service |<----->| Service | Usage Events | Accounting |
| Consumer | +-->| Element |------------->| Server |
+------------+ | +-----------+ +------------+
|
+------------+ |
| Service |<--+
| Consumer |
+------------+
Accounting Servers may forward Usage Events to other systems, possibly in other administrative domains. These transfers are not addressed by this document.
记帐服务器可能会将使用事件转发到其他系统，可能是在其他管理域中。本文件不涉及这些转让。
In March 1999 there were at least 19 Internet Drafts and 8 RFCs concerned with Accounting. These are summarised (by working group) in the following sections.
1999年3月，至少有19份互联网草案和8份涉及会计的RFC。以下各节（由工作组）对其进行了总结。
The RADIUS protocol [RAD-PROT] carries authentication, authorization and configuration information between a Network Access Server (NAS) and an authentication server. Requests and responses carried by the protocol are expressed in terms of RADIUS attributes such as User-Name, Service-Type, and so on. These attributes provide the information needed by a RADIUS server to authenticate users and to establish authorized network service for them.
RADIUS协议[RAD-PROT]在网络访问服务器（NAS）和身份验证服务器之间承载身份验证、授权和配置信息。协议承载的请求和响应以RADIUS属性（如用户名、服务类型等）表示。这些属性提供RADIUS服务器验证用户身份和为用户建立授权网络服务所需的信息。
The protocol was extended to carry accounting information between a NAS and a shared accounting server. This was achieved by defining a set of RADIUS accounting attributes [RAD-ACT].
该协议扩展为在NAS和共享记帐服务器之间传输记帐信息。这是通过定义一组RADIUS记帐属性[RAD-ACT]实现的。
RADIUS packets have a short header containing the RADIUS packet type and authenticator (sixteen octets) and length, followed by a sequence of (Type, Length, Value) triples, one for each attribute.
RADIUS数据包有一个包含RADIUS数据包类型、验证器（十六个八位组）和长度的短报头，后面是一系列（类型、长度、值）三元组，每个属性一个。
RADIUS is very widely used, and a number of significant new extensions to it have been proposed. For example [RAD-EXT] discusses extensions to implement the Extensible Authentication Protocol (EAP) and the Apple Remote Access Protocol (ARAP). [RAD-TACC] discusses extensions to permit RADIUS to interwork effectively with tunnels using protocols such as PPTP and L2TP.
RADIUS的应用非常广泛，已经提出了许多重要的新扩展。例如，[RAD-EXT]讨论了实现可扩展身份验证协议（EAP）和苹果远程访问协议（ARAP）的扩展。[RAD-TACC]讨论了允许RADIUS使用PPTP和L2TP等协议与隧道有效互通的扩展。
Each RADIUS attribute is identified by an 8-bit number, referred to as the RADIUS Type field. Up-to-date values of this field are specified in the most recent Assigned Numbers RFC [ASG-NBR], but the current list is as follows:
每个半径属性由一个8位数字标识，称为半径类型字段。此字段的最新值在最近的分配编号RFC[ASG-NBR]中指定，但当前列表如下：
RADIUS Attributes [RAD-PROT] 36 Login-LAT-Group 37 Framed-AppleTalk-Link 1 User-Name 38 Framed-AppleTalk-Network 2 User-Password 39 Framed-AppleTalk-Zone 3 CHAP-Password 4 NAS-IP-Address 60 CHAP-Challenge 5 NAS-Port 61 NAS-Port-Type 6 Service-Type 62 Port-Limit 7 Framed-Protocol 63 Login-LAT-Port 8 Framed-IP-Address 9 Framed-IP-Netmask RADIUS Accounting Attributes 10 Framed-Routing [RAD-ACT] 11 Filter-Id 12 Framed-MTU 40 Acct-Status-Type 13 Framed-Compression 41 Acct-Delay-Time 14 Login-IP-Host 42 Acct-Input-Octets 15 Login-Service 43 Acct-Output-Octets 16 Login-TCP-Port 44 Acct-Session-Id 17 (unassigned) 45 Acct-Authentic 18 Reply-Message 46 Acct-Session-Time 19 Callback-Number 47 Acct-Input-Packets 20 Callback-Id 48 Acct-Output-Packets 21 (unassigned) 49 Acct-Terminate-Cause 22 Framed-Route 50 Acct-Multi-Session-Id 23 Framed-IPX-Network 51 Acct-Link-Count 24 State 25 Class RADIUS Extension Attributes 26 Vendor-Specific [RAD-EXT] 27 Session-Timeout 28 Idle-Timeout 52 Acct-Input-Gigawords
半径属性[RAD-PROT]36登录LAT组37框架AppleTalk链路1用户名38框架AppleTalk网络2用户密码39框架AppleTalk区域3 CHAP密码4 NAS IP地址60 CHAP挑战5 NAS端口61 NAS端口类型6服务类型62端口限制7框架协议63登录LAT端口8框架IP地址9框架IP网络掩码半径记帐属性10帧路由[RAD-ACT]11筛选器Id 12帧MTU 40帐户状态类型13帧压缩41帐户延迟时间14登录IP主机42帐户输入八位字节15登录服务43帐户输出八位字节16登录TCP端口44帐户会话Id 17（未分配）45 Acct Authentic 18回复消息46 Acct会话时间19回拨号码47 Acct输入数据包20回拨Id 48 Acct输出数据包21（未分配）49 Acct终止原因22帧路由50 Acct多会话Id 23帧IPX网络51 Acct链路计数24状态25类半径扩展属性26特定于供应商的[RAD-EXT]27会话超时28空闲超时52帐户输入千兆字
29 Termination-Action 53 Acct-Output-Gigawords 30 Called-Station-Id 54 Unused 31 Calling-Station-Id 55 Event-Timestamp 32 NAS-Identifier 33 Proxy-State 70 ARAP-Password 34 Login-LAT-Service 71 ARAP-Features 35 Login-LAT-Node 72 ARAP-Zone-Access 73 ARAP-Security 74 ARAP-Security-Data 75 Password-Retry 76 Prompt 77 Connect-Info 78 Configuration-Token 79 EAP-Message 80 Message-Authenticator
29终止操作53帐户输出Gigawords 30被叫站Id 54未使用31主叫站Id 55事件时间戳32 NAS标识符33代理状态70 ARAP密码34登录LAT服务71 ARAP功能35登录LAT节点72 ARAP区域访问73 ARAP安全74 ARAP安全数据75密码重试76提示77连接信息78配置令牌79 EAP消息80消息验证器
84 ARAP-Challenge-Response 85 Acct-Interim-Interval 87 NAS-Port-Id 88 Framed-Pool
84 ARAP质询响应85帐户临时间隔87 NAS端口Id 88帧池
RADIUS Tunneling Attributes [RAD-TACC]
半径隧道属性[RAD-TACC]
64 Tunnel-Type 65 Tunnel-Medium-Type 66 Tunnel-Client-Endpoint 67 Tunnel-Server-Endpoint 68 Acct-Tunnel-Connection 69 Tunnel-Password
64隧道类型65隧道介质类型66隧道客户端终结点67隧道服务器终结点68帐户隧道连接69隧道密码
81 Tunnel-Private-Group-ID 82 Tunnel-Assignment-ID 83 Tunnel-Preference
81隧道专用组ID 82隧道分配ID 83隧道首选项
90 Tunnel-Client-Auth-ID 91 Tunnel-Server-Auth-ID
90隧道客户端身份验证ID 91隧道服务器身份验证ID
The DIAMETER framework [DIAM-FRAM] defines a policy protocol used by clients to perform Policy, AAA and Resource Control. This allows a single server to handle policies for many services. The DIAMETER protocol consists of a header followed by objects. Each object is encapsulated in a header known as an Attribute-Value Pair (AVP).
DIAMETER框架[DIAM-FRAM]定义了一个策略协议，客户端使用该协议执行策略、AAA和资源控制。这允许单个服务器处理多个服务的策略。DIAMETER协议由一个标题和一个对象组成。每个对象封装在称为属性值对（AVP）的头中。
DIAMETER defines a base protocol that specifies the header formats, security extensions and requirements as well as a small number of mandatory commands and AVPs. A new service can extend DIAMETER by extending the base protocol to support new functionality.
DIAMETER定义了一个基本协议，该协议指定了头格式、安全扩展和要求以及少量强制命令和AVP。通过扩展基本协议以支持新功能，新服务可以扩展DIAMETER。
One key differentiator with DIAMETER is its inherent support for Inter-Server communication. Although this can be achieved in a variety of ways, the most useful feature is the ability to "proxy" messages across a set of DIAMETER servers (known as a proxy chain).
DIAMETER的一个关键区别在于其对服务器间通信的固有支持。尽管这可以通过多种方式实现，但最有用的功能是能够跨一组DIAMETER服务器（称为代理链）“代理”消息。
The DIAMETER Accounting Extension document [DIAM-ACT] extends DIAMETER by defining a protocol for securely transferring accounting records over the DIAMETER base protocol. This includes the case where accounting records may be passed through one or more intermediate proxies, in accordance with the 'referral broker' model.
DIAMETER Accounting Extension document[DIAM-ACT]通过定义一个协议来扩展DIAMETER，该协议用于通过DIAMETER基本协议安全地传输记帐记录。这包括根据“转介经纪人”模式，会计记录可能通过一个或多个中间代理传递的情况。
The DIAMETER accounting protocol [DIAM-ACT] defines DIAMETER records for transferring an ADIF record (see below). It introduces five new attributes (480..485) which specify the way in which accounting information is to be delivered between DIAMETER servers.
DIAMETER accounting protocol[DIAM-ACT]定义了用于传输ADIF记录的DIAMETER记录（见下文）。它引入了五个新属性（480..485），用于指定在DIAMETER服务器之间传递会计信息的方式。
DIAMETER AVPs are identified by a 16-bit number defined in [DIAM-AUTH]. Since most of the AVPs found in that document were copied from the RADIUS protocol [RAD-PROT], it is possible to have both RADIUS and DIAMETER servers read the same dictionary and users files.
直径AVP由[DIAM-AUTH]中定义的16位数字标识。由于该文档中发现的大多数AVP都是从RADIUS协议[RAD-PROT]复制的，因此可以让RADIUS和DIAMETER服务器读取相同的字典和用户文件。
The backward compatibility that DIAMETER offers is intended to facilitate deployment. To this end, DIAMETER inherits the RADIUS attributes, and adds only a few of its own.
DIAMETER提供的向后兼容性旨在促进部署。为此，DIAMETER继承了RADIUS属性，并且只添加了它自己的一些属性。
In the list below attribute numbers which are used for RADIUS attributes but not for DIAMETER are indicated with a star (*). RADIUS attributes used by DIAMETER are not listed again here.
在下面的列表中，用于半径属性但不用于直径的属性号用星号（*）表示。此处不再列出直径使用的半径属性。
The DIAMETER attributes are:
直径属性包括：
4 (unassigned, *) 17 (unassigned) 21 (unassigned) 24 (unassigned, *) 25 (unassigned, *) 27 (unassigned, *) 32 (unassigned, *) 33 (unassigned, *) 280 Filter-Rule 281 Framed-Password-Policy
4（未分配，*）17（未分配）21（未分配）24（未分配，*）25（未分配，*）27（未分配，*）32（未分配，*）33（未分配，*）280筛选规则281框架密码策略
480 Accounting-Record-Type 481 ADIF-Record 482 Accounting-Interim-Interval 483 Accounting-Delivery-Max-Batch 484 Accounting-Delivery-Max-Delay 485 Accounting-Record-Number
480会计记录类型481 ADIF记录482会计中期间隔483会计交付最大批次484会计交付最大延迟485会计记录编号
600 SIP-Sequence 601 SIP-Call-ID 602 SIP-To 603 SIP-From
600 SIP序列601 SIP呼叫ID 602 SIP到603 SIP来自
[ROAM-IMPL] reviews the design and functionality of existing roaming implementations. "Roaming capability" may be loosely defined as the ability to use any one of multiple Internet service providers (ISPs), while maintaining a formal customer-vendor relationship with only one. One requirement for successful roaming is the provision of effective accounting.
[ROAM-IMPL]审查现有漫游实施的设计和功能。“漫游能力”可以粗略地定义为能够使用多个互联网服务提供商（ISP）中的任何一个，同时只与一个ISP保持正式的客户-供应商关系。成功漫游的一个要求是提供有效的记帐。
[ROAM-ADIF] proposes a standard accounting record format, the Accounting Data Interchange Format (ADIF), which is designed to compactly represent accounting data in a protocol-independent manner. As a result, ADIF may be used to represent accounting data from any protocol using attribute value pairs (AVPs) or variable bindings.
[ROAM-ADIF]提出了一种标准会计记录格式，即会计数据交换格式（ADIF），该格式旨在以协议无关的方式紧凑地表示会计数据。因此，ADIF可用于使用属性值对（AVP）或变量绑定表示来自任何协议的记帐数据。
ADIF does not define accounting attributes of its own. Instead, it gives examples of accounting records using the RADIUS accounting attributes.
ADIF不定义其自身的会计属性。相反，它给出了使用RADIUS会计属性的会计记录示例。
The RTFM Architecture [RTFM-ARC] provides a general method of measuring network traffic flows between "metered traffic groups". Each RTFM flow has a set of "address" attributes, which define the traffic groups at each of the flow's end-points.
RTFM体系结构[RTFM-ARC]提供了测量“计量流量组”之间网络流量的通用方法。每个RTFM流都有一组“地址”属性，这些属性定义了流的每个端点处的流量组。
As well as address attributes, each flow has traffic-related attributes, e.g. times of first and last packets, counts for packets and bytes in each direction.
除了地址属性外，每个流还具有与流量相关的属性，例如第一个和最后一个数据包的时间、数据包计数以及每个方向上的字节数。
RTFM flow measurements are made by RTFM meters [RTFM-MIB] and collected by RTFM meter readers using SNMP. The MIB uses a "DataPackage" convention, which specifies the attribute values to be read from a flow table row. The meter returns the values for each
RTFM流量测量由RTFM流量计[RTFM-MIB]进行，并由RTFM流量计读取器使用SNMP进行采集。MIB使用“数据包”约定，该约定指定要从流表行读取的属性值。仪表会返回每个仪表的值
required attribute within a BER-encoded sequence. This means there is only one object identifier for the whole sequence, greatly reducing the number of bytes required to retrieve the data.
BER编码序列中的必需属性。这意味着整个序列只有一个对象标识符，大大减少了检索数据所需的字节数。
RTFM attributes are identified by a 16-bit attribute number.
RTFM属性由16位属性号标识。
The RTFM Attributes are:
RTFM属性包括：
0 Null 1 Flow Subscript Integer Flow table info
0空1流下标整数流表信息
4 Source Interface Integer Source Address 5 Source Adjacent Type Integer 6 Source Adjacent Address String 7 Source Adjacent Mask String 8 Source Peer Type Integer 9 Source Peer Address String 10 Source Peer Mask String 11 Source Trans Type Integer 12 Source Trans Address String 13 Source Trans Mask String
4源接口整数源地址5源相邻类型整数6源相邻地址字符串7源相邻掩码字符串8源对等类型整数9源对等地址字符串10源对等掩码字符串11源传输类型整数12源传输地址字符串13源传输掩码字符串
14 Destination Interface Integer Destination Address 15 Destination Adjacent Type Integer 16 Destination Adjacent Address String 17 Destination AdjacentMask String 18 Destination PeerType Integer 19 Destination PeerAddress String 20 Destination PeerMask String 21 Destination TransType Integer 22 Destination TransAddress String 23 Destination TransMask String
14目的地接口整数目的地地址15目的地相邻类型整数16目的地相邻地址字符串17目的地相邻掩码字符串18目的地对等类型整数19目的地对等地址字符串20目的地对等掩码字符串21目的地转换类型整数22目的地转置地址字符串23目的地跨任务字符串
26 Rule Set Number Integer Meter attribute
26规则集数字整数米属性
27 Forward Bytes Integer Source-to-Dest counters 28 Forward Packets Integer 29 Reverse Bytes Integer Dest-to-Source counters 30 Reverse Packets Integer 31 First Time Timestamp Activity times 32 Last Active Time Timestamp 33 Source Subscriber ID String Session attributes 34 Destination Subscriber ID String 35 Session ID String
27转发字节整数源到目标计数器28转发数据包整数29反向字节整数目标到源计数器30反向数据包整数31第一次时间戳活动次数32上次活动时间戳33源订户ID字符串会话属性34目标订户ID字符串35会话ID字符串
36 Source Class Integer "Computed" attributes 37 Destination Class Integer 38 Flow Class Integer 39 Source Kind Integer 40 Destination Kind Integer 41 Flow Kind Integer
36源类整数“计算”属性37目标类整数38流类整数39源类整数40目标类整数41流类整数
50 MatchingStoD Integer PME variable
50匹配TOD整数PME变量
51 v1 Integer Meter Variables 52 v2 Integer 53 v3 Integer 54 v4 Integer 55 v5 Integer
51 v1整数仪表变量52 v2整数53 v3整数54 v4整数55 v5整数
65-127 "Extended" attributes (to be defined by the RTFM working group)
65-127“扩展”属性（由RTFM工作组定义）
The ISDN MIB [ISDN-MIB] defines a minimal set of managed objects for SNMP-based management of ISDN terminal interfaces. It does not explicitly define anything related to accounting, however it does define isdnBearerChargedUnits as
ISDN MIB[ISDN-MIB]定义了一组最小的受管对象，用于基于SNMP的ISDN终端接口管理。它没有明确定义任何与会计相关的内容，但是它将ISDNBarerChargedInits定义为
The number of charged units for the current or last connection. For incoming calls or if charging information is not supplied by the switch, the value of this object is zero.
当前或上次连接的充电单元数。对于传入呼叫或交换机未提供计费信息，此对象的值为零。
This allows for an ISDN switch to convert its traffic flow data (such as Call Connect Time) into charging data.
这允许ISDN交换机将其业务流数据（如呼叫连接时间）转换为计费数据。
The relevant object in the MIB is the ISDN bearer table, which has entries in the following form:
MIB中的相关对象是ISDN承载表，它具有以下形式的条目：
IsdnBearerEntry ::=
SEQUENCE {
isdnBearerChannelType INTEGER,
isdnBearerOperStatus INTEGER,
isdnBearerChannelNumber INTEGER,
isdnBearerPeerAddress DisplayString,
isdnBearerPeerSubAddress DisplayString,
isdnBearerCallOrigin INTEGER,
isdnBearerInfoType INTEGER,
isdnBearerMultirate TruthValue,
isdnBearerCallSetupTime TimeStamp,
IsdnBearerEntry ::=
SEQUENCE {
isdnBearerChannelType INTEGER,
isdnBearerOperStatus INTEGER,
isdnBearerChannelNumber INTEGER,
isdnBearerPeerAddress DisplayString,
isdnBearerPeerSubAddress DisplayString,
isdnBearerCallOrigin INTEGER,
isdnBearerInfoType INTEGER,
isdnBearerMultirate TruthValue,
isdnBearerCallSetupTime TimeStamp,
isdnBearerCallConnectTime TimeStamp, isdnBearerChargedUnits Gauge32 }
IsDNBarerCallConnectTime时间戳，IsDNBarerChargeDunits量表32}
The "ATM Accounting Information MIB" document [ATM-ACT] describes a large set of accounting objects for ATM connections. An administrator may select objects from this set using a selector of the form (subtree, list) where "subtree" specifies an object identifier from the AToMMIB. For each subtree there is a table holding values for each ATM connection. The required connections are indicated by setting bits in "list", which is an octet string. For example, the set containing the number of received cells for the first eight ATM connections would be selected by (atmAcctngReceivedCells, 0xFF).
“ATM记帐信息MIB”文档[ATM-ACT]描述了ATM连接的大量记帐对象。管理员可以使用形式（子树，列表）的选择器从该集中选择对象，其中“子树”从AToMMIB中指定对象标识符。对于每个子树，都有一个表，其中包含每个ATM连接的值。所需的连接通过在“列表”中设置位来表示，该列表是一个八位字节字符串。例如，包含前八个ATM连接的接收信元数的集合将由（ATMACTNGReceivedCells，0xFF）选择。
The Connection-Oriented Accounting MIB document [ATM-COLL] defines a MIB providing managed objects used for controlling the collection and storage of accounting information for connection-oriented networks such as ATM. The accounting data is collected into files for later retrieval via a file transfer protocol. Records within an accounting file are stored as BER strings [ASN1, BER].
面向连接的记帐MIB文档[ATM-COLL]定义了一个MIB，该MIB提供用于控制面向连接的网络（如ATM）记帐信息的收集和存储的托管对象。会计数据被收集到文件中，以便以后通过文件传输协议检索。会计文件中的记录存储为BER字符串[ASN1，BER]。
Accounting data objects within the AToMMBIB are identified by the last integer in their object identifiers.
AToMMBIB中的记帐数据对象由其对象标识符中的最后一个整数标识。
The ATM accounting data objects are:
ATM记帐数据对象是：
1 atmAcctngConnectionType 2 atmAcctngCastType 3 atmAcctngIfName 4 atmAcctngIfAlias 5 atmAcctngVpi 6 atmAcctngVci 7 atmAcctngCallingParty 8 atmAcctngCalledParty 9 atmAcctngCallReference 10 atmAcctngStartTime 11 atmAcctngCollectionTime 12 atmAcctngCollectMode 13 atmAcctngReleaseCause 14 atmAcctngServiceCategory 15 atmAcctngTransmittedCells 16 atmAcctngTransmittedClp0Cells 17 atmAcctngReceivedCells
1 ATMACTNGCONNECTIONTYPE 2 ATMACTNGCASTTYPE 3 ATMACTNGIFNAME 4 ATMACTNGIFALIAS 5 ATMACTNGVPI 6 ATMACTNGVCI 7 ATMACTNGCALLING第8方ATMACTNGCALL 9 ATMACTNGCALL参考10 ATMACTNGSTARTTIME 11 ATMACTNGCollectionTime 12 ATMACTNGCollectionMode 13 ATMACTNGRELEASE 14 ATMACTNGServiceCategory 15 ATMACTNGTransmittedCells 16ATMACTNGTransmittedDLP0cells 17 ATMACTNGReceivedcells
18 atmAcctngReceivedClp0Cells 19 atmAcctngTransmitTrafficDescriptorType 20 atmAcctngTransmitTrafficDescriptorParam1 21 atmAcctngTransmitTrafficDescriptorParam2 22 atmAcctngTransmitTrafficDescriptorParam3 23 atmAcctngTransmitTrafficDescriptorParam4 24 atmAcctngTransmitTrafficDescriptorParam5 25 atmAcctngReceiveTrafficDescriptorType 26 atmAcctngReceiveTrafficDescriptorParam1 27 atmAcctngReceiveTrafficDescriptorParam2 28 atmAcctngReceiveTrafficDescriptorParam3 29 atmAcctngReceiveTrafficDescriptorParam4 30 atmAcctngReceiveTrafficDescriptorParam5 31 atmAcctngCallingPartySubAddress 32 atmAcctngCalledPartySubAddress 33 atmAcctngRecordCrc16
18 ATMACTNGReceivedCLP0cells 19 ATMACTNGTransmittTrafficDescriptor类型20 ATMACTNGTransmittTrafficDescriptor参数21 ATMACTNGTransmittTrafficDescriptor参数22 ATMACTNGTransmittTrafficDescriptor参数23 ATMACTNGTransmittTrafficDescriptor参数24 ATMACTNGTransmittTrafficDescriptor参数25 ATMACTNGReceiveTrafficDescriptor类型26ATMACTNGReceiveTrafficDescriptor参数27 ATMACTNGReceiveTrafficDescriptor参数28 ATMACTNGReceiveTrafficDescriptor参数29 ATMACTNGReceiveTrafficDescriptor参数30 ATMACTNGReceiveTrafficDescriptor参数31 ATMACTNGCallingPartySubaddress 32 ATMACTNGPartySubaddress 33 ATMACTNGRecordCRC16
As we move towards providing more than simple "best effort" connectivity, there has been a tremendous surge of interest in (and work on) protocols to provide managed Quality of Service for Internet sessions. This is of particular interest for the provision of "Integrated Services", i.e. the transport of audio, video, real-time, and classical data traffic within a single network infrastructure.
随着我们朝着提供不仅仅是简单的“尽力而为”的连接的方向发展，人们对为Internet会话提供托管服务质量的协议产生了极大的兴趣（并致力于此）。这对于提供“综合服务”尤其重要，即在单一网络基础设施内传输音频、视频、实时和经典数据流量。
Two approaches to this have emerged so far:
迄今为止出现了两种方法：
- the Integrated Services architecture (intserv) [IIS-ARC], with its accompanying signaling protocol, RSVP [RSVP-ARC], and RSVP's Common Open Policy Service protocol, COPS [RAP-COPS]
- 综合服务体系结构（intserv）[IIS-ARC]及其附带的信令协议RSVP[RSVP-ARC]和RSVP的公共开放策略服务协议COPS[RAP-COPS]
- the Differentiated Services architecture (diffserv) [DSRV-ARC]
- 区分服务体系结构（diffserv）[DSRV-ARC]
RSVP is a signaling protocol that applications may use to request resources from the network. The network responds by explicitly admitting or rejecting RSVP requests. Certain applications that have quantifiable resource requirements express these requirements using intserv parameters [IIS-SPEC].
RSVP是一种信令协议，应用程序可以使用它从网络请求资源。网络通过明确承认或拒绝RSVP请求进行响应。某些具有可量化资源需求的应用程序使用intserv参数[IIS-SPEC]表达这些需求。
Diffserv networks classify packets into one of a small number of aggregated flows or "classes", based on the diffserv codepoint (DSCP) in the packet's IP header. At each diffserv router, packets are subjected to a "per-hop behavior" (PHB), which is invoked by the DSCP. Since RSVP is purely a requirements signalling protocol it can also be used to request connections from a diffserv network [RS-DS-OP].
Diffserv网络根据数据包IP报头中的Diffserv代码点（DSCP）将数据包分类为少量聚合流或“类”之一。在每个diffserv路由器上，数据包都受到“每跳行为”（PHB）的约束，该行为由DSCP调用。由于RSVP纯粹是一种需求信令协议，因此它也可用于从diffserv网络[RS-DS-OP]请求连接。
A set of parameters for specifying a requested Quality of Service are given in [IIS-SPEC]. These have been turned into accounting attributes within RTFM [RTFM-NEWA] and within the RSVP MIB [RSVP-MIB].
[IIS-SPEC]中给出了一组用于指定请求的服务质量的参数。这些已转换为RTFM[RTFM-NEWA]和RSVP MIB[RSVP-MIB]中的记帐属性。
The RTFM QoS attributes are:
RTFM QoS属性包括：
98 QoSService 99 QoSStyle 100 QoSRate 101 QoSSlackTerm 102 QoSTokenBucketRate 103 QoSTokenBucketSize 104 QoSPeakDataRate 105 QoSMinPolicedUnit 106 QoSMaxPolicedUnit
98 Qoservice 99 QoSStyle 100 QoSRate 101 Qoslackterm 102 QoSTokenBucketRate 103 QoSTokenBucketSize 104 QoSPeakDataRate 105 Qosimpolicedunit 106 QosmpolicedUnit
The RSVP MIB contains a large number of objects, arranged within the following sections:
RSVP MIB包含大量对象，这些对象排列在以下部分中：
General Objects Session Statistics Table Session Sender Table Reservation Requests Received Table Reservation Requests Forwarded Table RSVP Interface Attributes Table RSVP Neighbor Table
常规对象会话统计表会话发送方表保留请求接收表保留请求转发表RSVP接口属性表RSVP邻居表
The Session tables contain information such as the numbers of senders and receivers for each session, while the Reservation Requests tables contain details of requests handled by the RSVP router. There are too many objects to list here, but many of them could be used for accounting. In particular, RSVP Requests contain the specification of the service parameters requested by a user; these, together with the actual usage data for the connection make up an accounting record for that usage.
会话表包含每个会话的发送者和接收者的数量等信息，而保留请求表包含RSVP路由器处理的请求的详细信息。此处列出的对象太多，但其中许多可用于记帐。具体地，RSVP请求包含用户请求的服务参数的规范；这些数据与连接的实际使用数据一起构成该使用情况的记帐记录。
ITU-T Recommendation Q.825 specifies how CDRs (Call Detail Records) are produced and managed in Network Elements for POTS, ISDN and IN (Intelligent Networks).
ITU-T建议Q.825规定了如何在POTS、ISDN和in（智能网络）的网元中生成和管理CDR（呼叫详细记录）。
Uses of Call Detail information for various purposes are discussed.
讨论了呼叫详细信息在各种用途中的使用。
Each call produces one or more records describing events that occurred during the life of a call. Data may be produced in real time (single CDRs), near real-time (blocks of CDRs), or as batch files of CDRs.
每个调用生成一个或多个记录，描述在调用生命周期内发生的事件。数据可以实时（单个CDR）、近实时（CDR块）或作为CDR的批处理文件生成。
The information model for Call Detail Recording is formally described in terms of an Entity-Relationship model, and an object model specified in terms of GDMO templates (Guidelines for the Definition of Managed Objects). Note that this model includes the ways in which CDRs are transported from the (NE) Network Element where they are generated to the OS (Operations System) where they are used.
调用详细信息记录的信息模型以实体关系模型的形式描述，对象模型以GDMO模板（托管对象定义指南）的形式指定。请注意，此模型包括将CDR从生成CDR的（NE）网元传输到使用CDR的OS（操作系统）的方式。
The following attributes are defined. The explanations given are very brief summaries only, see [Q-825] for the complete text.
定义了以下属性。给出的解释只是非常简短的总结，完整的文本见[Q-825]。
1 accessDelivery Indicates that the call was delivered to the called subscriber
1 accessDelivery表示呼叫已传递给被叫用户
2 accountCodeInput Account code (for billing), supplied by subscriber.
2账户代码输入账户代码（用于计费），由订户提供。
78 additionalParticipantInfo (No details given)
78其他参与者信息（未提供详细信息）
5 b-PartyCategory Subscriber category for called subscriber.
5被叫用户的b-PartyCategory用户类别。
4 bearerService Bearer capability information (only for ISDN calls).
4承载服务承载能力信息（仅适用于ISDN呼叫）。
13 cDRPurpose Reason for triggering this Call Data Record.
13.触发此通话数据记录的原因。
70 callDetailDataId Unique identifier for the CallDetailData object.
70 callDetailDataId CallDetailData对象的唯一标识符。
79 callDuration Duration of call
79通话时长通话时长
6 callIdentificationNumber Identification number for call; all records produced for this call have the same callIdenfificationNumber.
6呼叫识别号码呼叫识别号码；为此呼叫生成的所有记录都具有相同的CalledFificationNumber。
73 callStatus Identifies whether the call was answered or not.
73 callStatus标识呼叫是否已应答。
9 calledPartyNumber Telephone number of the called subscriber (may be a "diverted-to" or "translated" number.
9被叫用户的被叫方号码（可以是“转接到”或“翻译”的号码）。
7 callingPartyCategory Calling subscriber category.
7呼叫方类别呼叫用户类别。
8 callingPartyNumber Telephone number of the calling party.
8呼叫方号码呼叫方的电话号码。
10 callingPartyNumberNotScreened An additional, user-provided (not screened) number to the calling party.
10 CallingPartyNumber未屏蔽用户向主叫方提供的额外（未屏蔽）号码。
11 callingPartyType Calling subscriber type.
11呼叫方类型呼叫用户类型。
74 carrierId Carrier ID to which the call is sent.
74将呼叫发送到的carrierId运营商ID。
12 cause Cause and location value for the termination of the call.
12呼叫终止的原因和位置值。
14 chargedDirectoryNumber Charged directory number (where the charged participant element can't indicate the number).
14 chargedDirectoryNumber收费目录号（其中收费的参与者元素不能指示该号码）。
16 chargedParticipant Participant to be charged for the usage.
16收费参与方将对使用收费。
15 chargingInformation Charging information generated by a Network Element which is capable of charging.
15计费信息由能够计费的网元生成的计费信息。
17 configurationMask Time consumption, e.g. from B-answer to termination time, between partial call records, etc.
17配置掩码时间消耗，例如从B应答到终止时间、部分通话记录之间的时间消耗等。
18 conversationTime Time consumption from B-answer to end of call.
18会话时间从B应答到通话结束的时间消耗。
19 creationTriggerList List of trigger values which will create Call Detail data objects.
19 CreationRiggerList将创建调用细节数据对象的触发器值列表。
75 dPC Destination point code (for analysis purposes).
75 dPC目标点代码（用于分析目的）。
20 dataValidity Indicates that the NE is having problems, contents of the generated Call Detail record is not reliable.
20 dataValidity表示网元有问题，生成的呼叫详细记录内容不可靠。
23 durationTimeACM Time consumption from seizure until received ACM.
23持续时间ACM从扣押到收到ACM的时间消耗。
21 durationTimeB-Answer Time consumption from seizure until B-answer.
21持续时间B回答从发作到B回答的时间消耗。
22 durationTimeNoB-Answer Time from seizure to termination when no B-answer was received.
22 durationTimeNoB在未收到B-应答时从发作到终止的应答时间。
25 exchangeInfo Identity of exchange where Call Detail record was generated.
25生成呼叫详细记录的exchange的exchangeInfo标识。
26 fallbackBearerService Fallback bearer capability information for a call.
26呼叫的FallbackBearService回退承载能力信息。
27 glare Indicates if a glare condition was encountered.
27眩光指示是否遇到眩光条件。
31 iNServiceInformationList Contains information about the use of IN (Intelligent Network) services.
31 iNServiceInformationList包含有关使用IN（智能网络）服务的信息。
32 iNSpecificInformation Contains information about the use of one IN service.
32 iNSpecificInformation包含有关使用一台在用设备的信息。
33 iSUPPreferred Indicate whether an ISUP preference was requested.
33 iSupplied表示是否请求iSupplied首选项。
28 immediateNotificationForUsageMetering Indicates that the Call Detail records requires immediate data transfer to the Operations System.
28 immediateNotificationForUsageMetering表示呼叫详细信息记录需要立即向操作系统传输数据。
34 maxBlockSize Maximum number of Call Detail records in a block.
34 maxBlockSize块中调用详细信息记录的最大数量。
35 maxTimeInterval Maximum latency allowable for near-real-time Call Detail data delivery.
35 maxTimeInterval近实时呼叫详细信息数据传递允许的最大延迟。
36 networkManagementControls Indicates which Traffic Management Control has affected the call.
36 networkManagementControls指示影响呼叫的流量管理控制。
37 networkProviderId Indicates the Network Provider for whom the CDR is generated.
37 networkProviderId表示为其生成CDR的网络提供商。
76 oPC Originating point code for a failed call (for analysis purposes).
76失败呼叫的oPC起始点代码（用于分析目的）。
38 operatorSpecific1AdditionalNumber 40 operatorSpecific2AdditionalNumber 42 operatorSpecific3AdditionalNumber Operator-defined additional participant information.
38操作员规格1附加编号40操作员规格2附加编号42操作员规格3附加编号操作员定义的附加参与者信息。
39 operatorSpecific1Number 41 operatorSpecific2Number 43 operatorSpecific3Number Operator-defined participant information.
39操作员指定编号41操作员指定编号43操作员指定编号操作员定义的参与者信息。
44 originalCalledNumber Telephone number of the original called party.
44原被叫方的原被叫电话号码。
45 partialGeneration Included if the CDR (Call Detail record) output is partial. Such CDRs have a field indicating their partial record number.
45如果CDR（呼叫详细记录）输出是部分的，则包括部分生成。此类CDR有一个字段，指示其部分记录编号。
77 participantInfo (No details given).
77参与者信息（未提供详细信息）。
46 percentageToBeBilled Percentage to be billed when normal billing rules are not to be followed.
46%当不遵守正常计费规则时，要计费的待计费百分比。
47 periodicTrigger Defines the intervals at which the CDR file should be created.
47 periodicTrigger定义了创建CDR文件的时间间隔。
48 personalUserId Internationally unique personal User Identity (for UPT calls).
48 personalUserId国际唯一的个人用户标识（用于UPT呼叫）。
49 physicalLineCode Identifies the call subscriber's physical line.
49 PhysicalCallineCode标识呼叫用户的物理线路。
50 progress Describes an event which occurred during the life of a call.
50 progress描述在通话期间发生的事件。
51 queueInfo Used to record usage of queueing resources with IN calls.
51 queueInfo用于记录使用IN调用的排队资源的使用情况。
52 receivedDigits The digits dialed by the subscriber. (Normally only included for customer care purposes).
52 Received数字用户拨打的数字。（通常仅用于客户护理目的）。
53 recordExtensions Information elements added by network operators and/or manufacturers in addition to the standard ones above.
53网络运营商和/或制造商在上述标准元素之外添加的信息元素。
TIPHON [TIPHON] is an XML-based protocol, carried by HTTP, which handles accounting and authorization requests and responses.
TIPHON[TIPHON]是一种基于XML的协议，由HTTP承载，用于处理记帐和授权请求及响应。
The following are elements selected from TIPHON's DTD that are used for accounting.
以下是从TIPHON的DTD中选择的用于记帐的元素。
<!ELEMENT Currency (#PCDATA)> <!ELEMENT Amount (#PCDATA)> Identifies a numeric value. Expressed using the period (.) as a decimal separator with no punctuation as the thousands separator.
<!要素货币（#PCDATA）><！元素量（#PCDATA）>标识一个数值。使用句点（.）作为十进制分隔符表示，不使用标点符号作为千位分隔符。
<!ELEMENT CallId (#PCDATA)> Contains a call's H.323 CallID value, and is thus used to uniquely identify individual calls.
<!元素CallId（#PCDATA）>包含呼叫的H.323 CallId值，因此用于唯一标识单个呼叫。
<!ELEMENT Currency (#PCDATA)> Defines the financial currency in use for the parent element.
<!元素货币（#PCDATA）>定义父元素使用的财务货币。
<!ELEMENT DestinationInfo type ( e164 | h323 | url | email | transport | international | national | network | subscriber | abbreviated | e164prefix ) Gives the primary identification of the destination for a call.
<!元素DestinationInfo类型（e164 | h323 | url |电子邮件|传输|国际|国家|网络|订户|缩写| e164前缀）提供呼叫目的地的主要标识。
<!ELEMENT Increment (#PCDATA)> Indicates the number of units being accounted.
<!元素增量（#PCDATA）>表示要计算的单元数。
<!ELEMENT Service EMPTY> Indicates a type of service being priced, authorized, or reported. An empty Service element indicates basic Internet telephony service, which is the only service type defined by V1.4.2 of the specification. The specification notes that "Later revisions of this standard are expected to specify more enhanced service definitions to represent quality of service, availability, payment methods, etc."
<!ELEMENT Service EMPTY>表示正在定价、授权或报告的服务类型。空服务元素表示基本Internet电话服务，这是规范V1.4.2定义的唯一服务类型。该规范指出，“本标准的后续修订预计将规定更多增强的服务定义，以表示服务质量、可用性、支付方式等。”
<!ELEMENT DestinationInfo type ( e164 | h323 | url | email | transport | international | national | network | subscriber | abbreviated | e164prefix) Gives the primary identification of the source of a call.
<!元素DestinationInfo类型（e164 | h323 | url |电子邮件|传输|国际|国家|网络|订户|缩写| e164前缀）提供呼叫源的主要标识。
<!ELEMENT Timestamp (#PCDATA)> A restricted form of [ISO-DATE] that indicates the time at which the component was generated.
<!元素时间戳（#PCDATA）>一种受限形式的[ISO-DATE]，表示组件生成的时间。
<!ELEMENT TransactionId (#PCDATA)> Contains an integer, decimal valued identifier assigned to a specific authorized transaction.
<!元素TransactionId（#PCDATA）>包含分配给特定授权事务的整数、十进制值标识符。
<!ELEMENT Unit (#PCDATA)> Indicates the units by which pricing is measured or usage recorded. It shall contain one of the following values: s seconds p packets (datagrams) byte bytes
<!元素单位（#PCDATA）>表示衡量价格或记录使用情况的单位。它应包含以下值之一：s秒p数据包（数据报）字节
<!Element UsageDetail ( Service, Amount, Increment, Unit ) > Collects information describing the usage of a service.
<!Element UsageDetail（服务、金额、增量、单位）>收集描述服务使用情况的信息。
MSIX [MSIX-SPEC] is an XML-based protocol transported by HTTP that is used to make accounting service definitions and transmit service usage information. As its service definitions are parameterized and dynamic, it makes no definition of services or attributes itself, but allows implementors to make their own. It specifies only the base data types that attributes may take: STRING, UNISTRING, INT32, FLOAT, DOUBLE, BOOLEAN, TIMESTAMP.
MSIX[MSIX-SPEC]是由HTTP传输的基于XML的协议，用于创建记帐服务定义和传输服务使用信息。由于它的服务定义是参数化的和动态的，所以它不定义服务或属性本身，而是允许实现者自己定义。它只指定属性可能采用的基本数据类型：STRING、UNISTRING、INT32、FLOAT、DOUBLE、BOOLEAN、TIMESTAMP。
RTFM and AToMMIB use ASN.1 Basic Encoding Rules (BER) to encode lists of attributes into accounting records. RTFM uses SNMP to retrieve such records as BER strings, thus avoiding having to have an object identifier for every object.
RTFM和AToMMIB使用ASN.1基本编码规则（BER）将属性列表编码到会计记录中。RTFM使用SNMP来检索诸如BER字符串之类的记录，从而避免了每个对象都必须有一个对象标识符。
AToMMIB carries this a stage further by defining an accounting file format in ASN.1 and making it available for retrieval by a file transfer protocol, thereby providing a more efficient alternative to simply retrieving the records using SNMP.
AToMMIB通过在ASN.1中定义记帐文件格式并使其可通过文件传输协议进行检索，从而为使用SNMP检索记录提供了更有效的替代方案，从而进一步推进了这一阶段。
A Q.825 Call Record is an ASN.1 SET containing a specified group of the Q.825 attributes. Call records would presumably be encoded as BER strings before being collected for later processing.
一个Q.825调用记录是一个ASN.1集合，包含一组指定的Q.825属性。呼叫记录可能在被收集以供以后处理之前被编码为BER字符串。
Radius packets carry a sequence of attributes and their values, as (Type, Length, Value) triples. The format of the value field is one of four data types.
Radius数据包携带一系列属性及其值，如（类型、长度、值）三元组。值字段的格式是四种数据类型之一。
string 0-253 octets
字符串0-253八位字节
address 32 bit value, most significant octet first.
地址32位值，最重要的八位位组在前。
integer 32 bit value, most significant octet first.
整数32位值，最高有效八位位组优先。
time 32 bit value, most significant octet first -- seconds since 00:00:00 GMT, January 1, 1970. The standard Attributes do not use this data type but it is presented here for possible use within Vendor-Specific attributes.
时间32位值，最高有效八位组第一位--自1970年1月1日格林威治标准时间00:00:00以来的秒数。标准属性不使用此数据类型，但此处提供此数据类型，以便在特定于供应商的属性中使用。
Each DIAMETER message consists of multiple AVP's that are 32-bit aligned, with the following format:
每个DIAMETER消息由多个32位对齐的AVP组成，格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |P|T|V|R|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor ID (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |P|T|V|R|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor ID (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+
Code The AVP Code identifies the attribute uniquely. If the Vendor-Specific bit is set, the AVP Code is allocated from the vendor's private address space.
代码AVP代码唯一标识属性。如果设置了供应商特定位，则从供应商的专用地址空间分配AVP代码。
The first 256 AVP numbers are reserved for backward compatibility with RADIUS and are to be interpreted as per RADIUS [RAD-PROT]. AVP numbers 256 and above are used for DIAMETER, which are allocated by IANA.
前256个AVP编号保留用于与RADIUS向后兼容，并根据RADIUS[RAD-PROT]进行解释。AVP编号256及以上用于IANA分配的直径。
AVP Length A 16-bit field contains the total object length in bytes. Must always be a multiple of 4, and at least 8.
AVP长度16位字段包含以字节为单位的对象总长度。必须始终为4的倍数，且至少为8。
AVP Flags P Protected bit T Tag bit V Vendor-ID bit R Reserved (MUST be set to 0) M Mandatory bit
AVP标志P受保护位T标记位V供应商ID位R保留（必须设置为0）M强制位
ADIF (Accounting Data Interchange Format [ROAM-ADIF]) presents a general, text-based format for accounting data files, described in a straightforward BNF grammar. Its file header contains a field indicating the default protocol from which accounting attributes are drawn. If an attribute from another protocol is to be used, it is preceded by its protocol name, for example rtfm//27 would be RTFM's "forward bytes" attribute. Comments in an ADIF file begin with a cross-hatch.
ADIF（会计数据交换格式[ROAM-ADIF]）为会计数据文件提供了一种基于文本的通用格式，用简单的BNF语法描述。其文件头包含一个字段，指示从中绘制记帐属性的默认协议。如果要使用另一个协议的属性，则该属性前面会有其协议名称，例如，rtfm//27将是rtfm的“转发字节”属性。ADIF文件中的注释以十字线开头。
Example: An ADIF file encoding RADIUS accounting data
示例：对RADIUS记帐数据进行编码的ADIF文件
version: 1
device: server3
description: Accounting Server 3
date: 02 Mar 1999 12:19:01 -0500
defaultProtocol: radius
version: 1
device: server3
description: Accounting Server 3
date: 02 Mar 1999 12:19:01 -0500
defaultProtocol: radius
rdate: 02 Mar 1999 12:20:17 -0500
#NAS-IP-Address
4: 204.45.34.12
#NAS-Port
5: 12
#NAS-Port-Type
rdate: 02 Mar 1999 12:20:17 -0500
#NAS-IP-Address
4: 204.45.34.12
#NAS-Port
5: 12
#NAS-Port-Type
61: 2 #User-Name 1: fred@bigco.com #Acct-Status-Type 40: 2 #Acct-Delay-Time 41: 14 #Acct-Input-Octets 42: 234732 #Acct-Output-Octets 43: 15439 #Acct-Session-Id 44: 185 #Acct-Authentic 45: 1 #Acct-Session-Time 46: 1238 #Acct-Input-Packets 47: 153 #Acct-Output-Packets 48: 148 #Acct-Terminate-Cause 49: 11 #Acct-Multi-Session-Id 50: 73 #Acct-Link-Count 51: 2
61:2#用户名1:fred@bigco.com#账户状态类型40:2#账户延迟时间41:14#账户输入八位字节42:234732#账户输出八位字节43:15439#账户会话Id 44:185#账户真实45:1#账户会话时间46:1238#账户输入数据包47:153#账户输出数据包48:148#账户终止原因49:11#账户多会话Id 50:73#账户链接计数51:2
AAA needs a well-defined set of attributes whose values are to be carried in records to or from accounting servers.
AAA需要一组定义良好的属性，这些属性的值将在会计服务器的记录中携带。
Most of the existing sets of documents described above include a set of attributes, identified by small integers. It is likely that these sets overlap, i.e. that some of them have attributes which represent the same quantity using different names in different sets. This suggests it might be possible to produce a single combined set of "universal" accounting attributes, but such a "universal" set does not seem worthwhile.
上面描述的大多数现有文档集都包含一组由小整数标识的属性。这些集合很可能重叠，即其中一些集合的属性在不同集合中使用不同的名称表示相同的数量。这表明，可能会产生一组单一的“通用”会计属性组合，但这样一组“通用”会计属性似乎不值得。
The ADIF approach of specifying a default protocol (from which attributes are assumed to come) and identifying any exceptions seems much more practical. We therefore propose that AAA should use the
ADIF指定默认协议（假定属性来自该协议）并识别任何异常的方法似乎更加实用。因此，我们建议AAA应使用
ADIF convention (or something like it) to identify attributes, together with all the sets of attributes covered by the [ASG-NBR] document.
ADIF公约（或类似公约）用于识别属性，以及[ASG-NBR]文档所涵盖的所有属性集。
AAA needs a simple interchange file format, to be used for accounting data. Several schemes for packaging and transporting such data have been described above.
AAA需要一个简单的交换文件格式，用于会计数据。上文已经描述了包装和运输此类数据的几种方案。
The SNMP-based ones fit well within the context of an SNMP-based network management system. RTFM and AToMMIB provide ways to reduce the SNMP overhead for collecting data, and AToMMIB defines a complete file format. Both provide good ways to collect accounting data.
基于SNMP的网络管理系统非常适合基于SNMP的网络管理系统。RTFM和AToMMIB提供了减少收集数据的SNMP开销的方法，AToMMIB定义了完整的文件格式。两者都提供了收集会计数据的好方法。
As an interchange format, however, ASN.1-based schemes suffer from being rather complex binary structures. This means that one requires suitable tools to work with them, as compared to plain-text files where one can use existing text-based utilities.
然而，作为一种交换格式，基于ASN.1的方案受到相当复杂的二进制结构的影响。这意味着，与可以使用现有基于文本的实用程序的纯文本文件相比，您需要合适的工具来使用它们。
The binary schemes such as RADIUS and DIAMETER have simpler structures, but they too need purpose-built tools. For general use they would need to be extended to allow them to use attributes from other protocols.
诸如半径和直径之类的二进制方案具有更简单的结构，但它们也需要专门构建的工具。对于一般用途，需要对它们进行扩展，以允许它们使用来自其他协议的属性。
From the point of view of being easy for humans to understand, ADIF seems very promising. Of course any processing program would need a suitable ADIF input parser, but using plain-text files makes them much easier to understand.
从人类易于理解的角度来看，ADIF似乎非常有希望。当然，任何处理程序都需要合适的ADIF输入解析器，但使用纯文本文件使它们更容易理解。
TIPHON's record format is specified by an XML DTD. While XML representations have the advantages of being well-known, they are limited by XML's inability to specify type or other validity checking for information within the tags. This situation will likely be improved by the XML Schema [XML-SCHM] efforts that are underway, but a stable reference is not yet available.
TIPHON的记录格式由XML DTD指定。虽然XML表示具有众所周知的优点，但它们受到XML无法为标记中的信息指定类型或其他有效性检查的限制。目前正在进行的XML模式[XML-SCHM]工作可能会改善这种情况，但还没有稳定的参考。
It is generally agreed that there is a need for a standard record format and transport protocol for communication between Service Elements and Accounting Servers.
人们普遍认为，服务元素和记帐服务器之间的通信需要标准记录格式和传输协议。
There is less agreement on the following issues:
在以下问题上没有达成一致意见：
o Separate or integral record format and transport protocol o Standard set of base data types o Service definitions: part of the protocol or separately defined
o 单独或完整的记录格式和传输协议o标准的基本数据类型集o服务定义：协议的一部分或单独定义
o Service definition namespace management
o 服务定义命名空间管理
The following sections address these issues.
以下各节讨论这些问题。
All known Internet-centric billing protocols to date have an integral record format. That is, the collection of Properties that describe a Usage Event are specified as an integral part of the protocol, typically as a part of a "submit" message that is used to transmit a Usage Event from a Service Entity to an Accounting Server.
迄今为止，所有已知的以互联网为中心的计费协议都有一个完整的记录格式。也就是说，描述使用情况事件的属性集合被指定为协议的组成部分，通常作为“提交”消息的一部分，该消息用于将使用情况事件从服务实体传输到记帐服务器。
It may be advantageous to define a record format that is independent of the transport protocol. Such a record format should support both representation of individual records and records in bulk, as Usage Events are often aggregated and transmitted in bulk.
定义独立于传输协议的记录格式可能是有利的。这样的记录格式应该支持单个记录和批量记录的表示，因为使用事件通常是批量聚合和传输的。
A separate record format is useful for record archiving and temporary file storage. Multiple transport protocols may be defined without affecting the record format. The task of auditing is made easier if a standard file format is defined. If a canonical format is used, bulk records may be hashed with MD5 [MD5] or a similar function, for reliability and security purposes.
单独的记录格式对于记录存档和临时文件存储非常有用。可以在不影响记录格式的情况下定义多个传输协议。如果定义了标准文件格式，审计任务就会变得更容易。如果使用规范格式，出于可靠性和安全性目的，可以使用MD5[MD5]或类似函数对批量记录进行散列。
+------------+
| transport |
| header |
+------------+ +------------+
| | | |
| Usage | | Usage |
| Event(s) | | Event(s) |
| | | |
| | | |
+------------+ +------------+
| trailer |
+------------+
+------------+
| transport |
| header |
+------------+ +------------+
| | | |
| Usage | | Usage |
| Event(s) | | Event(s) |
| | | |
| | | |
+------------+ +------------+
| trailer |
+------------+
record format transport protocol
记录格式传输协议
If the protocol is written such that it can transmit Usage Events in the record format, no record rewriting for transport is required.
如果协议的编写使其能够以记录格式传输使用情况事件，则不需要为传输重写记录。
Record formats and protocols use a combination of data locality and explicit tagging to identify data elements. Mail [RFC822], for instance, defines a header block composed of several Attribute-Value Pairs, followed by a message body. Each header field is explicitly
记录格式和协议使用数据位置和显式标记的组合来标识数据元素。例如，Mail[RFC822]定义了一个由多个属性值对组成的头块，后跟一个消息体。每个标题字段都是显式的
tagged, but the order of the AVPs is undefined. The message body is not tagged (except with an additional preceding blank line), and is found through its position in the message, which must be after all header fields.
已标记，但AVP的顺序未定义。消息正文没有标记（前面有一个额外的空行除外），而是通过其在消息中的位置找到的，该位置必须位于所有标题字段之后。
Some record formats make no use of tags--data elements are identified only by their position within a record structure. While this practice provides for the least amount of record space overhead, it is difficult to later modify the record format by adding or removing elements, as all record readers will have to be altered to handle the change. Tagged data allows old readers to detect unexpected tags and to detect if required data are missing. If the overhead of carrying explicit tags can be borne, it is advantageous to use explicitly tagged data elements where possible.
有些记录格式不使用标记——数据元素仅通过它们在记录结构中的位置来标识。虽然这种做法提供了最少的记录空间开销，但以后很难通过添加或删除元素来修改记录格式，因为必须更改所有记录读取器才能处理更改。标记数据允许旧读取器检测意外的标记，并检测所需数据是否丢失。如果可以承担携带显式标记的开销，则在可能的情况下使用显式标记的数据元素是有利的。
An AVP approach has proven useful in accounting. RADIUS [RADIUS] uses numeric data type identifiers. ETSI's TIPHON [TIPHON] uses XML markup.
AVP方法在会计中已被证明是有用的。RADIUS[RADIUS]使用数字数据类型标识符。ETSI的TIPHON[TIPHON]使用XML标记。
For an AAA accounting record format, the authors suggest that each Property be named by a textual or numeric identifier and carry a value and a data type indicator, which governs interpretation of the value. It may also be useful for each Property to carry a units of measure identifier. The TIPHON specification takes this approach. TS 101 321 also carries an Increment field, which denominates the Property's Unit of Measure field. Whether this additional convenience is necessary is a matter for discussion.
对于AAA会计记录格式，作者建议每个属性由文本或数字标识符命名，并带有一个值和一个数据类型指示符，该指示符控制对值的解释。对于每个属性来说，携带度量单位标识符也很有用。TIPHON规范采用这种方法。TS 101 321还携带一个增量字段，该字段命名属性的度量单位字段。这种额外的便利是否必要，有待讨论。
It is not strictly necessary for each data record to carry data type, units of measure, or increments identifiers. If this information is recorded in a record schema document that is referenced by each data record, each record may be validated against the schema without the overhead of carrying type information.
严格来说，每个数据记录不必携带数据类型、度量单位或增量标识符。如果此信息记录在每个数据记录引用的记录模式文档中，则可以根据模式验证每个记录，而不需要携带类型信息。
It is useful to define a standard set of primitive data types to be used by the record format and protocol. Looking at the prior art, DIAMETER supports Data (arbitrary octets), String (UTF-8), Address (32 or 128 bit), Integer32, Integer64, Time (32 bits, seconds since 1970), and Complex. MSIX [MSIX-SPEC] supports String, Unistring, Int32, Float, Double, Boolean, and Timestamp. SMIv2 [SMI-V2] offers ASN.1 types INTEGER, OCTET STRING, and OBJECT IDENTIFIER, and the application-defined types Integer32, IpAddress, Counter32, Gauge32, Unsigned32, TimeTicks, Opaque, and Counter64.
定义记录格式和协议使用的一组标准基本数据类型是很有用的。从现有技术来看，DIAMETER支持数据（任意八位字节）、字符串（UTF-8）、地址（32或128位）、整数32、整数64、时间（32位，自1970年以来的秒）和复数。MSIX[MSIX-SPEC]支持字符串、Unistring、Int32、浮点、双精度、布尔值和时间戳。SMIv2[SMI-V2]提供ASN.1类型整数、八位字节字符串和对象标识符，以及应用程序定义的类型Integer32、IpAddress、Counter32、Gauge32、Unsigned32、TimeTicks、不透明和Counter64。
An appropriate set would likely include booleans, 32 and 64 bit signed integers, 32 and 64 bit floats, arbitrary octets, UTF-8 and UTF-16 strings, and ISO 8601:1988 [ISO-DATE] timestamps. Fixed-precision numbers capable of representing currency amounts (with precision specified on both sides of the decimal point) have proven useful in accounting record formats, as they are immune to the precision problems that are encountered when one attempts to represent fixed-point amounts with floating point numbers.
合适的集合可能包括布尔、32位和64位有符号整数、32位和64位浮点、任意八位字节、UTF-8和UTF-16字符串以及ISO 8601:1988[ISO-DATE]时间戳。事实证明，能够表示货币金额的固定精度数字（小数点两侧都指定了精度）在会计记录格式中非常有用，因为它们不受试图用浮点数表示固定点金额时遇到的精度问题的影响。
It may be worthwhile to consider the datatypes that are being specified by the W3C's "XML Schema Part 2: Datatypes" [XML-DATA] document. That document specifies a rich set of base types, along with a mechanism to specify derivations that further constrain the base types.
考虑W3C的“XML模式第2部分：数据类型”[XMLDATA ]文档所指定的数据类型可能是值得的。该文档指定了一组丰富的基类型，以及一种指定进一步约束基类型的派生的机制。
Each Usage Event requires its own unique identifier.
每个使用事件都需要自己的唯一标识符。
It is expedient to allow Service Elements to create their own unique identifiers. In this manner, Usage Events can be created and archived without the involvement of an Accounting Server or other central authority.
允许服务元素创建它们自己的唯一标识符是有利的。通过这种方式，可以创建和归档使用事件，而无需记帐服务器或其他中央机构的参与。
A number of methods for creating unique identifiers are well known. One popular identifier is an amalgamation of a monotonically increasing sequence number, a large random value, a network element identifier, and a timestamp. Another possible source of entropy is a hash value of all or part of the record itself.
创建唯一标识符的许多方法是众所周知的。一种流行的标识符是单调递增序列号、大随机值、网元标识符和时间戳的组合。熵的另一个可能来源是全部或部分记录本身的散列值。
RFC 822 [MAIL], RFC 1036 [NEWS], and RFC 2445 [ICAL-CORE] give guidance on the creation of good unique identifiers.
RFC 822[邮件]、RFC 1036[新闻]和RFC 2445[ICAL-CORE]为创建良好的唯一标识符提供了指导。
A critical differentiator in accounting record formats and protocols is their capability to account for arbitrary service usage. To date, no accounting record format or protocol that can handle arbitrary service definitions has achieved broad acceptance on the Internet.
记帐记录格式和协议的一个关键区别在于它们能够解释任意的服务使用。迄今为止，没有一种会计记录格式或协议能够处理任意的服务定义，在互联网上得到广泛接受。
This section analyzes the issues in service definition and makes a case for a record format and protocol with the capability to carry Usage Events for rich, independently-defined services.
本节分析了服务定义中的问题，并介绍了一种记录格式和协议，它能够为丰富的、独立定义的服务传递使用事件。
It is informative to survey a number of popular Internet protocols and document encodings and examine their capacities for extension. These protocols can be categorized into two broad categories--"fully specified" protocols that have little provision for extension and "framework" protocols that are incomplete, but provide a basis for future extension when coupled with application documents.
调查一些流行的Internet协议和文档编码并检查它们的扩展能力是有益的。这些协议可以分为两大类——“完全指定”的协议，它们很少提供扩展，而“框架”协议是不完整的，但在与应用程序文档结合时为将来的扩展提供了基础。
Examples of fully-specified protocols are NTP [NTP], NNTP [NNTP], RADIUS Accounting [RAD-ACT], and HTML [HTML].
完全指定协议的示例有NTP[NTP]、NNTP[NNTP]、RADIUS Accounting[RAD-ACT]和HTML[HTML]。
Aside from leaving some field values "reserved for future use", all of Network Time Protocol's fields are fixed-width and completely defined. This is appropriate for a simple protocol that solves a simple problem.
除了保留一些字段值“留作将来使用”，所有网络时间协议的字段都是固定宽度的，并且完全定义。这适用于解决简单问题的简单协议。
Network News Transfer Protocol [NEWS-PROT] specifies that further commands may be added, and requests that non-standard implementations use the "X-" experimental prefix so as to not conflict with future additions. The content of news is 7-bit data, with the high-order bit cleared to 0. Nothing further about the content is defined. There is no in-protocol facility for automating decoding of content type.
网络新闻传输协议[News-PROT]规定可以添加更多命令，并要求非标准实现使用“X-”前缀，以避免与将来添加的命令冲突。新闻内容为7位数据，高位清除为0。关于内容没有进一步的定义。没有用于自动解码内容类型的协议内设施。
We pay particular attention to RADIUS Accounting [RAD-ACT]. Perhaps the second most frequently heard complaint (after security shortcomings) about RADIUS Accounting is its preassigned and fixed set of "Types". These are coded as a range of octets from 40 to 51 and are as follows:
我们特别关注RADIUS会计[RAD-ACT]。也许第二个最常听到的关于RADIUS记帐的抱怨（在安全缺陷之后）是它预先指定和固定的“类型”。它们被编码为从40到51的八位字节范围，如下所示：
40 Acct-Status-Type 41 Acct-Delay-Time 42 Acct-Input-Octets 43 Acct-Output-Octets 44 Acct-Session-Id 45 Acct-Authentic 46 Acct-Session-Time 47 Acct-Input-Packets 48 Acct-Output-Packets 49 Acct-Terminate-Cause 50 Acct-Multi-Session-Id 51 Acct-Link-Count
40账户状态类型41账户延迟时间42账户输入八位字节43账户输出八位字节44账户会话Id 45账户真实46账户会话时间47账户输入数据包48账户输出数据包49账户终止原因50账户多会话Id 51账户链路计数
These identifiers were designed to account for packet-based network access service. They are ill-suited for describing other services. While extension documents have specified additional types, the base
这些标识符用于说明基于分组的网络访问服务。它们不适合描述其他服务。虽然扩展文档指定了其他类型，但基
protocol limits the type identifier to a single octet, limiting the total number of types to 256.
协议将类型标识符限制为单个八位字节，将类型总数限制为256。
HTML/2.0 [HTML] is mostly a fully-specified protocol, but with W3C's HTML/4.0, HTML is becoming more of a framework protocol. HTML/2.0 specified a fixed set of markups, with no provision for addition (without protocol revision).
HTML/2.0[HTML]主要是一个完全指定的协议，但随着W3C的HTML/4.0，HTML越来越成为一个框架协议。HTML/2.0指定了一组固定的标记，没有添加的规定（没有协议修订）。
Examples of "framework" protocols and document encodings are HTTP, XML, and SNMP.
“框架”协议和文档编码的示例有HTTP、XML和SNMP。
HTTP/1.1 [HTTP] is somewhat similar to NNTP in that it is designed to transport arbitrary content. It is different in that it supports description of that content through its Content-Type, Content-Encoding, Accept-Encoding, and Transfer-Encoding header fields. New types of content can be designated and carried by HTTP/1.1 without modification to the HTTP protocol.
HTTP/1.1[HTTP]在某种程度上类似于NNTP，因为它设计用于传输任意内容。它的不同之处在于，它支持通过内容类型、内容编码、接受编码和传输编码头字段来描述该内容。HTTP/1.1可以指定和携带新类型的内容，而无需修改HTTP协议。
XML [XML] is a preeminent general-purpose framework encoding. DTD publishing is left to users. There is no standard registry of DTDs.
XML[XML]是一种卓越的通用框架编码。DTD发布留给用户。没有DTD的标准注册表。
SNMP presents a successful example of a framework protocol. SNMP's authors envisioned SNMP as a general management protocol, and allow extension through the use of private MIBs. SNMP's ASN.1 MIBs are defined, published, and standardized without the necessity to modify the SNMP standard itself. From "An Overview of SNMP" [SNMP-OVER]:
SNMP提供了一个框架协议的成功示例。SNMP的作者将SNMP设想为一种通用管理协议，并允许通过使用专用MIB进行扩展。SNMP的ASN.1 MIB是定义、发布和标准化的，无需修改SNMP标准本身。从“SNMP概述”[SNMP-OVER]：
It can easily be argued that SNMP has become prominent mainly from its ability to augment the standard set of MIB objects with new values specific for certain applications and devices. Hence, new functionality can continuously be added to SNMP, since a standard method has been defined to incorporate that functionality into SNMP devices and network managers.
可以很容易地说，SNMP之所以变得突出，主要是因为它能够用特定于某些应用程序和设备的新值来扩充MIB对象的标准集。因此，可以不断向SNMP添加新功能，因为已经定义了一种标准方法来将该功能合并到SNMP设备和网络管理器中。
Most accounting protocols are fully-specified, with either a completely defined service or set of services (RADIUS Accounting) or with one or more services defined and provision for "extension" services to be added to the protocol later (TIPHON). While the latter is preferable, it may be preferable to take a more SNMP-like approach, where the accounting record format and protocol provide only a framework for service definition, and leave the task of service definition (and standardization) to separate efforts. In this manner, the accounting protocol itself would not have to be modified to handle new services.
大多数记帐协议都是完全指定的，要么是完全定义的服务或一组服务（RADIUS记帐），要么是定义了一个或多个服务，并提供了“扩展”服务，以便稍后添加到协议中（TIPHON）。虽然后者更可取，但可能更可取的是采用更类似SNMP的方法，其中记帐记录格式和协议仅提供服务定义的框架，并将服务定义（和标准化）的任务留给单独的工作。这样，记帐协议本身就不必修改以处理新的服务。
Versioning is a naming and compatibility issue. Version identifiers are useful in service definition because they enable service definitions to be upgraded without a possibly awkward name change. They also enable possible compatibility between different versions of the same service.
版本控制是一个命名和兼容性问题。版本标识符在服务定义中很有用，因为它们使服务定义能够升级，而不必进行可能令人尴尬的名称更改。它们还支持同一服务的不同版本之间可能的兼容性。
An example could be the service definition of a phone call. Version 1 might define Properties for the start time, duration, and called and calling party numbers. Later, version 2 is defined, which augments the former service definition with a byte count. An Accounting Server, aware only of Version 1, may accept Version 2 records, discarding the additional information (forward compatibility). Alternately, if an Accounting Server is made aware of version 2, it could optionally still accept version 1 records from Service Elements, provided the Accounting Sever does not require the additional information to properly account for service usage (backward compatibility).
例如，电话的服务定义。版本1可能会定义开始时间、持续时间以及被叫方和主叫方号码的属性。稍后，定义了版本2，该版本使用字节计数扩展了以前的服务定义。仅知道版本1的记帐服务器可以接受版本2记录，放弃附加信息（向前兼容性）。或者，如果记帐服务器知道版本2，它也可以选择接受来自服务元素的版本1记录，前提是记帐服务器不需要额外的信息来正确说明服务使用情况（向后兼容性）。
Accounting record formats and protocols to date do not sufficiently addressed "compound" service description.
迄今为止，会计记录格式和协议未充分说明“复合”服务描述。
A compound service is a service that is described as a composition of other services. A conference call, for example, may be described as a number of point-to-point calls to a conference bridge. It is important to account for the individual calls, rather than just summing up an aggregate, both for auditing purposes and to enable differential rating. If these calls are to be reported to the Accounting Server individually, the Usage Events require a shared identifier that can be used by the Accounting Server and other back-end systems to group the records together.
复合服务是一种被描述为其他服务组合的服务。例如，会议呼叫可以被描述为对会议网桥的多个点对点呼叫。为了审计目的和实现差异评级，重要的是要考虑到单个呼叫，而不仅仅是汇总。如果要将这些调用单独报告给记帐服务器，则使用事件需要一个共享标识符，记帐服务器和其他后端系统可以使用该标识符将记录分组在一起。
In order for a Service Element to report compound events over time as a succession of individual Usage Events, the accounting protocol requires a facility to communicate that the compound event has started and stopped. The "start" message can be implicit--the transmission of the first Usage Event will suffice. An additional semaphore is required to tell the Accounting Server that the compound service is complete and may be further processed. This is necessary to prevent the Accounting Server from prematurely processing compound events that overlap the end of a billing period.
为了让服务元素将一段时间内的复合事件报告为一系列单独的使用事件，记帐协议需要一个设施来通信复合事件已经开始和停止。“开始”消息可以是隐式的——第一个使用事件的传输就足够了。需要一个额外的信号量来告诉记帐服务器复合服务已完成并且可能会被进一步处理。这对于防止记帐服务器过早地处理与计费周期结束时间重叠的复合事件是必要的。
RADIUS Accounting has some provision for this sort of accounting with its "Acct-Multi-Session-Id" field. Unfortunately, RADIUS Accounting's other shortcomings preclude it from being used in general purpose service usage description.
RADIUS记帐在其“Acct Multi Session Id”字段中为此类记帐做了一些规定。不幸的是，RADIUS Accounting的其他缺点妨碍了它在通用服务使用描述中的应用。
"Framework" protocols, as previously mentioned, do not define complete schema for their payload. For interoperability to be achieved, it must be possible for:
如前所述，“框架”协议并没有为其负载定义完整的模式。为了实现互操作性，必须能够：
(1) content definers to specify definitions without conflicting with the names of other definitions
(1) 内容定义者指定的定义与其他定义的名称不冲突
(2) protocol users to find and use content definitions
(2) 协议用户查找和使用内容定义
Condition (1) can be readily managed through IANA assignment or by using an existing namespace differentiator (for example, DNS).
条件（1）可以通过IANA分配或使用现有名称空间区分符（例如DNS）轻松管理。
Condition (2) is harder, and places considerable burden on the implementors. Their clients and servers must be able, statically or dynamically, to find and validate definitions, and manage versioning issues.
条件（2）更加困难，给实现者带来了相当大的负担。他们的客户机和服务器必须能够静态或动态地查找和验证定义，并管理版本控制问题。
As previously mentioned, the XML specification provides no facility for DTD discovery or namespace management. XML specifies only a document format, and as such does not need to specify support for more "protocol" oriented problems.
如前所述，XML规范没有提供DTD发现或名称空间管理功能。XML只指定文档格式，因此不需要指定对更多面向“协议”的问题的支持。
For an accounting record format and protocol, an approach closer to SNMP's is useful. SNMP uses an ISO-managed dotted-decimal namespace. An IANA-managed registry of service types is a possibility. Another possibility, used by MSIX [MSIX-SPEC], is for Service Element creators to identify their services by concatenation of a new service name with existing unique identifier, such as a domain name.
对于记帐记录格式和协议，更接近SNMP的方法很有用。SNMP使用ISO管理的点十进制名称空间。可以使用IANA管理的服务类型注册表。MSIX[MSIX-SPEC]使用的另一种可能性是服务元素创建者通过将新服务名称与现有唯一标识符（如域名）连接起来来标识其服务。
A standard record format for service definitions would make it possible for Service Element creators to directly supply accounting system managers with the required definitions, via the network or other means.
服务定义的标准记录格式将使服务元素创建者能够通过网络或其他方式直接向会计系统经理提供所需的定义。
It may be useful to define more than one record encoding.
定义多个记录编码可能很有用。
A "verbose" XML encoding is easily implemented and records can be syntactically verified with existing tools. "Human-readable" protocols tend to have an edge on "bitfield" protocols where ease of
“详细”XML编码很容易实现，并且可以使用现有工具对记录进行语法验证。“人类可读”协议往往比“位域”协议更具优势，因为“位域”协议易于使用
implementation is paramount and the application can tolerate any additional processing required to generate, parse, and transport the records.
实现至关重要，应用程序可以容忍生成、解析和传输记录所需的任何附加处理。
A alternative "compressed" encoding that makes minimal use of storage and processing may be useful in many contexts.
在许多情况下，尽可能少地使用存储和处理的替代“压缩”编码可能很有用。
There are disadvantages to supporting multiple encodings. Optionally-supported multiple encodings mandate the requirement for capabilities exchange between Service Element and Accounting Server. Also, implementations can tend to "drift apart", with one encoding better-supported than another. Unless all encodings are mandatory, implementors may find they are unable to interoperate because they picked the wrong encoding.
支持多种编码有缺点。可选支持的多种编码要求在服务元素和记帐服务器之间进行功能交换。此外，实现可能倾向于“分离”，一种编码比另一种编码更受支持。除非所有编码都是强制性的，否则实现者可能会发现他们无法进行互操作，因为他们选择了错误的编码。
This document summarises many existing IETF and ITU documents; please refer to the original documents for security considerations for their particular protocols.
本文件总结了许多现有的IETF和ITU文件；有关其特定协议的安全注意事项，请参阅原始文档。
It must be possible for the accounting protocol to be carried by a secure transport. A canonical record format is useful so that regeneration of secure record hashes is possible.
记帐协议必须能够通过安全传输进行传输。规范记录格式非常有用，因此可以重新生成安全记录哈希。
When dealing with accounting data files, one must take care that their integrity and privacy are preserved. This document, however, is only concerned with the format of such files.
在处理会计数据文件时，必须注意保护其完整性和隐私。然而，本文件仅涉及此类文件的格式。
[ACC-BKG] Mills, C., Hirsch, G. and G. Ruth, "Internet Accounting Background", RFC 1272, November 1991.
[ACC-BKG]Mills，C.，Hirsch，G.和G.Ruth，“互联网会计背景”，RFC 1272，1991年11月。
[ASG-NBR] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[ASG-NBR]Reynolds，J.和J.Postel，“指定编号”，标准2，RFC 1700，1994年10月。
[ASN1] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization, International Standard 8824, December 1987.
[ASN1]信息处理系统.开放系统互连.抽象语法符号1规范（ASN.1），国际标准化组织，国际标准88241987年12月。
[ATM-ACT] McCloghrie, K., Heinanen, J., Greene, W. and A. Prasad, "Accounting Information for ATM Networks", RFC 2512, February 1999.
[ATM-ACT]McCloghrie，K.，Heinanen，J.，Greene，W.和A.Prasad，“ATM网络的会计信息”，RFC 25112999年2月。
[ATM-COLL] 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.
[ATM-COLL]McCloghrie，K.，Heinanen，J.，Greene，W.和A.Prasad，“用于控制面向连接网络的会计信息收集和存储的托管对象”，RFC 2513，1999年2月。
[BER] Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Notation One (ASN.1), International Organization for Standardization, International Standard 8825, December 1987.
[BER]信息处理系统.开放系统互连.抽象符号1（ASN.1）的基本编码规则规范，国际标准化组织，国际标准88251987年12月。
[DIAM-ACT] Arkko, J., Calhoun, P.R., Patel, P. and Zorn, G., "DIAMETER Accounting Extension", Work in Progress.
[DIAM-ACT]Arkko，J.，Calhoun，P.R.，Patel，P.和Zorn，G.，“直径会计扩展”，正在进行的工作。
[DIAM-AUTH] Calhoun, P.R. and Bulley, W., "DIAMETER User Authentication Extensions", Work in Progress.
[DIAM-AUTH]Calhoun，P.R.和Bulley，W.，“DIAMETER用户身份验证扩展”，正在进行中。
[DIAM-FRAM] Calhoun, P.R., Zorn, G. and Pan, P., "DIAMETER Framework Document", Work in Progress.
[DIAM-FRAM]Calhoun，P.R.，Zorn，G.和Pan，P.，“DIAMETER框架文件”，正在进行的工作。
[DSRV-ARC] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[DSRV-ARC]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[HTML] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language - 2.0", RFC 1866, November 1995.
[HTML]Berners Lee，T.和D.Connolly，“超文本标记语言-2.0”，RFC 18661995年11月。
[HTTP] Fielding, R., Gettys, J., Mogul, J. Frystyk, H. and T. Berners-Lee, "Hypertext Transfer Protocol--HTTP/1.1", RFC 2068, January 1997.
[HTTP]Fielding，R.，Gettys，J.，Mogul，J.Frystyk，H.和T.Berners Lee，“超文本传输协议——HTTP/1.1”，RFC 2068，1997年1月。
[ICAL-CORE] Dawson, F. and D. Stenerson, "Internet Calendaring and Scheduling Core Object Specification", RFC 2445, November 1998.
[ICAL-CORE]Dawson，F.和D.Stenerson，“互联网日历和调度核心对象规范”，RFC 24451998年11月。
[IIS-ARC] Braden, R., Clark, D. and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[IIS-ARC]Braden，R.，Clark，D.和S.Shenker，“互联网体系结构中的综合服务：概述”，RFC 16331994年6月。
[IIS-SPEC] Shenker, S., Partridge, C. and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[IIS-SPEC]Shenker，S.，Partridge，C.和R.Guerin，“保证服务质量规范”，RFC 2212，1997年9月。
[ISDN-MIB] Roeck, G., "ISDN Management Information Base using SMIv2", RFC 2127, March 1997.
[ISDN-MIB]Roeck，G.“使用SMIv2的ISDN管理信息库”，RFC 2127，1997年3月。
[ISO-DATE] "Data elements and interchange formats -- Information interchange -- Representation of dates and times", ISO 8601:1988.
[ISO-DATE]“数据元和交换格式——信息交换——日期和时间的表示”，ISO 8601:1988。
[MAIL] Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES", STD 11, RFC 822, August 1982.
[邮件]Crocker，D.，“ARPA互联网文本信息格式标准”，STD 11，RFC 822，1982年8月。
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[MD5]Rivest，R.，“MD5消息摘要算法”，RFC 13211992年4月。
[MSIX-SPEC] Blount, A. and D. Young, "Metered Service Information Exchange 1.2", Work in Progress.
[MSIX-SPEC]Blount，A.和D.Young，“计量服务信息交换1.2”，正在进行中。
[NEWS-MSGS] Horton, M. and R. Adams, "Standard for Interchange of USENET Messages", RFC 1036, December 1987.
[NEWS-MSGS]Horton，M.和R.Adams，“USENET消息交换标准”，RFC 1036，1987年12月。
[NEWS-PROT] Kantor, B. and P. Lapsley, "Network News Transfer Protocol", RFC 977, February 1986.
[NEWS-PROT]Kantor，B.和P.Lapsley，“网络新闻传输协议”，RFC9771986年2月。
[NTP] Mills, D., "Network Time Protocol (NTP)", RFC 958, September 1985.
[NTP]Mills，D.，“网络时间协议（NTP）”，RFC 958，1985年9月。
[Q-825] "Specification of TMN applications at the Q3 interface: Call detail recording", ITU-T Recommendation Q.825, 1998.
[Q-825]“第三季度接口的TMN应用规范：呼叫详细记录”，ITU-T建议Q.825，1998年。
[RAD-ACT] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RAD-ACT]Rigney，C.，“半径会计”，RFC 28662000年6月。
[RAD-EXT] Rigney, C., Willats, W. and Calhoun, P., "RADIUS Extensions", RFC 2869, June 2000.
[RAD-EXT]Rigney，C.，Willats，W.和Calhoun，P.，“半径延伸”，RFC 2869，2000年6月。
[RAD-PROT] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RAD-PROT]Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月。
[RAD-TACC] Zorn, G., Mitton, D. and A. Aboba, "RADIUS Accounting Modifications for Tunnel Protocol Support", RFC 2867, June 2000.
[RAD-TACC]Zorn，G.，Mitton，D.和A.Aboba，“隧道协议支持的半径计算修改”，RFC 28672000年6月。
[RAP-COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R. and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000.
[RAP-COPS]Boyle，J.，Cohen，R.，Durham，D.，Herzog，S.，Rajan，R.和A.Sastry，“COPS（公共开放政策服务）协议”，RFC 27482000年1月。
[ROAM-ADIF] Aboba, B. and D. Lidyard, "The Accounting Data Interchange Format (ADIF)", Work in Progress.
[ROAM-ADIF]Aboba，B.和D.Lidyard，“会计数据交换格式（ADIF）”，正在进行的工作。
[ROAM-IMPL] Aboba, B., Lu, J., Alsop, J., Ding, J. and W. Wang, "Review of Roaming Implementations", RFC 2194, September 1997.
[ROAM-IMPL]Aboba，B.，Lu，J.，Alsop，J.，Ding，J.和W.Wang，“漫游实施回顾”，RFC 2194，1997年9月。
[RS-DS-OP] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., Speer, M., Braden, R., Davie, B., Wroclawski, J. and E. Felstaine, "A Framework For Integrated Services Operation Over Diffserv Networks", Work in Progress.
[RS-DS-OP]Bernet，Y.，Yavatkar，R.，Ford，P.，Baker，F.，Zhang，L.，Speer，M.，Braden，R.，Davie，B.，Wroclawski，J.和E.Felstaine，“区分服务网络上的综合服务运营框架”，正在进行中。
[RSVP-ARC] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource Reservation Protocol (RSVP) Version 1 Functional Specification", RFC 2205, September 1997.
[RSVP-ARC]Braden，R.，Zhang，L.，Berson，S.，Herzog，S.和S.Jamin，“资源预留协议（RSVP）第1版功能规范”，RFC 22052997年9月。
[RSVP-MIB] Baker, F., Krawczyk, J. and A. Sastry, "RSVP Management Information Base using SMIv2", RFC 2206, September 1997.
[RSVP-MIB]Baker，F.，Krawczyk，J.和A.Sastry，“使用SMIv2的RSVP管理信息库”，RFC 2206，1997年9月。
[RTFM-ARC] Brownlee, N., Mills, C. and G. Ruth, "Traffic Flow Measurement: Architecture", RFC 2722, October 1999.
[RTFM-ARC]Brownlee，N.，Mills，C.和G.Ruth，“交通流测量：架构”，RFC2721999年10月。
[RTFM-MIB] Brownlee, N., "Traffic Flow Measurement: Meter MIB", Measurement: Architecture", RFC 2720, October 1999.
[RTFM-MIB]布朗利，N.，“交通流量测量：仪表MIB”，测量：架构，RFC2720，1999年10月。
[RTFM-NEWA] Handelman, S., Brownlee, N., Ruth, G. and S. Stibler, "New Attributes for Traffic Flow Measurement", RFC 2724, October 1999.
[RTFM-NEWA]Handelman，S.，Brownlee，N.，Ruth，G.和S.Stibler，“交通流测量的新属性”，RFC 27241999年10月。
[SIP-PROT] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[SIP-PROT]Handley，M.，Schulzrinne，H.，Schooler，E.和J.Rosenberg，“SIP：会话启动协议”，RFC 25431999年3月。
[SMI-V2] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[SMI-V2]McCloghrie，K.，Perkins，D.和J.Schoenwaeld，“管理信息结构版本2（SMI-V2）”，STD 58，RFC 2578，1999年4月。
[SNMP-OVER] "AN OVERVIEW OF SNMP V2.0", Diversified Data Resources, Inc., http://www.ddri.com, 1999.
[SNMP-OVER]“SNMP V2.0概述”，多元化数据资源公司。，http://www.ddri.com, 1999.
[TIPHON] "Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON); Inter-domain pricing, authorization, and usage exchange", TS 101 321 V1.4.2, December 1998.
[TIPHON]“网络上的电信和互联网协议协调（TIPHON）；域间定价、授权和使用交换”，TS 101 321 V1.4.2，1998年12月。
[XML] Bray, T., J. Paoli, and C. Sperberg-McQueen, "Extensible Markup Language (XML) 1.0", W3C Recommendation, February 1998.
[XML]Bray，T.，J.Paoli和C.Sperberg McQueen，“可扩展标记语言（XML）1.0”，W3C建议，1998年2月。
[XML-DATA] "XML Schema Part 2: Datatypes", W3C Working Draft 07 April 2000, April 2000.
[XML-DATA]“XML模式第2部分：数据类型”，W3C工作草案，2000年4月7日，2000年4月。
[XML-SCHM] "XML Schema Part 1: Structures", W3C Working Draft 7 April 2000, April 2000.
[XML-SCHM]“XML模式第1部分：结构”，W3C工作草案，2000年4月7日，2000年4月。
Nevil Brownlee Information Technology Systems & Services The University of Auckland
NevelBrand Lee信息技术系统与服务奥克兰大学
Phone: +64 9 373 7599 x8941
EMail: n.brownlee@auckland.ac.nz
Phone: +64 9 373 7599 x8941
EMail: n.brownlee@auckland.ac.nz
Alan Blount MetraTech Corp. 330 Bear Hill Road Waltham, MA 02451
Alan Blount MetraTech公司，马萨诸塞州沃尔瑟姆市熊山路330号，邮编02451
EMail: blount@alum.mit.edu
EMail: blount@alum.mit.edu
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编辑功能的资金目前由互联网协会提供。