RFC3334 日本語訳
3334 Policy-Based Accounting. T. Zseby, S. Zander, C. Carle. October 2002. (Format: TXT=103014 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group T. Zseby
Request for Comments: 3334 S. Zander
Category: Experimental G. Carle
Fraunhofer FOKUS
October 2002
Zsebyがコメントのために要求するワーキンググループT.をネットワークでつないでください: 3334秒間ザンダーCategory: 実験的なG.無作法者フラウンホーファーFOKUS2002年10月
Policy-Based Accounting
方針ベースの会計
Status of this Memo
この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.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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.
このドキュメントは会計アーキテクチャに柔軟性を提供するアプローチである方針ベースの会計について説明します。 会計方針は標準化された方法で会計アーキテクチャの構成について説明します。 設定情報を共有するためにそれらを会計アーキテクチャに器具を取り付けるのに使用して、Authenticationと、AuthorizationとAccounting(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アーキテクチャ(RFC2903)における方針ベースの会計でブロックとメッセージ系列について説明します。 例は異なったシナリオの会計方針の用法のために出されます。 また、それはどうしたらAAA承認フレームワーク(RFC2904)と会計コンポーネントを統合できるかが示されます。 このドキュメントは会計方針の記述のために言語を提案しません。 むしろ、存在か今度の規格から適当な方針言語を選ぶことができると思われます。
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
1. 序論…2 1.1動機…2 1.2 範囲を記録してください…3 2. 用語…4 3. 会計のプロバイダーネットワークの特性の影響…7 4. ビジネスの役割と関係…8 5. 規範モデルとブロック…11
Zseby, et. al. Experimental [Page 1] RFC 3334 Policy-Based Accounting October 2002
et Zseby、アル。 会計2002年10月の方針ベースの実験的な[1ページ]RFC3334
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
6. 会計方針…14 6.1会計方針状態…15 6.2 会計政策的措置…16 メーター構成のための6.3の例…17 7. 会計サービス…19 7.1 統合会計…19 7.2 離散的な会計…21 7.3 イントラドメイン会計…22 7.4 相互ドメイン会計…23 8. 異なったAuthorization Modelsとの会計…25 8.1 エージェント系列…25 8.2 系列を引いてください…26 8.3 系列を押してください…27 8.4 ローミング…28 9. 例…29 9.1印刷サービスの例…29 9.1 .1 イントラドメイン会計…29 9.1 .2 相互ドメイン会計…30 9.1 .3 ユーザ会計指示…31 9.2のモバイルの、または、移動している例…31 9.3Diffservの例…33 9.4ユーザ会計指示の例…37 10. セキュリティ問題…39 11. 参照…41 12. 承認…42作者のアドレス…43 完全な著作権宣言文…44
1. Introduction
1. 序論
1.1 Motivation
1.1 動機
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されることができます。 用法ベースの充電をサポートするために、資源予約と利用の情報の収集が必要です。 リソース用法に関するデータの収集は会計と呼ばれます。
Zseby, et. al. Experimental [Page 2] RFC 3334 Policy-Based Accounting October 2002
et Zseby、アル。 会計2002年10月の方針ベースの実験的な[2ページ]RFC3334
Service providers have various options for service differentiation, charging schemes and the provisioning of accounting services. The applied charging schemes for the provided services are one significant feature used by providers to distinguish themselves from competitors. Therefore, providers use different charging schemes and may change the schemes in accordance with their business plan. Providers can also offer different accounting services (e.g. standard, comprehensive, etc.) in order to allow customers/users to choose one scheme that meets the customers/users needs. Furthermore, it may be advantageous for a provider to outsource accounting functionality to a third party. Users introduce various traffic profiles and may have individual preferences regarding accounting services (like itemized invoices, accounting indications, spending limits etc.).
サービスプロバイダーには、会計サービスの体系と食糧を供給することを請求して、サービス分化のための様々なオプションがあります。 提供されたサービスの適用された充電体系はプロバイダーによって使用される、競争相手と自分たちを区別する1つの著しい特徴です。 したがって、プロバイダーは、異なった充電体系を使用して、それらのビジネス計画通りに体系を変えるかもしれません。 また、プロバイダーは、顧客/ユーザが顧客/ユーザ需要を満たす1つの体系を選ぶのを許容するために、異なった会計サービス(例えば、標準的、そして、包括的ななど)を提供できます。 その上、プロバイダーに、会計の機能性を第三者に社外調達するのは有利であるかもしれません。 ユーザは、様々なトラフィックプロフィールを紹介して、会計サービス(箇条書きされたインボイス、会計支出限界指摘などのような)に関して個々の好みを持っているかもしれません。
One further challenge for the configuration of accounting services are heterogeneous metering and accounting infrastructures within provider domains. Also, the usage of different accounting and metering solutions used in different provider networks complicates the sharing of configuration parameters (e.g. in roaming scenarios).
会計サービスの構成のためのさらなる1つの挑戦が、異種の計量であり、プロバイダードメインの中でインフラストラクチャを説明しています。 また、異なったプロバイダーネットワークに使用される異なった会計と計量解答の用法は設定パラメータ(例えば、ローミングシナリオの)の共有を複雑にします。
The configuration and dynamic adaptation of the accounting process to the business model and specific user demands requires a flexible configurable accounting infrastructure. The utilization of standardized policies for the expression of conditions and related configuration actions also allows the configuration of heterogeneous infrastructures. For this purpose we propose to use accounting policies to configure the accounting infrastructure and use the Authentication, Authorization and Accounting (AAA) architecture to exchange and to deploy these policies.
ビジネスモデルと特定のユーザ要求への会計作業の構成とダイナミックな適合はフレキシブルな構成可能な会計インフラストラクチャを必要とします。 また、状態と関連する構成動きの式のための標準化された方針の利用は異種のインフラストラクチャの構成を許します。 このために私たちは、会計インフラストラクチャを構成して、Authentication、Authorization、および交換するAccounting(AAA)アーキテクチャを使用して、これらの方針を配布するのに会計方針を使用するよう提案します。
1.2 Document Scope
1.2 ドキュメント範囲
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
このドキュメントは会計方針の構造と用法を説明します。 それはプロバイダーネットワークの特性がどう会計のための要件に影響を及ぼすかを示しています。 会計アーキテクチャのために会計作業と必要なブロックにかかわる異なる役割の関係を導入します。 このドキュメントは、会計サービスを構成するためにアーキテクチャとメカニズムについて説明します。 それは、方針で言い表された会計設定情報の交換にAAAプロトコルを使用するよう提案します。 それは会計構成自体のために特定のプロトコルを提案しません。 既存のプロトコル(例えば、Policy ProvisioningのSupportのためのCommonオープンPolicy Serviceプロトコル--COPS-PR、Simple Network Managementプロトコル--SNMPなど)で構成自体であることができます。 その上、それはどうしたらイントラと相互ドメインシナリオに異なった会計サービスを提供できるかが示されます。 例は会計の用法のために出されます。
Zseby, et. al. Experimental [Page 3] RFC 3334 Policy-Based Accounting October 2002
et Zseby、アル。 会計2002年10月の方針ベースの実験的な[3ページ]RFC3334
policies in different scenarios. They show how accounting components can be integrated into the authorization framework proposed in [RFC2904].
異なったシナリオの方針。 彼らは[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.
本書では表された方針ベースの会計アーキテクチャはGeneric AAA Server[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.
このドキュメントは会計方針の記述のために言語を提案しません。 存在か今度の規格から適当な方針言語を選ぶことができるとむしろ思われます。
2. Terminology
2. 用語
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.
Indication/確認がメッセージが起因しているAAAサーバ(課金情報が生成されたサーバ)から受取人まで押されるという(AAAサーバか顧客/ユーザアプリケーションであるかもしれません)Accounting指示であることを説明します。 会計指摘はサービスのためのリソース消費について説明する会計帳簿を含んでいます。 またメッセージが含むことができる会計指示は複数のサービスのための情報に集められました。 当座とセッションの終わりの会計指示メッセージがあることができます。 セッションの終わりの指摘をセッションの終わりだけの受取人に与えますが、サービスセッションの間指定された間隔で当座の指摘を受取人に提供します。 会計指摘は応用層の信頼性を提供すると会計確認で承諾されるかもしれません。
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.
会計Policy Indication/確認Accounting方針指示メッセージを会計方針を含んでいて、顧客/ユーザかAAAサーバから別のAAAサーバに送ります。応用層の信頼性を提供すると会計方針確認で会計方針指摘を承諾するかもしれません。
Zseby, et. al. Experimental [Page 4] RFC 3334 Policy-Based Accounting October 2002
et Zseby、アル。 会計2002年10月の方針ベースの実験的な[4ページ]RFC3334
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サーバで会計Request/答えAccounting要求を別の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サーバで会計Policy Request/答えAccounting方針要求を別の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.
会計Policies Accounting方針は会計データの世代、輸送、およびストレージのための規則について説明します。 これらの規則は会計作業の構成に使用されます。
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が機能性を供給するアプリケーションSpecific Module(ASM)が認証されて認可されたユーザに対するサービスのユーザ構成に必要です。 それはAAAサーバからの特殊情報(ASI)(例えば、ユーザ構成のための)がASMに送られた標準のメッセージでジェネリック形式かアプリケーションの特定の形式でカプセル化したアプリケーションを得ます。 ASMはメッセージからASIを抽出するか、またはジェネリック形式で与えられた情報を適切なアプリケーション特定の形式に変換します。 [RFC2903]でASMがどう使用されているかに関する詳細を見つけることができます。
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.
充電Schemes A充電体系は、充電について計算するための指示です。 通常、充電体系は変数(例えば、ボリューム(時間)はピークレートを予約した)を請求して、係数(例えば、1タイム・ユニットあたりの価格)を請求するのから成る公式によって表されます。 通常、充電変数は会計データからの情報によっていっぱいにされます。
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).
クラシファイアThisドキュメントは[RFC2475]で与えるようにクラシファイアの定義を使用します。 このドキュメントが、メーターが既に分類機能を含むと仮定するので、用語クラシファイアは追加分類(例えば、データ後工程の一部としての)を実行する実体に使用されるだけです。
Zseby, et. al. Experimental [Page 5] RFC 3334 Policy-Based Accounting October 2002
et Zseby、アル。 会計2002年10月の方針ベースの実験的な[5ページ]RFC3334
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.
メーターThisドキュメントは[RFC2722]で与えるようにメーターの定義を使用します。 このメーター定義は既にパケットの分類を含みます。 それはクラシファイアとメーターが別々の実体であるとみなされるDiffServモデル[RFC2475]と異なっています。
Meter Reader/Collector
This document uses the definition of meter reader and
collector as given in [RFC2722].
Thisが記録するメーター読者/コレクタは[RFC2722]で与えるようにメーター読者とコレクタの定義を使用します。
Meter Manager
This document uses the definition of meter manager as given
in [RFC2722].
メーターマネージャThisドキュメントは[RFC2722]で与えるようにメーターマネージャの定義を使用します。
Policy, policy condition, policy action
The terms policy, policy condition and policy action are used
as defined in [RFC3198].
方針、方針状態、政策的措置、用語方針であり、方針状態と政策的措置は中[RFC3198]で定義されるように使用されています。
QoS Auditing
Quality of Service (QoS) Auditing is the process of
evaluating whether a given quality of service guarantee (e.g.
thresholds for QoS parameters given in a Service Level
Agreement - SLA) has been met during the service
provisioning.
Service(QoS)監査のQoS Auditing Qualityは与えられたサービスの質保証(例えば、サービス・レベル・アグリーメントで与えられた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].
サービスClass Aサービスのクラスは、サービスプロバイダーでそのクラスに属しながら、サービス([RFC3198]で定義されるように)の取り扱いを指定します。 サービスのクラスには、ある種の識別子(例えば、名前)があります、そして、サービスの取り扱いは[RFC3198]で説明されるService Level Specification(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.
ユーザConfiguration WeはAAAアーキテクチャによって認証されて、認可されたユーザのためにサービスを構成するプロセスとUser Configurationを呼びます。 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(ビジネスの役割と彼らの関係)で関連する用語(サービス、Service Subscriber、Service User、Network Provider、Service Provider、Broker)を見つけることができるサービスの定義。
Zseby, et. al. Experimental [Page 6] RFC 3334 Policy-Based Accounting October 2002
et Zseby、アル。 会計2002年10月の方針ベースの実験的な[6ページ]RFC3334
3. Impact of Provider Network Characteristics on Accounting
3. 会計のプロバイダーネットワークの特性の影響
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.
- サイズと個々の顧客に対応するPurposeのA小さい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).
- 体系Thereが存在すると宣言して、さまざまな充電が、異なった技術的な、そして/または、経済のモデルに基づく関税変数を使用することで計画されます。 選ばれた充電体系はプロバイダーのための会計要件に影響を及ぼします。 いくつかの充電体系が要件を説明しながらゼロかわずかだけにつながる間、他の充電体系は非常に過酷であるかもしれません。 例えば、均一料金充電体系は会計インフラストラクチャを全く必要としません。 これと対照して、ボリュームベースの充電体系は伝えられたボリュームの測定を必要として、これによる増加は会計のための複雑さを必要とします。 変動価格を導入する関税は、定期的に課金情報(例えば、当座の会計指摘による)をユーザに提供するのを必要とするかもしれません。
- Accounting Services Providers may offer different accounting services (e.g. accounting indication, itemized invoice, etc.)
- 会計Services Providersは異なった会計サービスを提供するかもしれません。(例えば、会計指示、箇条書きされたインボイスなど)
- 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
- 他のプロバイダーProvidersとの会計協定には、他のプロバイダーとの協定が、例えば、一度計量するだけでよいように会計タスクを共有して、会計データを分配するためにあるかもしれません。 そうだとすれば、プロバイダーが会計データだけではなく、会計モジュール(例えば、メーター)の構成の情報も交換できるなら、役に立つかもしれません。 それはそうです。
Zseby, et. al. Experimental [Page 7] RFC 3334 Policy-Based Accounting October 2002
et Zseby、アル。 会計2002年10月の方針ベースの実験的な[7ページ]RFC3334
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).
プロバイダーがあらかじめ会計データがどのように集められて、モニターされるだろうか、そして、会計データに関する論争がどのように解決されるかに同意するように、重要です。 プロバイダーの間の論争を最小にするために、それは、どちらかがともに会計データを集めるでしょう--そして、一定の間隔を置いてもう片方のデータとそれを比べるのに同意するために重要であって、例えば、月毎です--または、ともに、彼ら(または信頼できる第三者機関で)のひとりによって提供された会計データの単独の源を使用するでしょう。
- 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.
- Existing Infrastructure(メーター、データ収集は指す)プロバイダーのCapabilitiesを利用すると、機能は会計機能を提供できるネットワークの中に既に持たれているかもしれません(例えば、MIBが反対します、プロフィールメーター、独占会計溶液)。 コピーされた機能性を避けるために、これらの会計リソースを使用するのは可能であるべきです。 したがって、異なったタイプの会計モジュール(例えば、メーター)の構成は可能であるべきです。 モジュール構成を説明する表す共通語はこのために役に立つでしょう。
4. Business roles and relations
4. ビジネスの役割と関係
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.
現在の、そして、今度のインターネットでサービス条項を調査する際に、私たちはサービス用法lifecycleの一部である異なったビジネスの役割を特定しました。 このセクションで、私たちは最初に、サービスという用語を定義します。 その後、異なる役割とそれらの関係は定義されます。 このモデルにおけるビジネスの役割は後の例で使用されます。
- 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.
- サービスAサービスはプロバイダーによって顧客に提供された1セットの能力です。 この定義では、プロバイダーと顧客は後で定義されたビジネスの役割の1つであるかもしれません。 異種のサービスは認識されなければなりません。
- Information services handle the delivery of information to the
customer on top of transport services. In content-based
services, the service subscriber pays for the content (e.g. for
a file, an image, a video, etc.). In communication-based
services, the service subscriber pays for the provisioning of a
certain form of communication (e.g. video conferencing or IP
telephony).
- 情報サービスは輸送サービスの上で情報の配送を顧客に扱います。 内容ベースのサービスでは、サービス加入者は内容(例えば、ファイル、イメージ、ビデオなどのための)の代価を払います。 コミュニケーションベースのサービスでは、サービス加入者はあるフォームに関するコミュニケーション(例えば、ビデオ会議かIP電話技術)の食糧を供給することの代価を払います。
- Transport services describe the provisioning of pure
transportation of IP packets. At the IP layer, this may include
the differentiation of packets (e.g. number of packets with a
certain DSCP), Intserv based reservation or other methods for
QoS enhancement (e.g. Automatic Repeat reQuest - ARQ, Forward
- 輸送サービスはIPパケットの純粋な輸送の食糧を供給することについて説明します。 IP層では、これがQoS増進のためのパケット(例えば、あるDSCPがあるパケットの数)、Intservのベースの予約または他のメソッドの分化を含むかもしれない、(例えば、Automatic Repeat reQuest--ARQ、Forward
Zseby, et. al. Experimental [Page 8] RFC 3334 Policy-Based Accounting October 2002
et Zseby、アル。 会計2002年10月の方針ベースの実験的な[8ページ]RFC3334
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.
- サービス加入者のサービスSubscriberはサービスに加入して、その結果サービスプロバイダーとの契約上の関係を持っている実体と基本的な輸送サービスを提供するネットワーク内の提供者です。 また、サービス加入者はサービス利用者として務めることができます。 サービス加入者には、関連情報をサービスに提供するブローカーとの関係があるかもしれません。
- 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.
- サービス利用者のサービスUserはサービスを利用する実体です。 サービス加入者にとって、サービス利用者は同じである場合があります。 加入者とユーザが同じでない場合では、サービス加入者は彼女が責任があるすべてのサービス利用者のためにサービス用法を制御できるべきです。
- 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.
- ネットワークProvider Aネットワーク内の提供者は基本的なネットワークインフラをサービス利用者に提供する実体です、サービス加入者、サービスプロバイダーとブローカー。 ネットワーク内の提供者は輸送サービスを提供します。 サービスはネットワークインフラの上で提供されます。 サービスプロバイダーには、サービス加入者とサービスプロバイダー(そして、ブローカー)との契約上の関係があります。 ネットワーク内の提供者の転送ネットワークはたぶんすべての加入者、プロバイダー、およびブローカーに接する世界的なネットワークではありません。 転送ネットワークはビジネス関係がそれらの間に存在であっている中に異なったネットワーク内の提供者によって制御された多くのサブネットワークかドメインに区分されます。 それぞれのドメインはイントラドメイン管理と会計に原因となります。 相互ドメイン管理と会計のために、ネットワーク内の提供者の間の適切な通信インターフェースは存在しなければなりません。
- 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
- サービスProvider Aサービスプロバイダー実体はサービスを提供します。 サービスプロバイダーは直接サービス加入者/ユーザに対するサービスを提供できます。 また、サービスプロバイダーはサービス加入者に対するサービスを転売する別のサービスプロバイダー(小売業者)に対するサービスを販売する卸売業者のように行動できます。 サービスプロバイダーには、契約上の関係があります。
Zseby, et. al. Experimental [Page 9] RFC 3334 Policy-Based Accounting October 2002
et Zseby、アル。 会計2002年10月の方針ベースの実験的な[9ページ]RFC3334
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 |<-+
+---------------+ |
^ |
+----+
+----+ V| +---------------+ | | ブローカー| <、-+ +------>| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--+ | +---------------+ | | ^ | | | | | V V| +------------------+ +---------------+ | | サービス| | サービス| | | 加入者| <、-、-、-、-、--、>| プロバイダー| | | | | | <、-+ | | +--------------+ | +---------------+ | | | | サービス利用者| | ^ ^ | | | +--------------+ | | +----+ | +------------------+ | | ^ | | | | | V| | +---------------+ | +------>| ネットワーク| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--+ | プロバイダー| <、-+ +---------------+ | ^ | +----+
Figure 1: Roles and business relations
図1: 役割とビジネス関係
Zseby, et. al. Experimental [Page 10] RFC 3334 Policy-Based Accounting October 2002
et Zseby、アル。 会計2002年10月の方針ベースの実験的な[10ページ]RFC3334
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]に従って、この例はインターネット印刷シナリオについて説明します。 加入者は会社です、そして、ユーザはその会社の従業員です。 ファイルサーバーとプリント・サーバは2つの異なったサービスプロバイダーのものです。 会社はファイルサービスのための再販業者として機能するプリント・サーバサービスに加入します。 ファイルサーバーサービスは適切な輸送サービス(多分、ユーザー選択に基づいている)を選びます、その結果、ファイルサーバーには、与えられた位置からデータをダウンロードして、それらをプリント・サーバに送るのに提供された輸送サービスを使用するネットワーク内の提供者との契約があります。
Example 2: A company (service subscriber) has a contract with a video archive (service provider). An employee can download clips in different qualities from the archive. The employee can use different transport mechanisms for the download. In order to get the appropriate transport, the user contacts an agency (broker) that returns a reference to a network provider which provides the required transport service. As an alternative, the content (video) can be delivered in different qualities via different transport mechanisms by the service provider. The service provider chooses an appropriate network provider which provides a transport service compliant with the conditions the service provider offers to the subscribers. In this case the service provider can use the facilities of a broker to get a reference to appropriate network providers.
例2: 会社(サービス加入者)には、ビデオアーカイブ(サービスプロバイダー)との契約があります。 従業員はアーカイブと異なった品質でクリップをダウンロードできます。 従業員はダウンロードに異なった移送機構を使用できます。 適切な輸送を得るために、ユーザは必要な輸送サービスを提供するネットワーク内の提供者の参照を返す政府機関(ブローカー)に連絡します。 代替手段として、サービスプロバイダーは異なった品質で異なった移送機構で内容(ビデオ)を提供できます。 サービスプロバイダーはサービスプロバイダーが加入者に提供する状態による対応することの輸送サービスを提供する適切なネットワーク内の提供者を選びます。 この場合、参照にネットワーク内の提供者を当てさせるのにサービスプロバイダーはブローカーの施設を使用できます。
5. Reference Model and Building Blocks
5. 規範モデルとブロック
We have developed a reference model for describing the interactions between the different metering, accounting and charging processes and their configuration via policies. This reference model is shown in Figure 2. At the right side, five layers show the different building blocks. The blocks are layered according to the processing of the data from the bottom level metering via accounting, up to the final billing process. Data aggregation is not only done at the collection layer, it can also be done at the other layers. The building blocks on the different layers are configured through the policies shown on the left side. Higher layer policies can be translated into lower layer policies. The configuration parameters are extracted from the policy and passed to the corresponding building block. The tasks of the different building blocks are as follows:
私たちは、方針で異なった計量と、会計と充電プロセスとの相互作用とそれらの構成について説明するために規範モデルを開発しました。 この規範モデルは図2で見せられます。 右側によって、5つの層が異なったブロックを見せています。 下部レベルからのデータの処理に従って、ブロックは会計で計量しながら、層にされます、最終的な課金プロセスまで。 収集層にデータ集合をするだけではありません、また、他の層にそれができます。 異なった層のブロックは左側に示された方針で構成されます。 より高い層の方針を下層方針に翻訳できます。 設定パラメータは、方針から抜粋されて、対応するブロックに移られます。 異なったブロックのタスクは以下の通りです:
- Metering Meters are needed for capturing data about resource consumption in the network (e.g. transmitted volume). They will probably be placed at the edges of the network. Two types of meters can be
- Metering Metersがネットワーク(例えば、量を伝える)でリソース消費に関するデータを得るのに必要です。 それらはたぶんネットワークの縁に置かれるでしょう。 2つのタイプのメーターはそうであることができます。
Zseby, et. al. Experimental [Page 11] RFC 3334 Policy-Based Accounting October 2002
et Zseby、アル。 会計2002年10月の方針ベースの実験的な[11ページ]RFC3334
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.
- メーターに従ってデータが集めた収集はさらなる処理のために集められなければなりません。 メーター(モデルを押す)自体かコレクタ実体でメーターデータの収集を開始できます(モデルを引いてください)。 会計層に通過される前に集まっているデータを集めることができます。 計量方針は、収集と集合がどのように完了しているかを定義します。
Zseby, et. al. Experimental [Page 12] RFC 3334 Policy-Based Accounting October 2002
et Zseby、アル。 会計2002年10月の方針ベースの実験的な[12ページ]RFC3334
POLICY CONFIGURATION BUILDING BLOCKS
方針構成ブロック
+---------------+ +-------------------------+
| |------------------>| Billing |
| Billing & | +-------------------------+
| Charging | ^ charging
| | | data
| | +-------------------------+
| |------------------>| Charging |
+---------------+ +-------------------------+
| ^ acct
V | data
+---------------+ +-------------------------+
| Accounting | | |
| |------------------>| Accounting |
+---------------+ +-------------------------+
| ^ aggr. meter
V | data
+---------------+ +-------------------------+
| |------------------>| Collection |
| Metering | | |
| | +-------------------------+
| | ^ meter
| | | data
| | +-------------------------+
| |------------------>| Metering |
+---------------+ +-------------------------+
+---------------+ +-------------------------+ | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 支払い| | 支払い| +-------------------------+ | 充電| ^充電| | | データ| | +-------------------------+ | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 充電| +---------------+ +-------------------------+ | ^acct V| データ+---------------+ +-------------------------+ | 会計| | | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 会計| +---------------+ +-------------------------+ | ^aggrメーターV| データ+---------------+ +-------------------------+ | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 収集| | 計量| | | | | +-------------------------+ | | ^メーター| | | データ| | +-------------------------+ | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 計量| +---------------+ +-------------------------+
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.
- 会計Accountingはリソース消費に関するデータの収集について説明します。 これは会計データのデータ集会(計量を通した)のコントロール、輸送、およびストレージを含んでいます。 その後の充電において、計量されたデータは流れの創始者であるユーザと支払いに責任がある顧客(サービス加入者)に関連しているに違いありません。 会計作業の開始にとって、ユーザか外国プロバイダーを認証されて、権限を与えなければなりません。 AAAサーバはこれらの3つの機能を実行できます。会計作業は会計方針で構成されます。
- 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.
- 充電Chargingはサービスに基づく会計データセットと顧客従量税パラメタのために非通貨のコストを引き出します。 異なった費用測定基準は平行で同じ会計帳簿に適用さえされるかもしれません。 充電方針は適用された関税とパラメタを定義します。
Zseby, et. al. Experimental [Page 13] RFC 3334 Policy-Based Accounting October 2002
et Zseby、アル。 会計2002年10月の方針ベースの実験的な[13ページ]RFC3334
- 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.).
- 支払いBillingはChargingによって計算されたコストを通貨のユニットに翻訳して、顧客のために最終的な請求書を作ります。 支払い方針は特にタイプ(例えば、インボイス、クレジットカード)、請求書の書式(例えば、箇条書きされて、部分的なanyomizationなど)、および支払いのための時間(例えば、毎週の、そして、毎月のなど)を定義します。
We propose to use policies expressed in a standardized way to appropriately configure the meter, meter data collection and accounting processes.
私たちは、適切にメーター、メーターデータ収集、および会計作業を構成する標準化された方法で言い表された方針を使用するよう提案します。
6. Accounting Policies
6. 会計方針
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.
プッシュモデルのプッシュModel In、会計方針は、ローカルの会計インフラストラクチャに方針を確立するために別の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.
牽引力のモデルの牽引力のModel In、AAAサーバはリモートAAAサーバか顧客/ユーザから会計方針要求を送ることによって、方針を要求します。 リモートAAAサーバは適切な方針を含む答えとして会計方針回答を送ります。
Zseby, et. al. Experimental [Page 14] RFC 3334 Policy-Based Accounting October 2002
et Zseby、アル。 会計2002年10月の方針ベースの実験的な[14ページ]RFC3334
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
- メーター構成--データ収集と集合--会計帳簿分配とストレージ
6.1 Accounting Policy Condition
6.1 会計方針状態
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.
- サービスクラスServiceのクラスはプロバイダーによって定義されます。 彼らはプロバイダーによって提供されて、通常、ビジネスモデルに基づいて定義される異なったレベルか異種のサービスについて説明します。 顧客/ユーザはサービスのクラスを選択します。 1クラスあたりの適切な会計設定を定義するのに会計方針でこの選択されたクラスを使用できます。 例えば、これでは、より高い最優先するサービスのための標準のサービスより詳細な会計帳簿を提供するのは可能です。
Zseby, et. al. Experimental [Page 15] RFC 3334 Policy-Based Accounting October 2002
et Zseby、アル。 会計2002年10月の方針ベースの実験的な[15ページ]RFC3334
- 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.
- 会計タイプAccountingタイプは設定が1つ未満のキーワードであることを説明する倍数を結合します。 サービスのクラスのように、ビジネスモデルに従って、提供された会計タイプはプロバイダーによって定義されます。 これで、プロバイダーは、タイプが個人的には修理する例えば、異なった会計を申し出て、顧客/ユーザが1つを選択するのを許容できます。 1つのキーワードの下における設定の組み合わせはユーザのために選択を簡素化します。 例はキーワード(例えば、「包括的な会計」)の下の短いレポート間隔か別のキーワード(「標準の会計」)によってアクセスされるそれほど詳細でない記録のそれほど頻繁でない世代への高い粒状の会計帳簿の組み合わせです。 また、プロバイダーが会計タイプの上で同意するなら、会計タイプの定義は相互ドメインシナリオで助けることができます。
6.2 Accounting Policy Action
6.2 会計政策的措置
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.
- レポート間隔が何時で会計帳簿が生成されて、送られる間隔を指定する間隔を報告してください。 これは会計アーキテクチャでメーターとコレクタの構成に影響を及ぼします。
Zseby, et. al. Experimental [Page 16] RFC 3334 Policy-Based Accounting October 2002
et Zseby、アル。 会計2002年10月の方針ベースの実験的な[16ページ]RFC3334
- 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.
- 会計帳簿の目的地がデータベースかログファイルである蓄積時間If、蓄積時間は会計帳簿がどれくらい長い間保存されなければならないかを指定します。
- 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).
- 罰金がネットワークの流れを粒状にした(適用範囲で)流れ粒状が決定する流れ粒状は測定されます。 通常、粒状は、特定の分類規則をメーターにインストールすることによって、構成されます。 また、計量プロセスの後に適用される集合体系を構成することによって特定の粒状を設定するのも可能です。 粒状は個々のマイクロ流れ(例えば、5倍の<src、dest、proto、src-ポート、dest-ポート>が決定される)から粗い粒状のトラフィック骨材(1つのネットワークからの例えばすべてのトラフィック)まで変化できます。
- meter accuracy The parameters for the meter accuracy can determine, for instance, how often measurements take place at the meter, how accurate timestamps should be, etc. Meter accuracy parameters can also be used to configure sampling schemes.
- メーター精度のためのパラメタが決定できるメーター精度、例えばどれくらいの頻度で測定値はメーターで行われるか、正確なタイムスタンプがどうあるべきであるかなど。 また、標本抽出体系を構成するのにメーター精度パラメタを使用できます。
6.3 Example for Meter Configuration
6.3 メーター構成のための例
Note: In the following examples, the use of NeTraMet or NetFlow to
collect accounting information does not guarantee exact
accounting data, so it is not recommended for use in situations
where exact accounting data are needed.
以下に注意してください。 以下の例では、課金情報を集めるNeTraMetかNetFlowの使用が正確な会計データを保証しないので、状況における使用のために正確であるところで会計データが必要であることが推薦されません。
The following two examples show how accounting policies can be used to configure different meters. The accounting policy is sent from the AAA server to the ASM and there converted to the appropriate configuration information for the used meter.
以下の2つの例が異なったメーターを構成するのにどう会計方針を使用できるかを示しています。 AAAサーバからASMに会計方針を送ります、そして、中古のメーター単位で適切な設定情報に変換します。
If the meter NeTraMet [RFC2123] is used, the policy is converted into a NeTraMet ruleset that contains the relevant flows, attributes and reader instructions for the data collection. This information is passed to the NeTraMet manager that configures the meter and meter reader in accordance with the given configuration.
メーターNeTraMet[RFC2123]が使用されているなら、方針はデータ収集のための関連流れ、属性、および読者指示を含むNeTraMet rulesetに変換されます。 この情報は与えられた構成に従ってメーターとメーター読者を構成するNeTraMetマネージャに渡されます。
Zseby, et. al. Experimental [Page 17] RFC 3334 Policy-Based Accounting October 2002
et Zseby、アル。 会計2002年10月の方針ベースの実験的な[17ページ]RFC3334
+------------------+
| AAA |
| |
+------------------+
| ^
Policy | | Accounting Records
V |
+------------------+
| ASM |
| |
+------------------+
| ^
| |
| config +-----------------+
| |
+-------------------------------+ |
| | Accounting | |
| V | |
| +----------------+ | |
| | Meter Manager | | | Accounting Records
| +----------------+ | |
| | | | |
| SNMP V | |
| (conf)+---------------+ | |
| | | Meter Reader |---------+
| | +---------------+ |
| | ^ |
| V | |
| +-----------+ | |
| | Meter |-----+ |
| +-----------+ SNMP(DATA) |
| |
+-------------------------------+
+------------------+ | AAA| | | +------------------+ | ^方針| | 会計帳簿V| +------------------+ | ASM| | | +------------------+ | ^ | | | コンフィグ+-----------------+ | | +-------------------------------+ | | | 会計| | | V| | | +----------------+ | | | | メーターマネージャ| | | 会計帳簿| +----------------+ | | | | | | | | SNMP V| | | (conf)+---------------+ | | | | | メーター読者|---------+ | | +---------------+ | | | ^ | | V| | | +-----------+ | | | | メーター|-----+ | | +-----------+ SNMP(データ)| | | +-------------------------------+
Figure 3: Policy based Accounting with NeTraMet
図3: 方針はNeTraMetとAccountingを基礎づけました。
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によってフィルタ指示に翻訳されます。 メーター自体は、静的であり、したがって、設定情報で影響を受けません。
Zseby, et. al. Experimental [Page 18] RFC 3334 Policy-Based Accounting October 2002
et Zseby、アル。 会計2002年10月の方針ベースの実験的な[18ページ]RFC3334
+------------------+
| AAA |
| |
+------------------+
| ^
Policy | | Accounting Records
V |
+------------------+
| ASM |
| |
+------------------+
| ^
| |
| config | Accounting Records
| |
+-------------------------------+
| | Accounting |
| | |
| | +---------------------+ |
| | | Flow Collector | |
| | | +------------+ | |
| | | | Classifier | | |
| | | | Aggregator | | |
| +->| +------------+ | |
| +---------------------+ |
| ^ |
| | |
| +-----------+ | |
| | Meter |-----+ |
| +-----------+ UDP (DATA) |
| |
+-------------------------------+
+------------------+ | AAA| | | +------------------+ | ^方針| | 会計帳簿V| +------------------+ | ASM| | | +------------------+ | ^ | | | コンフィグ| 会計帳簿| | +-------------------------------+ | | 会計| | | | | | +---------------------+ | | | | 流れコレクタ| | | | | +------------+ | | | | | | クラシファイア| | | | | | | アグリゲータ| | | | +->| +------------+ | | | +---------------------+ | | ^ | | | | | +-----------+ | | | | メーター|-----+ | | +-----------+ UDP(データ)| | | +-------------------------------+
Figure 4: Policy based Accounting with NetFlow
図4: 方針はNetFlowとAccountingを基礎づけました。
7. Accounting Services
7. 会計サービス
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.
会計をプロセスに食糧を供給するサービスの一部(統合会計)か別々のサービス(離散的な会計)と考えることができます。 異なった意見と会計アーキテクチャに関するそれらの影響は以下で説明されます。
7.1 Integrated Accounting
7.1 統合会計
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
統合会計モデルの、会計は食糧を供給されたサービスの一部が見られます。 それは、会計が特定のサービスに結びつけられることを意味します。 したがって、会計作業は特定のサービスと力の料金先方払いの課金情報に適合します。
Zseby, et. al. Experimental [Page 19] RFC 3334 Policy-Based Accounting October 2002
et Zseby、アル。 会計2002年10月の方針ベースの実験的な[19ページ]RFC3334
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 :
| +-----------+ +----------------+ | :............:
+-------------------------------------+
+---------------------+ <。---1--->| ジェネリックAAAサーバ| <、-、--1--->|、| ............ | ベースのエンジンを統治してください。| <、-、-、--、|、-、-、-、-->: 方針: | | 3| :..........: +---------------------+ <。----|--+ ............ ^ +-->、: イベント: | :..........: 2 | +に対して----------------------+ ............... | アプリケーション特有です。| <--3 -->、: Acct方針: | モジュール| :.............: +----------------------+ ^ | 5 | +に対して-------------------------------------+ | サービス| | +-----------+ +----------------+ | .............. | | サービス| <-->、| 会計/| <--3 -->、: 会計: | | 支給| | 計量| | : データ: | +-----------+ +----------------+ | :............: +-------------------------------------+
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サーバに送られる会計帳簿に計量されたデータを変換します。会計帳簿がデータ変換であると生成するのにおいて、データの集合とフィルタリングは実行されるかもしれません。
Zseby, et. al. Experimental [Page 20] RFC 3334 Policy-Based Accounting October 2002
et Zseby、アル。 会計2002年10月の方針ベースの実験的な[20ページ]RFC3334
7.2 Discrete Accounting
7.2 離散的な会計
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.
また、統合会計アプローチと対照して、それ自身のところで会計を別々の、または、離散的なサービスと考えることができます。 この場合、会計は特定のサービスに結びつけられる必要はありません。 会計タスクを社外調達するのに離散的なAccountingを使用できます。 異なったサービスを説明できる一般的な会計システムは会計サービスを提供できます。
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.
例えば、一般化されたメーターは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 :
+-------------+ +---------------+ :............:
+---------------------+ <。---1--->| ジェネリックAAAサーバ| <、-、--1--->|、| ............ | ベースのエンジンを統治してください。| <、-、-、--、|、-、-、-、-->: 方針: | | 3| :..........: +---------------------+ <。----|--+ ............ ^ ^ +-->、: イベント: | | :..........: 2 2 | | +に対するV-------------+ +--------------+ ............... | アプリケーション| | アプリケーション| <--3 -->、: Acct方針: | 特定| | 特定| :.............: | モジュール| | モジュール| +-------------+ +--------------+ ^ ^ | | 5 5 | | +に対するV-------------+ +---------------+ .............. | サービス| | 会計/| <--3 -->、: 会計: | | | 計量| : データ: +-------------+ +---------------+ :............:
Figure 6: AAA Server with Discrete Accounting
図6: 離散的な会計があるAAAサーバ
Zseby, et. al. Experimental [Page 21] RFC 3334 Policy-Based Accounting October 2002
et Zseby、アル。 会計2002年10月の方針ベースの実験的な[21ページ]RFC3334
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).
会計サービスを社外調達したサービスプロバイダーは会計サービスプロバイダーからこのサービスを要求しなければなりません。 会計プロバイダーから最終的な目的地にそれらを送る前に記録への変更をするかもしれないサービスプロバイダーに発生している会計帳簿を送ります。 そのような一般的な会計サービスを持っていると、新種業務の作成は加速するかもしれません--インターネットでコンテンツサービスを特に専門にします。 また、この分離も、特別な会計が直接ネットワーク・サービスと結合されないサービス(例えば、会計指摘をユーザに送る)であるとサポートするのに有益です。 その上、異なったサービス(例えば1セットのサービスに使用できる異なった関税)に同じセットの会計戦略を適用できるなら、この分離は役に立ちます。
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.
別のオプションは計量サービスだけを社外調達することです。 メーターサービスプロバイダーは、それらを要求したサービスプロバイダーに、メーターデータを生成して、それらを送ります。 そして、サービスプロバイダーは、会計が受信されたメーターデータに基づく記録であると生成します。 サービスプロバイダーによって生成された会計データを有効にするのに別々の会計か計量サービスプロバイダーを使用できます。 顧客がサービスプロバイダーを信じないか、または訴訟の場合では、信じられた会計か計量プロバイダーがサービスプロバイダーによって生成された会計データの正当性を有効にすることができるなら。
7.3 Intra-Domain Accounting
7.3 イントラドメイン会計
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.
Intra-ドメイン会計[RFC2975]では、リソース消費に関するデータは用法のためにそのドメインに1つの管理ドメインに集められます。 会計方針は局所的に励行されます。 他のドメインがある会計データの交換は全くこのシナリオで必要でないので、他の実体で会計方針が交換される必要はありません。
Zseby, et. al. Experimental [Page 22] RFC 3334 Policy-Based Accounting October 2002
et Zseby、アル。 会計2002年10月の方針ベースの実験的な[22ページ]RFC3334
+-------------+
| Billing |
+-------------+
^
|
+-------------+
| ASM |
+-------------+
^
| ..............
+--------------+ : Accounting :
| AAA |<--->: Policies :
+--------------+ :............:
| ^
| |
V |
+--------------+
| ASM |
+--------------+
| ^
config | | Accounting Records
V |
+------------+ +-----------|----------+
| | Service usage | +--------+-------+ |
| End System |-------------->| | Accounting | |
| | | +----------------+ |
+------------+ | |
| Service |
+----------------------+
User Provider
+-------------+ | 支払い| +-------------+ ^ | +-------------+ | ASM| +-------------+ ^ | .............. +--------------+ : 会計: | AAA| <、-、-->: 方針: +--------------+ :............: | ^ | | V| +--------------+ | ASM| +--------------+ | ^コンフィグ| | 会計帳簿V| +------------+ +-----------|----------+ | | サービス用法| +--------+-------+ | | エンドシステム|、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| 会計| | | | | +----------------+ | +------------+ | | | サービス| +----------------------+ ユーザプロバイダー
Figure 7: Intra-Domain Accounting
図7: イントラドメイン会計
7.4 Inter-Domain Accounting
7.4 相互ドメイン会計
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.
Inter-ドメインAccountingに関しては、少なくとも2つの行政上切り離されたネットワークが会計作業にかかわります。 これらがRoaming/モバイルのIP Scenario[RFC2002]のホームとForeign-プロバイダーであるかもしれないかプロバイダーのチェーンは、サービスの食糧を供給するのがデータ転送にかかわるか、そして、そして/または、異なったドメインからのサービスです。 これらのシナリオでは、会計タスクを1つのプロバイダーへ代表として派遣するか、または複数のプロバイダーの中で共有するなら、プロバイダーの間の会計方針の交換が必要です。 AAAサーバは以下の図に示されるように会計方針の交換をします。
Zseby, et. al. Experimental [Page 23] RFC 3334 Policy-Based Accounting October 2002
et Zseby、アル。 会計2002年10月の方針ベースの実験的な[23ページ]RFC3334
| +-----------+
| | 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 | |
+----------------------+ |
| +-----------+ | | 支払い| | +-----------+ | ^ | | | +-----------+ | | ASM| | +-----------+ | ^ | | +------------------+ 1. AccPolInd+-----------+ | | <、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、|、|、|、|、| AAAF| 2. AccPolConf| AAAH| | |、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、|、|、|、|、| 3. AccRec| | | |、-、-、-、-、-、-、-、-、-、-、-、--、>|、| +------------------+ | +-----------+ コンフィグ| ^ | ^ | | | | V| | +に対して--------------+ | ............. | ASM| | : Acct。 : +--------------+ | : 方針: | ^ | :...........: | | | | | Acct。 記録| サービスV| | +------------+ 用法+-----------|----------+ | | | | +--------+-------+ | | | エンドシステム|、-、-、-、-、--、>|、| 会計| | | | | | +----------------+ | | +------------+ | | | | サービス| | +----------------------+ |
User Foreign-Provider Home-Provider
ユーザ外国プロバイダーホームプロバイダー
Figure 8: Inter-Domain Accounting (Roaming Example)
エイト環: 相互ドメイン会計(ローミングの例)
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
この例では、外国プロバイダーは会計データの収集を引き継ぎます。 ホームプロバイダーは充電体系を適用して、請求書を送るのに原因となります。 したがって、ホームプロバイダーは、外国プロバイダーからデータを説明する必要があります。 命令するために、必要な会計帳簿タイプとレポート頻度、ホームAAAサーバに関する外国プロバイダーは. 指示が含む外国AAAサーバに会計方針指示を送ります。
Zseby, et. al. Experimental [Page 24] RFC 3334 Policy-Based Accounting October 2002
et Zseby、アル。 会計2002年10月の方針ベースの実験的な[24ページ]RFC3334
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サーバのために最もわずかな共通点を交渉するために役に立つでしょう。
8. Accounting with different Authorization Models
8. 異なったAuthorization Modelsとの会計
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]は承認のために異なったメッセージ系列を紹介します。 以下のセクションで説明されるようにメッセージ系列のための構成可能に会計サービスの統合ができます。
8.1 Agent Sequence
8.1 エージェント系列
The appropriate accounting policy for the authorized service is either stored together with the authorization policy or in a separate repository. The configuration of the accounting infrastructure can be done together with the user configuration of the service equipment (messages 2 and 3 in Figure 9). User-specific configuration of the service equipment and the accounting infrastructure configuration might involve the transfer of configuration data to multiple entities in the network (e.g. to different routers for setting up QoS provisioning or to dedicated accounting meters).
認可されたサービスのための適切な会計方針が承認方針と共に保存されるか、別々の倉庫のどちらかにあります。 サービス設備(図9のメッセージ2と3)のユーザ構成と共に会計インフラストラクチャの構成ができます。 サービス設備と会計インフラストラクチャ構成のユーザ特有の構成はネットワーク(QoSの食糧を供給することをセットアップするための異なったルータ、または、例えば、専用会計メーターへの)における複数の実体にコンフィギュレーション・データの転送にかかわるかもしれません。
Zseby, et. al. Experimental [Page 25] RFC 3334 Policy-Based Accounting October 2002
et Zseby、アル。 会計2002年10月の方針ベースの実験的な[25ページ]RFC3334
+-------------------------+
+------+ | Service Provider |
| | 1 | +-------------------+ |
| |------+->| AAA Server | |
| |<-----+--| | |
| | 4 | +-------------------+ |
| User | | | ^ ^ |
| | | |2 |3 |AcctRec |
| | | V | | |
| | | +-------------------+ |
| | | | Service | |
| | | | Equipment | |
| | | +-------------------+ |
+------+ | |
+-------------------------+
+-------------------------+ +------+ | サービスプロバイダー| | | 1 | +-------------------+ | | |------+->| AAAサーバ| | | | <、-、-、-、--+--| | | | | 4 | +-------------------+ | | ユーザ| | | ^ ^ | | | | |2 |3 |AcctRec| | | | V| | | | | | +-------------------+ | | | | | サービス| | | | | | 設備| | | | | +-------------------+ | +------+ | | +-------------------------+
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はエージェント系列承認と会計メッセージを示しています。
8.2 Pull Sequence
8.2 牽引力の系列
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.
サービス設備のユーザ構成の間、エージェント系列と同様の状態で会計インフラストラクチャの構成ができます。 牽引力の系列が特定の承認要求の発信にかかわらないので(例えば、サービス設備がNetwork Access Server(NAS)であり、承認系列が単にダイヤルインのプロセスから始まるなら)、それはユーザから会計方針が指摘であるとサポートするために追加コミュニケーションを必要とするでしょう。
Zseby, et. al. Experimental [Page 26] RFC 3334 Policy-Based Accounting October 2002
et Zseby、アル。 会計2002年10月の方針ベースの実験的な[26ページ]RFC3334
+-------------------------+
+------+ | Service Provider |
| |AccPolInd +-------------------+ |
| |.........>| AAA Server | |
| |<.........| | |
| | | +-------------------+ |
| User | | ^ | ^ |
| | | |2 |3 |AcctRec |
| | | | V | |
| | 1 | +-------------------+ |
| |-------+->| Service | |
| |<------+--| Equipment | |
| | 4 | +-------------------+ |
+------+ | |
+-------------------------+
+-------------------------+ +------+ | サービスプロバイダー| | |AccPolInd+-------------------+ | | |.........>| AAAサーバ| | | |<…| | | | | | +-------------------+ | | ユーザ| | ^ | ^ | | | | |2 |3 |AcctRec| | | | | V| | | | 1 | +-------------------+ | | |-------+->| サービス| | | | <、-、-、-、-、--+--| 設備| | | | 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は牽引力の系列承認と会計メッセージを示しています。
8.3 Push Sequence
8.3 プッシュ系列
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) 一種のデジタルコインを必要としますが、どんなより遠い会計も必要でないようにチケットが作動します。 また、このモデルは匿名のサービスの用法をサポートします。
Zseby, et. al. Experimental [Page 27] RFC 3334 Policy-Based Accounting October 2002
et Zseby、アル。 会計2002年10月の方針ベースの実験的な[27ページ]RFC3334
Figure 11 shows push sequence authorization and accounting messages.
図11はプッシュ系列承認と会計メッセージを示しています。
+-------------------------+
+------+ | Service Provider |
| | 1 | +-------------------+ |
| |------+->| AAA Server | |
| |<-----+--| | |
| | 2 | +-------------------+ |
| User | | ^ |
| | | | AcctRec |
| | | | |
| | 3 | +-------------------+ |
| |------+->| Service | |
| |<-----+--| Equipment | |
| | 4 | +-------------------+ |
+------+ | |
+-------------------------+
+-------------------------+ +------+ | サービスプロバイダー| | | 1 | +-------------------+ | | |------+->| AAAサーバ| | | | <、-、-、-、--+--| | | | | 2 | +-------------------+ | | ユーザ| | ^ | | | | | AcctRec| | | | | | | | 3 | +-------------------+ | | |------+->| サービス| | | | <、-、-、-、--+--| 設備| | | | 4 | +-------------------+ | +------+ | | +-------------------------+
Figure 11: Accounting and Push Sequence
図11: 会計学とプッシュ系列
8.4 Roaming
8.4 ローミング
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で出されます。 このシナリオは設定できる可能な方針とパラメタに関するかかわったプロバイダーの間の事前同意を必要とします。
Zseby, et. al. Experimental [Page 28] RFC 3334 Policy-Based Accounting October 2002
et Zseby、アル。 会計2002年10月の方針ベースの実験的な[28ページ]RFC3334
9. Examples
9. 例
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.
以下の例は方針ベースの会計の使用を例証します。 例で利用されたサービスはイラスト目的にだけ利用されます、そして、彼らの使用は異なったメッセージとパラメタをほんとうは必要とします。
9.1 Printing Service Example
9.1 印刷サービスの例
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.
インターネットPrintingプロトコル(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つの可能なセットアップがあります: ファイルとプリント・サーバは単純組織(イントラドメインAccounting)、または、2つの異なった組織(相互Domain Accounting)に属します。 前者の場合、ただ一つのサービスプロバイダーはサービス用法のためにユーザに権限を与えなければなりません。 2番目の場合では、かかわった実体の間の信頼関係を確立するための2つの異なった可能性が区別されなければなりません[RFC2905]。
9.1.1 Intra-Domain Accounting
9.1.1 イントラドメイン会計
In the case of a single organization, the file and print service is provided by a single service provider. The service subscriber and user role are either one entity (e.g. private home user) or different entities (e.g. company as subscriber, employee as user). For data transport via the underlying network, the transportation service of a network provider is used. In this case, the AAA server of the provider controls the access to the file and the print server. This means the AAA server enforces the accounting policies and collects accounting data for both servers.
単純組織の場合では、ファイルと印刷サービスはただ一つのサービスプロバイダーによって提供されます。 サービス加入者とユーザの役割は、1つの実体(例えば、個人的な家庭でのユーザ)か異なった実体(例えば、加入者としての会社、ユーザとしての従業員)のどちらかです。 基本的なネットワークを通したデータ伝送において、ネットワーク内の提供者の輸送サービスは使用されています。 この場合、プロバイダーのAAAサーバはファイルとプリント・サーバへのアクセスを制御します。これは、AAAサーバが会計方針を実施して、両方のサーバのための会計データを集めることを意味します。
Zseby, et. al. Experimental [Page 29] RFC 3334 Policy-Based Accounting October 2002
et Zseby、アル。 会計2002年10月の方針ベースの実験的な[29ページ]RFC3334
9.1.2 Inter-Domain Accounting
9.1.2 相互ドメイン会計
If two different organizations are involved there are two possibilities for trust relationships as shown in [RFC2905]:
2つの異なった組織がかかわるなら、信頼関係のための2つの可能性が[RFC2905]に示されるようにあります:
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-->| サービスを印刷してください。|---1-->| ファイルサービス| | | <--2---| AAAサーバ| <--2---| AAAサーバ| | | | +--------------------+ | +-------------------+ | | | | プリント・サーバ| | | ファイルサーバー| | | | | そして、プリンタ| | | | +------+ | +--------------------+ | +-------------------+
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サーバに最終的な記録を送ることができます。そこでは、中古のリソースに基づく後の承認決定にそれを使用できます、すなわち、顧客が会社であり、ユーザが従業員であるなら。
Zseby, et. al. Experimental [Page 30] RFC 3334 Policy-Based Accounting October 2002
et Zseby、アル。 会計2002年10月の方針ベースの実験的な[30ページ]RFC3334
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で承認と特定のセッションへのメッセージを説明するのを結合できる)とあるセッションがどの活動から構成されるかを定義する方針を使用することで両方の会計帳簿を結びつけて、それらをユーザに割り当てることができます。
9.1.3 User Accounting Indication
9.1.3 ユーザ会計指示
For the printing service, there are a number of possible options for sending accounting indications to the user. Accounting indications give the user an indication of how much resources have been used until the time of the indication. A user can receive accounting indications or not depending on the accounting policy for the user.
印刷サービスのために、会計指摘をユーザに送るための多くの可能なオプションがあります。 会計指摘はどのくらいのリソースが指示の時間まで使用されたかしるしをユーザに与えます。 指摘を説明するか、またはユーザのために会計方針によらないで、ユーザは受信できます。
For Internet printing with the "print-by-reference" model, such indications would be very helpful for the user. Since the file is not on the clients site, the user might not have information on the file size or the number of pages that will be printed. This means the user has no idea of the costs of the service usage. If user and subscriber are a single entity, accounting indications would help users to avoid exceeding their spending limit. Additionally, accounting indications give the user a hint as to which resource usage has caused the charges. This can be compared to an itemized telephony bill where not only the monetary sum per month is printed but, in addition, information for every call (start time, duration, distance etc.) and its corresponding charge.
「参照による印刷」モデルがあるインターネット印刷のために、ユーザにとって、そのような指摘は非常に役立っているでしょう。 ファイルがクライアントサイトにないので、ユーザには、印刷されるファイルサイズかページ数の情報がないかもしれません。 これは、ユーザにはサービス用法のコストの考えが全くないことを意味します。 ユーザと加入者が単一体、指摘が、彼らの支出限界を超えながらユーザが避けるのを助ける会計であるなら。 さらに、会計指摘はリソース用法が充電を引き起こしたヒントをユーザに与えます。 1カ月あたりの通貨でない合計だけが印刷される箇条書きされた電話請求書にもかかわらず、あらゆる要求(開始時刻、距離持続時間など)とその対応する充電のための追加における情報とこれを比較できます。
9.2 Mobile/Roaming Example
9.2 モバイルの、または、移動している例
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はあるパラメタ(レポート間隔や会計帳簿形式のような)に影響を及ぼすことができます。 ホームプロバイダーがインボイスを作って、したがって、価格について計算するために適切な会計帳簿を必要とするなら、これは役に立ちます。
Zseby, et. al. Experimental [Page 31] RFC 3334 Policy-Based Accounting October 2002
et Zseby、アル。 会計2002年10月の方針ベースの実験的な[31ページ]RFC3334
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
ユーザ| 訪問されたISP| ホームISP| | | | +-----------+ .......... <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--12-------------------| 充電| <、-:充電します: | | | 支払い| :方針: | | +-----------+ :........: | | ^ | | | | | +-----------+ | | | ASM| | | +-----------+ | | ^ | | |11 | | | | +------------+ | +-------------+ | | | | | | | | |---10---->|、|、|、|、|、|、|、| Acct。 記録| AAAFサーバ|----3---->| AAAHサーバ| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| | <、-、--4-----| | | | | | | | | | | | | | | +------------+ | +-------------+ | ^ | ^ | | | | | | | | 5 9 | | | | | | | | V| | | | +----------------+| | | | ASM|| | 2 | || | | +----------------+| | | | ^ | | | | | | | | 6 8 | | | | | | | +------------+------+-------+ | 7 | | サービス| | | | <、-、-、-、-、-、-、--、| 設備| +----------+| | 1 | | |、-、>|会計|| | -------->|、| +----------+| | | | コンフィグ| | | | | | | +---------+ | | | | +->| Meters| | | | | +---------+ | | | +---------------------------+ | | | 図13: ローミングの例
Zseby, et. al. Experimental [Page 32] RFC 3334 Policy-Based Accounting October 2002
et Zseby、アル。 会計2002年10月の方針ベースの実験的な[32ページ]RFC3334
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を取り入れます。 拡張ローミングの例は図13に示されます。 ホームAAAサーバに訪問されたISPを切れさせてください。ステップ(1)、(2)、および(3)はAAAを通したユーザからのステップ(4)では、ユーザの特定のサービスパラメタを訪問されたISPのAAAサーバに与えて、ユーザ構成が行われるサービス設備(5)に転送するという認証/承認要求の推進について説明します。 ユーザ特有のサービスパラメタはさらに、訪問されたISPの会計インフラストラクチャの構成のための必要な方針を含むかもしれません。 例えば、会計方針は「タイプYに関するX1会計帳簿が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).
ユーザ依存するサービスパラメタはASMによって適切な設定情報(6)に変換されます。 その時、ユーザは完成した認証/承認プロセス(7)に関して知識があります。 会計アーキテクチャは、リソース用法を計量し始めて、計量記録をASM(8)に送ります。 ASMは必要な会計帳簿をいっぱいにするのに計量されたデータを使用して、訪問されたISPのAAAサーバ(9)にそれらを送ります。 訪問されたISPは、データを後処理するか、または直接ホームISP(10)にそれらを送ることができます。 このデータと共に、入力されるようにユーザ/顧客(12)にインボイスをホームプロバイダードメイン(11)の中で充電方針(関税定石)を使用することによって充電と支払いモジュールで作って、次に、送ります。
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.
また、追加オプションとして、特別なサービスとしてユーザ(会計指示)に会計帳簿を提供できます。 この特別なサービスにおいて、別々の承認が必要です。
9.3 Diffserv Example
9.3 Diffservの例
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-掲示板]に基づくDiffservサービス[RFC2475]のための方針でどう構成されるかがわかります。 サービスは、より高い優先度とサービスによるパケットの輸送が、説明するのを含んでいるということであり、QoSは監査です。 図14はサービスセットアップを示しています。 ユーザはAAAサーバに対するDiffservサービスのために、Service Request(SR)を発行します。要求は必要なサービスのクラスのためのユーザIDとパラメタを含んでいます。
User->AAA: user-x@nw-a, service=diffserv, class=gold,
amount=2Mbit, dest= nw-b
ユーザ->、AAA、: user-x@nw-a 、サービス=diffserv、クラス=金、2Mbit、量=dest= nw-b
Zseby, et. al. Experimental [Page 33] RFC 3334 Policy-Based Accounting October 2002
et Zseby、アル。 会計2002年10月の方針ベースの実験的な[33ページ]RFC3334
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、クラス=金と等しく、量は2Mbit、src=nw-a dest=nw-bと等しいです。
The ASM takes over the task of translating the application specific information into appropriate user configuration information for the service equipment. For the given Diffserv example, the service equipment consists of three components: accounting equipment, the QoS auditing equipment and the bandwidth broker architecture. The ASM has to address all three components to set up the requested service for the user. The translation of the ASI into configuration information for the components can be done by evaluating service provisioning policies. For example, the ASM could have the following service provisioning policy:
ASMはサービス設備のための適切なユーザ設定情報にアプリケーション特殊情報を翻訳するタスクを引き継ぎます。 与えられたDiffservの例に関しては、サービス設備は3つのコンポーネントから成ります: 会計設備、QoSの監査の設備、および帯域幅はアーキテクチャを仲介します。 ASMは、ユーザのために要求されたサービスをセットアップするためにすべての3つのコンポーネントを扱わなければなりません。 方針に食糧を供給するサービスを評価することによって、コンポーネントのための設定情報へのASIに関する翻訳ができます。 例えば、ASMは以下のサービス食糧を供給する方針を持つことができました:
if class==gold {
set bw-request.class = gold
set accounting.type = comprehensive
set qos-audit.metric = one-way-delay
...
}
=金を分類してくださいなら一方向包括的なセットセットbw-request.class=金のセットaccounting.type=qos-audit.metric=遅れ…
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.
これは与えられたパラメタでゴールドサービスを求める掲示板に帯域幅要求を送るのに結果として生じます。 その上、ASMは与えられたネットワークの間の1つの道で延着している測定のために包括的な会計のための会計設備への要求とQoSの監査の設備への要求を出します。
ASM->BB: BW-request(gold, src=nw-a, dest=nw-b, amount=2Mbit)
ASM->、掲示板、: BW-要求(金、src=nw-a、dest=nw-b、量=2Mbit)
ASM->Acct: Acct-request(comprehensive, src=nw-a)
ASM、-、>Acct: Acct-要求(包括的である、src=nw-a)
ASM->QoS: QoS-audit-request(one-way-delay, src=nw-a, dest=nw-b)
ASM、-、>QoS: QoS監査要求(一方向遅れ、src=nw-a、dest=nw-b)
The bandwidth broker then sets up the Diffserv infrastructure to provide the prioritized forwarding according to the definition of a gold class. This is done in accordance with the actual bandwidth broker's architecture and is not further considered here. For the Accounting Configuration and the QoS Audit Control, local configuration policies exist for setting up the service.
そして、帯域幅ブローカーは、金のクラスの定義に応じて最優先する推進を提供するためにDiffservインフラストラクチャをセットアップします。 これを実際の帯域幅ブローカーのアーキテクチャによってして、ここでさらに考えません。 Accounting ConfigurationとQoS Audit Controlに関しては、ローカルの構成方針は、サービスをセットアップするために存在しています。
Zseby, et. al. Experimental [Page 34] RFC 3334 Policy-Based Accounting October 2002
et Zseby、アル。 会計2002年10月の方針ベースの実験的な[34ページ]RFC3334
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測定方針: -メートル法の=一方向であるなら、延着してください。受動態が設定した設定メソッド=が48ビットの=セットイングレスメーター位置=アクセスポイントをtimestampsizeする、(設定された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.It州のネットワークアクセスポイントにメーター位置を設定します。 与えられたレポート目標に結果として起こる記録を送らなければなりません。 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)のメーターに命令します。
Zseby, et. al. Experimental [Page 35] RFC 3334 Policy-Based Accounting October 2002
et Zseby、アル。 会計2002年10月の方針ベースの実験的な[35ページ]RFC3334
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: a. a. 規則dscp=23、src=/24、b.b.dest=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 |
+--------------------------------------------------+
SR+-------+ ユーザ----------------->| AAA| +-------+ | | ASI対+-------+ +-----------------| ASM|--------------+--------------+ | 方針+-------+ 方針| BW要求| | パラメタパラメタ| | | | | -----|----------------------------------------|--------------|----- | サービス設備| | +に対するV V---------------+ .............. +-----------+ +-----------+ | 会計| <-->: 地方の:<-->| QoS| | 帯域幅| | | : 方針: | 監査| | ブローカー| +---------------+ :............: +-----------+ +-----------+ | | | メーター指示| 測定セットアップV対+--------------------------------------------------+ | 測定| | インフラストラクチャ| +--------------------------------------------------+
Figure 14: Diffserv Service Provision Setup
図14: Diffservサービス支給セットアップ
The QoS audit control instructs two meters (at MP1 and MP2) to set up a passive one-way-delay measurement.
QoS監査コントロールは、受け身の一方向遅れ測定をセットアップするよう2メーター(MP1とMP2の)に命令します。
QoS->MI: MP1: add rule dscp=23, src=a.a.a.a/24 dest=b.b.b.b/24,
save timestamp-48
MP2: add rule dscp=23, src=a.a.a.a/24, dest=b.b.b.b/24,
save timestamp-48
QoS->、ミ、: MP1: a. a. a. /24dest=b.b.規則dscp=23、src=b.b/24を加えてください、そして、タイムスタンプ-48MP2を取っておいてください: /24(b.b.dest=b.b/24)がタイムスタンプ-48を保存するa.規則dscp=23、src=a.a.を加えてください。
Zseby, et. al. Experimental [Page 36] RFC 3334 Policy-Based Accounting October 2002
et Zseby、アル。 会計2002年10月の方針ベースの実験的な[36ページ]RFC3334
9.4 User Accounting Indication Example
9.4 ユーザ会計指示の例
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サーバにAccounting Service Request(ASR)を送ります。
user->AAA: user-x@nw-a, service= accounting indications,
report interval= 60 s
ユーザ->、AAA、: user-x@nw-a 、会計サービス=指摘は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: user-x@nw-a 、会計サービス=指摘は60秒間の間隔=を報告します。
Zseby, et. al. Experimental [Page 37] RFC 3334 Policy-Based Accounting October 2002
et Zseby、アル。 会計2002年10月の方針ベースの実験的な[37ページ]RFC3334
The ASM generates an accounting policy based on the ASI and passes this policy to the Accounting Configuration.
ASMはASIに基づく会計方針を生成して、この方針をAccounting Configurationに通過します。
ASM->Acct: If src=a.a.a.x {
acc-indication = on
report interval = 60s
report target= a.a.a.x
}
ASM、-、>Acct: srcがa.a.a.xと等しいならレポート間隔=60年代レポート目標=a.a.a.xのacc-指示=
ASR +-------+
User --------------->| AAA |
+-------+
|
| ASI
V
+-------+
| ASM |
+-------+
|
-------------------------|---------------------------
Service Equipment | Accounting Policy
V
+-----------------+ ..............
| Accounting |<---->: Local Acct :
| | : Policies :
+-----------------+ :............:
|
| Meter Instructions
V
+-----------------+
| Measurement |
| Infrastructure |
+-----------------+
ASR+-------+ ユーザ--------------->| AAA| +-------+ | | ASI対+-------+ | ASM| +-------+ | -------------------------|--------------------------- サービス設備| 会計方針対+-----------------+ .............. | 会計| <、-、-、-->: 地方のAcct: | | : 方針: +-----------------+ :............: | | メーター指示対+-----------------+ | 測定| | インフラストラクチャ| +-----------------+
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.
Accounting Configurationは会計方針によってASMとローカルの会計方針からメーター指示を生成して、測定インフラストラクチャにそれらを移ります。
local Acct-Policy: if acc-indication {
record type = compact
}
ローカルのAcct-方針: acc-指示です。コンパクトな状態でタイプ=を記録してください。
Acct->MI: MP1: set report interval = 60 s
add report target = a.a.a.x
Acct>のMI: MP1: レポート間隔=60秒間設定されて、レポート目標=a.a.a.xを加えてください。
Zseby, et. al. Experimental [Page 38] RFC 3334 Policy-Based Accounting October 2002
et Zseby、アル。 会計2002年10月の方針ベースの実験的な[38ページ]RFC3334
10. Security Considerations
10. セキュリティ問題
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.
- 会計方針、会計帳簿情報Both会計方針、および会計帳簿の偽造は情報の偽造の目標であるかもしれません。 会計方針は設定情報を含んでいます。 この情報を変更するのが悪-構成された会計に通じることができて、データが会計システムを横断する計量システムは、にせの会計帳簿を非検出したか(例えば、1メーターの分類規則を変えることによって説明されないで)、または作り出します。 会計帳簿は、リソース消費に関するデータを含んでいて、支払いの基礎を提供します。 会計帳簿を変更するのは誤った請求書に通じるかもしれません。 その上、方針か会計帳簿が向け直されもしませんし、取り除かれもしないで、偽造方針か記録が挿入されないのは、重要です。
- Eavesdropping It may be required to keep accounting policies and accounting records confidential between the involved parties.
- 盗聴Itは関係者の間で会計方針と会計帳簿を秘密にしなければならないかもしれません。
- 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)攻撃Both 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.
- 会計方針と会計データUnauthorized実体の秘密保持は、会計方針か会計帳簿を読むべきではありませんし、変更できないべきです。 標準の暗号化メソッドでこれを達成できます。
Zseby, et. al. Experimental [Page 39] RFC 3334 Policy-Based Accounting October 2002
et Zseby、アル。 会計2002年10月の方針ベースの実験的な[39ページ]RFC3334
- 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.
- 会計データと会計方針ソースItの認証はそれが確実にされて、データが一次資料によって溯源されるということであるべきです。 デジタル署名を使用することによって、ソース認証を達成できます。
- 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.
- また、デジタル署名でデータが方針とItが確実にされるべきであるという記録であったのにもかかわらずの、受信機送付者からデータ認証への途中で変更されて、説明する保全の保護を達成できます。
- 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.
- データItを確実にしなければならないサービスプロバイダーによって生成された会計データがある会計であると正しい状態で生成されて、正当性について確かめます。 プロバイダーは、故意に(すなわち、鍛造する)不正確な会計が記録であると何気なさに(例えば、不完全な構成)生成するかもしれません。 これらの不正確な会計帳簿には、不正確な請求書の結果がたぶんあります。 顧客はそれらの測定値信頼できる第三者機関によって集められたデータを通して会計データの正当性について確かめることができます。 信頼できる第三者機関は監査のサービスを提供するセクション7.2か、より一般的な実体で説明されるように独立している会計サービスプロバイダーであるかもしれません。
- Prevention and protection against Denial of Service attacks The AAA protocol and all building blocks should be designed and implemented in a way as resistant as possible to denial of service attacks. An additional strategy to defend against DoS attacks is to add a component to the meter system that is able to detect suspicious traffic patterns. Upon detection, further actions can be taken according to a pre-defined policy.
- サービス妨害に対する防止と保護がAAAプロトコルを攻撃して、すべてのブロックが、できるだけサービス不能攻撃に抵抗力がある方法で設計されていて、実装されるべきです。 DoS攻撃に対して防御する追加戦略は疑わしげなトラフィック・パターンを検出できるメーターシステムにコンポーネントを追加することです。 検出のときに、事前に定義された方針によると、さらなる行動を取ることができます。
The prevention of these hazards has to be considered for the protocols used for accounting policy exchange and the transportation of accounting records. Since the security requirements for authentication, transmission level security, data object confidentiality and integrity are addressed in the criteria for AAA protocol evaluation [RFC2989], we assume that the future AAA protocol(s) will be suited for secure accounting record transfer and probably also for secure accounting policy transport. Furthermore, we assume that existing or upcoming solutions for secure transportation and enforcement of policies can be used. Real prevention of DoS attacks is quite difficult. A selective dropping of the attackers packets is impossible if the malicious packets cannot be separated from the valid customer traffic. Dropping of all packets of a certain type may prevent authorized customers from using the service and therefore help the attacker to achieve her goal.
これらの危険の防止はプロトコルのために会計方針交換と会計帳簿の輸送において使用されていた状態で考えられなければなりません。 認証、トランスミッションレベルセキュリティ、データ・オブジェクト秘密性、および保全のためのセキュリティ要件がAAAプロトコル評価[RFC2989]の評価基準で扱われるので、私たちは、将来のAAAプロトコルが安全な会計帳簿転送とたぶん安全な会計方針輸送にも合うと思います。 その上、私たちは、方針の安全な輸送と実施のための存在か今度のソリューションを使用できると思います。 DoS攻撃の本当の防止はかなり難しいです。 有効な顧客トラフィックから悪意があるパケットを分離できないなら、攻撃者パケットの選択している低下は不可能です。 あるタイプのパケットが防ぐかもしれないすべてを落とすのは、サービスを利用するので顧客に権限を与えて、したがって、攻撃者が目的を果たすのを助けます。
Zseby, et. al. Experimental [Page 40] RFC 3334 Policy-Based Accounting October 2002
et Zseby、アル。 会計2002年10月の方針ベースの実験的な[40ページ]RFC3334
11. References
11. 参照
[I2-BB] Internet2-QBone Bandwidth Broker,
http://www.merit.edu/working.groups/i2-qbone-bb
[I2-掲示板] Internet2-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移動性サポート」、RFC3220、1996年10月。
[RFC2123] Brownlee, N., "Traffic Flow Measurement: Experiences with
NeTraMet", RFC 2123, March 1997.
[RFC2123]ブラウンリー、N.、「流量測定を取引してください」 「NeTraMetの経験」、RFC2123、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.ウィス、「差別化されたサービスのためのアーキテクチャ」、RFC2475、1998年12月。
[RFC2566] DeBry, R., "Internet Printing Protocol/1.0: Model and
Semantics", RFC 2911, April 1999.
[RFC2566] DeBry、R.、「プロトコル/1.0に以下を印刷するインターネット」 「モデルと意味論」、RFC2911、4月1999日
[RFC2722] Brownlee, N., Mills, C. and G. Ruth, "Traffic Flow
Measurement: Architecture", RFC 2722, October 1999.
[RFC2722] ブラウンリー、N.、工場、C.、およびG.ルース、「流量測定を取引してください」 「アーキテクチャ」、RFC2722、1999年10月。
[RFC2903] de Laat, C., Gross, G., Gommans, L., Vollbrecht, J. and
D. Spence, "Generic AAA Architecture", RFC 2903, August
2000.
[RFC2903] de LaatとC.とGrossとG.とGommansとL.とVollbrechtとJ.とD.スペンス、「ジェネリックAAAアーキテクチャ」、RFC2903、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.とGrossとG.とde BruijnとB.とde LaatとC.とHoldregeとM.とD.スペンス、「AAA承認フレームワーク」、RFC2904、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.とGrossとG.とde BruijnとB.とde LaatとC.とHoldregeとM.とD.スペンス、「AAA承認アプリケーションの例」、RFC2905、2000年8月。
[RFC2924] Brownlee, N. and A. Blount, "Accounting Attributes and
Record Formats", RFC 2924, September 2000.
[RFC2924] ブラウンリーとN.とA.ブラント、「属性とレコード形式を説明します」、RFC2924、2000年9月。
[RFC2975] Aboba, B., Arkko, J. and D. Harrington, "Introduction to
Accounting Management", RFC 2975, October 2000.
[RFC2975] AbobaとB.とArkkoとJ.とD.ハリントン、「会計管理への紹介」、RFC2975、2000年10月。
Zseby, et. al. Experimental [Page 41] RFC 3334 Policy-Based Accounting October 2002
et Zseby、アル。 会計2002年10月の方針ベースの実験的な[41ページ]RFC3334
[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.とShiinoとH.とウォルシュとP.とゾルンとG.とDommetyとG.とパーキンスとC.とパティルとB.とミットンとD.とマニングとS.と用務員とM.とチェンとX.とSivalinghamとS.とハミードとA.とムンソンとM.とジェイコブズとS.とリムとB.とヒルシュマンとB.とシューとR.とクーとH.とLipfordとM.とキャンベルとE.とシューとY.と馬場とS.とE.ジャキュース、「ネットワークアクセスのためにAAAプロトコルを評価する評価基準」とガラスで覆います、RFC2989、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.とHuynhとA.とカールソンとM.とペリーとJ.とS.Waldbusser、「方針を拠点とする管理のための用語」RFC3198(2001年11月)。
12. Acknowledgments
12. 承認
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 de Laatのメンバーに感謝したがっています、有意義な論議とコメントのために。 このドキュメントへの彼らのレビューと貴重な入力のためのバーナードAboba、ネヴィル・ブラウンリー、およびエドEllessonには特別な感謝があります。
Zseby, et. al. Experimental [Page 42] RFC 3334 Policy-Based Accounting October 2002
et Zseby、アル。 会計2002年10月の方針ベースの実験的な[42ページ]RFC3334
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 10589ベルリンドイツ電話のターニャZsebyフラウンホーファー研究所: +49-30-34、63 7153、Fax: +49-30-34 53 8153はメールされます: zseby@fokus.fhg.de
Sebastian Zander Fraunhofer Institute for Open Communication Systems Kaiserin-Augusta-Allee 31 10589 Berlin Germany Phone: +49-30-34 63 7287 Fax: +49-30-34 63 8287 EMail: zander@fokus.fhg.de
オープンコミュニケーションシステム皇后オーガスタ並木道31 10589ベルリンドイツ電話のセバスチャンザンダーフラウンホーファー研究所: +49-30-34、63 7287、Fax: +49-30-34 63 8287はメールされます: zander@fokus.fhg.de
Georg Carle Fraunhofer Institute for Open Communication Systems Kaiserin-Augusta-Allee 31 10589 Berlin Germany Phone: +49-30-34 63 7149 Fax: +49-30-34 63 8149 EMail: carle@fokus.fhg.de
オープンコミュニケーションシステム皇后オーガスタ並木道31 10589ベルリンドイツ電話のゲオルク無作法者フラウンホーファー研究所: +49-30-34、63 7149、Fax: +49-30-34 63 8149はメールされます: carle@fokus.fhg.de
Zseby, et. al. Experimental [Page 43] RFC 3334 Policy-Based Accounting October 2002
et Zseby、アル。 会計2002年10月の方針ベースの実験的な[43ページ]RFC3334
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Zseby, et. al. Experimental [Page 44]
et Zseby、アル。 実験的[44ページ]
一覧
スポンサーリンク
