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
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.
プロパティの使用状況イベントのコンポーネントを。電話を記述する使用状況イベントは、例えば、「期間」プロパティを持っているかもしれません。
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デバイス、音声およびFAXゲートウェイ、会議ブリッジが含まれます。
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.
使用状況イベントサービス利用のインスタンスの説明。
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 |
+------------+
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パケットは（タイプ、長さ、値）トリプル、各属性に対して1つのシーケンスが続くRADIUSパケットタイプとオーセンティケータ（16オクテット）と長さを含む短いヘッダを有しています。
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）とAppleリモートアクセスプロトコル（ARAP）を実装するための拡張機能について説明します。 [RAD-TACC]はトンネルは、PPTPとL2TPなどのプロトコルを使用して効果的に連動するようにRADIUSを可能にするために拡張機能を説明します。
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:
各RADIUS属性は、8ビットの番号によって識別される、RADIUSタイプフィールドと呼びます。最新のこのフィールドの値は、最新の割り当て番号の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
RADIUSアトリビュート[RAD-PROT] 36ログイン-LAT-グループ37 1ユーザー名 - AppleTalkのリンクフレームを選ぶ38 2ユーザー・パスワードのAppleTalk-ネットワークフレームを選ぶ39 3 CHAP-パスワードのAppleTalkゾーン額縁4 NAS-IP-アドレス60 CHAPチャレンジ5 NASポート61 NASポート型6サービスタイプ62ポートリミット7 63ログイン-LATポート8入れる-IPアドレス、プロトコル入れる9入れる-IP-ネットマスクRADIUSアカウンティング10入れるルーティング属性[RAD-ACT] 11フィルタ-ID 12 40 ACCT-ステータス型13入れる圧縮41 ACCT-遅延時間14ログイン-IP-ホスト42 ACCT-入力オクテット15ログイン・サービス43 ACCT-出力 - -MTU入れますオクテット16ログイン-TCPポート44アカウンティング・セッションId 17（未割り当て）45 ACCT-本物18返信メッセージ46 ACCT-セッション時間19コールバック・ナンバー47 ACCT-入力-パケット20コールバック-ID 48 ACCT-出力 - パケット21（未割り当て）49 ACCT-終了原因22 50 ACCT-マルチセッションId-ルート入れる23 51 ACCT-リンク数24状態25クラスRADIUS拡張属性26ベンダー固有[RAD-EXT-IPX-ネットワーク入れます] 27セッションタイムアウト28アイドルタイムアウト52のAcct-入力-Gigawo RDS
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
54未使用31は、発呼ステーション-ID 55イベントタイムスタンプ32 NAS-識別子33プロキシ・ステート70 ARAP-パスワード34ログイン-LAT-サービス71 ARAP-特徴-ステーション-IDと呼ばれる29終了アクション53 ACCT-出力-Gigawords 30 35ログイン-LAT-ノード72 ARAPゾーンアクセス73 ARAP-Securityの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のAcct-中間間隔87 NAS-ポートID 88フレームを選ぶ - プール
RADIUS Tunneling Attributes [RAD-TACC]
RADIUSトンネル属性[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のAcct-トンネル接続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トンネルサーバー-AUTH-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アカウンティング拡張文書[DIAM-ACT]は確実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アカウンティングプロトコル[DIAM-ACT]はADIFレコード（以下を参照）を転送するためのDIAMETERレコードを定義します。これは、会計情報は、DIAMETERサーバ間で配信されるべき方法を指定する5つの新しい属性（480..485）を紹介します。
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.
DIAMETER用の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.
RADIUSのために使用されている属性番号の下のリスト内の属性が、DIAMETERのためにスター（*）で示されていません。 DIAMETERが使用するRADIUS属性は、ここでは再び記載されていません。
The DIAMETER attributes are:
DIAMETER属性は、次のとおりです。
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が入れます-password-ポリシー
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-CALL-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）のいずれかを使用する能力として定義することができます。成功したローミングのための一つの要件は、効果的な会計処理を提供することです。
[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 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.
RTFM流量測定はRTFMメーター[RTFM-MIB]で作られ、SNMPを用いてRTFMメーター読者によって収集されます。 MIBは、フローテーブルの行から読み出される属性値を指定する「DataPackage」規約を使用します。メーターは、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元ピア・タイプInteger 9元ピアアドレス列10元ピアマスクストリング11のソーストランスInteger型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宛先AdjacentMaskストリング18宛先PeerType整数19宛先PeerAddressストリング20宛先PeerMaskストリング21宛先TransType整数22宛先TransAddressストリング23宛先TransMaskストリング
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フォワードバイト整数ソース・ツー・destがカウンタ28パケットを転送整数29リバースバイトの整数DestはツーSourceは32最終アクティブ時間タイムスタンプ33ソースサブスクライバID文字列セッションは34宛先加入者のID属性30リバースパケット整数31ファーストタイムスタンプの活動時間をカウンタ文字列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デスティネーションクラスInteger型38のフロークラス整数39出典種類整数40宛先の種類整数41フロー種類整数属性
50 MatchingStoD Integer PME variable
50 MatchingStoD整数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]はISDN端末インターフェイスのSNMPベースの管理のための管理オブジェクトの最小セットを定義します。これは、明示的に、しかし、それはようisdnBearerChargedUnitsを定義し、会計処理に関連するものを定義していません
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, isdnBearerCallConnectTime TimeStamp,
isdnBearerChargedUnits Gauge32
}
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接続のための値を保持するテーブルがあります。必要な接続は、オクテット列である「リスト」内のビットをセットすることによって示されています。例えば、最初の8つのATM接続のために受信されたセルの数を含む集合は（atmAcctngReceivedCells、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】このようなATMなどの接続指向型ネットワークのための課金情報の収集と格納を制御するために使用される管理オブジェクトを提供するMIBを定義します。会計データは、ファイル転送プロトコルを介した後の検索のためのファイルに収集されます。アカウンティングファイル内のレコードは、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 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
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 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
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.
私たちは、単純な「ベストエフォート」の接続性以上のものを提供向かって移動すると、興味の驚異的なサージがあった（と上で動作）インターネットセッションのためにサービスの管理品質を提供するためのプロトコルを。これは、「統合サービス」、オーディオ、ビデオ、リアルタイム、および単一のネットワークインフラストラクチャ内の古典的なデータトラフィックの、すなわち輸送の提供のために特に重要です。
Two approaches to this have emerged so far:
これには2つのアプローチがこれまでに登場しました。
- 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]
- それに付随するシグナリングプロトコル、RSVP [RSVP-ARC]、およびRSVPの共通オープンポリシーサービスプロトコル、COPS [RAP-COPS]とのサービス統合型アーキテクチャ（イントサーブ）[IIS-ARC]、
- 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ルータにおいて、パケットのDSCPによって呼び出される「ホップ単位動作」（PHB）に供されます。 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-ネバ]内および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
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
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は、CDRは（コール詳細レコード）POTS、ISDNおよびIN（インテリジェントネットワーク）のためのネットワーク要素で生成され、管理される方法を指定します。
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.
各コールは、コールの期間中に発生したイベントを記述する1つまたは複数のレコードを生成します。データをリアルタイムに生成することができる（単一の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は、彼らが、彼らが使用しているOS（オペレーションシステム）に生成されている（NE）ネットワーク要素から輸送される方法を含んでいることに注意してください。
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 accountCodeInputアカウントコード（課金のために）、加入者によって供給されます。
78 additionalParticipantInfo (No details given)
78 additionalParticipantInfo（NO詳細は与えられていません）
5 b-PartyCategory Subscriber category for called subscriber.
被呼加入者のための5のB-PartyCategory加入者カテゴリ。
4 bearerService Bearer capability information (only for ISDN calls).
4 bearerServiceベアラ能力情報（ISDNコールのみ）。
13 cDRPurpose Reason for triggering this Call Data Record.
このコールデータレコードをトリガするための13 cDRPurpose理由。
70 callDetailDataId Unique identifier for the CallDetailData object.
オブジェクトのための70 callDetailDataId CallDetailData一意の識別子。
79 callDuration Duration of call
コールの79 callDuration期間
6 callIdentificationNumber Identification number for call; all records produced for this call have the same callIdenfificationNumber.
コール6 callIdentificationNumber識別番号。この呼び出しのために生産されるすべてのレコードが同じcallIdenfificationNumberを持っています。
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 calledPartyNumber電話番号（「流用-する」または「翻訳」の数であってもよいです。
7 callingPartyCategory Calling subscriber category.
7 callingPartyCategory加入者カテゴリを呼び出します。
8 callingPartyNumber Telephone number of the calling party.
発信者の8 callingPartyNumber電話番号。
10 callingPartyNumberNotScreened An additional, user-provided (not screened) number to the calling party.
10は発呼者に追加、ユーザー提供（スクリーニングではない）の数をcallingPartyNumberNotScreened。
11 callingPartyType Calling subscriber type.
加入者のタイプを呼び出す11 callingPartyType。
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 chargedParticipant参加者は、使用のために充電されます。
15 chargingInformation Charging information generated by a Network Element which is capable of charging.
充電が可能なネットワーク構成要素によって生成された課金情報を15 chargingInformation。
17 configurationMask Time consumption, e.g. from B-answer to termination time, between partial call records, etc.
17 configurationMask時間消費、例えばB-答えからの終了時に、部分的な通話記録の間、など
18 conversationTime Time consumption from B-answer to end of call.
コールの最後にB-答えから18 conversationTime時間消費。
19 creationTriggerList List of trigger values which will create Call Detail data objects.
コール詳細データオブジェクトを作成するトリガ値の19 creationTriggerList一覧。
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がNEに問題があることを示し、生成されたコール詳細レコードの内容は、信頼できるものではありません。
23 durationTimeACM Time consumption from seizure until received ACM.
受信ACMまでの発作から23 durationTimeACM時間消費。
21 durationTimeB-Answer Time consumption from seizure until B-answer.
B-解答までの発作から21 durationTimeB-回答時間の消費量。
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 exchangeInfoアイデンティティ。
26 fallbackBearerService Fallback bearer capability information for a call.
コール26 fallbackBearerService代替ベアラ能力情報。
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は、サービス内の1つの使用に関する情報が含まれます。
33 iSUPPreferred Indicate whether an ISUP preference was requested.
33 iSUPPreferredはISUP嗜好が要求したかどうかを示します。
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 operatorSpecific1AdditionalNumber 40 operatorSpecific2AdditionalNumber 42 operatorSpecific3AdditionalNumber追加参加者情報をオペレータに定義されました。
39 operatorSpecific1Number 41 operatorSpecific2Number 43 operatorSpecific3Number Operator-defined participant information.
39 operatorSpecific1Number 41 operatorSpecific2Number 43 operatorSpecific3Number参加者情報をオペレータ定義。
44 originalCalledNumber Telephone number of the original called party.
元の着信側の44 originalCalledNumber電話番号。
45 partialGeneration Included if the CDR (Call Detail record) output is partial. Such CDRs have a field indicating their partial record number.
CDR（詳細レコードを呼び出して）出力が部分的であれば45 partialGenerationが含まれています。このようなCDRは、その部分のレコード数を示すフィールドを持っています。
77 participantInfo (No details given).
77 participantInfo（NO詳細は与えられていません）。
46 percentageToBeBilled Percentage to be billed when normal billing rules are not to be followed.
通常の課金ルールに従うべきでないとき46 percentageToBeBilled割合が課金されます。
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コールの）固有の個人ユーザーID。
49 physicalLineCode Identifies the call subscriber's physical line.
49 physicalLineCodeは、コール加入者の物理回線を識別します。
50 progress Describes an event which occurred during the life of a call.
50の進捗状況は、通話の期間中に発生したイベントを記述します。
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 receivedDigits加入者によってダイヤルされたディジット。 （通常は唯一の顧客ケアの目的のために含まれています）。
53 recordExtensions Information elements added by network operators and/or manufacturers in addition to the standard ones above.
上記標準のものに加えて、ネットワークオペレータ及び/又は製造者によって追加された53のrecordExtensions情報要素。
TIPHON [TIPHON] is an XML-based protocol, carried by HTTP, which handles accounting and authorization requests and responses.
TIPHON [TIPHON]は、会計と承認要求と応答を処理するHTTPによって運ばれるXMLベースのプロトコル、です。
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.
<！ELEMENT通貨（#PCDATA）> <！ELEMENT量（#PCDATA）>数値を識別します。数千の区切りとしてない句読点との小数点としてピリオド（。）を使用して発現させました。
<!ELEMENT CallId (#PCDATA)> Contains a call's H.323 CallID value, and is thus used to uniquely identify individual calls.
<！ELEMENT CallId（#PCDATA）>コールのH.323 CallID値が含まれていますので、一意に個々の通話を識別するために使用されます。
<!ELEMENT Currency (#PCDATA)> Defines the financial currency in use for the parent element.
<！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.
<！ELEMENT DestinationInfoタイプ（E164 | H323 | URL |メール|交通機関|国際|全国の|ネットワーク|加入|省略| e164prefix）は、コールの送信先の主要な識別情報を提供します。
<!ELEMENT Increment (#PCDATA)> Indicates the number of units being accounted.
<！ELEMENTインクリメント（#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サービスEMPTY>は、価格の許可、または報告されているサービスの種類を示します。空のサービス要素は、仕様の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.
<！ELEMENT DestinationInfoタイプ（E164 | H323 | URL |メール|交通機関|国際|全国の|ネットワーク|加入|省略| e164prefix）は呼び出し元の主な識別を提供します。
<!ELEMENT Timestamp (#PCDATA)> A restricted form of [ISO-DATE] that indicates the time at which the component was generated.
<！ELEMENTタイムスタンプ（#PCDATA）>成分が生成された時刻を示す[ISO-DATE]のA制限形。
<!ELEMENT TransactionId (#PCDATA)> Contains an integer, decimal valued identifier assigned to a specific authorized transaction.
<！ELEMENT 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
<！ELEMENTユニット（#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は、このようにすべてのオブジェクトのオブジェクト識別子を持つようになる避け、BERの文字列として、このようなレコードを取得するためにSNMPを使用しています。
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これにより、より効率的な代替手段を提供単にSNMPを使用してレコードを検索するために、ASN.1でアカウンティングファイルフォーマットを定義し、ファイル転送プロトコルによる検索のためにそれが利用可能にすることによって、さらにこの段階を運びます。
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コール録音は、Q.825属性の指定されたグループを含むASN.1のSETです。通話記録は、おそらく後の処理のために収集される前に、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.
半径パケットは（タイプ、長さ、値）トリプルとして、属性とその値のシーケンスを運びます。値フィールドのフォーマットは、4つのデータ型のいずれかです。
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ビットの最初の値が、最も重要なオクテット - 秒は00:00:00 GMT、1970年1月1日以降の標準的な属性は、このデータ型を使用していないが、それはベンダー固有の属性内で使用可能性のためにここに示されています。
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 ...
+-+-+-+-+-+-+-+-+
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（0に設定しなければなりません）Rリザーブビット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
例：ADIFファイルのエンコーディング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：1999年3月2日12時20分17秒-0500＃NAS-IP-アドレス4：204.45.34.12＃NAS-ポート5：12＃NASポート型
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＃ACCT-遅延時間41：14＃ACCT-入力オクテット42：234732＃ACCT-出力オクテット43：15439 ＃アカウンティング・セッションId 44：185＃ACCT-本物45：1＃アカウンティングセッションタイム46：1238＃ACCT-入力-パケット47：153＃ACCT-出力-パケット48：148＃ACCT-終了原因49 ：11＃ACCT-マルチセッションID 50：73＃ACCT-リンク数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ベースのスキームは、かなり複雑なバイナリ構造であることに悩まされています。これは、1つは、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.
RADIUSやDIAMETERなどのバイナリ方式では、単純な構造を持っていますが、彼らはあまりにも専用のツールが必要です。一般的な使用のために、彼らは彼らが他のプロトコルからの属性を使用することができるように拡張する必要があります。
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 Service definition namespace management
O分離または一体の記録フォーマットとサービス定義O基本データ・タイプの標準セットOトランスポートプロトコル：プロトコルの一部又は別途定義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 |
+------------+
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 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.
レコード・フォーマットとプロトコルは、データ要素を識別するために、データの局所性および明示的タグの組み合わせを使用します。メールは[RFC822]、例えば、メッセージの本体に続くいくつかの属性と値のペアで構成されるヘッダブロックを定義します。各ヘッダフィールドは、明示的にタグ付けされているが、の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はまた、測定フィールドのプロパティの単位をdenominatesインクリメントフィールドを、運びます。この追加の利便性が必要であるかどうかは、議論の問題です。
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.
レコード形式とプロトコルによって使用されるプリミティブデータタイプの標準セットを定義することが有用です。先行技術を見ると、直径がデータ（任意オクテット）、文字列（UTF-8）、アドレス（32または128ビット）、Integer32の、Integer64、時間（32ビット、1970年秒）、及びコンプレックスをサポートします。 MSIX [MSIX-SPEC]は文字列、UNISTRING、のInt32、フロート、ダブル、ブール、およびタイムスタンプをサポートしています。 SMIv2の[SMI-V2]はASN.1タイプINTEGER、OCTET STRINGを、オブジェクト識別子、およびアプリケーション定義型Integer32の、IPアドレス、Counter32の、Gauge32、Unsigned32の、時間刻み、不透明、および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.
1988 [ISO-DATE]タイムスタンプ：適切なセットは、おそらくブール値、32ビットおよび64ビット符号付き整数、32ビットおよび64ビットの浮動小数点数、任意のオクテット、UTF-8およびUTF-16文字列、及びISO 8601を含むであろう。 （小数点の両側に指定された精度で）通貨額を表すことが可能な固定精度の数値は、それらが発生した精度の問題に免疫があるように、1つは固定小数点量を表現しようとすると、アカウンティングレコードフォーマットにおいて有用であることが分かっています浮動小数点数。
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.
[XML-DATA]文書：W3Cの「データ型XMLスキーマパート2」で指定されているデータ型を検討する価値があるかもしれません。その文書には、さらに基本型を制約導出を指定するメカニズムとともに、ベースタイプの豊富なセットを指定します。
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.
サービス要素は、独自のユニークな識別子を作成できるようにするために好都合です。このように、使用状況イベントを作成することができ、会計Serverや他の中央当局の関与なしにアーカイブ。
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.
一意の識別子を作成するための多くの方法がよく知られています。 1つの一般識別子が単調に増加するシーケンス番号、大きなランダム値、ネットワーク要素識別子、およびタイムスタンプの融合です。エントロピーの別の可能なソースは、レコード自体の全て又は一部のハッシュ値です。
RFC 822 [MAIL], RFC 1036 [NEWS], and RFC 2445 [ICAL-CORE] give guidance on the creation of good unique identifiers.
RFC 822 [MAIL]、RFC 1036 [NEWS]、および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.
一般的なインターネットプロトコルや文書のエンコーディングの数を調査し、拡張のために彼らの能力を調べるために有益です。これらのプロトコルは、2つの広いカテゴリーに分類することができます - 拡張と不完全である「フレームワーク」のプロトコルのために少し引当金を持っている「完全指定」プロトコルが、出願書類に連結されたときに、将来の拡張のための基礎を提供します。
Examples of fully-specified protocols are NTP [NTP], NNTP [NNTP], RADIUS Accounting [RAD-ACT], and HTML [HTML].
完全に指定されたプロトコルの例としては、NTP [NTP]、NNTP [NNTP]、RADIUSアカウンティング[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-」実験的な接頭辞を使用することを要求します。内容について、さらに0 Nothingにクリア上位ビットが定義されているとのニュースの内容は、7ビットのデータです。コンテンツタイプのデコーディングを自動化するためのイン・プロトコル機能はありません。
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アカウンティングについて（セキュリティ上の欠点の後）は、第2の最も頻繁に聞いた苦情は、「タイプ」のその事前に割り当てられた固定セットです。これらは、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
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に幾分似ています。それはそのコンテンツタイプ、コンテンツのエンコーディングを通じてその内容の記述をサポートし、エンコードを受け入れ、転送-Encodingヘッダフィールドという点では異なっています。コンテンツの新しいタイプは、HTTPプロトコルを変更することなく指定され、HTTP / 1.1で実施することができます。
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-OVER] "SNMPの概要" から：
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アカウンティング）のいずれかで1つまたは複数のサービスが定義されており、「拡張子」のサービス後のプロトコルに追加する（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つのレコードを受け入れることができます。代わりに、会計Serverは、バージョン2を認識して作られている場合、それはまだオプションでバージョンサービス要素から1つのレコードを受け入れることができ、会計Severのは、サービスの利用（後方互換性）のために適切に考慮して、追加情報を必要としません提供。
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アカウンティングの他の欠点は、汎用サービスの利用状況の説明に使用されるのを妨げます。
"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 implementation is paramount and the application can tolerate any additional processing required to generate, parse, and transport the records.
「冗長」XMLエンコーディングを簡単に実装され、レコードが構文的に既存のツールで確認することができます。 「人間可読」プロトコルは、実装の容易さが重要であり、アプリケーションが生成するのに必要な追加の処理を許容解析し、レコードを輸送することができる「ビットフィールド」プロトコルにエッジを有する傾向があります。
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.
複数のエンコーディングをサポートするには欠点があります。必要に応じて、サポートされる複数のエンコーディングは、サービス要素とアカウンティングサーバ間の機能交換のための要件を義務付けます。また、実装は他よりも優れた、支持された1つの符号化で、「離れてドリフト」する傾向があることができます。すべてのエンコーディングは必須でない限り、実装者は、彼らが間違ったエンコーディングを選んだので、相互運用することができないかもしれません。
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]ミルズ、C.、ハーシュ、G.とG.ルース、 "インターネット会計の背景"、RFC 1272、1991年11月。
[ASG-NBR] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[ASG-NBR]レイノルズ、J.およびJ.ポステル、 "割り当て番号"、STD 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）、国際標準化機構の仕様、国際標準8824、1987年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.、グリーン、W.及びA. Prasadの "ATMネットワークのための課金情報"、RFC 2512、1999年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.、グリーン、W.およびA.プラサド、 "接続指向ネットワークのための会計情報の収集と記憶を制御するためにオブジェクトを管理"、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）のための基本的な符号化規則、国際標準化機構の仕様、国際標準8825、1987年12月。
[DIAM-ACT] Arkko, J., Calhoun, P.R., Patel, P. and Zorn, G., "DIAMETER Accounting Extension", Work in Progress.
[DIAM-ACT] Arkko、J.、カルフーン、P.R.、パテル、P.及びゾルン、G.、 "DIAMETERアカウンティング拡張子"、進行中の作業。
[DIAM-AUTH] Calhoun, P.R. and Bulley, W., "DIAMETER User Authentication Extensions", Work in Progress.
[DIAM-AUTH]カルフーン、P.R.とBulley、W.、 "DIAMETERユーザー認証拡張機能"、進行中の作業。
[DIAM-FRAM] Calhoun, P.R., Zorn, G. and Pan, P., "DIAMETER Framework Document", Work in Progress.
[DIAM-FRAM]カルフーン、P.R.、ゾルン、G.およびパン、P.、 "DIAMETERフレームワーク文献"、ProgressのWork。
[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]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.とW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
[HTML] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language - 2.0", RFC 1866, November 1995.
[HTML]バーナーズ=リー、T.、およびD.コノリー、 "ハイパーテキストマークアップ言語 - 2.0"、RFC 1866、1995年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]フィールディング、R.、ゲティス、J.、モーグル、J. Frystyk、H.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - 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]ドーソン、F.とD. Stenerson、 "インターネットカレンダーとスケジュールのコアオブジェクト仕様"、RFC 2445、1998年11月。
[IIS-ARC] Braden, R., Clark, D. and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[IIS-ARC]ブレーデン、R.、クラーク、D.とS. Shenker、 "インターネットアーキテクチャにおける統合サービス：概要"、RFC 1633、1994年6月。
[IIS-SPEC] Shenker, S., Partridge, C. and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[IIS-SPEC] Shenker、S.、ヤマウズラ、C.とR.ゲラン、 "保証されたサービスの質の仕様"、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.
[MAIL]クロッカー、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 1321、1992年4月。
[MSIX-SPEC] Blount, A. and D. Young, "Metered Service Information Exchange 1.2", Work in Progress.
[MSIX-SPEC]ブラント、A.とD.ヤング、 "従量制サービス情報交換1.2" は、進行中の作業。
[NEWS-MSGS] Horton, M. and R. Adams, "Standard for Interchange of USENET Messages", RFC 1036, December 1987.
[NEWS-MSGS]ホートン、M.およびR.アダムス、 "標準USENETの交換のためのメッセージ"、RFC 1036、1987年12月。
[NEWS-PROT] Kantor, B. and P. Lapsley, "Network News Transfer Protocol", RFC 977, February 1986.
[NEWS-PROT]カンター、B.およびP.ラプスリー、 "ネットワークニュース転送プロトコル"、RFC 977、1986年2月。
[NTP] Mills, D., "Network Time Protocol (NTP)", RFC 958, September 1985.
[NTP]ミルズ、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] "Q3界面でTMNアプリケーションの仕様：詳細記録コール"、ITU-T勧告Q.825、1998。
[RAD-ACT] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RAD-ACT] Rigney、C.、 "RADIUSアカウンティング"、RFC 2866、2000年6月。
[RAD-EXT] Rigney, C., Willats, W. and Calhoun, P., "RADIUS Extensions", RFC 2869, June 2000.
[RAD-EXT] Rigney、C.、Willats、W.とカルフーン、P.、 "RADIUS拡張機能"、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.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、RFC 2865 "ユーザーサービス（RADIUS）でリモート認証ダイヤル"、2000年6月。
[RAD-TACC] Zorn, G., Mitton, D. and A. Aboba, "RADIUS Accounting Modifications for Tunnel Protocol Support", RFC 2867, June 2000.
[RAD-TACC]ソーン、G.、ミトン、D.とA. Aboba、 "トンネルプロトコルサポートのためのRADIUSアカウンティングの変更"、RFC 2867、2000年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]ボイル、J.、コーエン、R.、ダラム、D.、ヘルツォーク、S.、ラジャン、R.およびA. Sastry、 "COPS（共通オープンポリシーサービス）プロトコル"、RFC 2748年1月2000。
[ROAM-ADIF] Aboba, B. and D. Lidyard, "The Accounting Data Interchange Format (ADIF)", Work in Progress.
[ROAM-ADIF] Aboba、B.及びD. Lidyard、 "会計データ交換フォーマット（ADIF）"、ProgressのWork。
[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.、陸、J.、オールソップ、J.、丁、J.およびW.ワング、 "ローミング実装のレビュー"、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.、フォード、P.、ベイカー、F.、チャン、L.、シュペーア、M.、ブレーデン、R.、デイビー、B.、Wroclawski、J 。とE. Felstaine、「統合サービスオペレーション以上のDiffservネットワークのためのフレームワーク」が進行中で働いています。
[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]ブレーデン、R.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP）バージョン1機能仕様"、RFC 2205、1997年9月。
[RSVP-MIB] Baker, F., Krawczyk, J. and A. Sastry, "RSVP Management Information Base using SMIv2", RFC 2206, September 1997.
[RSVP-MIB]ベーカー、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]ブラウンリー、N.、ミルズ、C.およびG.ルース、 "トラフィックフロー測定：アーキテクチャ"、RFC 2722、1999年10月。
[RTFM-MIB] Brownlee, N., "Traffic Flow Measurement: Meter MIB", Measurement: Architecture", RFC 2720, October 1999.
[RTFM-MIB]ブラウンリー、N.、 "トラフィックフロー測定：メーターMIB"、測定：アーキテクチャ」、RFC 2720、1999年10月。
[RTFM-NEWA] Handelman, S., Brownlee, N., Ruth, G. and S. Stibler, "New Attributes for Traffic Flow Measurement", RFC 2724, October 1999.
[RTFM-ネバ] Handelman、S.、ブラウンリー、N.、ルース、G.とS. Stibler、 "交通流計測のための新しい属性"、RFC 2724、1999年10月。
[SIP-PROT] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[SIP-PROT]ハンドレー、M.、Schulzrinneと、H.、学生はE.およびJ.ローゼンバーグ、 "SIP：セッション開始プロトコル"、RFC 2543、1999年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.、パーキンス、D.およびJ. Schoenwaelder、STD 58、RFC 2578、1999年4月 "管理情報バージョン2（SMIv2）の構造"。
[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]ブレイ、T.、J.パオリ、及びC. Sperberg-マックイーン、 "拡張マークアップ言語（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
Nevilブラウンリー情報技術システムアンドサービスオークランド大学
Phone: +64 9 373 7599 x8941 EMail: n.brownlee@auckland.ac.nz
電話：+64 9 373 7599 x8941メール：n.brownlee@auckland.ac.nz
Alan Blount MetraTech Corp. 330 Bear Hill Road Waltham, MA 02451
アラン・ブラントMetraTech社330ベアヒルロードウォルサム、MA 02451
EMail: blount@alum.mit.edu
メールアドレス：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 Editor機能のための基金は現在、インターネット協会によって提供されます。