[要約] RFC 2924は、会計属性とレコード形式に関する標準化されたガイドラインです。その目的は、会計情報の一貫性と相互運用性を確保することです。
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.
Copyright（c）The Internet Society（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デバイス、音声およびファックスゲートウェイ、会議橋が含まれます。
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.
サービス要素は、サービス消費者にサービスを提供します。以前、および/またはサービスが提供されている間、サービス要素は会計サーバーに使用イベントをレポートします。あるいは、Accounting Serverは、使用イベントのサービス要素を照会する場合があります。使用イベントは、単独または大量に送信されます。
+------------+ +-----------+ +------------+
| 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サーバーが必要とする情報を提供して、ユーザーを認証し、認定ネットワークサービスを確立します。
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と共有会計サーバーの間で会計情報を伝達するために拡張されました。これは、一連の半径会計属性[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パケットタイプと認証器（60オクテット）と長さを含む短いヘッダーがあり、その後、各属性に1つの（タイプ、長さ、値）トリプルのシーケンスが続きます。
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.
半径は非常に広く使用されており、それに対する多くの重要な新しい拡張機能が提案されています。たとえば、[rad-ext]は、拡張機能について説明して、拡張可能な認証プロトコル（EAP）とAppleリモートアクセスプロトコル（ARAP）を実装します。[RAD-TACC]は、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
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
84 ARAP-Challenge-Response 85 Acct-Interim-Interval 87 NAS-Port-Id 88 Framed-Pool
84 ARAP-CHALLENGE-RESPONSE 85 ACCT-INTERIM-INTERVAL 87 NAS-PORT-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 ACCT-Tunnel-Connection 69 Tunnel-Password
81 Tunnel-Private-Group-ID 82 Tunnel-Assignment-ID 83 Tunnel-Preference
81 Tunnel-Private-Group-ID 82 Tunnel-assignment-ID 83トンネルプレーファレンス
90 Tunnel-Client-Auth-ID 91 Tunnel-Server-Auth-ID
90 Tunnel-Client-Auth-ID 91 Tunnel-Server-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 Framework [Diam-Fram]は、ポリシー、AAA、およびリソース制御を実行するためにクライアントが使用するポリシープロトコルを定義します。これにより、単一のサーバーが多くのサービスのポリシーを処理できます。直径プロトコルは、ヘッダーとオブジェクトが続くもので構成されています。各オブジェクトは、属性値ペア（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.
直径は、ヘッダー形式、セキュリティ拡張、要件、および少数の必須コマンドとAVPを指定するベースプロトコルを定義します。新しいサービスは、ベースプロトコルを拡張して新しい機能をサポートすることにより、直径を拡張できます。
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).
直径の重要な差別化要因の1つは、サーバー間通信に対する固有のサポートです。これはさまざまな方法で実現できますが、最も便利な機能は、一連の直径サーバー（プロキシチェーンとして知られている）で「プロキシ」メッセージを「プロキシ」する機能です。
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.
直径の会計拡張ドキュメント[Diam-act]は、直径ベースプロトコルに会計記録を安全に転送するプロトコルを定義することにより、直径を拡張します。これには、「紹介ブローカー」モデルに従って、会計記録が1つ以上の中間プロキシを通過する場合が含まれます。
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レコードを転送するための直径レコードを定義します（以下を参照）。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.
直径AVPは、[直径]で定義された16ビット数によって識別されます。そのドキュメントで見つかったAVPのほとんどは、RADIUSプロトコル[RAD-Prot]からコピーされたため、半径と直径の両方のサーバーに同じ辞書ファイルとユーザーファイルを読み取らせることができます。
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が提供する後方互換性は、展開を容易にすることを目的としています。この目的のために、直径は半径属性を継承し、独自の属性をいくつか追加します。
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 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
4（割り当て、 *）17（割り当てされていない）21（割り当てなし）24（割り当てされていない、 *）25（割り当てられていない、 *）27（割り当てられていない、 *）-PassWord-Policy 480 Accounting-Record-Type 481 Adif-Record 482 Accounting-Interim-interval 483 Accounting-Delivery-Max-Batch 484 Accounting-Delibリー-Max-Delay 485 Accounting-Record-Number
600 SIP-Sequence 601 SIP-Call-ID 602 SIP-To 603 SIP-From
600 SIP-Sequence 601 SIP-CALL-ID 602 SIP-TO 603 SIP-FROM
[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）のいずれかを使用する能力として大まかに定義される場合がありますが、正式な顧客とベンダーの関係を1つだけに維持します。ローミングを成功させるための1つの要件は、効果的な会計の提供です。
[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は、フローテーブル行から読み取られる属性値を指定する「データパッケージ」規則を使用します。メーターは、BERエンコードされたシーケンス内で必要な各属性の値を返します。これは、シーケンス全体に1つのオブジェクト識別子のみがあり、データの取得に必要なバイト数を大幅に削減することを意味します。
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 null 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
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
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
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
50 MatchingStoD Integer PME variable
50 MatchingStod Integer PME変数
51 v1 Integer Meter Variables
52 v2 Integer
53 v3 Integer
54 v4 Integer
55 v5 Integer
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ベースの管理用の管理されたオブジェクトの最小セットを定義します。会計に関連するものを明示的に定義していませんが、isdnbearerCheDunitsを次のように定義しています
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 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
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 atmAcctngReceiveTrafficDescriptorType26 atmacctngreceivetrafficdescriptorparam1 27 atmacctngreceivetrafficdescriptorparam2 28 atmacctngreceivetrafficdescriptorparam329 atmacctngreceivetrafficdescriptorparam430 atmacctngadcctncctrparparparparparparparparparparparparparparparparparparparparparparparparparparparparparparparparparparparparparparparparparparparparparparparparparparparmcctngevetrafficdescriptorparam4 AlledPartySubAddress 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]
- 統合サービスアーキテクチャ（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要求を明示的に認めたり拒否したりすることで応答します。定量化可能なリソース要件を持つ特定のアプリケーションは、INTSVパラメーター[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 CodePoint（DSCP）に基づいて、パケットを少数の集計フローまたは「クラス」の1つに分類します。各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 Qosservice 99 Qosstyle 100 Qosrate 101 Qosslackterm 102 Qostokenbucketrate 103 Qostokenbucketsize 104 Qosminpolicedunit 105 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
一般的なオブジェクトセッションセッション統計テーブルセッション送信者テーブル予約リクエスト受信テーブル予約リクエスト転送されたテーブル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は、CDR（コール詳細レコード）がPOT、ISDN、および（インテリジェントネットワーク）のネットワーク要素で作成および管理される方法を指定します。
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が（NE）ネットワーク要素から輸送される方法が含まれていることに注意してください。そこでは、使用されている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サブスクライバーが提供する2つのAccountCodeInputアカウントコード（請求用）。
78 additionalParticipantInfo (No details given)
78 adthipparticantinfo（詳細は示されていません）
5 b-PartyCategory Subscriber category for called subscriber.
5 B-Partyategoryサブスクライバーカテゴリと呼ばれるサブスクライバーのカテゴリ。
4 bearerService Bearer capability information (only for ISDN calls).
4 BearerService Bearer機能情報（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 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 CallPartynumberの電話番号は、呼び出されたサブスクライバーの電話番号です（「転用」または「翻訳された」番号である場合があります。
7 callingPartyCategory Calling subscriber category.
7 CallingPartyategory Calling Subscriberカテゴリ。
8 callingPartyNumber Telephone number of the calling party.
8 CallingPartynumber呼び出し党の電話番号。
10 callingPartyNumberNotScreened An additional, user-provided (not screened) number to the calling party.
10 CallingPartYnumberNotsCreed Calling PartyNumberNotsCreed Calling Partyに追加のユーザーが提供する（スクリーニングされていない）番号。
11 callingPartyType Calling subscriber type.
11 CallingPartyType Calling Subscriber Type。
74 carrierId Carrier ID to which the call is sent.
コールが送信される74 Carrierid Carrier 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 ConfigurationMask時間消費、例えばb-annswerから終了時間、部分的なコールレコードなどの間。
18 conversationTime Time consumption from B-answer to end of call.
18 AnswerからCallの終了までの会話時間の時間消費。
19 creationTriggerList List of trigger values which will create Call Detail data objects.
19 CoredTriggerListは、詳細データオブジェクトを呼び出すトリガー値のリストを作成します。
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 datavalityは、NEが問題を抱えていることを示しています。生成されたコール詳細レコードの内容は信頼できません。
23 durationTimeACM Time consumption from seizure until received ACM.
23発作からACMを受け取るまでの時間消費。
21 durationTimeB-Answer Time consumption from seizure until B-answer.
21 HurterimeB-Answer発作からB-answerまでの時間消費。
22 durationTimeNoB-Answer Time from seizure to termination when no B-answer was received.
22 b-annswerが受信されなかった場合の発作から終了までの22 durationtimenob-andwer時間。
25 exchangeInfo Identity of exchange where Call Detail record was generated.
25通話詳細レコードが生成された交換のExchangeInfo ID。
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（Intelligent Network）サービスの使用に関する情報が含まれています。
32 iNSpecificInformation Contains information about the use of one IN service.
32 InptificInformationには、サービス中の使用に関する情報が含まれています。
33 iSUPPreferred Indicate whether an ISUP preference was requested.
33 Isuppreferedは、ISUPの選好が要求されたかどうかを示します。
28 immediateNotificationForUsageMetering Indicates that the Call Detail records requires immediate data transfer to the Operations System.
28即時検証ForUSAGEMETERINGは、通話の詳細レコードには操作システムへの即時データ転送が必要であることを示しています。
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 operatorspecific1AdddiTionalNumber 40オペレーターspecific2additionalnumber 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.
45 CDR（Call Record）出力が部分的な場合は、部分的に含まれています。このようなCDRには、部分的な記録数を示すフィールドがあります。
77 participantInfo (No details given).
77 PrivitionAntininfo（詳細は記載されていません）。
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周期的なものは、CDRファイルを作成する間隔を定義します。
48 personalUserId Internationally unique personal User Identity (for UPT calls).
48 PersonalUserid国際的にユニークなパーソナルユーザーアイデンティティ（UPTコール用）。
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 Progressは、呼び出しの期間中に発生したイベントについて説明します。
51 queueInfo Used to record usage of queueing resources with IN calls.
51 QueueInfoは、コールでキューイングリソースの使用を記録するために使用されます。
52 receivedDigits The digits dialed by the subscriber. (Normally only included for customer care purposes).
52受信サブスクライバーによってダイヤルされた数字を受信しました。（通常、カスタマーケアの目的でのみ含まれています）。
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]は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）>数値を識別します。数千人のセパレーターとして句読点のない10進分離器として期間（。）を使用して表現しました。
<!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 | Email | Transport | International | National | Network | Subrevided | E164Prefix）は、宛先の主要な識別を提供します。
<!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."
<！要素サービス空>は、価格、承認、または報告されているサービスの種類を示します。空のサービス要素は、基本的なインターネットテレフォニーサービスを示します。これは、仕様の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 |電子メール|インターナショナル|国家|ネットワーク|サブスクライバー|省略| e164prefix）は、呼び出しのソースの主要な識別を提供します。
<!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.
<！Element TransactionID（#PCDATA）>は、特定の承認されたトランザクションに割り当てられた整数、10進価値のある識別子が含まれています。
<!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.
<！要素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]は、Accountingサービスの定義を作成し、サービスの使用情報を送信するために使用されるHTTPによって輸送されるXMLベースのプロトコルです。そのサービス定義はパラメーター化されており、動的であるため、サービスまたは属性自体の定義はありませんが、実装者は独自に作成できます。属性が取得できる基本データ型のみを指定します。文字列、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の会計ファイル形式を定義し、ファイル転送プロトコルで検索できるようにすることにより、これをさらに段階的に運びます。
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セットです。コールレコードは、後の処理のために収集される前に、おそらく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パケットは、（タイプ、長さ、値）トリプルとして、一連の属性とその値を持ちます。値フィールドの形式は、4つのデータ型の1つです。
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 GMT以降の秒。
Each DIAMETER message consists of multiple AVP's that are 32-bit aligned, with the following format:
各直径メッセージは、次の形式を使用して、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.
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数は、半径との後方互換性のために予約されており、半径[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
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
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
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 convention (or something like it) to identify attributes, together with all the sets of attributes covered by the [ASG-NBR] document.
デフォルトのプロトコル（属性が来ると想定される）を指定し、例外を特定するADIFアプローチは、はるかに実用的であると思われます。したがって、AAAは、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入力パーサーが必要ですが、プレーンテキストファイルを使用すると、理解しやすくなります。
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.
レコード形式とプロトコルは、データの局所性と明示的なタグ付けの組み合わせを使用して、データ要素を識別します。たとえば、Mail [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.
一部のレコード形式はタグを使用しません - DATA要素は、レコード構造内の位置によってのみ識別されます。このプラクティスでは、レコードスペースのオーバーヘッドの量が少ないことを提供しますが、すべてのレコードリーダーを変更して変更を処理するために変更する必要があるため、要素を追加または削除することでレコード形式を後で変更することは困難です。タグ付きデータにより、古い読者は予期しないタグを検出し、必要なデータが欠落しているかどうかを検出できます。明示的なタグを運ぶことのオーバーヘッドを担うことができる場合、可能であれば明示的にタグ付けされたデータ要素を使用することが有利です。
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.
レコード形式とプロトコルで使用されるプリミティブデータ型の標準セットを定義すると便利です。以前のアートを見ると、直径はデータ（任意のオクテット）、弦（UTF-8）、アドレス（32または128ビット）、整数32、整数、時間（1970年以来32ビット、秒）、および複合体をサポートします。MSIX [MSIX-Spec]は、String、Unistring、Int32、Float、Double、Boolean、およびTimestampをサポートしています。SMIV2 [SMI-V2]は、ASN.1タイプの整数、Octet String、およびオブジェクト識別子、およびアプリケーション定義型タイプinteger32、iPaddress、Counter32、Gauge32、unsigned32、Timeticks、Opaque、および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：データ型」[XML-DATA]ドキュメントで指定されているデータ型を考慮することは価値があるかもしれません。このドキュメントは、ベースタイプの豊富なセットを指定し、ベースタイプをさらに制約する派生物を指定するメカニズムを指定します。
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.
一意の識別子を作成するための多くの方法はよく知られています。人気のある識別子の1つは、単調に増加するシーケンス数、大きなランダム値、ネットワーク要素識別子、およびタイムスタンプの融合です。エントロピーのもう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.
Network News Transfer Protocol [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:
私たちは、半径会計[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
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-PACTETS 48 ACCT-OUTPUTET-Packets 49 ACCTターミネート原因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に多少似ています。コンテンツタイプ、コンテンツエンコード、受け入れエンコード、および転送エンコードヘッダーフィールドを通じて、そのコンテンツの説明をサポートするという点で異なります。新しいタイプのコンテンツは、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を一般的な管理プロトコルとして構想し、プライベートMIBSを使用して拡張を許可しました。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アカウンティング）のいずれか、または1つ以上のサービスが定義されており、後にプロトコルに追加される「拡張」サービスの提供を備えた完全に指定されています。後者は望ましいが、会計レコード形式とプロトコルがサービス定義のフレームワークのみを提供し、サービス定義（および標準化）を任せて努力を分離するために、より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を認識している場合、Accounting Severがサービスの使用（後方互換性）を適切に説明するために追加情報を必要としない場合、サービス要素からバージョン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 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.
複数のエンコーディングをサポートするには欠点があります。オプションでサポートされている複数のエンコーディングは、サービス要素と会計サーバーの間の機能交換の要件を義務付けています。また、実装は「漂流」する傾向があり、あるエンコードは別のものよりもサポートされています。すべてのエンコーディングが必須でない限り、実装者は、間違ったエンコードを選択したため、相互操作ができないと判断する場合があります。
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。and 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、「割り当てられた番号」、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]情報処理システム - オープンシステムの相互接続 - 抽象的な構文表記の仕様（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.、Greene、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.、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）の基本エンコードルールの仕様、国際標準化機関、国際標準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.、Calhoun、P.R.、Patel、P。and Zorn、G。、「直径の会計拡張」、進行中の作業。
[DIAM-AUTH] Calhoun, P.R. and Bulley, W., "DIAMETER User Authentication Extensions", Work in Progress.
[Diam-Auth] Calhoun、P.R。and 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。、「直径フレームワークドキュメント」、進行中の作業。
[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 2475、1998年12月。
[HTML] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language - 2.0", RFC 1866, November 1995.
[HTML] Berners -Lee、T。およびD. Connolly、「HyperText Markup Language -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] 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 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] Braden、R.、Clark、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.、Partridge、C。and 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。、「The MD5 Message-Digest Algorithm」、RFC 1321、1992年4月。
[MSIX-SPEC] Blount, A. and D. Young, "Metered Service Information Exchange 1.2", Work in Progress.
[MSIX-Spec] Blount、A。およびD. Young、「Metered Service Information Exchange 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.
[ニュースプロット] Kantor、B。およびP. Lapsley、「Network News Transfer Protocol」、RFC 977、1986年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]「Q3インターフェイスでのTMNアプリケーションの仕様：コール詳細記録」、ITU-T推奨Q.825、1998。
[RAD-ACT] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[Rad-act] Rigney、C。、「Radius Accounting」、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。and Calhoun、P。、「Radius Extensions」、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 2865、2000年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 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] Boyle、J.、Cohen、R.、Durham、D.、Herzog、S.、Rajan、R.およびA. Sastry、「The Cops（Common Open Policy Service）Protocol」、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）」、進行中の作業。
[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、「Review of Roaming Implements」、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、「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] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（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] 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、「トラフィックフロー測定：アーキテクチャ」、RFC 2722、1999年10月。
[RTFM-MIB] Brownlee, N., "Traffic Flow Measurement: Meter MIB", Measurement: Architecture", RFC 2720, October 1999.
[RTFM-MIB] Brownlee、N。、「トラフィックフロー測定：Meter 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-Newa] Handelman、S.、Brownlee、N.、Ruth、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] Handley、M.、Schulzrinne、H.、Schooler、E。and J. Rosenberg、「SIP：SESSION INTIATION Protocol」、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.、Perkins、D。、およびJ. Schoenwaelder、「管理情報の構造バージョン2（SMIV2）」、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の概要」、Diversified Data Resources、Inc.、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
Nevil Brownlee Information Technology＆Servicesオークランド大学
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 Corp. 330 Bear Hill Road Waltham、MA 02451
EMail: blount@alum.mit.edu
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。