[要約] RFC 3334は、ポリシーベースの会計に関する標準化された手法を提案しており、ネットワークトラフィックの計測と請求を効率化することを目的としています。
Network Working Group T. Zseby
Request for Comments: 3334 S. Zander
Category: Experimental G. Carle
Fraunhofer FOKUS
October 2002
Policy-Based Accounting
ポリシーベースの会計
Status of this Memo
本文書の位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
Abstract
概要
This document describes policy-based accounting which is an approach to provide flexibility to accounting architectures. Accounting policies describe the configuration of an accounting architecture in a standardized way. They are used to instrument the accounting architecture and can be exchanged between Authentication, Authorization and Accounting (AAA) entities in order to share configuration information.
このドキュメントは、会計アーキテクチャに柔軟性を提供するアプローチであるポリシーベースの会計について説明しています。会計方針では、標準化された方法で会計アーキテクチャの構成を説明しています。これらは、会計アーキテクチャの器具に使用され、構成情報を共有するために認証、承認、会計（AAA）エンティティの間で交換できます。
This document describes building blocks and message sequences for policy-based accounting in the generic AAA architecture (RFC 2903). Examples are given for the usage of accounting policies in different scenarios. It is also shown how accounting components can be integrated into the AAA authorization framework (RFC 2904). This document does not propose a language for the description of accounting policies. Rather, it is assumed that a suitable policy language can be chosen from existing or upcoming standards.
このドキュメントでは、一般的なAAAアーキテクチャ（RFC 2903）におけるポリシーベースの会計の構成要素とメッセージシーケンスについて説明しています。さまざまなシナリオでの会計ポリシーの使用について例が示されています。また、会計コンポーネントをAAA認証フレームワーク（RFC 2904）に統合する方法も示されています。このドキュメントは、会計方針の説明のための言語を提案していません。むしろ、既存または今後の基準から適切な政策言語を選択できると想定されています。
Table of Contents
目次
1. Introduction...............................................2
1.1 Motivation.................................................2
1.2 Document Scope.............................................3
2. Terminology................................................4
3. Impact of Provider Network Characteristics on Accounting...7
4. Business roles and relations...............................8
5. Reference Model and Building Blocks.......................11
6. Accounting Policies.......................................14
6.1 Accounting Policy Condition...............................15
6.2 Accounting Policy Action..................................16
6.3 Example for Meter Configuration...........................17
7. Accounting Services.......................................19
7.1 Integrated Accounting.....................................19
7.2 Discrete Accounting.......................................21
7.3 Intra-Domain Accounting...................................22
7.4 Inter-Domain Accounting...................................23
8. Accounting with different Authorization Models............25
8.1 Agent Sequence............................................25
8.2 Pull Sequence.............................................26
8.3 Push Sequence.............................................27
8.4 Roaming...................................................28
9. Examples..................................................29
9.1 Printing Service Example..................................29
9.1.1 Intra-Domain Accounting...................................29
9.1.2 Inter-Domain Accounting...................................30
9.1.3 User Accounting Indication................................31
9.2 Mobile/Roaming Example....................................31
9.3 Diffserv Example..........................................33
9.4 User Accounting Indication Example........................37
10. Security Considerations...................................39
11. References................................................41
12. Acknowledgments...........................................42
Author's Addresses..............................................43
Full Copyright Statement........................................44
Even if we will have much more bandwidth in the future than now, the control of network resource utilization remains essential for the support of applications with special demands and for the prevention of (malicious or accidental) waste of bandwidth. Charging provides a possibility to control utilization and sharing of network resources. Charging in multi-service networks can be done based on the reserved or the actual used resources. Charging on reserved resources is an important concept since reservation usually precludes other users from using the reserved resources. Nevertheless, if charging is limited to reservation parameters only, the applied charge depends on the ability of the user to give a good prediction of the expected traffic characteristics. This can be extenuated by using a charging scheme that is based on both the reserved and the used resources. In order to support usage-based charging, the collection of information about the resource reservation and utilization is required. The collection of data about resource usage is called accounting.
今よりもはるかに多くの帯域幅があるとしても、ネットワークリソースの利用の制御は、特別な要求を伴うアプリケーションのサポートと、帯域幅の（悪意のあるまたは偶発的な）無駄の防止に不可欠なままです。充電は、ネットワークリソースの利用と共有を制御する可能性を提供します。マルチサービスネットワークでの充電は、予約済みまたは実際の使用済みリソースに基づいて実行できます。予約されたリソースの充電は重要な概念です。なぜなら、予約は通常、他のユーザーが予約されたリソースを使用することを妨げるからです。それにもかかわらず、充電が予約パラメーターのみに制限されている場合、適用された充電は、予想されるトラフィック特性の適切な予測を提供するユーザーの能力に依存します。これは、予約されたリソースと使用済みリソースの両方に基づいた充電スキームを使用することにより、拡張できます。使用ベースの充電をサポートするために、リソースの予約と利用に関する情報の収集が必要です。リソースの使用に関するデータの収集は、会計と呼ばれます。
Service providers have various options for service differentiation, charging schemes and the provisioning of accounting services. The applied charging schemes for the provided services are one significant feature used by providers to distinguish themselves from competitors. Therefore, providers use different charging schemes and may change the schemes in accordance with their business plan. Providers can also offer different accounting services (e.g. standard, comprehensive, etc.) in order to allow customers/users to choose one scheme that meets the customers/users needs. Furthermore, it may be advantageous for a provider to outsource accounting functionality to a third party. Users introduce various traffic profiles and may have individual preferences regarding accounting services (like itemized invoices, accounting indications, spending limits etc.).
サービスプロバイダーには、サービス差別化、充電スキーム、会計サービスの提供に関するさまざまなオプションがあります。提供されたサービスに適用された充電スキームは、競合他社と区別するためにプロバイダーが使用する重要な機能の1つです。したがって、プロバイダーは異なる充電スキームを使用し、ビジネスプランに従ってスキームを変更する場合があります。プロバイダーは、顧客/ユーザーが顧客/ユーザーのニーズを満たす1つのスキームを選択できるようにするために、さまざまな会計サービス（標準、包括的ななど）を提供することもできます。さらに、プロバイダーが会計機能を第三者に外部委託することが有利かもしれません。ユーザーはさまざまなトラフィックプロファイルを導入し、会計サービス（項目別の請求書、会計指示、支出制限など）に関して個別の好みを持っている場合があります。
One further challenge for the configuration of accounting services are heterogeneous metering and accounting infrastructures within provider domains. Also, the usage of different accounting and metering solutions used in different provider networks complicates the sharing of configuration parameters (e.g. in roaming scenarios).
会計サービスの構成のためのさらに1つの課題は、プロバイダードメイン内の不均一な計量および会計インフラストラクチャです。また、さまざまなプロバイダーネットワークで使用されるさまざまな会計および計測ソリューションの使用は、構成パラメーターの共有を複雑にします（たとえば、ローミングシナリオで）。
The configuration and dynamic adaptation of the accounting process to the business model and specific user demands requires a flexible configurable accounting infrastructure. The utilization of standardized policies for the expression of conditions and related configuration actions also allows the configuration of heterogeneous infrastructures. For this purpose we propose to use accounting policies to configure the accounting infrastructure and use the Authentication, Authorization and Accounting (AAA) architecture to exchange and to deploy these policies.
会計プロセスのビジネスモデルと特定のユーザー需要への構成と動的適応には、柔軟な構成可能な会計インフラストラクチャが必要です。条件の表現および関連する構成アクションの表現のための標準化されたポリシーの利用により、不均一なインフラストラクチャの構成も可能になります。この目的のために、会計ポリシーを使用して会計インフラストラクチャを構成し、認証、承認、会計（AAA）アーキテクチャを使用して、これらのポリシーを展開することを提案します。
This document describes the structure and usage of accounting policies. It shows how the characteristics of the provider network influence the requirements for accounting. The relations between the different roles that are involved in the accounting process and the required building blocks for an accounting architecture are introduced. This document describes an architecture and mechanisms to configure the accounting service. It proposes to use the AAA protocol for the exchange of accounting configuration information expressed in policies. It does not propose a specific protocol for the accounting configuration itself. The configuration itself can be done by existing protocols (e.g. Common Open Policy Service Protocol for Support of Policy Provisioning - COPS-PR, Simple Network Management Protocol - SNMP, etc.). Furthermore, it is shown how different accounting services can be provided in intra- and inter-domain scenarios. Examples are given for the usage of accounting policies in different scenarios. They show how accounting components can be integrated into the authorization framework proposed in [RFC2904].
このドキュメントでは、会計ポリシーの構造と使用について説明します。プロバイダーネットワークの特性が、会計の要件にどのように影響するかを示しています。会計プロセスに関与するさまざまな役割と、会計アーキテクチャに必要なビルディングブロックとの関係が導入されています。このドキュメントでは、会計サービスを構成するためのアーキテクチャとメカニズムについて説明します。ポリシーで表明された会計構成情報の交換にAAAプロトコルを使用することを提案しています。会計構成自体の特定のプロトコルを提案しません。構成自体は、既存のプロトコル（たとえば、ポリシープロビジョニングをサポートするための一般的なオープンポリシーサービスプロトコル - COPS -PR、シンプルなネットワーク管理プロトコル-SNMPなど）によって実行できます。さらに、ドメイン内およびドメイン間のシナリオで異なる会計サービスを提供する方法が示されています。さまざまなシナリオでの会計ポリシーの使用について例が示されています。彼らは、[RFC2904]で提案されている承認フレームワークに会計コンポーネントを統合する方法を示しています。
Accounting management architectures and objectives as well as the transport of accounting records are discussed in [RFC2975] and are not further explained here. This document focuses on the configuration of the accounting architecture and measurement devices.
会計管理のアーキテクチャと目標、および会計記録の輸送については[RFC2975]で説明されており、ここではこれ以上説明されていません。このドキュメントは、会計アーキテクチャおよび測定デバイスの構成に焦点を当てています。
The policy-based accounting architecture represented in this document describes policy-based accounting from the perspective of a Generic AAA Server [RFC2903]. Such a server combines into a single entity the functions of managing accounting policy, together with the functions of managing user-specific authentication, authorization and service provisioning. Some service providers may choose to implement an approach that does not combine these functions into a single entity or protocol, in which case that particular aspect of this architecture does not apply.
このドキュメントに記載されているポリシーベースの会計アーキテクチャは、一般的なAAAサーバー[RFC2903]の観点からのポリシーベースの会計について説明しています。このようなサーバーは、ユーザー固有の認証、承認、およびサービス提供の管理の機能とともに、会計ポリシーの管理の機能を単一のエンティティに結合します。一部のサービスプロバイダーは、これらの機能を単一のエンティティまたはプロトコルに組み合わないアプローチを実装することを選択する場合があります。その場合、このアーキテクチャの特定の側面は適用されません。
This document does not propose a language for the description of accounting policies. It is rather assumed that a suitable policy language can be chosen from existing or upcoming standards.
このドキュメントは、会計方針の説明のための言語を提案していません。むしろ、既存または今後の基準から適切なポリシー言語を選択できると想定されています。
Accounting Indication/Confirmation Accounting indication messages are pushed from the originating AAA server (the server where the accounting information was generated) to the recipient which can be an AAA server or a customer/user application. Accounting indications contain accounting records which describe the resource consumption for a service. Accounting indication messages can also contain aggregated information for multiple services. There can be interim and end-of-session accounting indication messages. Interim indications are delivered in specified intervals to the recipient during the service session while end-of-session indications are given to the recipient at the end of the session only. Accounting indications may be acknowledged by accounting confirmations to provide application layer reliability.
会計表示/確認会計表示メッセージは、AAAサーバーまたは顧客/ユーザーアプリケーションである可能性のある発信元のAAAサーバー（会計情報が生成されたサーバー）から受信者にプッシュされます。会計指示には、サービスのリソース消費を説明する会計記録が含まれています。会計表示メッセージには、複数のサービスの集計情報も含めることができます。暫定およびセッション終了会計表示メッセージが存在する場合があります。暫定的な適応症は、サービスセッション中に受信者に指定された間隔で配信され、セッションの終了のみがセッションの終了のみに受信者に与えられます。会計上の適応症は、アプリケーション層の信頼性を提供するために、会計確認によって認められる場合があります。
Accounting Policy Indication/Confirmation Accounting policy indication messages contain accounting policies and are sent from a customer/user or a AAA server to another AAA server. Accounting policy indications may be acknowledged by accounting policy confirmations to provide application layer reliability.
会計方針の表示/確認会計ポリシー表示メッセージには、会計ポリシーが含まれており、顧客/ユーザーまたはAAAサーバーから別のAAAサーバーに送信されます。会計方針の適応は、アプリケーション層の信頼性を提供するために、会計方針の確認によって認められる場合があります。
Accounting Request/Answer Accounting requests are sent by an AAA server to another AAA server to request the current accounting information for a particular session set (polling). The request is answered with an accounting answer which contains the accounting records.
会計要求/回答会計リクエストは、AAAサーバーから別のAAAサーバーに送信され、特定のセッションセット（ポーリング）の現在の会計情報を要求します。要求は、会計記録を含む会計回答で回答されます。
Accounting Policy Request/Answer Accounting policy requests are sent by an AAA server to another AAA server or a customer/user to request accounting policies for a service. The request is answered by an accounting policy answer that contains the accounting policy.
会計ポリシーの要求/回答会計ポリシーの要求は、AAAサーバーから別のAAAサーバーまたは顧客/ユーザーに送信され、サービスの会計ポリシーを要求します。この要求は、会計方針を含む会計方針の回答によって回答されます。
Accounting Policies Accounting policies describe rules for generation, transport and storage of accounting data. These rules are used for the configuration of the accounting process.
会計方針会計ポリシーでは、会計データの生成、輸送、保管に関する規則について説明します。これらのルールは、会計プロセスの構成に使用されます。
Application Specific Module (ASM) An ASM provides the functionalities required for the user configuration of a service to an authenticated and authorized user. It gets application specific information (ASI) (e.g. for user configuration) from the AAA server, either in a generic format or in an application specific format, encapsulated in a standard message sent to the ASM. The ASM either extracts the ASI from the message or converts information given in a generic format into the appropriate application specific format. Further information on how the ASM is used can be found in [RFC2903].
アプリケーション固有のモジュール（ASM）ASMは、認証された認証されたユーザーにサービスのユーザー構成に必要な機能を提供します。AAAサーバーからASMに送信された標準メッセージにカプセル化されたAAAサーバーから、AAAサーバーからアプリケーション固有の情報（ASI）（例：ユーザー構成など）を取得します。ASMは、メッセージからASIを抽出するか、一般的な形式で指定された情報を適切なアプリケーション固有の形式に変換します。ASMの使用方法の詳細については、[RFC2903]に記載されています。
Charging Schemes A charging scheme is an instruction for calculating a charge. Usually, a charging scheme is represented by a formula that consists of charging variables (e.g. volume, time, reserved peak rate) and charging coefficients (e.g. price per time unit). The charging variables are usually filled by information from accounting data.
充電スキーム充電スキームは、料金を計算するための指示です。通常、充電スキームは、充電変数（ボリューム、時間、ピークレートなど）および充電係数（例：時間単位の価格）で構成される式で表されます。充電変数は通常、会計データからの情報によって埋められます。
Classifier This document uses the definition of classifier as given in [RFC2475]. Since this document assumes that meters already include classification functions, the term classifier is only used for entities that perform additional classification (e.g. as part of data post processing).
分類器このドキュメントは、[RFC2475]に与えられた分類器の定義を使用します。このドキュメントでは、メーターにはすでに分類関数が含まれていると想定しているため、分類項は追加の分類を実行するエンティティにのみ使用されます（たとえば、データ後処理の一部として）。
Meter This document uses the definition of meter as given in [RFC2722]. This meter definition already includes the classification of packets. It differs from the DiffServ model [RFC2475] where classifier and meter are considered as separate entities.
メーターこのドキュメントは、[RFC2722]に与えられたメーターの定義を使用します。このメーター定義には、すでにパケットの分類が含まれています。それは、分類器とメーターが個別のエンティティと見なされるDiffServモデル[RFC2475]とは異なります。
Meter Reader/Collector This document uses the definition of meter reader and collector as given in [RFC2722].
メーターリーダー/コレクターこのドキュメントは、[RFC2722]に記載されているメーターリーダーとコレクターの定義を使用しています。
Meter Manager This document uses the definition of meter manager as given in [RFC2722].
メーターマネージャーこのドキュメントは、[RFC2722]に与えられたメーターマネージャーの定義を使用しています。
Policy, policy condition, policy action The terms policy, policy condition and policy action are used as defined in [RFC3198].
ポリシー、ポリシー条件、ポリシーアクションという用語ポリシー、ポリシー条件、およびポリシーアクションは、[RFC3198]で定義されているように使用されます。
QoS Auditing Quality of Service (QoS) Auditing is the process of evaluating whether a given quality of service guarantee (e.g. thresholds for QoS parameters given in a Service Level Agreement - SLA) has been met during the service provisioning.
QoS監査品質サービスの品質（QOS）監査は、サービスの提供中に、特定のサービス保証（たとえば、サービスレベル契約で指定されたQoSパラメーターのしきい値など）がサービス提供中に満たされているかどうかを評価するプロセスです。
Service Class A service class specifies the handling of a service (as defined in [RFC3198]) belonging to that class by the service provider. A service class has some kind of identifier (e.g. name) and the handling of the service is defined by a Service Level Specification (SLS) as described in [RFC3198].
サービスクラスAサービスクラスは、サービスプロバイダーによってそのクラスに属するサービス（[RFC3198]で定義されている）の処理を指定します。サービスクラスには何らかの識別子（名前など）があり、サービスの処理は[RFC3198]で説明されているようにサービスレベル仕様（SLS）によって定義されます。
User Configuration We refer to User Configuration as the process of configuring a service for a user which has been authenticated and authorized by the AAA architecture. Although an AAA architecture is not directly responsible for this user-dependent configuration, it may be responsible for triggering the process.
ユーザー構成ユーザー構成を、AAAアーキテクチャによって認証および承認されているユーザー向けのサービスを構成するプロセスと呼びます。AAAアーキテクチャは、このユーザー依存の構成について直接責任を負いませんが、プロセスのトリガーを担当する可能性があります。
Further definitions of service related terms (Service, Service Subscriber, Service User, Network Provider, Service Provider, Broker) can be found in section 4 (business roles and their relations).
サービス関連用語（サービス、サービスサブスクライバー、サービスユーザー、ネットワークプロバイダー、サービスプロバイダー、ブローカー）のさらなる定義は、セクション4（ビジネスの役割とその関係）にあります。
There are many options for future service providers for the realization of service differentiation and provisioning. Therefore, provider networks can vary with respect to several characteristics that impact accounting and charging:
サービスの差別化とプロビジョニングを実現するための将来のサービスプロバイダーには、多くのオプションがあります。したがって、プロバイダーネットワークは、会計と充電に影響を与えるいくつかの特性に関して異なる場合があります。
- Size and Purpose A small ISP that deals with individual customers may charge individual users based on single flows. Backbone operators often have small ISPs and large corporations as customers, and usually charge based on traffic aggregates instead of individual flows.
- サイズと目的個々の顧客を扱う小さなISPは、単一のフローに基づいて個々のユーザーを請求する場合があります。バックボーンオペレーターは、多くの場合、顧客として小規模なISPと大企業を持ち、通常は個々のフローではなくトラフィックの集合体に基づいて請求します。
- QoS provisioning technique Diffserv accounting requirements differ from Intserv accounting requirements (e.g. meter granularity).
- QoSプロビジョニング手法DIFFSERV会計要件は、INTSERV会計要件（メーターの粒度など）とは異なります。
- Service classes The definition of service classes within a network and the degree of freedom that customers are given (e.g. gold/silver/bronze service vs. a free choice of individual traffic profile parameters) is important, e.g. for the flow classification within the network, and influences the accounting functions required.
- サービスクラスネットワーク内のサービスクラスの定義と顧客が与えられる自由度（たとえば、ゴールド/シルバー/ブロンズサービスと個々の交通プロファイルパラメーターの自由な選択）が重要です。ネットワーク内のフロー分類について、必要な会計機能に影響を与えます。
- Charging scheme There exists a wide variety of charging schemes using tariff variables based on different technical and/or economic models. The chosen charging scheme(s) influence the accounting requirements for the provider. While some charging schemes lead to zero or only few accounting requirements, other charging schemes may be highly demanding. For instance, flat rate charging schemes require no accounting infrastructure at all. In contrast to this, volume-based charging schemes require the measurement of the transmitted volume and, with this, increases the complexity for accounting. Tariffs that introduce variable prices may require to provide the users regularly with accounting information (e.g. by interim accounting indications).
- 充電スキームさまざまな技術モデルおよび/または経済モデルに基づいて、関税変数を使用して、さまざまな充電スキームが存在します。選択された充電スキームは、プロバイダーの会計要件に影響を与えます。一部の充電スキームはゼロまたは少数の会計要件につながりますが、他の充電スキームは非常に要求が厳しい場合があります。たとえば、定額充電スキームは、会計インフラストラクチャをまったく必要としません。これとは対照的に、ボリュームベースの充電スキームでは、送信されたボリュームの測定が必要であり、これにより、会計の複雑さが向上します。さまざまな価格を導入する関税は、ユーザーに会計情報を定期的に提供する必要がある場合があります（例：暫定会計兆候による）。
- Accounting Services Providers may offer different accounting services (e.g. accounting indication, itemized invoice, etc.)
- 会計サービスプロバイダーは、異なる会計サービスを提供する場合があります（例：会計表示、項目別の請求書など）
- Accounting agreements with other providers Providers may have agreements with other providers in order to share accounting tasks and distribute accounting data so that, e.g., metering need only be done once. If so, it may be useful if providers can not only exchange accounting data, but also information on the configuration of accounting modules (e.g. meters). It is important for providers to agree beforehand how accounting data will be collected and monitored, and how disputes concerning accounting data will be resolved. In order to minimize disputes between providers, it is important for them to agree that either both will collect accounting data - and will compare it with the other's data at regular intervals, e.g. monthly - or both will use a single source of accounting data provided by one of them (or by a trusted third party).
- 他のプロバイダーとの会計契約は、会計タスクを共有し、会計データを配布するために他のプロバイダーと契約を結ぶことができます。その場合、プロバイダーが会計データを交換するだけでなく、会計モジュールの構成に関する情報（メーターなど）も交換できる場合に役立つ場合があります。プロバイダーは、会計データの収集と監視方法、および会計データに関する紛争がどのように解決されるかを事前に同意することが重要です。プロバイダー間の紛争を最小限に抑えるためには、両方が会計データを収集し、定期的に他のデータと比較することに同意することが重要です。毎月 - またはその両方で、そのうちの1人が提供する（または信頼できる第三者によって）提供された会計データの単一のソースが使用されます。
- Exploiting Capabilities of Existing Infrastructure (meters, data collection points) Providers may already have functions within the network that can provide accounting functions (e.g. MIB objects, profile meters, proprietary accounting solutions). In order to avoid duplicated functionality, it should be possible to use these accounting resources. Therefore, the configuration of different types of accounting modules (e.g. meters) should be possible. A common language to express accounting module configurations would be useful for this purpose.
- 既存のインフラストラクチャ（メーター、データ収集ポイント）の機能を活用するプロバイダーは、ネットワーク内に会計機能を提供できる機能（MIBオブジェクト、プロファイルメーター、独自の会計ソリューションなど）を提供できる機能を既に持っている可能性があります。複製された機能を回避するために、これらの会計リソースを使用することが可能です。したがって、さまざまな種類の会計モジュール（メートルなど）の構成が可能です。会計モジュールの構成を表現する共通言語は、この目的に役立ちます。
In investigating service provisions in the current and forthcoming Internet, we identified different business roles which are part of the service usage lifecycle. In this section we first define the term service. Afterwards, the different roles and their relationships are defined. The business roles in this model are used in the later examples.
現在および今後のインターネットでのサービス規定を調査する際に、サービス使用ライフサイクルの一部であるさまざまなビジネス役割を特定しました。このセクションでは、最初にサービスという用語を定義します。その後、異なる役割とその関係が定義されます。このモデルのビジネスの役割は、後の例で使用されています。
- Service A service is a set of capabilities offered by a provider to a customer. In this definition, provider and customer can be one of the business roles defined later. Different kinds of services have to be recognized.
- サービスサービスは、プロバイダーが顧客に提供する一連の機能です。この定義では、プロバイダーと顧客は後で定義されるビジネス役の1つになります。さまざまな種類のサービスを認識する必要があります。
- Information services handle the delivery of information to the customer on top of transport services. In content-based services, the service subscriber pays for the content (e.g. for a file, an image, a video, etc.). In communication-based services, the service subscriber pays for the provisioning of a certain form of communication (e.g. video conferencing or IP telephony).
- 情報サービスは、輸送サービスに加えて顧客に情報の提供を処理します。コンテンツベースのサービスでは、サービスサブスクライバーはコンテンツを支払います（たとえば、ファイル、画像、ビデオなどの場合）。通信ベースのサービスでは、サービスサブスクライバーは、特定の形式のコミュニケーション（ビデオ会議やIPテレフォニーなど）のプロビジョニングに支払います。
- Transport services describe the provisioning of pure transportation of IP packets. At the IP layer, this may include the differentiation of packets (e.g. number of packets with a certain DSCP), Intserv based reservation or other methods for QoS enhancement (e.g. Automatic Repeat reQuest - ARQ, Forward Error Correction - FEC). A transport service might also include mechanisms on other layers for improving the transport (e.g. MPLS).
- 輸送サービスは、IPパケットの純粋な輸送のプロビジョニングについて説明しています。IPレイヤーでは、これには、パケットの差別化（特定のDSCPを含むパケットの数）、INTSERVベースの予約、またはQOS強化のためのその他の方法（自動リピートリクエスト-ARQ、フォワードエラー補正-FEC）が含まれる場合があります。輸送サービスには、輸送を改善するための他の層のメカニズム（MPLSなど）も含まれる場合があります。
- Management services are responsible for the management of resources (e.g. configuration, accounting, security). Accounting services describe the provisioning of data about the current or previous resource reservation and usage. Accounting services are needed by providers to generate a bill or by users to monitor their resource usage.
- 管理サービスは、リソースの管理（構成、会計、セキュリティなど）の管理を担当します。会計サービスは、現在または以前のリソースの予約と使用に関するデータの提供について説明しています。会計サービスは、プロバイダーが請求書を生成するために、またはユーザーがリソースの使用を監視するために必要です。
- Service Subscriber The service subscriber is the entity that has subscribed to a service and thus has a contractual relationship with a service provider and a network provider which provides the underlying transport service. A service subscriber can also act as a service user. The service subscriber might have a relationship with a broker that provides service relevant information.
- サービスサブスクライバーサービスサブスクライバーは、サービスにサブスクライブしたエンティティであり、したがって、サービスプロバイダーと基礎となる輸送サービスを提供するネットワークプロバイダーと契約上の関係を持っています。サービスサブスクライバーは、サービスユーザーとしても機能します。サービスサブスクライバーは、サービスに関連する情報を提供するブローカーとの関係を持っている場合があります。
- Service User The service user is the entity that uses the service. The service user can be identical to the service subscriber. In cases where subscriber and user are not identical, the service subscriber should be able to control the service usage for all service users she is responsible for.
- サービスユーザーサービスユーザーは、サービスを使用するエンティティです。サービスユーザーは、サービスサブスクライバーと同一にすることができます。サブスクライバーとユーザーが同一でない場合、サービスサブスクライバーは、責任を負うすべてのサービスユーザーのサービス使用を制御できるはずです。
- Network Provider A network provider is the entity that provides the underlying network infrastructure for the service user, service subscriber, service provider and broker. A network provider provides transport services. The services are delivered on top of the network infrastructure. The service provider has a contractual relationship with the service subscriber and service provider (and the broker). The transport network of a network provider is probably not a global network which connects all subscribers, providers and brokers. The transport network is segmented into a number of sub-networks or domains controlled by different network providers with business relations existing between them. Each domain is responsible for intra-domain management and accounting. For inter-domain management and accounting, appropriate communication interfaces between network providers must exist.
- ネットワークプロバイダーネットワークプロバイダーは、サービスユーザー、サービスサブスクライバー、サービスプロバイダー、ブローカーに基礎となるネットワークインフラストラクチャを提供するエンティティです。ネットワークプロバイダーは輸送サービスを提供します。サービスは、ネットワークインフラストラクチャの上に配信されます。サービスプロバイダーは、サービスサブスクライバーおよびサービスプロバイダー（およびブローカー）と契約上の関係を持っています。ネットワークプロバイダーのトランスポートネットワークは、おそらくすべてのサブスクライバー、プロバイダー、ブローカーをつなぐグローバルネットワークではありません。トランスポートネットワークは、さまざまなネットワークプロバイダーによって制御される多くのサブネットワークまたはドメインにセグメント化されており、それらの間にビジネス関係が存在します。各ドメインは、ドメイン内の管理と会計を担当します。ドメイン間管理と会計の場合、ネットワークプロバイダー間の適切な通信インターフェイスが存在する必要があります。
- Service Provider A service provider entity provides a service. A service provider can offer a service directly to the service subscriber/user. A service provider can also act like a wholesaler selling a service to another service provider (retailer) which re-sells the service to the service subscriber. The service provider has contractual relationships with other service providers, subscribers, brokers and network providers. A service provider provides information services on top of transport services provided by network providers.
- サービスプロバイダーサービスプロバイダーエンティティがサービスを提供します。サービスプロバイダーは、サービスサブスクライバー/ユーザーに直接サービスを提供できます。サービスプロバイダーは、サービスをサービスサブスクライバーに再販売する別のサービスプロバイダー（小売業者）にサービスを販売する卸売業者のように行動することもできます。サービスプロバイダーは、他のサービスプロバイダー、加入者、ブローカー、ネットワークプロバイダーと契約上の関係を持っています。サービスプロバイダーは、ネットワークプロバイダーが提供する輸送サービスの上に情報サービスを提供します。
- Broker The broker entity allows the other roles to access the information controlled by the broker. The broker can provide different information to different business roles. For example, a service subscriber can get references to appropriate service providers and/or network providers (e.g. a broker gives the subscriber a reference to a network provider which can provide bandwidth as required by the subscriber). A broker can also interact with other brokers to complete their information. In this case, broker-to-broker business relationships exist.
- ブローカーブローカーエンティティにより、他の役割がブローカーによって制御される情報にアクセスすることができます。ブローカーは、さまざまなビジネス役に異なる情報を提供できます。たとえば、サービスサブスクライバーは、適切なサービスプロバイダーおよび/またはネットワークプロバイダーへの参照を取得できます（たとえば、ブローカーは、サブスクライバーが要求される帯域幅を提供できるネットワークプロバイダーにサブスクライバーに参照を提供します）。ブローカーは、他のブローカーと対話して情報を完成させることもできます。この場合、ブローカーとブローカーのビジネス関係が存在します。
Figure 1 depicts the different roles and the business relations between them.
図1は、異なる役割とそれらの間のビジネス関係を示しています。
+----+
V |
+---------------+ |
| Broker |<-+
+------>| |<-----------------+
| +---------------+ |
| ^ |
| | |
| V V
| +------------------+ +---------------+
| | Service | | Service |
| | Subscriber |<------>| Provider |
| | | | |<-+
| | +--------------+ | +---------------+ |
| | | Service User | | ^ ^ |
| | +--------------+ | | +----+
| +------------------+ |
| ^ |
| | |
| V |
| +---------------+ |
+------>| Network |<-----------------+
| Provider |<-+
+---------------+ |
^ |
+----+
Figure 1: Roles and business relations The following examples show how this business relationship model can be applied to different services.
図1：役割とビジネス関係次の例は、このビジネス関係モデルをさまざまなサービスに適用する方法を示しています。
Example 1: This example describes an Internet printing scenario according to the "print-by-reference" model [RFC2566]. The subscriber is a company and the users are the employees of that company. The file server and print server belong to two different service providers. The company subscribes to the print server service which acts as reseller for the file service. The file server service chooses the appropriate transport service (maybe based on user preference), thus the file server has a contract with a network provider using the offered transport service for downloading the data from the given location and sending them to the print server.
例1：この例では、「再参照」モデル[RFC2566]に従って、インターネット印刷シナリオを説明しています。加入者は会社であり、ユーザーはその会社の従業員です。ファイルサーバーと印刷サーバーは、2つの異なるサービスプロバイダーに属します。会社は、ファイルサービスの再販業者として機能する印刷サーバーサービスを購読しています。ファイルサーバーサービスは、適切なトランスポートサービス（ユーザーの好みに基づいている可能性があります）を選択します。したがって、ファイルサーバーは、特定の場所からデータをダウンロードして印刷サーバーに送信するために提供されたトランスポートサービスを使用してネットワークプロバイダーと契約します。
Example 2: A company (service subscriber) has a contract with a video archive (service provider). An employee can download clips in different qualities from the archive. The employee can use different transport mechanisms for the download. In order to get the appropriate transport, the user contacts an agency (broker) that returns a reference to a network provider which provides the required transport service. As an alternative, the content (video) can be delivered in different qualities via different transport mechanisms by the service provider. The service provider chooses an appropriate network provider which provides a transport service compliant with the conditions the service provider offers to the subscribers. In this case the service provider can use the facilities of a broker to get a reference to appropriate network providers.
例2：会社（サービスサブスクライバー）には、ビデオアーカイブ（サービスプロバイダー）と契約があります。従業員は、アーカイブからさまざまな品質のクリップをダウンロードできます。従業員は、ダウンロードに異なる輸送メカニズムを使用できます。適切なトランスポートを取得するために、ユーザーは、必要な輸送サービスを提供するネットワークプロバイダーへの参照を返す代理店（ブローカー）に連絡します。別の方法として、コンテンツ（ビデオ）は、サービスプロバイダーによってさまざまな輸送メカニズムを介してさまざまな品質で配信できます。サービスプロバイダーは、サービスプロバイダーが加入者に提供する条件に準拠した輸送サービスを提供する適切なネットワークプロバイダーを選択します。この場合、サービスプロバイダーはブローカーの機能を使用して、適切なネットワークプロバイダーへの参照を取得できます。
We have developed a reference model for describing the interactions between the different metering, accounting and charging processes and their configuration via policies. This reference model is shown in Figure 2. At the right side, five layers show the different building blocks. The blocks are layered according to the processing of the data from the bottom level metering via accounting, up to the final billing process. Data aggregation is not only done at the collection layer, it can also be done at the other layers. The building blocks on the different layers are configured through the policies shown on the left side. Higher layer policies can be translated into lower layer policies. The configuration parameters are extracted from the policy and passed to the corresponding building block. The tasks of the different building blocks are as follows:
さまざまな計量、会計、充電プロセス、およびポリシーを介した構成との間の相互作用を説明するための参照モデルを開発しました。この参照モデルを図2に示します。右側には、5つの層が異なる構成要素を示しています。ブロックは、最終的な請求プロセスまで、会計を介して下位レベルの計量からデータの処理に応じて階層化されます。データ集約は、コレクションレイヤーで行われるだけでなく、他のレイヤーでも実行できます。異なるレイヤーのビルディングブロックは、左側に示されているポリシーを通じて構成されています。高層ポリシーは、下層ポリシーに翻訳できます。構成パラメーターはポリシーから抽出され、対応するビルディングブロックに渡されます。さまざまなビルディングブロックのタスクは次のとおりです。
- Metering Meters are needed for capturing data about resource consumption in the network (e.g. transmitted volume). They will probably be placed at the edges of the network. Two types of meters can be distinguished: Static meters and configurable meters. In the case of static meters, all flows are measured with a fixed granularity, not distinguishing if a subsequent charging process needs the specific meter data or not. In most cases the large amount of captured data makes filtering and/or aggregation after the metering necessary. In case of a configurable meter, the meter collects meter data only for flows specified by metering policies.
- ネットワーク内のリソース消費に関するデータをキャプチャするには、計量計が必要です（たとえば、送信ボリューム）。それらはおそらくネットワークの端に配置されます。2種類のメーターを区別できます：静的メーターと構成可能なメーター。静的メートルの場合、すべてのフローは固定された粒度で測定されますが、後続の充電プロセスに特定のメーターデータが必要かどうかは区別されません。ほとんどの場合、大量のキャプチャされたデータにより、計量が必要な後にフィルタリングおよび/または集約が行われます。構成可能なメーターの場合、メーターはメーターポリシーで指定されたフローのみのメーターデータを収集します。
For configuration of the meter process, the following issues must be addressed: (a) metering scope (whether to meter all flows or only selected flows), (b) flow granularity (e.g. micro flows or traffic aggregates) (c) metered flow attributes (i.e. which data is to be collected for a specific flow), and (d) meter accuracy (measurement intervals etc.).
メータープロセスの構成のために、次の問題に対処する必要があります：（a）メータースコープ（すべてのフローまたは選択されたフローのみを計算するかどうか）、（b）フロー粒度（例：マイクロフローまたはトラフィックアグリゲート）（c）メーターのフロー属性（つまり、どのデータを特定のフローに対して収集するか）、および（d）メートルの精度（測定間隔など）。
- Collection The data gathered by the meter(s) has to be collected for further processing. Collection of meter data can be initiated by the meter itself (push model) or by a collector entity (pull model). Collected data can be aggregated before being passed to the accounting layer. Metering policies define how collection and aggregation is done.
- 収集メーターによって収集されたデータは、さらに処理するために収集する必要があります。メーターデータの収集は、メーター自体（プッシュモデル）またはコレクターエンティティ（プルモデル）によって開始できます。収集されたデータは、会計層に渡される前に集約できます。計量ポリシーは、収集と集約の行われる方法を定義します。
POLICY CONFIGURATION BUILDING BLOCKS
+---------------+ +-------------------------+
| |------------------>| Billing |
| Billing & | +-------------------------+
| Charging | ^ charging
| | | data
| | +-------------------------+
| |------------------>| Charging |
+---------------+ +-------------------------+
| ^ acct
V | data
+---------------+ +-------------------------+
| Accounting | | |
| |------------------>| Accounting |
+---------------+ +-------------------------+
| ^ aggr. meter
V | data
+---------------+ +-------------------------+
| |------------------>| Collection |
| Metering | | |
| | +-------------------------+
| | ^ meter
| | | data
| | +-------------------------+
| |------------------>| Metering |
+---------------+ +-------------------------+
Figure 2: Reference Model
図2：参照モデル
- Accounting Accounting describes the collection of data about resource consumption. This includes the control of data gathering (via metering), transport and storage of accounting data. For subsequent charging, the metered data must be associated with a user that is the initiator of a flow and a customer (service subscriber) that is responsible for payment. For initiation of an accounting process, a user or foreign provider must be authenticated and authorized. These three functions can be performed by the AAA server. The accounting process is configured through accounting policies.
- 会計会計は、リソース消費に関するデータの収集について説明しています。これには、データ収集の制御（メーターを介して）、会計データの輸送、ストレージが含まれます。その後の充電の場合、メーターデータは、フローのイニシエーターであるユーザーと、支払いを担当する顧客（サービスサブスクライバー）に関連付けられている必要があります。会計プロセスを開始するには、ユーザーまたは外国のプロバイダーを認証および承認する必要があります。これらの3つの機能は、AAAサーバーで実行できます。会計プロセスは、会計ポリシーを通じて構成されます。
- Charging Charging derives non-monetary costs for accounting data sets based on service and customer specific tariff parameters. Different cost metrics may be applied to the same accounting records even in parallel. Charging policies define the tariffs and parameters which are applied.
- 充電充電は、サービスおよび顧客固有の関税パラメーターに基づいて、会計データセットの非金銭的コストを導き出します。並行しても、同じ会計記録に異なるコストメトリックを適用できます。充電ポリシーは、適用される関税とパラメーターを定義します。
- Billing Billing translates costs calculated by the Charging into monetary units and generates a final bill for the customer. Billing policies define among others the type (e.g. invoice, credit card), the form of the bill (e.g. itemized or not, partial anyomization, etc.) and the time for billing (e.g. weekly, monthly, etc.).
- 請求請求は、通貨ユニットへの請求によって計算された費用を変換し、顧客に最終請求書を生み出します。請求ポリシーでは、とりわけ、タイプ（請求書、クレジットカードなど）、請求書の形式（例：項目別か、部分的な希薄化など）、および請求の時間（例：週刊、毎月など）を定義しています。
We propose to use policies expressed in a standardized way to appropriately configure the meter, meter data collection and accounting processes.
標準化された方法で表現されたポリシーを使用して、メーター、メーターのデータ収集、会計プロセスを適切に構成することを提案します。
Accounting policies describe rules for generation, transport and storage of accounting data. They can be exchanged between AAA instances at the user or provider premises. They provide a standardized representation of configuration information that can be converted into the appropriate settings for different elements of the accounting infrastructures (e.g. different meters).
会計方針は、会計データの生成、輸送、保管に関する規則を説明しています。ユーザーまたはプロバイダーの施設でAAAインスタンス間で交換できます。これらは、会計インフラストラクチャのさまざまな要素（異なるメーターなど）の適切な設定に変換できる構成情報の標準化された表現を提供します。
As shown in Figure 2, accounting policies configure the accounting process. Policies for the configuration of the metering and collection process can be derived from accounting policies. Accounting policies are not used to configure the charging or billing process. Accounting policies reside in the AAA server (local policies) or are received from other AAA servers (extra-domain policies) or customers/users. Two different models of obtaining accounting policies can be differentiated: push and pull model.
図2に示すように、会計ポリシーは会計プロセスを構成します。計量および収集プロセスの構成に関するポリシーは、会計ポリシーから導き出すことができます。会計ポリシーは、請求または請求プロセスの構成には使用されません。会計ポリシーは、AAAサーバー（ローカルポリシー）に存在するか、他のAAAサーバー（ドメイン外のポリシー）または顧客/ユーザーから受信されます。会計ポリシーを取得する2つの異なるモデルを区別できます：プッシュアンドプルモデル。
Push Model In the push model, accounting policies are pushed from another AAA server or customer/user in order to establish the policies in the local accounting infrastructure. The acceptance and use of pushed policies requires special security considerations. The evaluation of the policy should not take place without an appropriate security check of the policy in advance. Also, the evaluation of the condition can lead to unwanted actions in the AAA server if the condition contains critical data either intentionally (to attack the system) or by accident. Even the evaluation of the condition can cause problems (e.g. DoS). Therefore, not only the action, but also the condition, has to be checked for potential security hazards before it is evaluated.
プッシュモデルのプッシュモデルでは、地元の会計インフラストラクチャでポリシーを確立するために、別のAAAサーバーまたは顧客/ユーザーから会計ポリシーがプッシュされます。プッシュされたポリシーの受け入れと使用には、特別なセキュリティ上の考慮事項が必要です。ポリシーの評価は、事前にポリシーの適切なセキュリティチェックなしで行われるべきではありません。また、条件の評価は、条件に意図的に（システムを攻撃するため）または偶然に重要なデータが含まれている場合、AAAサーバーで不要なアクションにつながる可能性があります。状態の評価でさえ問題を引き起こす可能性があります（DOSなど）。したがって、アクションだけでなく、条件も評価される前に、潜在的なセキュリティハザードを確認する必要があります。
Pull Model In the pull model, the AAA server requests the policy from a remote AAA server or customer/user by sending an accounting policy request. The remote AAA server sends an accounting policy reply as an answer that contains the appropriate policy.
プルモデルのプルモデルでは、AAAサーバーは、会計ポリシーリクエストを送信することにより、リモートAAAサーバーまたは顧客/ユーザーにポリシーを要求します。リモートAAAサーバーは、適切なポリシーを含む回答として会計ポリシーの返信を送信します。
Accounting policies are enforced by the network elements that are configured in accordance with the policies. They influence the following settings in the accounting architecture:
会計ポリシーは、ポリシーに従って構成されているネットワーク要素によって実施されます。会計アーキテクチャの次の設定に影響を与えます。
- meter configuration - data collection and aggregation - accounting record distribution and storage
- メーター構成 - データ収集と集約 - 会計レコードの分布とストレージ
An accounting policy consists of one or more rules, each having a condition part and an action part. The condition part expresses under which condition the policy should be enforced. The following attributes are examples for variables in a policy condition statement.
会計方針は、1つ以上のルールで構成され、それぞれに条件部分とアクションパーツがあります。条件部分は、どの条件がポリシーを実施すべきかを表します。次の属性は、ポリシー条件ステートメントの変数の例です。
- customer/user ID The customer/user ID identifies the customer or user of the service. It can be used in a policy condition in order to select a customer or user specific accounting configuration (as policy action). For example, it can be user-dependent whether accounting indications are sent to the user or not.
- 顧客/ユーザーID顧客/ユーザーIDは、サービスの顧客またはユーザーを識別します。顧客またはユーザー固有の会計構成（ポリシーアクションとして）を選択するために、ポリシー条件で使用できます。たとえば、アカウンティングの表示がユーザーに送信されるかどうかにかかわらず、ユーザー依存性になる可能性があります。
- IP address IP addresses specify the devices or networks from which the service usage takes place. The address of specific hosts or subnets can be used to select accounting strategies specific to the customer or a user group associated with this address (e.g. all customers of an ISP, all public terminals etc.).
- IPアドレスIPアドレスは、サービスの使用が行われるデバイスまたはネットワークを指定します。特定のホストまたはサブネットのアドレスを使用して、このアドレスに関連付けられた顧客またはユーザーグループに固有の会計戦略を選択できます（たとえば、ISPのすべての顧客、すべての公開端末など）。
- time of day The time of day can be used, for instance, to configure the level of detail for the accounting record, the report interval and the destination.
- たとえば、時刻の時間を使用して、会計記録、レポート間隔、宛先の詳細レベルを構成するために使用できます。
- service class Service classes are defined by the provider. They describe different levels or different kinds of services that are offered by the provider and are usually defined based on a business model. Customers/users select a service class. This selected class can be used in accounting policies to define appropriate accounting settings per class. With this it is possible, for instance, to provide more detailed accounting records for higher prioritized services than for standard services.
- サービスクラスのサービスクラスは、プロバイダーによって定義されます。彼らは、プロバイダーが提供するさまざまなレベルまたはさまざまな種類のサービスを説明し、通常はビジネスモデルに基づいて定義されます。顧客/ユーザーは、サービスクラスを選択します。この選択されたクラスは、会計ポリシーで使用して、クラスごとに適切な会計設定を定義できます。これにより、たとえば、標準サービスよりも優先順位付けされたサービスのより詳細な会計記録を提供することが可能です。
- accounting type Accounting types combine multiple accounting settings under one keyword. Like service classes, the offered accounting types are defined by the provider in accordance with the business model. With this, providers can offer, for instance, different accounting types for one service and allow the customer/user to select one. The combination of settings under one keyword simplifies the selection for users. An example is the combination of high granular accounting records with short report intervals under a keyword (e.g. "comprehensive accounting"), or less frequent generation of less detailed records accessed by another keyword ("standard accounting"). The definition of accounting types can also help in inter-domain scenarios if providers agree on accounting types.
- 会計タイプの会計タイプは、1つのキーワードの下に複数の会計設定を組み合わせます。サービスクラスと同様に、提供される会計タイプは、ビジネスモデルに従ってプロバイダーによって定義されます。これにより、プロバイダーは、たとえば、1つのサービスに異なる会計タイプを提供し、顧客/ユーザーが1つのサービスを選択できるようにすることができます。1つのキーワードの下の設定の組み合わせにより、ユーザーの選択が簡素化されます。例としては、キーワードの下での短いレポート間隔（「包括的な会計」など）を持つ高粒度の会計記録の組み合わせ、または別のキーワードがアクセスした詳細な記録の少ない生成（「標準会計」）の組み合わせです。会計タイプの定義は、プロバイダーが会計タイプに同意した場合、ドメイン間シナリオにも役立ちます。
The action part defines the action that takes place if the condition is true. The action for an accounting policy is usually the configuration of the accounting infrastructure. This can already include settings for meters and collection entities. The following list gives examples for parameters of the accounting infrastructure that can be configured by an accounting policy action:
アクションパートは、条件が真である場合に発生するアクションを定義します。会計方針のアクションは、通常、会計インフラストラクチャの構成です。これには、メーターと収集エンティティの設定が既に含まれています。次のリストは、会計政策訴訟によって構成できる会計インフラストラクチャのパラメーターの例を示します。
- accounting record type/structure The required accounting data depends on the charging scheme. Therefore, different accounting records should be supported. There are two possibilities: Either different record types are defined, or a flexible record is used that consists of a variable set of accounting attributes. Accounting policies can be used to communicate to neighbor providers which kind of accounting record is needed to provide appropriate data for the charging scheme. The specification of the required accounting attributes can influence the settings of different components of the accounting architecture (e.g. which attributes have to be measured). An overview of accounting attributes and records can be found in [RFC2924].
- 会計記録の種類/構造必要な会計データは、充電スキームに依存します。したがって、異なる会計記録をサポートする必要があります。2つの可能性があります。異なるレコードタイプが定義されているか、可変会計属性のセットで構成される柔軟なレコードが使用されます。会計ポリシーを使用して、充電スキームに適切なデータを提供するために、どのような会計記録が必要かを近隣プロバイダーと通信することができます。必要な会計属性の仕様は、会計アーキテクチャのさまざまなコンポーネントの設定に影響を与える可能性があります（たとえば、どの属性を測定する必要があるか）。会計属性とレコードの概要は、[RFC2924]に記載されています。
- accounting record destination The accounting record destination describes to which entities accounting records are sent. The accounting record destination can be a charging entity, a neighbor provider, a user entity or a specific database. In these cases, authentication and authorization mechanisms have to be applied in order to ensure that unauthorized entities cannot get access to confidential data.
- 会計記録の宛先会計記録の目的地は、どのエンティティ会計記録が送信されるかについて説明します。会計記録の目的地は、充電エンティティ、近隣プロバイダー、ユーザーエンティティ、または特定のデータベースです。これらの場合、許可されていないエンティティが機密データにアクセスできないことを確認するために、認証と承認のメカニズムを適用する必要があります。
- report interval The report interval specifies in what time intervals accounting records are generated and sent. This influences the configuration of meters and collectors in the accounting architecture.
- レポート間隔レポート間隔は、会計レコードが生成および送信される時間間隔で指定されます。これは、会計アーキテクチャのメーターとコレクターの構成に影響します。
- storage time If the accounting record destination is a database or a log file, the storage time specifies how long the accounting records have to be stored.
- ストレージ時間会計レコードの宛先がデータベースまたはログファイルである場合、ストレージ時間は、会計レコードを保存する時間を指定します。
- access list The access list specifies who has the permissions to read the stored accounting records.
- アクセスリストアクセスリストには、保存された会計レコードを読み取る許可がある人が指定します。
- flow granularity The flow granularity determines how fine grained (in coverage) the flows in the network are measured. The granularity usually is configured by installing specific classification rules in the meter. It is also possible to set a specific granularity by configuring aggregation schemes that are applied after the metering process. The granularity can range from individual micro flows (e.g. determined by the quintuple <src, dest, proto, src-port, dest-port>) up to coarse granular traffic aggregates (e.g. all traffic from one network).
- 流れの粒度フローの粒度は、ネットワーク内のフローが測定される（カバレッジで）どれだけ細かい粒子を測定するかを決定します。粒度は通常、特定の分類ルールをメーターにインストールすることによって構成されます。また、計量プロセスの後に適用される集約スキームを構成することにより、特定の粒度を設定することもできます。粒度は、個々のマイクロフロー（たとえば、quintuple <src、dest、proto、src-port、dest-port>）から粗い粒状トラフィック集合体（たとえば、1つのネットワークからのすべてのトラフィック）までの範囲です。
- meter accuracy The parameters for the meter accuracy can determine, for instance, how often measurements take place at the meter, how accurate timestamps should be, etc. Meter accuracy parameters can also be used to configure sampling schemes.
- メーター精度メーターの精度のパラメーターは、たとえば、メーターで測定が行われる頻度、正確なタイムスタンプなどを決定できます。メーターの精度パラメーターを使用してサンプリングスキームを構成することもできます。
Note: In the following examples, the use of NeTraMet or NetFlow to collect accounting information does not guarantee exact accounting data, so it is not recommended for use in situations where exact accounting data are needed.
注：次の例では、会計情報を収集するためにNetrametまたはNetflowを使用しても、正確な会計データが保証されないため、正確な会計データが必要な状況での使用は推奨されません。
The following two examples show how accounting policies can be used to configure different meters. The accounting policy is sent from the AAA server to the ASM and there converted to the appropriate configuration information for the used meter.
次の2つの例は、アカウンティングポリシーを使用してさまざまなメーターを構成する方法を示しています。会計ポリシーはAAAサーバーからASMに送信され、そこで使用済みメーターの適切な構成情報に変換されました。
If the meter NeTraMet [RFC2123] is used, the policy is converted into a NeTraMet ruleset that contains the relevant flows, attributes and reader instructions for the data collection. This information is passed to the NeTraMet manager that configures the meter and meter reader in accordance with the given configuration.
Meter Netramet [RFC2123]を使用すると、ポリシーは、データ収集の関連するフロー、属性、リーダーの指示を含むNetrametルールセットに変換されます。この情報は、指定された構成に従ってメーターとメーターの読者を構成するNetramet Managerに渡されます。
+------------------+
| AAA |
| |
+------------------+
| ^
Policy | | Accounting Records
V |
+------------------+
| ASM |
| |
+------------------+
| ^
| |
| config +-----------------+
| |
+-------------------------------+ |
| | Accounting | |
| V | |
| +----------------+ | |
| | Meter Manager | | | Accounting Records
| +----------------+ | |
| | | | |
| SNMP V | |
| (conf)+---------------+ | |
| | | Meter Reader |---------+
| | +---------------+ |
| | ^ |
| V | |
| +-----------+ | |
| | Meter |-----+ |
| +-----------+ SNMP(DATA) |
| |
+-------------------------------+
Figure 3: Policy based Accounting with NeTraMet
図3：Netrametによるポリシーベースの会計
If the meter NetFlow [NetFlow] is used, the meter policies are translated by the ASM into filter instructions for the flow collector. The meter itself is static and therefore is not affected by the configuration information.
メーターNetflow [Netflow]を使用すると、メーターポリシーはASMによってフローコレクターのフィルター命令に翻訳されます。メーター自体は静的であるため、構成情報の影響を受けません。
+------------------+
| AAA |
| |
+------------------+
| ^
Policy | | Accounting Records
V |
+------------------+
| ASM |
| |
+------------------+
| ^
| |
| config | Accounting Records
| |
+-------------------------------+
| | Accounting |
| | |
| | +---------------------+ |
| | | Flow Collector | |
| | | +------------+ | |
| | | | Classifier | | |
| | | | Aggregator | | |
| +->| +------------+ | |
| +---------------------+ |
| ^ |
| | |
| +-----------+ | |
| | Meter |-----+ |
| +-----------+ UDP (DATA) |
| |
+-------------------------------+
Figure 4: Policy based Accounting with NetFlow
図4：Netflowを使用したポリシーベースの会計
Accounting can be seen as part of the service provisioning process (integrated accounting) or as a separate service (discrete accounting). The different views and their impact on the accounting architecture are described below.
会計は、サービスプロビジョニングプロセス（統合会計）の一部として、または別のサービス（離散会計）と見なすことができます。さまざまな見解と会計アーキテクチャへの影響を以下に説明します。
In the integrated accounting model, the accounting is seen as part of the provisioned service. That means the accounting is coupled with a specific service. Therefore, the accounting process is tailored to the specific service and might collect accounting information by directly exploiting some service specific entities. For example, accounting for IP telephony could use call signaling information from a SIP server. The configuration of the accounting architecture is done as part of the user configuration of the service equipment. Accounting policies are defined as part of the contractual agreement. The ASM converts the instructions from the AAA server into the appropriate user configuration including settings for the accounting architecture.
統合された会計モデルでは、会計はプロビジョニングされたサービスの一部と見なされます。つまり、会計は特定のサービスと結びついています。したがって、会計プロセスは特定のサービスに合わせて調整されており、一部のサービス固有のエンティティを直接搾取することにより、会計情報を収集する可能性があります。たとえば、IPテレフォニーの会計は、SIPサーバーからの通話信号情報を使用できます。会計アーキテクチャの構成は、サービス機器のユーザー構成の一部として行われます。会計方針は、契約契約の一部として定義されます。ASMは、AAAサーバーからの指示を、会計アーキテクチャの設定を含む適切なユーザー構成に変換します。
+---------------------+
<---1--->| Generic AAA Server |<---1--->
| | ............
| Rule based engine |<----|----->: Policy :
| | 3| :..........:
+---------------------+<----|--+ ............
^ +-->: Events :
| :..........:
2
|
V
+----------------------+ ...............
| Application specific |<--3-->: Acct Policy :
| Module | :.............:
+----------------------+
^
|
5
|
V
+-------------------------------------+
| Service |
| +-----------+ +----------------+ | ..............
| | Service |<-->| Accounting/ |<--3-->: Accounting :
| | Provision | | Metering | | : Data :
| +-----------+ +----------------+ | :............:
+-------------------------------------+
Figure 5: AAA Server with Integrated Accounting
図5：統合された会計を持つAAAサーバー
Data about the resource consumption is sent back to the AAA server via the ASM. The accounting process within the service converts the metered data into accounting records which are sent to the AAA server. For generating accounting records data conversion, aggregation and filtering of data might be performed.
リソース消費に関するデータは、ASMを介してAAAサーバーに送信されます。サービス内の会計プロセスは、メーターデータをAAAサーバーに送信する会計レコードに変換します。アカウンティングレコードのデータ変換を生成するには、データの集約とフィルタリングが実行される場合があります。
In contrast to the integrated accounting approach, accounting can also be seen as a separate or discrete service on its own. In this case the accounting does not have to be coupled with a specific service. Discrete Accounting can be used for outsourcing the accounting task. The accounting service can be provided by a general accounting system which is able to account for different services.
統合された会計アプローチとは対照的に、会計は独立または個別のサービスと見なすこともできます。この場合、会計を特定のサービスと組み合わせる必要はありません。離散会計は、会計タスクのアウトソーシングに使用できます。会計サービスは、さまざまなサービスを説明できる一般会計システムによって提供できます。
For example, a generalized meter can do accounting for web traffic, FTP traffic and voice over IP traffic. If accounting is a separate service, one provider can do the accounting (charging and billing) for several other service providers. Accounting is offered just like any other service. This means authentication and authorization might be required prior to the accounting service provisioning. Furthermore, it is important that the involved parties agree beforehand how the accounting service is provided, what parameters can be set and how disputes will be resolved. After the accounting service has been configured, the AAA server can do the user configuration of the service.
たとえば、一般化されたメーターは、Webトラフィック、FTPトラフィック、およびIPトラフィックの音声の会計を行うことができます。会計が別のサービスである場合、1人のプロバイダーが他のいくつかのサービスプロバイダーに対して会計（充電と請求）を行うことができます。会計は、他のサービスと同じように提供されます。これは、会計サービスの提供の前に認証と承認が必要になる場合があることを意味します。さらに、関係者は、会計サービスの提供方法、どのパラメーターを設定できるか、どのように紛争を解決するかを事前に事前に同意することが重要です。会計サービスが構成された後、AAAサーバーはサービスのユーザー構成を実行できます。
+---------------------+
<---1--->| Generic AAA Server |<---1--->
| | ............
| Rule based engine |<----|----->: Policy :
| | 3| :..........:
+---------------------+<----|--+ ............
^ ^ +-->: Events :
| | :..........:
2 2
| |
V V
+-------------+ +--------------+ ...............
| Application | | Application |<--3-->: Acct Policy :
| Specific | | Specific | :.............:
| Module | | Module |
+-------------+ +--------------+
^ ^
| |
5 5
| |
V V
+-------------+ +---------------+ ..............
| Service | | Accounting/ |<--3-->: Accounting :
| | | Metering | : Data :
+-------------+ +---------------+ :............:
Figure 6: AAA Server with Discrete Accounting A service provider that has outsourced the accounting service has to request this service from an accounting service provider. The generated accounting records are sent from the accounting provider to the service provider who may make modifications to the records before sending them to the final destination. Having such a general accounting service might speed up the creation of new services - especially specialized content services - in the Internet. This separation is also beneficial to support special accounting services (e.g. sending accounting indications to users) that are not directly coupled to a network service. Furthermore, this separation is useful if the same set of accounting strategies can be applied to different services (e.g. different tariffs which can be used for a set of services).
図6：個別の会計を持つAAAサーバー会計サービスを外部委託したサービスプロバイダーは、会計サービスプロバイダーからこのサービスを要求する必要があります。生成された会計記録は、会計プロバイダーからサービスプロバイダーに送信されます。サービスプロバイダーは、最終目的地に送信する前にレコードを変更することができます。このような一般会計サービスを受けることで、インターネットで新しいサービス（特に専門的なコンテンツサービス）の作成がスピードアップされる可能性があります。この分離は、ネットワークサービスに直接結合されていない特別な会計サービス（たとえば、ユーザーに会計指標を送信する）をサポートするためにも有益です。さらに、この分離は、同じ一連の会計戦略を異なるサービスに適用できる場合に役立ちます（たとえば、一連のサービスに使用できる異なる関税）。
Another option is to outsource only the metering service. The meter service provider generates meter data and sends them to the service provider who has requested them. The service provider then generates accounting records based on the received meter data. A separate accounting or metering service provider can be used to validate the accounting data generated by a service provider. If the customer does not trust a service provider, or in the case of a legal action, a trusted accounting or metering provider is able to validate the correctness of the accounting data generated by the service provider.
別のオプションは、メータリングサービスのみを外部委託することです。メーターサービスプロバイダーはメーターデータを生成し、それらを要求したサービスプロバイダーに送信します。サービスプロバイダーは、受信メーターデータに基づいて会計レコードを生成します。別の会計または計量サービスプロバイダーを使用して、サービスプロバイダーによって生成された会計データを検証できます。顧客がサービスプロバイダーを信頼していない場合、または法的措置の場合、信頼できる会計または計量プロバイダーは、サービスプロバイダーによって生成された会計データの正確性を検証できます。
In Intra-Domain accounting [RFC2975], the data about resource consumption is collected in one administrative domain for usage in that domain. Accounting policies are enforced locally. Since no exchange of accounting data with other domains is required in this scenario, accounting policies do not need to be exchanged with other entities.
ドメイン内会計[RFC2975]では、リソース消費に関するデータは、そのドメインで使用するために1つの管理ドメインに収集されます。会計方針は地元で実施されています。このシナリオでは、他のドメインとの会計データの交換は必要ないため、会計ポリシーを他のエンティティと交換する必要はありません。
+-------------+
| Billing |
+-------------+
^
|
+-------------+
| ASM |
+-------------+
^
| ..............
+--------------+ : Accounting :
| AAA |<--->: Policies :
+--------------+ :............:
| ^
| |
V |
+--------------+
| ASM |
+--------------+
| ^
config | | Accounting Records
V |
+------------+ +-----------|----------+
| | Service usage | +--------+-------+ |
| End System |-------------->| | Accounting | |
| | | +----------------+ |
+------------+ | |
| Service |
+----------------------+
User Provider
Figure 7: Intra-Domain Accounting
図7：ドメイン内会計
For Inter-Domain Accounting, at least two administratively separated networks are involved in the accounting process. These can be a Home- and a Foreign-Provider in a Roaming/Mobile IP Scenario [RFC2002] or a chain of providers if service provisioning involves data transfer and/or services from different domains. In these scenarios, the exchange of accounting policies between providers is necessary if accounting tasks are delegated to one provider or shared among multiple providers. The exchange of accounting policies is done by the AAA servers as shown in the figure below.
ドメイン間会計の場合、少なくとも2つの管理的に分離されたネットワークが会計プロセスに関与しています。これらは、ローミング/モバイルIPシナリオ[RFC2002]のホームおよび外交プロバイダーまたは、サービスの提供に異なるドメインからのデータ転送および/またはサービスが含まれる場合のプロバイダーのチェーンである可能性があります。これらのシナリオでは、会計タスクが1人のプロバイダーに委任されたり、複数のプロバイダー間で共有されたりする場合、プロバイダー間の会計方針の交換が必要です。以下の図に示すように、会計ポリシーの交換はAAAサーバーによって行われます。
| +-----------+
| | Billing |
| +-----------+
| ^
| |
| +-----------+
| | ASM |
| +-----------+
| ^
| |
+------------------+ 1. AccPolInd +-----------+
| |<-------------| |
| | | | |
| AAAF | 2.AccPolConf | AAAH |
| |------------->| |
| | | | |
| | 3. AccRec | |
| |------------->| |
+------------------+ | +-----------+
config | ^ | ^
| | | |
V | | V
+--------------+ | .............
| ASM | | : Acct. :
+--------------+ | : Policies :
| ^ | :...........:
| | |
| | Acct. Records |
Service V | |
+------------+ usage +-----------|----------+ |
| | | +--------+-------+ | |
| End System |------>| | Accounting | | |
| | | +----------------+ | |
+------------+ | | |
| Service | |
+----------------------+ |
User Foreign-Provider Home-Provider
ユーザー外部プロバイダーホームプロバイダー
Figure 8: Inter-Domain Accounting (Roaming Example)
図8：ドメイン間会計（ローミングの例）
In this example, the foreign provider takes over the collection of accounting data. The home provider is responsible for applying a charging scheme and sending the bill. Therefore, the home provider needs accounting data from the foreign provider. In order to instruct the foreign provider about the desired accounting record type and report frequency, the home AAA server sends an accounting policy indication to the foreign AAA server. The indication contains the accounting policy. Instead of sending an indication, the accounting policies could also be piggy backed onto an authorization reply. If the foreign AAA server is able to configure devices in a way to enforce the desired policy (e.g. the meters are capable of metering the requested attributes) the accounting policy indication is acknowledged. In case the requested policy cannot be enforced, the accounting service is denied. Reasons to deny the enforcement of a specific accounting policy could be, e.g. because the meter is not capable of measuring the requested attributes or the frequency of records cannot be provided, or the home provider is not authorized to get the requested detailed data. In this case procedures would be useful to negotiate the smallest common denominator for the involved AAA servers regarding the provisioning of accounting data.
この例では、外国人プロバイダーが会計データの収集を引き継ぎます。ホームプロバイダーは、請求スキームを適用し、請求書を送信する責任があります。したがって、ホームプロバイダーには、外国のプロバイダーからの会計データが必要です。外国のプロバイダーに目的の会計記録の種類とレポート頻度について指示するために、Home AAAサーバーは、外国のAAAサーバーに会計方針の表示を送信します。適応症には会計方針が含まれています。兆候を送信する代わりに、会計ポリシーは、承認返信にバックすることもできます。外国のAAAサーバーが、目的のポリシーを実施する方法でデバイスを構成できる場合（たとえば、メーターが要求された属性を計算できる）、会計方針の表示が認められます。要求されたポリシーを実施できない場合、会計サービスは拒否されます。特定の会計方針の施行を拒否する理由は、例えばメーターが要求された属性を測定できないか、レコードの頻度を提供できないため、またはホームプロバイダーが要求された詳細データを取得する権限を与えられていないためです。この場合、手順は、会計データのプロビジョニングに関する関係するAAAサーバーの最小共通点分母と交渉するのに役立ちます。
The AAA authorization framework [RFC2904] introduces different message sequences for authorization. The integration of configurable accounting services for the message sequences can be done as described in the following sections.
AAA認証フレームワーク[RFC2904]は、承認のためにさまざまなメッセージシーケンスを導入します。メッセージシーケンスの構成可能な会計サービスの統合は、以下のセクションで説明するように実行できます。
The appropriate accounting policy for the authorized service is either stored together with the authorization policy or in a separate repository. The configuration of the accounting infrastructure can be done together with the user configuration of the service equipment (messages 2 and 3 in Figure 9). User-specific configuration of the service equipment and the accounting infrastructure configuration might involve the transfer of configuration data to multiple entities in the network (e.g. to different routers for setting up QoS provisioning or to dedicated accounting meters).
承認されたサービスの適切な会計方針は、承認ポリシーとともに保存されるか、別のリポジトリに保存されます。会計インフラストラクチャの構成は、サービス機器のユーザー構成とともに実行できます（図9のメッセージ2および3）。サービス機器のユーザー固有の構成とアカウンティングインフラストラクチャ構成には、ネットワーク内の複数のエンティティに構成データを転送することが含まれます（たとえば、QoSプロビジョニングを設定するための異なるルーターまたは専用の会計メーターに）。
+-------------------------+
+------+ | Service Provider |
| | 1 | +-------------------+ |
| |------+->| AAA Server | |
| |<-----+--| | |
| | 4 | +-------------------+ |
| User | | | ^ ^ |
| | | |2 |3 |AcctRec |
| | | V | | |
| | | +-------------------+ |
| | | | Service | |
| | | | Equipment | |
| | | +-------------------+ |
+------+ | |
+-------------------------+
Figure 9: Accounting and Agent Sequence
図9：会計およびエージェントシーケンス
In the agent sequence, it is possible to allow the user to send accounting policies (e.g. for accounting indications) together with the authorization request to the AAA server. Figure 9 shows the agent sequence authorization and accounting messages.
エージェントのシーケンスでは、AAAサーバーへの承認要求とともに、ユーザーが会計ポリシー（例：会計表示の場合）を送信できるようにすることができます。図9は、エージェントシーケンスの承認と会計メッセージを示しています。
The configuration of the accounting infrastructure can be done similar to the agent sequence during the user configuration of the service equipment. Since the pull sequence does not involve the sending of a specific authorization request (e.g. if the service equipment is a Network Access Server (NAS) and the authorization sequence simply starts with the dial-in process), it would need additional communication to support accounting policy indications from users.
会計インフラストラクチャの構成は、サービス機器のユーザー構成中にエージェントシーケンスと同様に実行できます。プルシーケンスには特定の承認要求の送信が含まれないため（たとえば、サービス機器がネットワークアクセスサーバー（NAS）、認証シーケンスがダイヤルインプロセスから始まる場合）、会計をサポートするための追加の通信が必要になります。ユーザーからのポリシー指標。
+-------------------------+
+------+ | Service Provider |
| |AccPolInd +-------------------+ |
| |.........>| AAA Server | |
| |<.........| | |
| | | +-------------------+ |
| User | | ^ | ^ |
| | | |2 |3 |AcctRec |
| | | | V | |
| | 1 | +-------------------+ |
| |-------+->| Service | |
| |<------+--| Equipment | |
| | 4 | +-------------------+ |
+------+ | |
+-------------------------+
Figure 10: Accounting and Pull Sequence
図10：会計およびプルシーケンス
This can be, for instance, achieved by a hybrid model of agent and pull sequence where the user sends an accounting policy indication to the AAA server in addition to the messages exchange for the pull sequence. Figure 10 shows the pull sequence authorization and accounting messages.
これは、たとえば、エージェントとプルシーケンスのハイブリッドモデルによって達成できます。ここでは、ユーザーがプルシーケンスのメッセージ交換に加えてAAAサーバーに会計ポリシーの表示を送信します。図10は、プルシーケンスの承認と会計メッセージを示しています。
In the push sequence, there is no direct connection between the AAA server and the service equipment. In this sequence there are three possibilities for setting up the accounting infrastructure:
プッシュシーケンスでは、AAAサーバーとサービス機器の間に直接的な接続はありません。このシーケンスでは、会計インフラストラクチャを設定するための3つの可能性があります。
a) A standard fixed accounting procedure that has been assigned in advance for the specific combination of authorized user and service is used.
a) 許可されたユーザーとサービスの特定の組み合わせのために事前に割り当てられた標準的な固定会計手順が使用されます。
b) The ticket (message 3 in Figure 11) contains information about the accounting policies used (e.g. different tickets for the same service with different accounting policies).
b) チケット（図11のメッセージ3）には、使用される会計ポリシーに関する情報が含まれています（例：異なる会計方針を備えた同じサービスの異なるチケット）。
c) The ticket acts as a kind of digital coin and no further accounting is needed. This model also supports the anonymous usage of a service.
c) チケットは一種のデジタルコインとして機能し、それ以上の会計は必要ありません。このモデルは、サービスの匿名の使用もサポートしています。
Figure 11 shows push sequence authorization and accounting messages.
図11は、プッシュシーケンスの承認と会計メッセージを示しています。
+-------------------------+
+------+ | Service Provider |
| | 1 | +-------------------+ |
| |------+->| AAA Server | |
| |<-----+--| | |
| | 2 | +-------------------+ |
| User | | ^ |
| | | | AcctRec |
| | | | |
| | 3 | +-------------------+ |
| |------+->| Service | |
| |<-----+--| Equipment | |
| | 4 | +-------------------+ |
+------+ | |
+-------------------------+
Figure 11: Accounting and Push Sequence
図11：会計およびプッシュシーケンス
If the provisioning of the service and the final authentication/ authorization process is done by different organizations, accounting is rather coupled to the service provisioning process than to the authentication/authorization process. Since the data doesn't have to traverse the home providers network, the home provider has no possibility of collecting data about the resource consumption. Therefore, accounting will usually take place in the foreign provider domain (i.e. in the domain that does the service provisioning). Nevertheless, in order to ensure consistency of the authentication, authorization and accounting processes (e.g. allocation of user IDs to accounting records) and the production of a bill, a connection between the accounting process in the service provisioning domain and the deciding authentication/authorization process (e.g. at the home provider) is needed.
サービスのプロビジョニングと最終的な認証/承認プロセスがさまざまな組織によって行われた場合、会計は、認証/認証プロセスよりもサービス提供プロセスにむしろ結合されます。データはホームプロバイダーネットワークを通過する必要がないため、ホームプロバイダーはリソース消費に関するデータを収集する可能性はありません。したがって、会計は通常、外国のプロバイダードメイン（つまり、サービスプロビジョニングを行うドメイン）で行われます。それにもかかわらず、認証、承認、会計プロセスの一貫性を確保するため（例：ユーザーIDの会計記録への割り当て）、および法案の作成、サービスプロビジョニングドメインの会計プロセスと決定の認証/認証/認証プロセスの間の接続（例：ホームプロバイダー）が必要です。
A possible way of doing this is if the foreign provider gets the accounting policies from the home provider and sets up the accounting architecture in accordance to the given policies, the foreign provider can generate accounting records and send them back to the home provider. The home provider then can apply charging and can produce a bill. An example for this is given in section 9.2. This scenario requires a prior agreement between the involved providers about the possible policies and parameters that are allowed to be set.
これを行う可能性のある方法は、外国人プロバイダーがホームプロバイダーから会計ポリシーを取得し、指定されたポリシーに従って会計アーキテクチャを設定する場合、外国人プロバイダーは会計記録を生成してホームプロバイダーに送り返すことができます。その後、ホームプロバイダーは請求を適用し、請求書を作成できます。この例は、セクション9.2に記載されています。このシナリオには、設定が許可されている可能なポリシーとパラメーターについて、関係するプロバイダー間の事前の合意が必要です。
The following examples illustrate the use of policy-based accounting. Please note that the services used in the examples are used only for illustration purposes and their use in reality requires different messages and parameters.
次の例は、ポリシーベースの会計の使用を示しています。例で使用されるサービスは、イラストの目的でのみ使用され、実際に使用するには異なるメッセージとパラメーターが必要であることに注意してください。
The Internet Printing Protocol (IPP) [RFC2566], and especially the "print-by-reference" model, provides a very interesting example scenario for accounting and the interaction between authorization and accounting. We will describe possible solutions for the accounting of this service and how the accounting is triggered by the authorization. We will show how the model presented above can be used for this example.
インターネット印刷プロトコル（IPP）[RFC2566]、特に「リファレンス」モデルは、会計と承認と会計の間の相互作用の非常に興味深い例のシナリオを提供します。このサービスの会計と、承認によって会計がどのようにトリガーされるかについての可能な解決策について説明します。上記のモデルをこの例で使用する方法を示します。
IPP "print-by-reference" allows a user to request a print service to print a particular file. The file to be printed is not on the client system but rather on a public server. That is, the clients print request can contain a reference, or pointer, to the document instead of the actual document itself. The print service must then read the file to a file server (used for spooling) prior to the printing. There are two possible setups: The file and print server either belong to a single organization (Intra-Domain Accounting) or to two different organizations (Inter-Domain Accounting). In the first case, the user must be authorized by a single service provider for service usage. In the second case, two different possibilities for establishing a trust relationships between the involved entities have to be distinguished [RFC2905].
IPP「Print-by-Reference」を使用すると、ユーザーは特定のファイルを印刷するために印刷サービスを要求できます。印刷されるファイルは、クライアントシステムではなく、パブリックサーバーにあります。つまり、クライアントの印刷リクエストには、実際のドキュメント自体の代わりに、ドキュメントへの参照またはポインターを含めることができます。印刷サービスは、印刷前にファイルサーバー（スプールに使用）にファイルを読み取る必要があります。2つのセットアップがあります。ファイルと印刷サーバーは、単一の組織（ドメイン内会計）または2つの異なる組織（ドメイン間会計）に属します。最初のケースでは、ユーザーはサービスの使用について単一のサービスプロバイダーによって承認される必要があります。2番目のケースでは、関係するエンティティ間の信頼関係を確立するための2つの異なる可能性を区別する必要があります[RFC2905]。
In the case of a single organization, the file and print service is provided by a single service provider. The service subscriber and user role are either one entity (e.g. private home user) or different entities (e.g. company as subscriber, employee as user). For data transport via the underlying network, the transportation service of a network provider is used. In this case, the AAA server of the provider controls the access to the file and the print server. This means the AAA server enforces the accounting policies and collects accounting data for both servers.
単一の組織の場合、ファイルと印刷サービスは単一のサービスプロバイダーによって提供されます。サービスサブスクライバーとユーザーの役割は、1つのエンティティ（プライベートホームユーザーなど）または異なるエンティティ（サブスクライバーとしての会社、ユーザーとしての従業員）のいずれかです。基礎となるネットワークを介したデータ輸送には、ネットワークプロバイダーの輸送サービスが使用されます。この場合、プロバイダーのAAAサーバーは、ファイルと印刷サーバーへのアクセスを制御します。これは、AAAサーバーが会計ポリシーを実施し、両方のサーバーの会計データを収集することを意味します。
If two different organizations are involved there are two possibilities for trust relationships as shown in [RFC2905]:
2つの異なる組織が関与している場合、[RFC2905]に示されているように、信頼関係の2つの可能性があります。
1. The user has an agreement with the print server; the print server has an agreement with the file server. 2. The user has agreements with both print and file server.
1. ユーザーは印刷サーバーと契約を結んでいます。印刷サーバーには、ファイルサーバーとの契約があります。2.ユーザーは、印刷サーバーとファイルサーバーの両方と契約を結んでいます。
In case 1, the user is first authorized by the print service and the request is forwarded to the file server. The file server authorizes the print server and determines if the printer is allowed to access the file. In this case which is shown in Figure 12, the accounting policies from the user arrive at the print service AAA server.
ケース1では、ユーザーは最初に印刷サービスによって承認され、リクエストはファイルサーバーに転送されます。ファイルサーバーは、印刷サーバーを承認し、プリンターがファイルにアクセスできるかどうかを判断します。図12に示すこの場合、ユーザーからの会計ポリシーが印刷サービスAAAサーバーに到着します。
USER DOMAIN PRINT SERVICE DOMAIN FILE SERVICE DOMAIN
| |
+------+ | |
| | | |
| | | |
| | | +--------------------+ | +-------------------+
| User |---1-->| Print Service |---1-->| File Service |
| |<--2---| AAA Server |<--2---| AAA Server |
| | | +--------------------+ | +-------------------+
| | | | Print Server | | | File Server |
| | | | and Printer | | | |
+------+ | +--------------------+ | +-------------------+
1: AccPolInd, 2: AccPolConf
1：Accpolind、2：Accpolconf
Figure 12: Inter-Domain Accounting and Printing Service
図12：ドメイン間会計および印刷サービス
The print service AAA server has to decide which policies can be enforced locally and which must be passed further to the file service AAA server. The print service can add additional accounting policies. In case the file server does not support the desired accounting policies, the print server must notify the user's AAA server and some policy conflict resolution must occur. After the file server has transferred the file to the print service, it generates an accounting record according to the accounting policy and passes it to the print service. The print service generates the final accounting record for the service session based on its own and the file service data after finishing printing. This record will be used for the later billing process. Additionally, the print server can send the final record to the user's AAA server. There it can be used for later authorization decisions based on used resources, i.e. if the customer is a company and the user is an employee.
印刷サービスAAAサーバーは、どのポリシーをローカルで実施できるか、どのポリシーをファイルサービスAAAサーバーに渡す必要があるかを決定する必要があります。印刷サービスは、追加の会計方針を追加できます。ファイルサーバーが目的の会計ポリシーをサポートしていない場合、印刷サーバーはユーザーのAAAサーバーに通知する必要があり、ポリシーの競合解決が発生する必要があります。ファイルサーバーがファイルを印刷サービスに転送した後、会計ポリシーに従って会計記録を生成し、印刷サービスに渡します。印刷サービスは、印刷を終えた後、それ自体とファイルサービスデータに基づいて、サービスセッションの最終会計記録を生成します。このレコードは、後の請求プロセスに使用されます。さらに、印刷サーバーは最終レコードをユーザーのAAAサーバーに送信できます。そこでは、使用済みのリソースに基づいた後で許可された決定に使用できます。つまり、顧客が会社であり、ユーザーが従業員である場合です。
In case 2, the customer AAA server has an agreement with file and print server. In this case, the user's AAA server sends accounting policies to the file and the print server. After finishing the service, both servers generate accounting records for the delivered services which are used for later billing. As in the former case, the accounting data can be sent to the user's AAA server for use in later authorization decisions. The user's AAA server can tie both accounting records together and assign them to the user using audited session information (authorization and accounting messages for a particular session could be coupled via a session ID) and policies that define which activities a certain session is composed of.
ケース2では、顧客AAAサーバーはファイルおよび印刷サーバーと合意しています。この場合、ユーザーのAAAサーバーは、会計ポリシーをファイルと印刷サーバーに送信します。サービスを終了した後、両方のサーバーは、後の請求に使用される配信されたサービスの会計レコードを生成します。前者の場合と同様に、会計データは、後の許可決定で使用するためにユーザーのAAAサーバーに送信できます。ユーザーのAAAサーバーは、両方のアカウンティングレコードを結び付けて、監査済みのセッション情報（特定のセッションの承認と会計メッセージをセッションIDで結合できます）と、特定のセッションが構成されているアクティビティを定義するポリシーを使用してユーザーに割り当てることができます。
For the printing service, there are a number of possible options for sending accounting indications to the user. Accounting indications give the user an indication of how much resources have been used until the time of the indication. A user can receive accounting indications or not depending on the accounting policy for the user.
印刷サービスには、ユーザーに会計表示を送信するための多くの可能なオプションがあります。会計の適応症は、適応症の時期まで使用されているリソースの量をユーザーに示します。ユーザーは、ユーザーの会計方針に応じて、会計上の適応症を受け取るかどうかを受け取ることができます。
For Internet printing with the "print-by-reference" model, such indications would be very helpful for the user. Since the file is not on the clients site, the user might not have information on the file size or the number of pages that will be printed. This means the user has no idea of the costs of the service usage. If user and subscriber are a single entity, accounting indications would help users to avoid exceeding their spending limit. Additionally, accounting indications give the user a hint as to which resource usage has caused the charges. This can be compared to an itemized telephony bill where not only the monetary sum per month is printed but, in addition, information for every call (start time, duration, distance etc.) and its corresponding charge.
「リファレンスごと」モデルを使用したインターネット印刷の場合、このような適応症はユーザーにとって非常に役立ちます。ファイルはクライアントサイトにないため、ユーザーはファイルサイズまたは印刷されるページの数に関する情報を持っていない場合があります。これは、ユーザーがサービスの使用コストを知らないことを意味します。ユーザーとサブスクライバーが単一のエンティティである場合、会計指示は、ユーザーが支出の制限を超えないようにするのに役立ちます。さらに、会計上の適応症は、リソースの使用が料金を引き起こしたことに関するヒントをユーザーに与えます。これは、1か月あたりの金額が印刷されるだけでなく、すべての呼び出し（開始時間、期間、距離など）および対応する充電の情報が印刷されるだけでなく、項目別のテレフォニー法案と比較できます。
In this section, the "Dial-in with Roaming" example from the authorization examples [RFC2905], [RFC2002] is used to show how accounting functions could interact with authorization functions. The accounting modules (e.g. collectors and meters) are seen here as part of the service equipment which is, in this example, located at the visited ISP premises. The basic configuration of the accounting modules is probably done by the visited ISP itself, but the visited ISP can allow the home ISP to influence certain parameters (like report interval or accounting record format). This is useful if the home provider generates the invoice and therefore needs appropriate accounting records to calculate the prices.
このセクションでは、承認例[RFC2905]、[RFC2002]の「ローミングを伴うダイヤルイン」の例を使用して、会計機能が認証機能とどのように相互作用できるかを示します。会計モジュール（コレクターやメーターなど）は、この例では、訪問されたISP施設にあるサービス機器の一部としてここで見られます。会計モジュールの基本的な構成は、おそらく訪問されたISP自体によって行われますが、訪問されたISPは、Home ISPが特定のパラメーター（レポート間隔や会計記録形式など）に影響を与えることができます。これは、ホームプロバイダーが請求書を生成し、したがって価格を計算するために適切な会計記録が必要な場合に役立ちます。
User | Visited ISP | Home ISP
| |
| | +-----------+ ..........
<--------------------12-------------------| Charging, |<-:charging:
| | | Billing | :policies:
| | +-----------+ :........:
| | ^
| | |
| | +-----------+
| | | ASM |
| | +-----------+
| | ^
| | |11
| | |
| +------------+ | +-------------+
| | | | | |
| | |---10---->| |
| | | | | |
Acct. Records | AAAF Server|----3---->| AAAH Server |
<-----------------| |<---4-----| |
| | | | | |
| | | | | |
| +------------+ | +-------------+
| ^ | ^ |
| | | | |
| | 5 9 |
| | | | |
| | V | |
| | +----------------+|
| | | ASM ||
| 2 | ||
| | +----------------+|
| | | ^ |
| | | | |
| | 6 8 |
| | | | |
| +------------+------+-------+ |
7 | | Service | | | |
<--------| Equipment | +----------+| |
1 | | |->|Accounting|| |
-------->| | +----------+| |
| | config | | | |
| | | +---------+ | |
| | +->| Meters | | |
| | +---------+ | |
| +---------------------------+ |
| |
Figure 13: Roaming Example
The exchange of authorization data corresponds to the example in
[RFC2905]. As an additional component, we introduce an ASM between
home AAA and service equipment for the user configuration which
happens after successful authorization. The extended roaming example
is shown in Figure 13. Steps (1), (2) and (3) describe the
forwarding of an authentication/authorization request from the user
via the AAA sever of the visited ISP to the home AAA server. In step
(4), user specific service parameters are given to the visited ISP's
AAA server and are forwarded to the service equipment (5) where the
user configuration is done. The user-specific service parameters
could additionally include the desired policies for the configuration
of the accounting infrastructure of the visited ISP. An accounting
policy could be, for instance, "for user X one accounting record of
type Y has to be generated every 30 seconds". This accounting policy
is used by the visited ISP to configure his modules (e.g. metering,
data collection).
User-dependent service parameters are converted by the ASM into the appropriate configuration information (6). Then the user is informed about the completed authentication/authorization process (7). The accounting architecture starts metering the resource usage and sends metering records to the ASM (8). The ASM uses the metered data to fill the required accounting records and sends them to the visited ISP's AAA server (9). The visited ISP can either post-process the data or directly forward them to the home ISP (10). With this data as input, an invoice is generated by the charging and billing modules within the home providers domain (11) by using charging policies (tariff formulas), and then sent to the user/customer (12).
ユーザー依存のサービスパラメーターは、ASMによって適切な構成情報に変換されます（6）。次に、ユーザーは、完成した認証/認証プロセス（7）について通知されます。会計アーキテクチャは、リソースの使用量を計上し始め、ASMに計量レコードを送信します（8）。ASMは、計量されたデータを使用して必要な会計記録を記入し、訪問したISPのAAAサーバー（9）に送信します。訪問したISPは、データを後処理するか、自宅ISPに直接転送できます（10）。このデータを入力として、請求書は、充電ポリシー（関税式）を使用して、ホームプロバイダードメイン（11）内の充電および請求モジュールによって生成され、ユーザー/顧客（12）に送信されます。
As an additional option, accounting records can also be offered to the user (accounting indication) as a special service. For this special service a separate authorization is required.
追加のオプションとして、特別なサービスとしてユーザー（会計表示）に会計記録を提供することもできます。この特別なサービスには、個別の承認が必要です。
This example explains how integrated accounting is configured via policies for a Diffserv service [RFC2475] based on bandwidth brokers [I2-BB]. The service is the transport of packets with a higher priority and the service includes accounting and QoS auditing. Figure 14 shows the service setup. The user issues a Service Request (SR) for a Diffserv service to the AAA server. The request contains a user ID and the parameter for the desired service class.
この例では、帯域幅ブローカー[I2-BB]に基づいて、DiffServサービス[RFC2475]のポリシー[I2-BB]を介して統合会計がどのように構成されているかを説明しています。このサービスは、優先度が高いパケットの輸送であり、サービスには会計とQoS監査が含まれます。図14は、サービスのセットアップを示しています。ユーザーは、AAAサーバーへのDiffServサービスのサービス要求（SR）を発行します。リクエストには、ユーザーIDと目的のサービスクラスのパラメーターが含まれています。
User->AAA: user-x@nw-a, service=diffserv, class=gold,
amount=2Mbit, dest= nw-b
In this example, user-x is located at network A (nw-a) and requests a gold class service for all flows from this network to the destination network B (nw-b). After authentication and authorization has been completed successfully, the AAA server extracts the ASI from the request and passes them to the ASM of the Diffserv service.
この例では、User-XはネットワークA（NW-A）にあり、このネットワークから宛先ネットワークB（NW-B）へのすべてのフローのゴールドクラスサービスを要求します。認証と承認が正常に完了した後、AAAサーバーはリクエストからASIを抽出し、それらをDiffServサービスのASMに渡します。
AAA->ASM: service=diffserv, class=gold, amount=2Mbit, src=nw-a
dest=nw-b
The ASM takes over the task of translating the application specific information into appropriate user configuration information for the service equipment. For the given Diffserv example, the service equipment consists of three components: accounting equipment, the QoS auditing equipment and the bandwidth broker architecture. The ASM has to address all three components to set up the requested service for the user. The translation of the ASI into configuration information for the components can be done by evaluating service provisioning policies. For example, the ASM could have the following service provisioning policy:
ASMは、アプリケーション固有の情報をサービス機器の適切なユーザー構成情報に変換するタスクを引き継ぎます。指定されたdiffservの例では、サービス機器は、会計機器、QoS監査機器、帯域幅のブローカーアーキテクチャの3つのコンポーネントで構成されています。ASMは、ユーザーに要求されたサービスをセットアップするには、3つのコンポーネントすべてに対応する必要があります。コンポーネントの構成情報へのASIの翻訳は、サービスプロビジョニングポリシーを評価することで実行できます。たとえば、ASMは次のサービス提供ポリシーを持つことができます。
if class==gold {
set bw-request.class = gold
set accounting.type = comprehensive
set qos-audit.metric = one-way-delay
...
}
This results in sending a bandwidth request to the BB which asks for a gold service with the given parameters. Furthermore, the ASM issues a request to the accounting equipment for comprehensive accounting and a request to the QoS auditing equipment for a one-way-delay measurement between the given networks.
これにより、BBに帯域幅リクエストを送信し、指定されたパラメーターを使用してゴールドサービスを要求します。さらに、ASMは、包括的な会計のために会計装置に要求を発行し、特定のネットワーク間の一元配置測定のためのQoS監査機器へのリクエストを発行します。
ASM->BB: BW-request(gold, src=nw-a, dest=nw-b, amount=2Mbit)
ASM->Acct: Acct-request(comprehensive, src=nw-a)
ASM->QoS: QoS-audit-request(one-way-delay, src=nw-a, dest=nw-b)
The bandwidth broker then sets up the Diffserv infrastructure to provide the prioritized forwarding according to the definition of a gold class. This is done in accordance with the actual bandwidth broker's architecture and is not further considered here. For the Accounting Configuration and the QoS Audit Control, local configuration policies exist for setting up the service.
帯域幅ブローカーは、DiffServインフラストラクチャをセットアップして、ゴールドクラスの定義に従って優先順位付けされた転送を提供します。これは、実際の帯域幅ブローカーのアーキテクチャに従って行われ、ここではさらに考慮されていません。会計構成とQOS監査制御のために、サービスをセットアップするためのローカル構成ポリシーが存在します。
Accounting-Policy:
if type==comprehensive {
set meter-location = access-point(nw-a)
set record type =detailed
set report interval = 120 s
set report target = 193.175.12.8
^ indent of last two lines
}
QoS-Measurement-Policy:
if metric==one-way-delay {
set method = passive
set timestampsize = 48 bit
set ingress-meter-location = access-point(nw-a)
set egress-meter-location = access-point(nw-b)
}
In this case, the local accounting policy sets the meter location to the network access point of network A. It states that for comprehensive accounting, a detailed record type is required with a report interval of 120 s. The resulting records have to be sent to the given report target. The QoS measurement policy sets the measurement method to passive measurement. It sets the size used for timestamp representation to 48 bits. As meter locations, the meters at the access points of network A and network B are used.
この場合、ローカル会計ポリシーは、ネットワークAのネットワークアクセスポイントにメーターの場所を設定します。包括的な会計では、レポート間隔の120秒で詳細なレコードタイプが必要であると述べています。結果のレコードを指定されたレポートターゲットに送信する必要があります。QoS測定ポリシーは、測定方法をパッシブ測定に設定します。タイムスタンプの表現に使用されるサイズを48ビットに設定します。メーターの場所として、ネットワークAとネットワークBのアクセスポイントのメーターが使用されます。
After evaluating these policies, the instructions for the meter configuration are passed down to the measurement infrastructure. In our example, the accounting configuration instructs the meter at the first measurement point (MP1) to add a new rule with the given flow attributes and settings for storage and reporting of results.
これらのポリシーを評価した後、メーター構成の指示は測定インフラストラクチャに渡されます。この例では、会計構成は、最初の測定ポイント（MP1）のメーターに指示し、結果のストレージと報告のための与えられたフロー属性と設定を備えた新しいルールを追加します。
Acct->MI: MP1: add rule dscp=23, src=a.a.a/24, dest=b.b.b.b/24
save volume
set report interval = 120 s
set report target = 193.175.12.8
SR +-------+
User ----------------->| AAA |
+-------+
|
| ASI
V
+-------+
+-----------------| ASM |--------------+--------------+
| Policy +-------+ Policy | BW Request |
| Parameters Parameters | |
| | |
-----|----------------------------------------|--------------|-----
| Service Equipment | |
V V V
+---------------+ .............. +-----------+ +-----------+
| Accounting |<-->: Local :<-->| QoS | | Bandwidth |
| | : Policies : | Auditing | | Broker |
+---------------+ :............: +-----------+ +-----------+
| |
| Meter Instructions | Measurement Setup
V V
+--------------------------------------------------+
| Measurement |
| Infrastructure |
+--------------------------------------------------+
Figure 14: Diffserv Service Provision Setup
図14：DiffServサービスの提供セットアップ
The QoS audit control instructs two meters (at MP1 and MP2) to set up a passive one-way-delay measurement.
QoS監査制御は、2メートル（MP1およびMP2）に、パッシブの一方向測定を設定するよう指示します。
QoS->MI: MP1: add rule dscp=23, src=a.a.a.a/24 dest=b.b.b.b/24,
save timestamp-48
MP2: add rule dscp=23, src=a.a.a.a/24, dest=b.b.b.b/24,
save timestamp-48
This example explains how discrete accounting can be used to provide accounting indications for the user. Accounting indications are sent to the user in order to inform the user about current resource consumption. The accounting indication is a special accounting service that can be provided in addition to the standard accounting performed by the provider. Like for any other service, an authorization should take place before the accounting indication service provisioning. Therefore, the accounting here is seen as a separate service. That means the accounting service is independent of the main service and therefore can be applied to different services. It might be used as an addition to an integrated accounting that is part of the service. The authorization process for the accounting service is out of the scope of this document and therefore is not further explained here.
この例では、ユーザーに会計表示を提供するために離散会計を使用する方法を説明しています。現在のリソース消費についてユーザーに通知するために、会計指示がユーザーに送信されます。会計表示は、プロバイダーが実施した標準的な会計に加えて提供できる特別な会計サービスです。他のサービスと同様に、会計表示サービスのプロビジョニングの前に承認が行われるべきです。したがって、ここでの会計は別のサービスと見なされます。つまり、会計サービスはメインサービスとは独立しているため、さまざまなサービスに適用できます。サービスの一部である統合会計への追加として使用される場合があります。会計サービスの承認プロセスはこの文書の範囲外であるため、ここではこれ以上説明されていません。
Figure 15 illustrates the configuration message sequence for setting up the accounting service. First, the user sends an Accounting Service Request (ASR) to the AAA server which includes desired parameters for the provisioning of the accounting service (e.g. report interval).
図15は、会計サービスを設定するための構成メッセージシーケンスを示しています。まず、ユーザーは、会計サービスのプロビジョニングに目的のパラメーター（レポート間隔など）を含むAAAサーバーに会計サービスリクエスト（ASR）を送信します。
user->AAA: user-x@nw-a, service= accounting indications,
report interval= 60 s
The AAA server passes the ASI to the ASM of the accounting service after the user has been authenticated and authorized for the service usage.
AAAサーバーは、ユーザーがサービスの使用を認証および許可された後、ASIを会計サービスのASMに渡します。
AAA->ASM: user-x@nw-a, service=accounting indications,
report interval= 60 s
The ASM generates an accounting policy based on the ASI and passes this policy to the Accounting Configuration.
ASMは、ASIに基づいて会計方針を生成し、このポリシーを会計構成に渡します。
ASM->Acct: If src=a.a.a.x {
acc-indication = on
report interval = 60s
report target= a.a.a.x
}
ASR +-------+
User --------------->| AAA |
+-------+
|
| ASI
V
+-------+
| ASM |
+-------+
|
-------------------------|---------------------------
Service Equipment | Accounting Policy
V
+-----------------+ ..............
| Accounting |<---->: Local Acct :
| | : Policies :
+-----------------+ :............:
|
| Meter Instructions
V
+-----------------+
| Measurement |
| Infrastructure |
+-----------------+
Figure 15: Accounting Indication Configuration
図15：会計表示構成
The Accounting Configuration generates meter instructions according to the accounting policies from the ASM and local accounting policies and passes them to the measurement infrastructure.
会計構成は、ASMおよびローカル会計ポリシーからの会計方針に従ってメーターの命令を生成し、それらを測定インフラストラクチャに渡します。
local Acct-Policy: if acc-indication {
record type = compact
}
Acct->MI: MP1: set report interval = 60 s
add report target = a.a.a.x
Accounting services provide the basis for billing. Therefore, the incentives (mainly saving money) and potential for fraud is extremely high in the field of configuration of the accounting architecture and the collection of accounting data. In the presented framework, two types of data communications are required, the exchange of accounting policies and the collection of accounting records. Both communications introduce potential security hazards.
会計サービスは、請求の基礎を提供します。したがって、インセンティブ（主にお金の節約）と詐欺の可能性は、会計アーキテクチャの構成と会計データの収集の分野で非常に高いです。提示されたフレームワークでは、会計ポリシーの交換と会計記録の収集という2種類のデータ通信が必要です。両方の通信は、潜在的なセキュリティハザードを導入します。
The following potential security hazards can be identified:
次の潜在的なセキュリティハザードを特定できます。
- Forgery of accounting policies and accounting record information Both accounting policies and accounting records can be the target of forgery of information. Accounting policies contain configuration information. Modifying this information can lead to a mal-configured accounting and metering system which either allows data to traverse the accounting system undetected (without being accounted for, e.g. by changing the classification rules of a meter) or produces bogus accounting records. Accounting records contain data about resource consumption and provide the basis for billing. Modifying accounting records may lead to erroneous bills. Furthermore, it is important that policies or accounting records are not redirected or removed and that forged policies or records are not inserted.
- 会計方針と会計記録情報の偽造情報と会計記録の両方が、情報の偽造の標的になる可能性があります。会計ポリシーには構成情報が含まれています。この情報を変更すると、不変の会計および計測システムにつながる可能性があります。これにより、データが検出されない会計システムを通過させることができます（たとえば、メーターの分類ルールを変更することで説明することなく）、または偽の会計記録を生成します。会計記録には、リソース消費に関するデータが含まれており、請求の基礎を提供します。会計記録を変更すると、誤った請求書につながる可能性があります。さらに、ポリシーまたは会計記録がリダイレクトまたは削除されず、偽造されたポリシーまたは記録が挿入されないことが重要です。
- Eavesdropping It may be required to keep accounting policies and accounting records confidential between the involved parties.
- 盗聴することは、関係者間で会計ポリシーと会計記録を秘密にする必要がある場合があります。
- Denial of Service (DoS) attacks Both the AAA server and the accounting/metering subsystem can be the target of denial of service attacks. A denial of service attack against the AAA server may lead to malfunction and even breakdown of the server. This means the server will not be able to provide proper authentication, authorization and accounting functionality. The service provided by the AAA server will become unavailable or unusable. An attack to the server can be worse than an attack to the service equipment itself, especially if multiple services use one AAA server. An attack against the accounting/metering system will cause loss of metering data and/or loss of accounting records.
- サービス拒否（DOS）攻撃AAAサーバーの両方が攻撃し、会計/メータリングサブシステムがサービス拒否攻撃のターゲットになる可能性があります。AAAサーバーに対するサービス拒否攻撃は、サーバーの誤動作や故障にさえつながる可能性があります。これは、サーバーが適切な認証、承認、会計機能を提供できないことを意味します。AAAサーバーが提供するサービスは、利用できないか、使用できなくなります。サーバーへの攻撃は、特に複数のサービスが1つのAAAサーバーを使用している場合、サービス機器自体への攻撃よりも悪い場合があります。会計/計量システムに対する攻撃は、計量データの損失および/または会計記録の損失を引き起こします。
This leads to the following security requirements:
これは、次のセキュリティ要件につながります。
- Secrecy of accounting policies and accounting data Unauthorized entities should not be able to read or modify accounting policies or accounting records. This can be achieved with standard encryption methods.
- 会計ポリシーと会計データの秘密は、許可されていないエンティティが会計ポリシーまたは会計記録を読み取ったり変更したりすることはできないはずです。これは、標準の暗号化方法で実現できます。
- Authentication of accounting data and accounting policy sources It should be ensured that the data is originated by the original source. Source-authentication can be achieved by using digital signatures.
- 会計データと会計ポリシーソースの認証データが元のソースによって発信されることを保証する必要があります。デジタル署名を使用することにより、ソースオーメンテーションを実現できます。
- Protection of the integrity of accounting policies and records It should be ensured that the data was not modified on the way from sender to receiver. Data-authentication can also be achieved with digital signatures.
- 会計方針と記録の完全性の保護は、送信者から受信者への途中でデータが変更されないようにする必要があります。デジタル署名では、データ - 認証も実現できます。
- Verify correctness of generated accounting data It must be ensured that the accounting data generated by the service provider is correct. A provider may generate incorrect accounting records either deliberately (i.e. forging) or unintentionally (e.g. faulty configuration). These incorrect accounting records probably have the consequence of incorrect bills. Customers can verify the correctness of the accounting data through their measurements and/or through data collected by a trusted third party. A trusted third party can be an independent accounting service provider as described in section 7.2 or a more general entity providing an auditing service.
- 生成された会計データの正しさを確認することは、サービスプロバイダーによって生成された会計データが正しいことを確認する必要があります。プロバイダーは、意図的に（つまり、鍛造）または意図せず（たとえば、構成の故障）、誤った会計記録を生成する場合があります。これらの誤った会計記録には、おそらく誤った請求書の結果があります。顧客は、測定値および/または信頼できる第三者によって収集されたデータを通じて、会計データの正しさを検証できます。信頼できるサードパーティは、セクション7.2で説明されている独立した会計サービスプロバイダーまたは監査サービスを提供するより一般的なエンティティです。
- Prevention and protection against Denial of Service attacks The AAA protocol and all building blocks should be designed and implemented in a way as resistant as possible to denial of service attacks. An additional strategy to defend against DoS attacks is to add a component to the meter system that is able to detect suspicious traffic patterns. Upon detection, further actions can be taken according to a pre-defined policy.
- サービス拒否攻撃に対する予防と保護AAAプロトコルとすべてのビルディングブロックは、サービス拒否攻撃に対して可能な限り耐性のある方法で設計および実装する必要があります。DOS攻撃を防御するための追加の戦略は、疑わしいトラフィックパターンを検出できるメーターシステムにコンポーネントを追加することです。検出されると、事前に定義されたポリシーに従ってさらなるアクションを実行できます。
The prevention of these hazards has to be considered for the protocols used for accounting policy exchange and the transportation of accounting records. Since the security requirements for authentication, transmission level security, data object confidentiality and integrity are addressed in the criteria for AAA protocol evaluation [RFC2989], we assume that the future AAA protocol(s) will be suited for secure accounting record transfer and probably also for secure accounting policy transport. Furthermore, we assume that existing or upcoming solutions for secure transportation and enforcement of policies can be used. Real prevention of DoS attacks is quite difficult. A selective dropping of the attackers packets is impossible if the malicious packets cannot be separated from the valid customer traffic. Dropping of all packets of a certain type may prevent authorized customers from using the service and therefore help the attacker to achieve her goal.
これらの危険の防止は、会計政策交換と会計記録の輸送に使用されるプロトコルのために考慮されなければなりません。認証、送信レベルのセキュリティ、データオブジェクトの機密性、および整合性のためのセキュリティ要件は、AAAプロトコル評価の基準[RFC2989]で対処されているため、将来のAAAプロトコルが安全な会計記録転送に適していると仮定します。安全な会計政策輸送用。さらに、安全な輸送およびポリシーの施行のための既存または今後のソリューションを使用できると想定しています。DOS攻撃の実際の予防は非常に困難です。悪意のあるパケットを有効な顧客トラフィックから分離できない場合、攻撃者パケットの選択的なドロップは不可能です。特定のタイプのすべてのパケットをドロップすると、認定された顧客がサービスを使用することができないため、攻撃者が目標を達成するのに役立ちます。
[I2-BB] Internet2-QBone Bandwidth Broker, http://www.merit.edu/working.groups/i2-qbone-bb
[I2-BB] Internet2-Qbone Bandwidth Broker、http：//www.merit.edu/working.groups/i2-qbone-bb
[NetFlow] NetFlow Services and Applications, White Paper, Cisco Systems, 1999
[Netflow] Netflow Services andアプリケーション、ホワイトペーパー、Cisco Systems、1999
[RFC2002] Perkins, C., "IP Mobility Support", RFC 3220, October 1996.
[RFC2002] Perkins、C。、「IP Mobility Support」、RFC 3220、1996年10月。
[RFC2123] Brownlee, N., "Traffic Flow Measurement: Experiences with NeTraMet", RFC 2123, March 1997.
[RFC2123]ブラウンリー、N。、「トラフィックフロー測定：Netrametの経験」、RFC 2123、1997年3月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang Z.、W。Weiss、「差別化されたサービスの建築」、RFC 2475、1998年12月。
[RFC2566] DeBry, R., "Internet Printing Protocol/1.0: Model and Semantics", RFC 2911, April 1999.
[RFC2566] Debry、R。、「インターネット印刷プロトコル/1.0：モデルとセマンティクス」、RFC 2911、1999年4月。
[RFC2722] Brownlee, N., Mills, C. and G. Ruth, "Traffic Flow Measurement: Architecture", RFC 2722, October 1999.
[RFC2722] Brownlee、N.、Mills、C。and G. Ruth、「トラフィックフロー測定：アーキテクチャ」、RFC 2722、1999年10月。
[RFC2903] de Laat, C., Gross, G., Gommans, L., Vollbrecht, J. and D. Spence, "Generic AAA Architecture", RFC 2903, August 2000.
[RFC2903] de Laat、C.、Gross、G.、Gommans、L.、Vollbrecht、J。and D. Spence、「Generic AAA Architecture」、RFC 2903、2000年8月。
[RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., Gross, G., de Bruijn, B., de Laat, C., Holdrege, M. and D. Spence, "AAA Authorization Framework", RFC 2904, August 2000.
[RFC2904] Vollbrecht、J.、Calhoun、P.、Farrell、S.、Gommans、L.、Gross、G.、De Bruijn、B.、De Laat、C.、Holdrege、M。and D. Spence、 "AAA認証フレームワーク」、RFC 2904、2000年8月。
[RFC2905] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., Gross, G., de Bruijn, B., de Laat, C., Holdrege, M. and D. Spence, "AAA Authorization Application Examples", RFC 2905, August 2000.
[RFC2905] Vollbrecht、J.、Calhoun、P.、Farrell、S.、Gommans、L.、Gross、G.、De Bruijn、B.、De Laat、C.、Holdrege、M。and D. Spence、AAA認証申請の例」、RFC 2905、2000年8月。
[RFC2924] Brownlee, N. and A. Blount, "Accounting Attributes and Record Formats", RFC 2924, September 2000.
[RFC2924] Brownlee、N。およびA. Blount、「会計属性とレコード形式」、RFC 2924、2000年9月。
[RFC2975] Aboba, B., Arkko, J. and D. Harrington, "Introduction to Accounting Management", RFC 2975, October 2000.
[RFC2975] Aboba、B.、Arkko、J。、およびD. Harrington、「会計管理の紹介」、RFC 2975、2000年10月。
[RFC2989] Aboba, B., Calhoun, P., Glass, S., Hiller, T., McCann, P., Shiino, H., Walsh, P., Zorn, G., Dommety, G., Perkins, C., Patil, B., Mitton, D., Manning, S., Beadles, M., Chen, X., Sivalingham, S., Hameed, A., Munson, M., Jacobs, S., Lim, B., Hirschman, B., Hsu, R., Koo, H., Lipford, M., Campbell, E., Xu, Y., Baba, S. and E. Jaques, "Criteria for Evaluating AAA Protocols for Network Access", RFC 2989, November 2000.
[RFC2989] Aboba、B.、Calhoun、P.、Glass、S.、Hiller、T.、McCann、P.、Shiino、H.、Walsh、P.、Zorn、G.、Dommety、G.、Perkins、C.、Patil、B.、Mitton、D.、Manning、S.、Beadles、M.、Chen、X.、Sivalingham、S.、Hameed、A.、Munson、M.、Jacobs、S.、Lim、B.、Hirschman、B.、Hsu、R.、Koo、H.、Lipford、M.、Campbell、E.、Xu、Y.、Baba、S。、およびE. Jaques、「ネットワークのAAAプロトコルを評価するための基準アクセス」、RFC 2989、2000年11月。
[RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S. Waldbusser, "Terminology for Policy-Based Management", RFC 3198, November 2001.
[RFC3198] Westerinen、A.、Schnizlein、J.、Strassner、J.、Scherling、M.、Quinn、B.、Herzog、S.、Huynh、A.、Carlson、M.、Perry、J。and S.Waldbusser、「ポリシーベースの管理のための用語」、RFC 3198、2001年11月。
The authors would like to thank the members of the AAAARCH research group and in particular, the chairs, John Vollbrecht and Cees de Laat, for the fruitful discussions and comments. Special thanks are to Bernard Aboba, Nevil Brownlee and Ed Ellesson for their review and valuable input to this document.
著者は、AAARACH Research Groupのメンバー、特に椅子のJohn VollbrechtとCees de Laatに、実り多い議論とコメントに感謝したいと思います。この文書へのレビューと貴重な入力をしてくれたバーナード・アボバ、ネビル・ブラウンリー、エド・エルソンに感謝します。
Author's Addresses
著者のアドレス
Tanja Zseby Fraunhofer Institute for Open Communication Systems Kaiserin-Augusta-Allee 31 10589 Berlin Germany Phone: +49-30-34 63 7153 Fax: +49-30-34 53 8153 EMail: zseby@fokus.fhg.de
Tanja Zseby Fraunhofer Institute for Open Communication Systems Kaiserin-Augusta-Allee 31 10589ベルリンドイツ電話：49-30-34 63 7153 FAX：49-30-34 53 8153メール：zseby@fokus.fhg.de
Sebastian Zander Fraunhofer Institute for Open Communication Systems Kaiserin-Augusta-Allee 31 10589 Berlin Germany Phone: +49-30-34 63 7287 Fax: +49-30-34 63 8287 EMail: zander@fokus.fhg.de
Sebastian Zander Fraunhofer Open Communication Systems for Open Communication Systems Kaiserin-Augusta-Allee 31 10589ベルリンドイツ電話：49-30-34 63 7287 FAX：49-30-34 63 8287メール：zander@fokus.fhg.de
Georg Carle Fraunhofer Institute for Open Communication Systems Kaiserin-Augusta-Allee 31 10589 Berlin Germany Phone: +49-30-34 63 7149 Fax: +49-30-34 63 8149 EMail: carle@fokus.fhg.de
Georg Carle Fraunhofer Institute for Open Communication Systems Kaiserin-Augusta-Allee 31 10589ベルリンドイツ電話：49-30-34 63 7149 FAX：49-30-34 63 8149メール：carle@fokus.fhg.de
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
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エディター機能の資金は現在、インターネット協会によって提供されています。