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.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（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.
私たちが今よりも将来的にはより多くの帯域幅を持つことになります場合でも、ネットワークリソース活用の制御は、特別な要求を持つアプリケーションをサポートするための帯域幅の（悪意のあるまたは偶発）廃棄物の予防のために不可欠なまま。充電は、ネットワーク資源の利用と共有を制御する可能性を提供します。マルチサービス・ネットワークでの充電は、予約や実際の使用リソースに基づいて行うことができます。予約は通常、予約されたリソースを使用して他のユーザーを排除するため、予約されたリソース上で充電する重要な概念です。充電は予約パラメータに制限されている場合にもかかわらず、のみ、適用される料金が予想されるトラフィック特性の良い予測を与えるために、ユーザの能力に依存します。これは、予約済み、使用するリソースの両方に基づいて課金方式を使用することによってextenuatedすることができます。使用量ベースの課金をサポートするために、リソース予約および利用に関する情報の収集が必要です。リソースの使用状況に関するデータの収集は、会計と呼ばれています。
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つのスキームを選択することができるようにするために、異なる会計サービス（例えば、標準的な、総合的、など）を提供することができます。また、第三者に課金機能を委託するプロバイダのが有利であり得ます。ユーザーは、さまざまなトラフィックプロファイルを導入し、（項目別の請求書、会計適応症、支出制限などのような）会計サービスに関する個人の好みを有することができます。
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).
会計サービスの設定のための一つの更なる課題は、プロバイダドメイン内の異種計量及び会計インフラストラクチャです。また、別のプロバイダのネットワークで使用される異なる課金および計量ソリューションの使用は、（例えば、ローミングシナリオで）構成パラメータの共有化を複雑にします。
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認証および許可されたユーザへのサービスのユーザ構成に必要な機能を提供します。それはASMに送信される標準メッセージ内にカプセル化され、一般的な形式で、またはアプリケーション固有のフォーマットのいずれかで、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]で与えられるメーターManagerは、この文書では、メーター管理者の定義を使用しています。
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パラメータのため、例えばしきい値 - SLA）の与えられた品質がするかどうかを評価するプロセスであるサービスのプロビジョニング中に満たされています。
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].
サービスクラスサービスクラスは、サービスプロバイダによって、そのクラスに属する（[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).
- 技術Diffservの会計要件をプロビジョニングQoSは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).
- そこスキームを充電するさまざまな技術および/または経済モデルに基づく関税変数を使用してスキームを充電を幅広く存在します。選択した課金スキーム（S）プロバイダの会計要件に影響を与えます。いくつかの充電方式は、ゼロまたはわずか数会計要件につながる一方で、他の充電方式は、非常に厳しいかもしれません。例えば、定額課金方式は、まったく会計インフラストラクチャを必要としません。これとは対照的に、体積基準の充電方式は、伝送容量の測定を必要とし、これに、会計の複雑さを増大させます。変数の価格を導入関税は、定期的に会計情報（例えば中間会計兆候によって）ユーザーに提供するために必要な場合があります。
- 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.
- サービスのサービスは、顧客へのプロバイダが提供する機能のセットです。この定義では、プロバイダと顧客が、後に定義されたビジネスの役割のいずれかになります。サービスの種類を認識する必要があります。
- 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).
- 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
- トランスポートサービスは、IPパケットの純粋な輸送の提供を記述する。 ARQ、フォワード - IP層では、これはベースのIntServ予約またはQoSの向上のための他の方法（例えば、自動再送要求、パケットの分化（特定のDSCPを持つパケットの例えば数）を含んでもよいです
Error Correction - FEC). A transport service might also include mechanisms on other layers for improving the transport (e.g. MPLS).
エラー修正 - 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
図1：役割とビジネス関係
The following examples show how this business relationship model can be applied to different services.
次の例では、このビジネス・リレーションシップ・モデルは異なるサービスにどのように適用できるかを示しています。
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]に記載のインターネット印刷のシナリオを説明しています。加入者は会社であり、ユーザーがその会社の従業員です。ファイルサーバやプリントサーバには、二つの異なるサービスプロバイダに属しています。同社では、ファイルサービスのリセラーとして動作するプリントサーバーサービスに加入します。ファイル・サーバー・サービスは、このように、ファイルサーバが指定された場所からデータをダウンロードしてプリントサーバに送信するために提供されるトランスポート・サービスを使用して、ネットワークプロバイダとの契約を持っている、（多分、ユーザの嗜好に基づいて）適切なトランスポート・サービスを選択します。
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:
我々は、異なる計量間の相互作用を記述した会計方針及び経てプロセスとその設定を充電するための参照モデルを開発しました。この参照モデルは、5つの層が異なるビルディングブロックを示し、右側には図2に示されています。ブロックは、最終的な課金処理まで、会計を介してボトムレベルメーターからのデータの処理に係る積層されています。データ集計のみ収集層で行われていない、それはまた、他の層で行うことができます。異なる層上のビルディングブロックは、左側に示されたポリシーを使用して構成されています。上位層のポリシーは、下層ポリシーに変換することができます。構成パラメータは、ポリシーから抽出され、対応するビルディングブロックに渡されます。次のようにさまざまなビルディング・ブロックのタスクは次のとおりです。
- 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.
- 計量メータは、ネットワーク内のリソース消費（例えば、伝送容量）に関するデータを捕捉するために必要とされます。おそらく彼らはネットワークのエッジに配置されます。メートルの二つのタイプを区別することができます：静的メートルと設定可能メートル。静的メートルの場合には、すべてのフローは、その後の充電プロセスは、特定のメータデータを必要とするかどう区別しない、固定された粒度で測定されます。ほとんどの場合、捕捉されたデータの大規模な量が必要計量後のフィルタリングおよび/または凝集を行います。構成メートルの場合では、メータは、計量ポリシーによって指定されたフローのためのメータデータを収集します。
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.
- メートル（S）によって収集された収集データは、さらなる処理のために収集されなければなりません。メータデータの収集は、メータ自体（プッシュモデル）またはコレクタエンティティ（プルモデル）によって開始することができます。収集されたデータは、会計上の層に渡される前に集約することができます。 Meteringポリシーは、収集と集約がどのように行われるかを定義します。
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.).
- 課金課金は貨幣単位に充電することにより算出したコストを変換し、顧客のための最終的な請求書を生成します。課金政策は、とりわけ（例えば、請求書、クレジットカード）、請求書（例えば、項目別か、部分的anyomization、など）と課金のための時間（例えば、毎週、毎月など）の形をタイプを定義します。
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.
- 会計タイプの会計タイプは、一つのキーワードの下に複数のアカウンティング設定を兼ね備えています。サービスクラスと同様、提供された会計タイプは、ビジネス・モデルに基づいて、プロバイダによって定義されています。これにより、プロバイダは、一つのサービスのために、例えば、異なる会計処理の種類を提供し、顧客/ユーザーがいずれかを選択できるようにすることができます。一つのキーワードの下の設定の組み合わせは、ユーザーの選択を簡素化します。例では、別のキーワード（「標準会計」）によってアクセスされる以下の詳細なレコードのキーワード（例えば、「包括的会計」）、またはより少ない頻度世代下の短いレポート間隔の高い粒状アカウンティングレコードの組み合わせです。プロバイダは、会計の種類に同意する場合は、会計タイプの定義は、ドメイン間のシナリオで役立ちます。
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).
- フロー粒状流動粒度は、ネットワーク内のフローを測定する方法ファイン（カバレッジ）で粒度を判定する。粒度は通常、メータ内の特定の分類ルールをインストールすることによって構成されています。計量工程後に適用される集計方式を構成することによって、特定の粒度を設定することも可能です。粒度は、粒状トラフィック凝集体（一方のネットワークから、例えばすべてのトラフィック）を粗する個々のマイクロフロー（例えば五重<SRC、DEST、プロト、SRCポート、DESTポート>によって決定される）までの範囲であり得ます。
- 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つの例は、会計方針が異なるメートルを設定するために使用する方法を示しています。会計方針は、ASMにAAAサーバから送信され、使用メートルのための適切な構成情報をそこに変換されます。
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.
メータNeTraMet [RFC2123]を使用する場合、ポリシーはデータ収集に関連するフロー、属性およびリーダ命令を含むNeTraMetルールセットに変換されます。この情報は、特定の構成に応じて、メータメータリーダを構成NeTraMetマネージャに渡されます。
+------------------+
| 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トラフィック、IPトラフィック経由のFTPトラフィックと音声を占め行うことができます。会計は別のサービスである場合は、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
図6：離散会計とAAAサーバ
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).
会計サービスを外部委託しているサービスプロバイダは、会計サービスプロバイダからこのサービスを要求しなければなりません。生成された会計帳簿は、最終的な宛先に送信する前に、レコードへの変更を行うことができるサービスプロバイダにアカウンティングプロバイダから送られてきます。特に専門的なコンテンツ・サービス - - インターネットにおける一般的な会計サービスを持つことは、新たなサービスの創出をスピードアップすることがあります。この分離は、直接ネットワークサービスに結合されていない（例えば、ユーザーへの会計指標を送信する）特別会計サービスをサポートすることが有益です。会計戦略の同じセットが、異なるサービス（サービスのセットのために使用することができる、例えば異なる関税）に適用することができればさらに、この分離は、有用です。
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.
ドメイン間の会計については、少なくとも二つの管理上分離ネットワークは、課金処理に関与しています。サービスプロビジョニングは、異なるドメインからのデータ転送および/またはサービスを必要とする場合、これらはショッピング - とローミング/モバイル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.
この例では、外部プロバイダは、会計データの収集を引き継ぎます。ホームプロバイダは、充電方式を適用して請求書を送付する責任があります。したがって、ホーム・プロバイダは、外部プロバイダから会計データを必要とします。希望アカウンティングレコードの種類とレポートの頻度について外部プロバイダを指示するために、ホーム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).
認可サービスのための適切な会計方針は、いずれかの許可ポリシーまたは別のリポジトリにまとめて格納されます。課金インフラストラクチャの構成は、サービス機器のユーザ設定（メッセージ2及び3図9）と一緒に行うことができます。サービス機器およびアカウンティングインフラ構成のユーザ固有の設定（例えば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「プリント・バイ・リファレンス」は、ユーザが特定のファイルを印刷する印刷サービスを要求することを可能にします。印刷するファイルは、クライアント・システム上ではなく、公開サーバー上にありません。つまり、クライアントの印刷要求は、ドキュメントの代わりに実際の文書自体への参照、またはポインタを含むことができます。印刷サービスは、印刷前に（スプールに使用）ファイルサーバーにファイルを読み込む必要があります。 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.
単一の組織の場合には、ファイルと印刷サービスは、単一のサービスプロバイダによって提供されます。サービス加入者とユーザの役割は（加入者、利用者として従業員として、例えば会社）のどちらか一方のエンティティ（例えばプライベートホームユーザー）、または異なるエンティティです。基礎となるネットワークを介してデータ伝送のために、ネットワークプロバイダの輸送サービスが使用されます。この場合、プロバイダのAAAサーバは、ファイルおよびプリントサーバーへのアクセスを制御します。これは、AAAサーバは、会計方針を施行し、両方のサーバーのアカウンティングデータを収集することを意味します。
If two different organizations are involved there are two possibilities for trust relationships as shown in [RFC2905]:
二つの異なる組織が関与している場合は、[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.
「プリント・バイ・リファレンス」モデルとインターネット印刷の場合は、そのような兆候は、ユーザーにとって非常に参考になります。ファイルは、クライアントのサイトではないので、ユーザーはファイルサイズや印刷されたページ数の情報を持っていない可能性があります。これは、ユーザーがサービス利用のコストのないアイデアを持っていないことを意味します。ユーザーおよび加入者が単一のエンティティであれば、会計上の指示は、ユーザーが自分の限度額を超えないように役立つだろう。さらに、会計の適応症は、ユーザーにリソース使用量が電荷を起こしているためにどのようヒントを与えます。これは、月あたりの金銭の合計だけでなく、印刷された項目別の電話の請求書と比較することができますがほかに、すべての呼び出し（開始時間、所要時間、距離など）とそれに対応する料金情報。
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は、ホーム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).
認証データの交換は、[RFC2905]での一例に相当します。追加の成分として、我々は成功し、認可後に発生したユーザ設定のためのホームAAAとサービス機器との間にASMをご紹介します。拡張ローミングの例では、ステップ（1）、（2）及び（3）ホームAAAサーバへの訪問ISPのAAAのサーバを介してユーザからの認証/認可要求の転送を説明し、図13に示されています。ステップ（4）において、ユーザ特定のサービスパラメータは、訪問先ISPのAAAサーバに与えられ、ユーザ設定が行われているサービス機器（5）に転送されます。ユーザー固有のサービスパラメータは、さらに訪問したISPの会計インフラストラクチャを構成するための必要なポリシーを含めることができます。会計方針は、可能性があり、例えば、「ユーザX用タイプYの1つのアカウンティングレコードは30秒ごとに生成する必要があります」。この会計方針は、彼のモジュールを構成するために訪問したISPによって使用されている（例えば計量、データ収集）。
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).
ユーザ依存サービスパラメータは、適切な構成情報（6）にASMによって変換されます。その後、ユーザーが完了し、認証/承認プロセス（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]に基づいて、[RFC2475]のDiffservサービスのポリシーを経て統合会計が設定されている方法について説明します。サービスは、優先度の高いパケットのトランスポートであり、サービスは、課金およびQoS監査を含みます。図14は、サービスのセットアップを示しています。ユーザーは、AAAサーバへのDiffservサービスのためのサービス・リクエスト（SR）を発行します。要求には、ユーザIDと所望のサービスクラスのパラメータが含まれています。
User->AAA: user-x@nw-a, service=diffserv, class=gold, amount=2Mbit, dest= nw-b
USER-> AAA：ユーザー-Xする@ NW-、サービス=のDiffServクラス=金、量= 2Mビット、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.
この例では、ユーザ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
AAA-> ASM：サービス=のDiffServクラス=金、量= 2Mビット、SRC = NW-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は、サービス機器のための適切なユーザ設定情報にアプリケーション固有の情報を翻訳するタスクを引き継ぎます。会計機器、QoSの監査設備と帯域ブローカーアーキテクチャ：与えられたDiffserv例えば、サービス機器は、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-> BB：BW-要求（金、SRC = NW-、DEST = NW-B、量= 2Mビット）
ASM->Acct: Acct-request(comprehensive, src=nw-a)
ASM->アカウンティング：アカウンティング - 要求（包括的、SRC = NW-A）
ASM->QoS: QoS-audit-request(one-way-delay, src=nw-a, dest=nw-b)
ASM->のQoS：QoSの監査要求（片道遅延、SRC = NW-、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 }
アカウンティング・ポリシー：タイプ==包括的な{設定メータイン位置=アクセスポイント（NW-A）を設定レコードタイプ=最後の2行の詳細なセットのレポート間隔= 120秒、設定されたレポートの対象= 193.175.12.8 ^インデント}場合
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) }
QoSを測定ポリシー：メトリック==片道遅延{setメソッド=パッシブセットtimestampsize = 48ビットのセット入力メートルの位置=アクセスポイント（NW-A）は、出口メートル位置=アクセス・ポイントを設定した場合（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.
この場合、ローカル会計方針は、それが包括的会計に、詳細なレコードタイプが120秒のレポート間隔で必要とされることを述べてネットワークAのネットワーク・アクセス・ポイントへメータ位置を設定します。結果の記録は、特定のレポートをターゲットに送信する必要があります。 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
Acct-> MI：MP1：ルールのDSCPを追加= 23、SRC = a.a.a / 24、DEST = b.b.b.b / 24ボリュームセットのレポート間隔= 120秒セットレポートの対象= 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の監査制御は、受動的一方向遅延測定を設定する（MP1及びMP2に）2メートルに指示します。
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
QoS-> MI：MP1：追加ルールのDSCP = 23、SRC = AAAA / 24 DEST = BBBB / 24、タイムスタンプ48 MP2を保存：追加ルールのDSCP = 23、SRC = AAAA / 24、DEST = BBBB / 24、タイムスタンプを保存します-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
USER-> AAA：ユーザー-Xする@ NW-、サービス=会計適応症、レポート間隔= 60秒
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サーバは、会計サービスのASMにASIを渡します。
AAA->ASM: user-x@nw-a, service=accounting indications, report interval= 60 s
AAA-> ASM：ユーザー-X @のNW-A、サービス=会計適応症、レポート間隔= 60秒
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 }
ASM->アカウンティング：もしSRC = a.a.a.x {レポート間隔でACC-指示= = 60秒レポート目標= 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 }
ローカルアカウンティング・ポリシー：ACC-指示{レコード型=コンパクト}もし
Acct->MI: MP1: set report interval = 60 s add report target = a.a.a.x
Acct-> MI：MP1：設定レポート間隔= 60秒には、レポート対象= 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.
- 会計方針及び会計記録情報の両方会計方針や会計記録の偽造には、情報の偽造の対象とすることができます。会計方針は、構成情報が含まれています。この情報を変更する（例えば、メーターの分類ルールを変更することにより、会計処理されることなく）データが検出されない会計システムを横断することができ、または偽のアカウンティングレコードを生成するいずれかのMAL-構成課金および計量システムをもたらすことができます。アカウンティングレコードは、リソースの消費量に関するデータが含まれていると課金のための基礎を提供します。アカウンティングレコードを変更すると、誤った法案につながる可能性があります。さらに、政策や会計記録をリダイレクトまたは削除および鍛造方針やレコードが挿入されていないことをされていないことが重要です。
- 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.
これらの危険を防止するには、会計方針の交換や会計記録の輸送に使用されるプロトコルのために考慮しなければなりません。 [RFC2989]認証、伝送レベルのセキュリティ、データオブジェクトの機密性と整合性のためのセキュリティ要件は、AAAプロトコル評価基準で扱われているので、我々は将来のAAAプロトコル（s）はまた、おそらく安全なアカウンティングレコードの転送に適しとされると仮定します安全な会計方針の輸送のため。さらに、我々は、安全な輸送・ポリシーを施行するために既存または今後のソリューションを使用することができることを前提としています。 DoS攻撃の本当の防止は非常に困難です。悪意のあるパケットが有効な顧客トラフィックから分離することができない場合、攻撃者のパケットを選択的にドロップすることは不可能です。特定のタイプのすべてのパケットのドロップは、サービスを利用してから認可顧客を防ぐため、彼女の目標を達成するために、攻撃者を助けるかもしれません。
[I2-BB] Internet2-QBone Bandwidth Broker, http://www.merit.edu/working.groups/i2-qbone-bb
[I2-BB]インターネット2-QBone帯域ブローカー、http://www.merit.edu/working.groups/i2-qbone-bb
[NetFlow] NetFlow Services and Applications, White Paper, Cisco Systems, 1999
[NetFlowの]のNetFlowサービスとアプリケーション、ホワイトペーパー、シスコシステムズ、1999
[RFC2002] Perkins, C., "IP Mobility Support", RFC 3220, October 1996.
[RFC2002]パーキンス、C.、 "IPモビリティサポート"、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]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王Z.とW.ワイス、 "差別化サービスのためのアーキテクチャ"、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]ブラウンリー、N.、ミルズ、C.およびG.ルース、 "トラフィックフロー測定：アーキテクチャ"、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]デLAAT、C.、グロス、G.、Gommans、L.、Vollbrecht、J.およびD.スペンス、 "汎用AAAアーキテクチャ"、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.、カルフーン、P.、ファレル、S.、Gommans、L.グロス、G.、デBruijnグラフ、B.、デLAAT、C.、ホールドレッジ、M.とD.スペンス、 " 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.、カルフーン、P.、ファレル、S.、Gommans、L.グロス、G.、デBruijnグラフ、B.、デLAAT、C.、ホールドレッジ、M.とD.スペンス、 " AAA認証アプリケーション例」、RFC 2905、2000年8月。
[RFC2924] Brownlee, N. and A. Blount, "Accounting Attributes and Record Formats", RFC 2924, September 2000.
[RFC2924]ブラウンリー、N.とA.ブラント、 "会計属性とレコード形式"、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.ハリントン、 "会計管理の概要"、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.、カルフーン、P.、ガラス、S.、ヒラー、T.、マッキャン、P.、椎野、H.、ウォルシュ、P.、ゾルン、G.、Dommety、G.、パーキンス、 C.、パティル、B.、ミットン、D.、マニング、S.、Beadles、M.、チェン、X.、Sivalingham、S.、ハミード、A.、マンソン、M.、ジェイコブス、S.、リム、 B.、ハーシュマン、B.、スー、R.、クー、H.、Lipford、M.、キャンベル、E.、徐、Y.、馬場、S.及びE.・ジャック、「ネットワークの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.、クイン、B.、ヘルツォーク、S.、フイン、A.、カールソン、M.、ペリー、J.、および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.
著者は、実りある議論とコメントのために、AAAARCH研究グループのメンバー、特に、椅子、ジョンVollbrechtとCEESドLAATに感謝したいと思います。特別な感謝はこのドキュメントへの彼らのレビューと貴重な入力のためにバーナードAboba、NevilブラウンリーとエドEllessonにあります。
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
オープン通信システムカイザリンオーガスタダレ31のためのターニャZsebyフラウンホーファー研究所10589ベルリンドイツ電話：+ 49-30-34 63 7153ファックス：+ 49-30-34 53 8153 Eメール：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
オープン通信システムカイザリンオーガスタダレ31 10589ベルリンドイツの携帯電話のためのセバスチャンザンダーフラウンホーファー研究所：+ 49-30-34 63 7287ファックス：+ 49-30-34 63 8287 Eメール：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
オープン通信システムカイザリンオーガスタダレ31のためのゲオルグ・カールフラウンホーファー研究所10589ベルリンドイツ電話：+ 49-30-34 63 7149ファックス：+ 49-30-34 63 8149 Eメール：carle@fokus.fhg.de
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。