RFC1272 日本語訳
1272 Internet Accounting: Background. C. Mills, D. Hirsh, G.R. Ruth. November 1991. (Format: TXT=46562 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group C. Mills
Request for Comments: 1272 BBN
D. Hirsh
Meridian Technology Corporation
G. Ruth
BBN
November 1991
工場がコメントのために要求するワーキンググループC.をネットワークでつないでください: 1272 BBN D.ハーシュ子午線技術社のG.ルースBBN1991年11月
INTERNET ACCOUNTING: BACKGROUND
インターネット会計: バックグラウンド
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはインターネット標準を指定しません。 このメモの分配は無制限です。
1. Statement of Purpose
1. 目的説明書
This document provides background information for the "Internet Accounting Architecture" and is the first of a three document set:
このドキュメントは、「インターネット会計アーキテクチャ」に基礎的な情報を提供して、1人の3文献集合の1番目です:
Internet Accounting Background & Status (this document)
Internet Accounting Architecture (under construction)
Internet Accounting Meter Service (under construction)
インターネットAccounting Background&Status(このドキュメント)インターネットAccounting Architecture(工事中)インターネットAccounting Meter Service(工事中)
The focus at this time is on defining METER SERVICES and USAGE REPORTING which provide basic semantics for measuring network utilization, a syntax, and a data reporting protocol. The intent is to produce a set of standards that is of practical use for early experimentation with usage reporting as an internet accounting mechanism.
焦点がこのとき、ネットワーク利用、構文、およびデータ報告プロトコルを測定するのに基本的な意味論を提供するMETER SERVICESとUSAGE REPORTINGを定義するところにあります。 意図は用法がインターネット会計機構として報告している状態で早めの実験のために実用のものである1セットの規格を生産することです。
The architecture should be expandable as additional experience is gained. The short-term Internet Accounting solution is intended to merge with OSI and Autonomous Network Research Group (ANRG) efforts and be superseded by those efforts in the long term. The OSI accounting working groups are currently defining meter syntax and reporting protocols. The ANRG research group is currently researching economic models and accounting tools for the Internet environment.
追加経験をするのに従って、アーキテクチャは拡張可能であるべきです。 短期的なインターネットAccountingソリューションは、OSIとAutonomous Network Research Group(ANRG)取り組みと合併して、それらの取り組みによって長期で取って代わられることを意図します。 OSI会計ワーキンググループは、現在、メーター構文を定義して、プロトコルを報告しています。 ANRG研究グループは現在、インターネット環境のために経済モデルと会計ツールについて研究しています。
Internet Accounting as described here does not wrestle with the applications of usage reporting, such as monitoring and enforcing network policy; nor does it recommend approaches to billing or tackle such thorny issues as who pays for packet retransmission.
ここで説明されるインターネットAccountingは用法報告のアプリケーションと取っ組み合いをしません、ネットワーク方針をモニターして、実施するのなどように。 また、それは、支払いへのアプローチを推薦するか、またはだれがパケット「再-トランスミッション」の代金を支払うかような難しい問題に取り組みません。
This document provides background and tutorial information on issues
このドキュメントは問題のバックグラウンドと家庭教師の情報を提供します。
Mills, Hirsh, & Ruth [Page 1] RFC 1272 Internet Accounting: Background November 1991
工場、ハーシュ、およびルース[1ページ]RFC1272インターネット会計: バックグラウンド1991年11月
surrounding the architecture, or in a sense, an explanation of choices made in the Internet Accounting Architecture.
アーキテクチャ、またはある意味でインターネットAccounting Architectureでされた選択に関する説明を囲んでいます。
2. Goals for a Usage Reporting Architecture
2. アーキテクチャを報告する用法の目標
We have adopted the accounting framework and terminology used by OSI (ISO 7498-4 OSI Reference Model Part 4: Management Framework). This framework defines a generalized accounting management activity which includes calculations, usage reporting to users and providers and enforcing various limits on the use of resources. Our own ambitions are considerably more modest in that we are defining an architecture to be used over the short- term (until ISO and ANRG have final pronouncement and standards) that is limited to network USAGE REPORTING.
私たちはOSI(ISO7498-4OSI Reference Model Part4: 管理Framework)によって使用された会計フレームワークと用語を採用しました。 このフレームワークは計算(ユーザとプロバイダーに報告して、様々な限界にリソースの使用に押しつける用法)を含んでいる一般化された会計管理活動を定義します。 私たちがすなわちというネットワークUSAGE REPORTINGに制限された短い期間(ISOとANRGには最終的な宣告と規格があるまで)にわたって使用されるためにアーキテクチャを定義していて、私たち自身の野心はかなり穏やかです。
The OSI accounting model defines three basic entities:
OSI会計モデルは3つの基本的対象を定義します:
1) the METER, which performs measurements and aggregates the
results of those measurements;
1) METER(METERは測定を実行して、それらの測定値の結果に集めます)。
2) the COLLECTOR, which is responsible for the integrity and
security of METER data in short-term storage and transit;
and
2) COLLECTOR(COLLECTORは短期的なストレージとトランジットにおける、METERデータの保全とセキュリティに責任があります)。 そして
3) the APPLICATION, which processes/formats/stores METER
data. APPLICATIONS implicitly manage METERS.
3) APPLICATION。(そのAPPLICATIONはMETERデータを処理するか、フォーマットする、または保存します)。 APPLICATIONSはそれとなくMetersを管理します。
This working group, then, is concerned with specifying the attributes of METERS and COLLECTORS, with little concern at this time for APPLICATIONS.
次に、このワーキンググループはMetersとCOLLECTORSの属性を指定するのに関係があります、今回のAPPLICATIONSに関する少ない心配をもって。
3. The Usage Reporting Function
3. 用法報告機能
3.1. Motivation for Usage Reporting
3.1. 用法報告に関する動機
The dominant motivations for usage reporting are:
用法報告に関する優位な動機は以下の通りです。
o Understanding/Influencing Behavior.
Usage reporting provides feedback for the subscriber on
his use of network resources. The subscriber can better
understand his network behavior and measure the impact of
modifications made to improve performance or reduce
costs.
o 振舞いに理解しているか、または影響を及ぼします。 用法報告は彼のネットワーク資源の使用のときにフィードバックを加入者に提供します。 加入者は、彼のネットワークの振舞いを理解するほうがよくて、性能を向上させるのがされた変更の影響を測定するか、またはコストを削減できます。
o Measuring Policy Compliance.
From the perspective of the network provider, usage
reports might show whether or not a subscriber is in
compliance with the stated policies for quantity of
o 方針コンプライアンスを測定します。 ネットワーク内の提供者の見解から、用法レポートは、加入者が量のための述べられた方針に従っているかどうかを示すかもしれません。
Mills, Hirsh, & Ruth [Page 2] RFC 1272 Internet Accounting: Background November 1991
工場、ハーシュ、およびルース[2ページ]RFC1272インターネット会計: バックグラウンド1991年11月
network usage. Reporting alone is not sufficient to
enforce compliance with policies, but reports can
indicate whether it is necessary to develop additional
methods of enforcement.
用法をネットワークでつないでください。 単独で報告するのが方針で服従を強いることができないくらいレポートは、実施の追加メソッドを開発するのが必要であるかどうかを示すことができます。
o Rational Cost Allocation/Recovery.
Economic discipline can be used to penalize inefficient
network configuration/utilization as well as to reward
the efficient. It can be used to encourage bulk transfer
at off hours. It can be used as a means to allocate
operating costs in a zero-sum budget, and even be used as
the basis for billing in a profit-making fee-for-service
operation.
o 合理的な費用配分/回復。 効率の悪いネットワーク・コンフィギュレーション/利用を罰して、効率的の報酬を与えるのに経済規律を使用できます。 オフ時間にバルク転送を奨励するのにそれを使用できます。 それを運用経費を割り当てる手段として零和の予算で使用して、支払いの基礎として利益を上げるサービスのための料金操作に使用さえできます。
The chief deterrent to usage reporting is the cost of measuring usage, which includes:
用法報告への主要な抑止力は測定用法の費用です。(その費用は以下の通りです)。
o Reporting/collection overhead.
This offers an additional source of computational load
and network traffic due to the counting operations,
managing the reporting system, collecting the reported
data, and storing the resulting counts. Overhead
increases with the accuracy and reliability of the
accounting data.
o 報告/収集オーバーヘッド。 これは勘定操作のためコンピュータの負荷とネットワークトラフィックの追加源を提供します、リポーティングシステムを管理して、報告されたデータを集めて、結果として起こるカウントを保存して。 会計データの精度と信頼性に応じて、オーバーヘッドは上がります。
o Post-processing overhead.
Resources are required to maintain the post-processing
tasks of maintaining the accounting database, generating
reports, and, if appropriate, distributing bills,
collecting revenue, servicing subscribers.
o 後工程オーバーヘッド。 リソースが会計データベースを維持する後工程タスクを維持するのに必要です、そして、適切であるならレポートを作って、ビラをまいて、収入を集めて、加入者にサービスを提供して。
o Security overhead.
The use of security mechanisms will increase the overall
cost of accounting. Since accounting collects detailed
information about subscriber behavior on the network and
since these counts may also represent a flow of money, it
is necessary to have mechanisms to protect accounting
information from unauthorized disclosure or manipulation.
o セキュリティオーバーヘッド。 セキュリティー対策の使用は会計の全費用を増強するでしょう。 会計が加入者の振舞いの詳細な情報をネットワークに集めて、また、これらのカウントがお金の流れを表すかもしれないので、不当開示か操作から課金情報を保護するメカニズムを持つのが必要です。
The balance between cost and benefit is regulated by the GRANULARITY of accounting information collected. This balance is policy- dependent. To minimize costs and maximize benefit, accounting detail is limited to the minimum amount to provide the necessary information for the research and implementation of a particular policy.
費用と利益の間のバランスは集められた課金情報のGRANULARITYによって規制されます。 このバランスは方針に依存しています。 コストを最小にして、利益を最大にするなら、会計の詳細は、特定の方針の研究と実装のための必要事項を提供するために最小の量に制限されます。
Mills, Hirsh, & Ruth [Page 3] RFC 1272 Internet Accounting: Background November 1991
工場、ハーシュ、およびルース[3ページ]RFC1272インターネット会計: バックグラウンド1991年11月
3.2. Network Policy and Usage Reporting
3.2. ネットワーク方針と用法報告
Accounting requirements are driven by policy. Conversely, policy is typically influenced by the available management/reporting tools and their cost. This section is NOT a recommendation for billing practices, but intended to provide additional background for understanding the problems involved in implementing a simple, adequate usage reporting system.
会計要件は方針で追い立てられます。 逆に、方針は利用可能な管理/報告ツールとそれらの費用によって通常影響を及ぼされます。 支払いが練習されますが、簡単で、適切な用法リポーティングシステムを実装するのにかかわる問題を理解しているのに追加バックグラウンドを提供することを意図する以外に、このセクションは推薦ではありません。
Since there are few tools adequate for any form of cost recovery and/or long-term monitoring there are few organizations that practice proactive usage reporting in the Internet. Those that do have generally invented their own. But far and away the most common approach is to treat the cost of network operations as overhead with network reports limited to short-term, diagnostic intervention. But as the population and use of the Internet increases and diversifies, the complexity of paying for that usage also increases. Subsidies and funding mechanisms appropriate to non-profit organizations often restrict commercial use or require that "for profit" use be identified and billed separately from the non-profit use. Tax regulations may require verification of network connection or usage. Some portions of the Internet are distinctly "private", whereas other Internet segments are treated as public, shared infrastructure.
以来、どんなフォームの原価回収にも、適切なツールがわずかしかありません、そして、そこでの長期のモニターはインターネットで報告する先を見越す用法を練習するわずかな組織です。 それら自身一般に発明されたのがあるもの。 しかし、疑いなく最も一般的なアプローチはネットワークレポートが短期的で、診断している介入に制限されている状態でネットワーク操作の費用をオーバーヘッドとして扱うことです。 しかし、また、インターネットの人口と使用が増加して、多角化するのに従って、その用法の代価を払う複雑さは増加します。 民間非営利組織に適切な補助金と資金調達メカニズムは、しばしば商業用途を制限するか、または「利益」使用が別々に非営利の使用から特定されて、請求されるのを必要とします。 税法はネットワーク接続か用法の検証を必要とするかもしれません。 インターネットの数個の部分が明瞭に「個人的です」が、他のインターネットセグメントは公共の、そして、共有されたインフラストラクチャとして扱われます。
The number of administrations operating in some connection with the Internet is exploding. The network "hierarchy" (backbone, regional, enterprise, stub network) is becoming deeper (more levels), increasingly enmeshed (more cross-connections) and more diversified (different charters and usage patterns). Each of these administrations has different policies and by-laws about who may use an individual network, who pays for it, and how the payment is determined. Also, each administration balances the OVERHEAD costs of accounting (metering, reporting, billing, collecting) against the benefits of identifying usage and allocating costs.
インターネットとの何人かの関係で作動する政権の数は爆発しています。 ネットワーク「階層構造」(バックボーン、地方版、企業はネットワークを引き抜く)は、より深くなって(より多くのレベル)、ますます巻き込まれて(より多くの交差接続)、さらに多角化します(異なった特許と用法パターン)。 それぞれのこれらの政権には、だれが個々のネットワークを使用するかもしれないか、そして、だれがそれの代価を払うか、そして、支払いがどのように決定しているかに関する異なった方針と内規があります。 また、各管理は用法を特定して、コストを割り当てる利益に対して会計(計量していて、報告していて、請求している収集)のOVERHEADコストのバランスをとっています。
Some members of the Internet community are concerned that the introduction of usage reporting will encourage new billing policies which are detrimental to the current Internet infrastructure (though it is also reasonable to assert that the current lack of usage reporting may be detrimental as well). Caution and experimentation must be the watch words as usage reporting is introduced. Well before meters are used for active BILLING and ENFORCEMENT, they should first be used to:
インターネットコミュニティのメンバーの中には用法報告の導入が現在のインターネット基盤に有害な新しい支払い方針を奨励することを(また、また、用法報告の現在の不足も有害であるかもしれないと断言するのも妥当ですが)心配している人もいます。 用法報告を導入するとき、警告と実験は腕時計単語であるに違いありません。 メーターがアクティブなBILLINGとENFORCEMENTによく使用される前に、それらは最初に、以下のことに使用されるべきです。
o UNDERSTAND USER BEHAVIOR
(learn to quantify and/or predict individual and
aggregate traffic patterns over the long term),
o UNDERSTAND USER BEHAVIOR(長期的に見ると個々の、そして、集合のトラフィック・パターンを定量化する、そして/または、予測することを学びます)
Mills, Hirsh, & Ruth [Page 4] RFC 1272 Internet Accounting: Background November 1991
工場、ハーシュ、およびルース[4ページ]RFC1272インターネット会計: バックグラウンド1991年11月
o QUANTIFY NETWORK IMPROVEMENTS,
(measure user and vendor efficiency in how network
resources are consumed to provide end-user data transport
service) and
o そしてQUANTIFY NETWORK IMPROVEMENTSと、(ネットワーク資源がエンドユーザデータに輸送サービスを提供するために消費される測定ユーザと中のベンダー効率)。
o MEASURE COMPLIANCE WITH POLICY.
o 方針へのコンプライアンスを測定してください。
Accounting policies for network traffic already exist. But they are usually based on network parameters which change seldom, if at all. Such parameters require little monitoring (the line speed of a physical connection, e.g.,Ethernet, 9600 baud, FDDI). The connection to the network is then charged to the subscriber as a FLAT-FEE regardless of the amount of traffic passed across the connection and is similar to the monthly unlimited local service phone bill.
ネットワークトラフィックへの会計方針は既に存在しています。 しかし、通常、それらはめったにせいぜい変化しない回路パラメータに基づいています。 そのようなパラメタは、少ししか(物理接続のライン・スピード、例えば、イーサネット、9600年のボー、FDDI)をモニターするのを必要としません。 ネットワークとの接続は、次に、トラフィックの量にかかわらずFLAT-FEEが接続の向こう側に通ったので加入者に請求されて、毎月の無制限なローカル・サービス電話代請求書と同様です。
Usage-insensitive access charges are sufficient in many cases, and can be preferable to usage-based charging in Internet environments, for financial, technical, and social reasons. Sample incentives for the FLAT-FEE billing approach are:
用法神経の鈍いアクセスチャージは、多くの場合、十分であり、インターネット環境における用法ベースの充電より望ましい場合があります、財政的で、技術的で、社会的な理由で。 FLAT-FEE支払いアプローチのためのサンプル誘因は以下の通りです。
o FINANCIAL:
Predictable monthly charges. No overhead costs for
counting packets and preparing usage-based reports.
o 財政的: 予測できる月額使用料金。 どんなオーバーヘッドも、パケットと準備を数えるのに用法ベースのレポートかかりません。
o TECHNICAL:
Easing the sharing of resources. Eliminating the
headaches of needing another layer of accounting in proxy
servers which associate their usage with their clients'.
Examples of proxy servers which generate network traffic
on behalf of the actual user or subscriber are mail
daemons, network file servers, and print spoolers.
o 技術的: リソースの共有を緩和します。 彼らのクライアントのものにそれらの用法を関連づけるプロキシサーバにおける、会計の別の層を必要とする頭痛を取り除きます。 実施している者か加入者を代表してネットワークトラフィックを生成するプロキシサーバに関する例は、メールデーモンと、ネットワークファイルサーバと、プリントスプーラです。
o SOCIAL:
Treating the network as an unregulated public
infrastructure with equal access and information sharing.
Encouraging public-spirited behavior -- contributing to
public mailing lists, information distribution, etc.
o 社会的: 同等のアクセスと情報が共有されている状態で、調節されない公共のインフラストラクチャとしてネットワークを扱います。 公共のメーリングリスト、情報流通などに貢献して、公共心に富んでいる振舞いを奨励します。
In other cases USAGE-SENSITIVE charges may be preferred or required by a local administration's policy. Government regulations or the wishes of subscribers with low or intermittent traffic patterns may force the issue (note: FLAT FEES are beneficial for heavy network users. USAGE SENSITVE charges generally benefit the low-volume user). Where usage-sensitive accounting is used, cost ceilings and floors may still be established by static parameters, such as "pipe size" for fixed connections or "connection time" for dial-up connection, to satisfy the need for some predictability.
他の場合では、USAGE-SENSITIVE充電は、地方行政の方針によって好まれるか、または必要とされるかもしれません。 低いか間欠のトラフィック・パターンがある政府規制か加入者の願望が対決を迫るかもしれません。(以下に注意してください。 重いネットワーク利用者にとって、FLAT FEESは有益です。 一般に、USAGE SENSITVE充電は低ボリュームユーザのためになります。). 用法敏感な会計が使用されているところでは、天井かかってください。そうすれば、床は固定接続のための「パイプサイズ」かダイアルアップ接続のための「接続時間」などの静的なパラメタによってまだ確立されていて、何らかの予見性の需要を満たしてもよいです。
Mills, Hirsh, & Ruth [Page 5] RFC 1272 Internet Accounting: Background November 1991
工場、ハーシュ、およびルース[5ページ]RFC1272インターネット会計: バックグラウンド1991年11月
Different billing schemes may be employed depending on network measures of distance. For example, local network traffic may be flat-rate and remote internet traffic may be usage-based, analogous to the local and long distance billing policies adopted by the telephone companies.
距離のネットワーク基準によって、異なった支払い体系は使われるかもしれません。 例えば、企業内情報通信網トラフィックはちょうどレートであるかもしれません、そして、リモートインターネットトラフィックは用法ベースであるかもしれません、電話会社によって採られた地方の、そして、長い距離支払い方針に類似しています。
The ANRG is independently investigating policy models and infrastructure economics for billing and cost recovery.
ANRGは支払いと原価回収のために独自に政策モデルとインフラストラクチャ経済学を調査しています。
3.3. The Nature of Usage Accounting
3.3. 用法会計の本質
Although the exact requirements for internet usage accounting will vary from one network administration to the next and will depend on policies and cost trade-offs, it is possible to characterize the problem in some broad terms and thereby bound it. Rather than try to solve the problem in exhaustive generality (providing for every imaginable set of accounting requirements), some assumptions about usage accounting are posited in order to make the problem tractable and to render implementations feasible. Since these assumptions form the basis for our architectural and design work, it is important to make them explicit from the outset and hold them up to the scrutiny of the Internet community.
インターネット用法会計のための正確な要件は、1つのネットワーク管理から次に異なって、方針とコストトレードオフによるでしょうが、その結果、いくつかの広義語で問題を特徴付けるのがそれを縛ったのは、可能です。 むしろ、用法会計に関するいくつかの仮定が、問題を御しやすくして、実装を可能にするために徹底的な一般性における問題を解決しようとするより(あらゆる想像可能なセットの会計要件に備えて)置かれます。 これらの仮定が私たちの建築するのとデザイン仕事の基礎を形成するので、それらを着手によって明白にして、インターネットコミュニティの精査にそれらを持ち上げるのは重要です。
3.3.1. A Model for Internet Accounting
3.3.1. インターネット会計のためのモデル
We begin with the assumption that there is a "network administrator" or "network administration" to whom internet accounting is of interest. He "owns" and operates some subset of the internet (one or more connected networks)that may be called his "administrative domain". This administrative domain has well defined boundaries.
私たちはインターネット会計が興味がある「ネットワーク管理者」か「ネットワーク管理」があるという仮定で始めます。 彼は、彼の「管理ドメイン」と呼ばれるかもしれないインターネット(ものか以上がネットワークを接続した)の何らかの部分集合を「所有し」て、操作します。 この管理ドメインは境界をよく定義しました。
our domain X
-------------------
/ | | | |
/ | C
/ ------ /
Network A / | \ /
----- (diagonals \___/____
| | | cross admin. domain B
boundaries)
私たちのドメインX------------------- / | | | | / | C/------ /は/をネットワークでつなぎます。| \ / ----- (diagonals \___/____ | | | cross admin. domain B boundaries)
The network administrator is interested in 1) traffic within his boundaries and 2) traffic crossing his boundaries. Within his boundaries he may be interested in end-system to end-system accounting or accounting at coarser granularities (e.g., department to department).
ネットワーク管理者は彼の境界に交差する彼の境界と2)交通の中の1)交通に興味を持っています。 彼の境界の中では、彼は、より粗い粒状(例えば、部への部)でエンドシステム会計か会計へのエンドシステムに興味を持つかもしれません。
Mills, Hirsh, & Ruth [Page 6] RFC 1272 Internet Accounting: Background November 1991
工場、ハーシュ、およびルース[6ページ]RFC1272インターネット会計: バックグラウンド1991年11月
The network administrator is usually not interested in accounting for end-systems outside his administrative domain; his primary concern is accounting to the level of other ADJACENT (directly connected) administrative domains. Consider the viewpoint of the administrator for domain X of the internet. The idea is that he will send each adjacent administrative domain a bill (or other statement of accounting) for its use of his resources and it will send him a bill for his use of its resources. When he receives an aggregate bill from Network A, if he wishes to allocate the charges to end users or subsystems within his domain, it is HIS responsibility to collect accounting data about how they used the resources of Network A. If the "user" is in fact another administrative domain, B, (on whose behalf X was using A's resources) the administrator for X just sends his counterpart in B a bill for the part of X's bill attributable to B's usage. If B was passing traffic for C, them B bills C for the appropriate portion X's charges, and so on, until the charges percolate back to the original end user, say G. Thus, the administrator for X does not have to account for G's usage; he only has to account for the usage of the administrative domains directly adjacent to himself.
通常、ネットワーク管理者は彼の管理ドメインの外のエンドシステムのための会計に興味を持っていません。 彼の第一の関心は他のADJACENT(直接接続される)の管理ドメインのレベルについて報告しています。 インターネットのドメインXと管理者の観点を考えてください。 考えは彼が彼のリソースの使用のための請求書(または、会計の他の計算書)をそれぞれの隣接している管理ドメインに送るということです、そして、それは彼のリソースの使用のための請求書を彼に送るでしょう。 彼がNetwork Aから集合請求書を受け取るとき、彼が彼のドメインの中にエンドユーザかサブシステムに料金を割り当てたいなら、事実上、それらがどう「ユーザ」のNetwork A.Ifに関するリソースを使用したかに関する会計データを集めるHIS責任は別の管理ドメインです、Bことである、Xのための(だれの代理XがAのリソースを使用していたかときの)管理者はただXのビーズ用法に起因する請求書の部分のための請求書をBの彼の対応者に送ります。 Xのための管理者がBがC交通であり、それらが適切な部分Xの料金のためのB請求書Cであるので料金がオリジナルのエンドユーザにこして戻られるまでの言いたい事G.ThusでGの用法を説明する必要はないなら。 彼は直接自分に隣接して管理ドメインの用法を説明するだけでよいです。
This paradigm of recursive accounting may, of course, be used WITHIN an administrative domain that is (logically) comprised of sub- administrative domains.
再帰的な会計のこのパラダイムがそうするかもしれない、もちろん、中古のWITHINがサブ管理のドメインから(論理的に)成る管理ドメインであったなら。
The discussion of the preceding paragraphs applies to a general mesh topology, in which any Internet constituent domain may act as a service provider for any connected domain. Although the Internet topology is in fact such a mesh, there is a general hierarchy to its structure and hierarchical routing (when implemented) will make it logically hierarchical as far as traffic flow is concerned. This logical hierarchy permits a simplification of the usage accounting perspective.
先行のパラグラフの議論は一般的なメッシュトポロジーに適用されます。そこでは、どんなインターネットの構成しているドメインもどんな接続ドメインへのサービスプロバイダーとしても務めます。 事実上、インターネットトポロジーはそのようなメッシュですが、構造への一般的な階層構造があります、そして、階層型ルーティング(実行されると)で、交通の流れに関する限り、それは論理的に階層的になるでしょう。 この論理的な階層構造は用法会計見解の簡素化を可能にします。
At the bottom of the service hierarchy a service-consuming host sits on one of many "stub" networks. These are interconnected into an enterprise-wide extended LAN, which in turn receives Internet service, typically from a single attachment to a regional backbone. Regional backbones receive national transport services from national backbones such as NSFnet, Alternet, PSInet, CERFnet, NSInet, or Nordunet. In this scheme each level in the hierarchy has a constituency, a group for which usage reporting is germane, in the level underneath it. In the case of the NSFnet the natural constituency, for accounting purposes at least, is the regional nets (MIDnet, SURAnet,...). For the regionals it will be their member institutions; for the institutions, their stub networks; and for the stubs, their individual hosts.
サービス階層構造の下部では、サービスを消費するホストが多くの「スタッブ」ネットワークの1つに座ります。 これらは企業全体の拡張LANとインタコネクトされます、通常地方の背骨へのただ一つの付属から。(インターネットのサービスは順番に、LANのために受信されます)。 地方の背骨はNSFnet、Alternet、PSInet、CERFnet、NSInet、またはNordunetなどの国家の背骨から国家の輸送サービスを受けます。 この計画には、階層構造の各レベルでは、選挙民がいます、用法報告が適切であるグループ、それの下のレベルで。 NSFnetの場合では、少なくとも会計目的のために、自然な選挙民は地方のネット(MIDnet、SURAnet)です。 地方版のために、それらのメンバー団体になるでしょう。 団体、それらのスタッブネットワークのために。 スタッブのための彼らの個々のホスト。
Mills, Hirsh, & Ruth [Page 7] RFC 1272 Internet Accounting: Background November 1991
工場、ハーシュ、およびルース[7ページ]RFC1272インターネット会計: バックグラウンド1991年11月
3.3.2. Implications of the Model
3.3.2. モデルの含意
The significance of the model sketched above is that Internet accounting must be able to support accounting for adjacent (intermediate) systems, as well as end-system accounting. Adjacent system accounting information cannot be derived from end-system accounting (even if complete end-system accounting were feasible) because traffic from an end-system may reach the administrative domain of interest through different adjacent domains, and it is the adjacent domain through which it passes that is of interest.
上にスケッチされたモデルの意味はインターネット会計が、隣接している(中間的)システムの原因になるのを支持できなければならないということです、エンドシステム会計と同様に。 エンドシステムからの交通が異なった隣接しているドメインを通して興味がある管理ドメインに達するかもしれないので、エンドシステム会計(完全なエンドシステム会計が可能であったとしても)から隣接しているシステム課金情報を得ることができません、そして、興味があるのは、それが通る隣接しているドメインです。
The need to support accounting for adjacent intermediate systems means that internet accounting will require information not present in internet protocol headers (these headers contain source and destination addresses of end-systems only). This information may come from lower layer protocols (network or link layer) or from configuration information for boundary components (e.g., "what system is connected to port 5 of this IP router").
隣接している中間システムの原因になるのを支持する必要性は、インターネット会計がインターネットプロトコルヘッダーの現在でない情報を必要とすることを意味します(これらのヘッダーはエンドシステムだけのソースと送付先アドレスを含んでいます)。 この情報は下位層プロトコル(ネットワークかリンクレイヤ)か境界コンポーネントのための設定情報(例えば、「どんなシステムがこの5つのIPルータを移植するために接続される」)から来るかもしれません。
4. Meters
4. Meters
A METER is a process which examines a stream of packets on a communications medium or between a pair of media. The meter records aggregate counts of packets belonging to FLOWs between communicating entities (hosts/processes or aggregations of communicating hosts (domains)). The assignment of packets to flows may be done by executing a series of rules. Meters can reasonably be implemented in any of three environments -- dedicated monitors, in routers or in general-purpose systems.
METERはコミュニケーション媒体の上、または、1組のメディアの間のパケットの流れを調べる過程です。 メーター記録はパケットが実体(交信しているホスト(ドメイン)のホスト/過程か集合)を伝えることの間のFLOWsに属すカウントに集められます。 一連の規則を実行することによって、流れへのパケットの課題をするかもしれません。 一般に、Metersは、3つの環境のどれか--モニターを捧げるルータで合理的に実行されるか、またはシステムを目標とすることができます。
Meter location is a critical decision in internet accounting. An important criterion for selecting meter location is cost, i.e., REDUCING ACCOUNTING OVERHEAD and MINIMIZING THE COST OF IMPLEMENTATION.
メーター位置はインターネット会計で重大な決定です。 メーター位置を選択するための重要な評価基準は、費用と、すなわち、REDUCING ACCOUNTING OVERHEADとMINIMIZING THE COST OF IMPLEMENTATIONです。
In the trade-off between overhead (cost of accounting) and detail, ACCURACY and RELIABILITY play a decisive role. Full accuracy and reliability for accounting purposes require that EVERY packet must be examined. However, if the requirement for accuracy and reliability is relaxed, statistical sampling may be more practical and sufficiently accurate, and DETAILED ACCOUNTING is not required at all. Accuracy and reliability requirements may be less stringent when the purpose of usage-reporting is solely to understand network behavior, for network design and performance tuning, or when usage reporting is used to approximate cost allocations to users as a percentage of total fees.
オーバーヘッド(会計の費用)と詳細の間のトレードオフでは、ACCURACYとRELIABILITYは決定的な役割を果たします。 会計目的のための完全な精度と信頼性は、EVERYパケットを調べなければならないのを必要とします。 しかしながら、精度と信頼性のための要件が弛緩するなら、統計調査は、より実用的であって、十分正確であるかもしれません、そして、DETAILED ACCOUNTINGは全く必要ではありません。 用法で報告する目的が唯一ネットワークデザインと性能調律のためのネットワークの振舞いかそれとも用法報告がいつ総料金の割合として費用配分にユーザに近似するのに使用されるかを理解することであるときに、精度と信頼度要求事項はそれほど厳しくないかもしれません。
Overhead costs are minimized by accounting at the coarsest acceptable
間接費は許容できる最も粗いところの会計で最小にされます。
Mills, Hirsh, & Ruth [Page 8] RFC 1272 Internet Accounting: Background November 1991
工場、ハーシュ、およびルース[8ページ]RFC1272インターネット会計: バックグラウンド1991年11月
GRANULARITY, i.e., using the greatest amount of AGGREGATION possible to limit the number of accounting records generated, their size, and the frequency with which they are transmitted across the network or otherwise stored.
GRANULARITY、すなわち、制限するのにおいて可能なAGGREGATIONの最大級の量を使用する、会計帳簿の数が発生させたそれらのサイズ、およびそれらがネットワークの向こう側に伝えられるか、または別の方法で格納される頻度。
The other cost factor lies in implementation. Implementation will necessitate the development and introduction of hardware and software components into the internet. It is important to design an architecture that tends to minimize the cost of these new components.
実現にはもう片方のコスト要因があります。 実現はハードウェアとソフトウェアコンポーネントの開発と導入をインターネットに必要とするでしょう。 これらの新しいコンポーネントの費用を最小にする傾向がある構造を設計するのは重要です。
4.1. Meter Placement
4.1. メータープレースメント
In the model developed above, the Internet may be viewed as a hierarchical system of service providers and their corresponding constituencies. In this scheme the service provider accounts for the activity of the constituents or service consumers. Meters should be placed to allow for optimal data collection for the relevant constituency and technology. Meters are most needed at administrative boundaries and data collected such that service provider and consumer are able to reconcile their activities.
上で開発されたモデルでは、インターネットはサービスプロバイダーと彼らの対応する選挙民の階級制度として見なされるかもしれません。 この計画では、サービスプロバイダーは成分かサービス消費者の活動を説明します。 Metersは、関連選挙民と技術に関して最適のデータ収集を考慮するために置かれるべきです。 サービスプロバイダーと消費者が彼らの活動を和解させることができるように集められた管理境界とデータでメーターが最も必要です。
Routers (and/or bridges) are by definition and design placed (topologically) at these boundaries and so it follows that the most generally convenient place to position accounting meters is in or near the router. But again this depends on the underlying transport. Whenever the service-providing network is broadcast (e.g., bus- based), not extended (i.e., without bridging or routing), then meter placement is of no particular consequence. If one were generating usage reports for a stub LAN, meters could reasonably be placed in a router, a dedicated monitor, or a host at any point on the LAN. Where an enterprise-wide network is a LAN, the same observation holds. At the boundary between an enterprise and a regional network, however, in or near a router is an appropriate location for meters that will measure the enterprise's network activity.
ルータ(そして/または、橋)が定義上であるこれらに置かれた(位相的である)境界を設計するので、ルータかほぼルータには会計メーターを置くその最も一般に便利な場所があるということになります。 しかし、一方、これは基本的な輸送によります。 そして、サービスを提供するネットワークが広がっているのではなく(すなわち、橋を架けるのもルーティングなしで)、放送される(例えば、ベースのバス)ときはいつも、メータープレースメントはどんな特定の結果のものではありません。 1つがスタッブLANのための用法レポートを作っているなら、LANの任意な点に合理的にルータ、ひたむきなモニター、またはホストにメーターを置くことができるでしょうに。 企業全体のネットワークがLANであるところでは、同じ観測は成立します。 ルータ企業と地域ネットワーク、しかしながら、またはルータにおける境界に、企業のネットワーク活動を測定する何メーターも適切な位置があります。
Meters are placed in (or near) routers to count packets at the Internet Protocol Level. All traffic flows through two natural metering points: hosts and routers (Internet packet switches). Hosts are the ultimate source and sink of all traffic. Routers monitor all traffic which passes IN or OUT of each network. Motivations for selecting the routers as the metering points are:
メーターはインターネットプロトコルLevelでパケットを数える置かれたコネの、そして、(近い)のルータです。 すべての交通が自然な2計量ポイントを通して流れます: ホストとルータ(インターネットパケット交換機)。 ホストは究極の源であり、すべての流し台は交通です。 ルータはそれぞれのネットワークのINかOUTを渡すすべての交通をモニターします。 計量が指すのでルータを選択することに関する動機は以下の通りです。
o Minimization of cost and overhead.
(by concentrating the accounting function). Centralize
and minimize in terms of number of geographical or
administrative regions, number of protocols monitored,
and number of separate implementations modified. (Hosts
are too diverse and numerous for easy standardization.
o 費用極小化とオーバーヘッド。 (会計機能を集結するのによる。) 地理的であるか管理の領域の数、モニターされたプロトコルの数、および変更された別々の実現の数に関して集結して、最小にします。 (簡単な標準化に、ホストは、多様過ぎて、非常に多いです。
Mills, Hirsh, & Ruth [Page 9] RFC 1272 Internet Accounting: Background November 1991
工場、ハーシュ、およびルース[9ページ]RFC1272インターネット会計: バックグラウンド1991年11月
Routers concentrate traffic and are more homogeneous.)
ルータは、交通を集結して、より均質です。)
o Traffic control.
When and if usage sensitive quotas are involved, changes
in meter status (e.g., exceeding a quota) would result in
an active influence on network traffic (the router starts
denying access). A passive measuring device cannot
control network access in response to detecting state.
o トラフィックコントロール。 用法の機密の割当てがメーター状態(例えば、割当てを超えている)でいつ変化するか、そして、かかわって、変化するかどうかがネットワークトラフィックへの活発な影響をもたらすでしょう(ルータはアクセスを拒絶し始めます)。 状態を検出することに対応して受け身の測定装置はネットワークアクセスを制御できません。
o Intermediate system accounting.
As discussed above, internet accounting includes both
end-system and intermediate system accounting. Hosts see
only end-system traffic; routers see both the end-systems
(internet source and destination) and the adjacent
intermediate systems.
o 中間システム会計。 上で議論するように、インターネット会計はエンドシステムと中間システム会計の両方を含んでいます。 ホストはエンドシステム交通だけを見ます。 ルータはエンドシステム(インターネットソースと目的地)と隣接している中間システムの両方を見ます。
Therefore, meters should be placed at:
したがって、メーターは以下に置かれるべきです。
o administrative boundaries
only for measuring inter-domain traffic;
o 測定相互ドメイン交通だけへの管理境界。
o stub networks
for measuring intra-domain traffic. For intra-domain
traffic, the requirement for performing accounting at
almost every router is a disincentive for implementing a
usage-based charging policy.
o 測定イントラドメイン交通にネットワークを引き抜いてください。 イントラドメイン交通に、ほとんどあらゆるルータで会計を実行するための要件は、用法ベースの充電政策を実施するための行動を妨げるものです。
4.2. Meter Types
4.2. メータータイプ
Four possible types of metering technology are:
計量技術の4つの可能なタイプは以下の通りです。
o Network monitors:
These measure only traffic WITHIN a single network. They
include LAN monitors, X.25 call accounting systems and
traffic monitors in bridges.
o モニターをネットワークでつないでください: これらは交通のWITHINのaただ一つのネットワークだけを測定します。 彼らは橋にLANモニター、X.25コールアカウンティングシステム、および交通モニターを含んでいます。
o Line monitors:
These count packets flowing across a circuit. They would
be placed on inter-router trunks and on router ports.
o モニターを裏打ちしてください: これらはサーキットの向こう側に流れるパケットを数えます。 それらは相互ルータトランクスと、そして、ルータポートに置かれるでしょう。
o Router-integral meters:
These are meters located within a router, implemented in
software. They count packets flowing through the router.
o ルータ不可欠のメーター: これらはソフトウェアで実行されたルータの中に位置したメーターです。 彼らはルータを通して流れるパケットを数えます。
o Router spiders:
This is a set of line monitors that surround a router,
measure traffic on all of its ports and coordinate the
results.
o ルータクモ: これはルータを囲んでいて、ポートのすべてにおける交通を測定して、結果を調整する1セットの線モニターです。
Mills, Hirsh, & Ruth [Page 10] RFC 1272 Internet Accounting: Background November 1991
工場、ハーシュ、およびルース[10ページ]RFC1272インターネット会計: バックグラウンド1991年11月
4.3. Meter Structure
4.3. メーター構造
While topology argues in favor of meters in routers, granularity and security favor dedicated monitors. The GRANULARITY of the accountable entity (and its attributes) affects the amount of overhead incurred for accounting. Each entity/attribute/reporting interval combination is a separate meter. Each individual meter takes up local memory and requires additional memory or network resources when the meter reports to the application. Memory is a limited resource, and there are cost implications to expanding memory significantly or increasing the frequency of reporting. The number of concurrent flows open in a router is controlled by
トポロジーはルータがメーターを支持して論争しましたが、粒状とセキュリティ好意はモニターを捧げました。 責任がある実体(そして、属性)のGRANULARITYは会計で被られたオーバーヘッドの量に影響します。 それぞれの実体/属性/報告間隔組み合わせは別々のメーターです。 メーターがアプリケーションに報告するとき、それぞれの個々のメーターは、ローカルの記憶を始めて、追加メモリかネットワーク資源を必要とします。 メモリは限られたリソースです、そして、メモリをかなり広げるか、または報告の頻度を増加させることへの費用含意があります。 ルータにおける戸外が制御される同時発生の流れの数
o the granularity of the accountable entity
o 責任がある実体の粒状
o the granularity of the attributes and sub-categories of
packets
o 属性の粒状とパケットのサブカテゴリ
o memory
(the number of flows that can be stored concurrently, a
limit which can also be expressed as the average number
of flows existing at this granularity plus some delta,
e.g., peak hour average plus one standard deviation, or
...)
o メモリ(同時に格納できる流れの数かまた、この粒状とあるデルタに存在する流れの平均した数として言い表すことができる限界か例えば、ピーク時平均と1つの標準偏差か、…)
o the reporting interval
(the lifetime of an individual meter)
o 報告間隔(個々のメーターの生涯)
There is a spectrum of granularity control which ranges across the following dimensions. (Most administrations will probably choose a granularity somewhere in the middle of the spectrum.)
以下の寸法の向こう側に及ぶ粒状コントロールのスペクトルがあります。 (ほとんどの政権がたぶんスペクトルの中央のどこかで粒状を選ぶでしょう。)
ENTITY: Entities range across the spectrum from the coarsest granularity, PORT (a local view with a unique designation for the subscriber port through which packets enter and exit "my" network) through NETWORK and HOST to USER (not defined here). The port is the minimum granularity of accounting. HOST is the finest granularity defined here. Where verification is required, a network should be able to perform accounting at the granularity its subscribers use. Hosts are ultimately responsible for identifying the end user, since only the hosts have unambiguous access to user identification. This information could be shared with the network, but it is the host's responsibility to do so, and there is no mechanism in place at this time (e.g., an IP option, discussed in section 4.).
実体: 実体はスペクトルの向こう側に最も粗い粒状、PORT(パケットが「my」のネットワークに入って、出る加入者ポートのためのユニークな名称があるローカルの視点)からNETWORKとHOSTまでUSER(ここで、定義されない)に及びます。 ポートは会計の最小の粒状です。 HOSTはここで定義された中で最もすばらしい粒状です。 検証が必要であるところでは、ネットワークは加入者が使用する粒状で会計を実行できるべきです。 ホストは結局、ホストだけが明白なアクセスをユーザ登録名に持っているのでエンドユーザを特定するのに責任があります。 この情報をネットワークと共有できましたが、そうするのが、ホストの責任であり、メカニズムが全くこのとき(例えばセクション4で議論したIPオプション)、適所にありません。
ATTRIBUTE: Each new attribute requires that an additional flow be maintained for each entity. The coarsest granularity is NO
以下を結果と考えてください。 それぞれの新しい属性は、追加流れが各実体のために維持されるのを必要とします。 最も粗い粒状はノーです。
Mills, Hirsh, & Ruth [Page 11] RFC 1272 Internet Accounting: Background November 1991
工場、ハーシュ、およびルース[11ページ]RFC1272インターネット会計: バックグラウンド1991年11月
categorization of packets. The finest granularity would be to maintain state information about the higher-levels protocols or type of service being used by communicating processes across the network.
パケットの分類。 最もすばらしい粒状はネットワークの向こう側に過程を伝えることによって使用されることでサービスの、より高いレベルプロトコルかタイプの州の情報を保守するだろうことです。
VALUES: Values are the information which is recorded for each entity/attribute grouping. Usually values are counters, such as packet counts and byte counts. They may also be time stamps - start time and stop time, or reasons for starting or stopping reporting.
値: 値はそれぞれの実体/属性組分けのために記録される情報です。 通常、値はパケットカウントやバイト・カウントなどのカウンタです。 また、それらはタイムスタンプであるかもしれません--開始時刻と停止時間か、始まる理由か停止報告。
REPORTING INTERVAL: At the very finest level of granularity, each data packet might generate a separate accounting record. To report traffic at this level of detail would require approximately one packet of accounting information for every data packet sent. The reporting interval is then zero and no memory will be needed for flow record storage. For a non-zero reporting interval flow records must be maintained in memory. Storage for stale (old, infrequent) flows may be recycled when their data has been reported. As the reporting interval increases, more and more stale records accumulate.
間隔を報告します: 非常に最もすばらしいレベルの粒状では、各データ・パケットは別々の会計帳簿を生成するかもしれません。 このレベルの詳細におけるトラフィックがあらゆるデータ・パケットのために課金情報のおよそ1つのパケットを必要とすると報告するのが発信しました。 次に、報告間隔はゼロです、そして、メモリは全く流れ記録ストレージに必要でないでしょう。 非ゼロ報告間隔の間、メモリで流れ記録を保守しなければなりません。 それらのデータが報告されたとき、聞き古した(古くて、珍しい)流れのためのストレージは再生されるかもしれません。 報告間隔が増加するのに従って、ますます聞き古した記録は蓄積します。
The feasibility of a particular group of granularities varies with the PERFORMANCE characteristics of the network (link speed, link bandwidth, router processing speed, router memory), as well as the COST of accounting balanced against the requirement for DETAIL. Since technological advances can quickly obsolete current technical limitations, and since the policy structure and economics of the Internet are in flux, meters will be defined with VARYING GRANULARITY which is regulated according to the traffic requirements of the individual network or administration and technical limitations.
ネットワークのパフォーマンスの特性に従って、粒状の特定のグループに関する実現の可能性は異なります(リンク速度、リンク帯域幅、ルータ処理が疾走します、ルータメモリ)、DETAILのための要件に対してバランスをとる会計のCOSTと同様に。 技術的進歩がすぐに現在の技術的な制限を時代遅れにできて、インターネットの方針構造と経済学が流動的であるので、メーターは個々のネットワークか管理のトラフィック要件に従って規制されるVARYING GRANULARITYと技術的な制限で定義されるでしょう。
4.4. Collection Issues
4.4. 収集問題
There are two implicit assumptions about the nature of meters and traffic sources that they measure, both of which have substantial bearing on collectors.
彼らが測定するメーターとトラフィックソースの本質に関する2つの暗黙の仮定があります。その両方がかなりの関係をコレクタに持っています。
1. The matrix of communicating entity pairs is large but
sparse and, moreover, network traffic exhibits considerable
source, destination and attribute coherence - so that lists
can be quite compact.
1. 交信している実体組のマトリクスは、大きいのですが、まばらです、そして、そのうえ、ネットワークトラフィックはリストがかなりコンパクトになるように、かなりのソース、目的地、および属性一貫性を示します。
2. Meters can be configured to generate either a static set
of variables whose values are incremented, or a stream of
records that must be periodically transferred and removed
from the meter's memory.
2. 値が増加されている静的なセットの変数か計器メモリから定期的に移されて、取り除かなければならない記録のストリームのどちらかを生成するためにMetersを構成できます。
Mills, Hirsh, & Ruth [Page 12] RFC 1272 Internet Accounting: Background November 1991
工場、ハーシュ、およびルース[12ページ]RFC1272インターネット会計: バックグラウンド1991年11月
Meters can generate large, unstructured amounts of information and the essential collection issue revolves around mapping collection activities into an SNMP framework (or, to the extent that this is not successful, specifying other collection paradigms).
Metersは大きくて、不統一な量の情報を生成することができます、そして、不可欠の収集問題は、SNMPフレームワークに徴収活動を写像しながら(他の収集パラダイムをこれがうまくいっていないという範囲まで指定して)、周囲を回ります。
There are three major collection concerns:
3回の主要な収集関心があります:
o data confidentiality
o データの機密性
o data integrity
o データ保全
o local and remote collection control
o 地方の、そして、リモートな収集コントロール
The prime security concern is preserving the confidentiality of usage data. (See ISO 7498 Part 2, "Security Architecture," for security terminology used herein.) Given that accounting data are sensitive, the collector should be able (or may be required) to provide confidentiality for accounting data at the point of collection, through transmission and up to the point where the data is delivered. The delivery function may also require authentication of the origin and destination and provision for connection integrity (if connections are utilized). Other security services (e.g., measures to counter denial of service attacks) are not deemed necessary for internet accounting at this time. It is assumed that security services can be provided by SNMP and its mechanisms. (This will require further investigation.)
主要なセキュリティ関心は用法データの秘密性を保存しています。 (ISO7498Part2、「セキュリティー体系」をここに使用されるセキュリティ用語に関して見てください。) 会計データが機密であるなら、コレクタは、会計データに秘密性を提供するためにポイントまで収集のポイントにおいてトランスミッションを通してデータが提供されるできるべきです(または、必要であるかもしれません)。 また、配送機能は接続保全への発生源、目的地、および支給の認証を必要とするかもしれません(接続が利用されているなら)。 他のセキュリティー・サービス(例えば、サービス不能攻撃に対抗する測定)はこのとき、インターネット会計に必要であると考えられません。 SNMPとそのメカニズムでセキュリティー・サービスを提供できると思われます。(これはさらなる調査を必要とするでしょう。)
In order to have an accurate monitoring system, reliable delivery of data should be assured through one or more of:
正確な監視システムを持つために、データの信頼できる配信は1つか、より多くを保証されるべきです:
o an acknowledgement retransmission scheme;
o 承認「再-トランスミッション」体系。
o redundant reporting to multiple collectors;
o 複数のコレクタへの余分な報告。
o having backup storage located at the meter.
o バックアップ記憶装置を持っているのはメーターで場所を見つけられました。
There is a place for both application polling and meter traps within this scheme, but there are significant trade-offs associated with each.
この体系の中にアプリケーション世論調査とメーター罠の両方のための場所がありますが、それぞれに関連している重要なトレードオフがあります。
Polling means that the collection point has some control over when accounting data is sent, so that not all meters flood the collector at once. However, polling messages, particularly when structured with SNMP's GET-NEXT operator, add considerable overhead to the network. Meter traps are required in any case (whether or not polling is the preferred collection method), so that a meter may rid itself of data when its cache is full.
世論調査は、会計データを送るとき、収集ポイントが何らかのコントロールを家に迎えることを意味します、すべてのメーターがすぐにコレクタをあふれさせるというわけではないように。 しかしながら、特にSNMPのGET-ネクストオペレータと共に構造化されると、世論調査メッセージはかなりのオーバーヘッドをネットワークに追加します。 どのような場合でも、メーター罠が必要です(世論調査が都合のよい収集方法であるか否かに関係なく)、キャッシュが完全であるときに、1メーターがそれ自体からデータを取り除くことができるように。
Mills, Hirsh, & Ruth [Page 13] RFC 1272 Internet Accounting: Background November 1991
工場、ハーシュ、およびルース[13ページ]RFC1272インターネット会計: バックグラウンド1991年11月
The fundamental collection trade-off will be between primary and secondary storage at the meter, coupled with an efficient bulk- transfer protocol, versus minimal storage at the meter and a network-bandwidth-consuming collection discipline.
最小量のストレージに対してメーターとネットワーク帯域幅消費収集規律には基本的な収集トレードオフが効率的な大量転送プロトコルに結びつけられたメーターに予備選挙と補助記憶装置の間にあるでしょう。
A final collection concern is whether packets should be counted on entry into a router or upon exit from a router. It is the nature of IP that not every packet received by a router is actually passed to an output port. The Internet Protocol allows routers to discard packets (e.g., in times of congestion when the router cannot handle the offered load); it is presumed that higher level protocols (e.g., TCP) will provide whatever reliable delivery service the user deems necessary (by detecting non- delivery and retransmitting).
最終的な収集関心はルータからのパケットがエントリーのときに数えられるべきであるかどうかというルータか出口のことです。 あらゆるパケットがどんなルータで受けたというわけではないIPの自然が実際に出力ポートに向かうということです。 インターネットプロトコルで、ルータはパケット(例えば、ルータが提供された負荷を扱うことができない混雑の時代による)を捨てることができます。 より高い平らなプロトコル(例えば、TCP)がユーザが必要であると(非配送を検出して、再送するのによる)考えるどんな信頼できる配信サービスも提供すると推定されます。
The question arises, therefore, whether an internet accounting system should count all packets offered to a router (since each packet offered consumes some router resources) or just those that are finally passed by the router to a network (why should a user pay for undelivered packets?) Since there are good arguments for either position, we do not attempt to resolve this issue here. (It should be noted, however, that SMDS has chosen to count on exit only.) Rather, we require that an internet accounting should provide ability for counting packets either way -- on entry to or on exit from a router.
したがって、インターネット会計システムがすべてのルータ(提供された各パケットがいくつかのルータリソースを消費するので)に提供されたパケットかまさしくルータによって最終的にネットワークに通過されるものを数えるはずであるか否かに関係なく、質問が起こる、(なぜ、非提供されたパケットのためのユーザ賃金)であるべきです? 位置に、良い議論があるので、私たちは、ここでこの問題を解決するのを試みません。 (しかしながら、SMDSが、出口だけを頼りにするのを選んだことに注意されるべきです。) むしろ、私たちは、インターネット会計がエントリーのときに出口か出口の上でルータからパケットをいずれにせよ数えるのに能力を提供するべきであるのを必要とします。
5. Examples
5. 例
Here follows a series of examples to illustrate what data may be of interest to service providers and consumers in a number of different scenarios. In the illustrations that follow straight lines are interpreted as some sort of LAN. Diagonals are point- to-point links. Diamonds are routers. We assume that we are in a homogeneous protocol environment (IP).
ここで、多くの異なったシナリオでサービスプロバイダーと消費者にとって、どんなデータが興味深いかもしれないかを例証する一連の例が従います。 従うイラストでは、直線はある種のLANとして解釈されます。 対角線はある程度ポイントリンクです。 MR.ダイヤモンドはルータです。 私たちは、均質のプロトコル環境(IP)にはいると思います。
5.1 A Single Segment LAN
5.1 ただ一つのセグメントLAN
Consumers and providers on a single LAN service can utilize the same set of data: the contribution of individual hosts to total network load. A network accounting system measures flows between individual host pairs. (On a broadcast LAN, e.g., an Ethernet, this can be accomplished by a single meter placed anywhere on the LAN.) Using this data, costs for the network management activity can be apportioned to individual hosts or the departments that own/manage the hosts.
単一のLANサービスでの消費者とプロバイダーは同じセットのデータを利用できます: ネットワーク負荷を合計する個々のホストの貢献。 システム測定を説明するネットワークは個々のホスト組の間を流れます。 (放送LAN、例えば、イーサネットでは、LANでどこでも置かれた1個のメーターでこれを達成できます。) このデータを使用して、ホストを所有しているか、または管理する個々のホストか部にネットワークマネージメント活動のためのコストを分配できます。
Alternately, flows can be kept by source only, rather than source- destination pairs.
交互に、ソース目的地組より単に、そして、むしろソースは流れを保つことができます。
Mills, Hirsh, & Ruth [Page 14] RFC 1272 Internet Accounting: Background November 1991
工場、ハーシュ、およびルース[14ページ]RFC1272インターネット会計: バックグラウンド1991年11月
5.2 An Extended (Campus or Facility-Wide) LAN
5.2 拡張している(キャンパスの、または、施設全体の)LAN
128.252.100.X 128.252.150.X 128.253.220.X
+----------------+ +----------------+ +----------------+
| | |
| | |
/ \ / \ / \
128.252.100.10 128.252.150.10 128.253.220.10
\ / \ / \ /
| | |
+--+-+----------------------+-+----------------------+-+-+
| | |
/ \ / \ / \
128.252.130.10 128.252.120.10 128.253.140.10
\ / \ / \ /
| | |
| | |
+-----------------+ +-----------------+ +----------------+
128.252.130.X 128.252.120.X 128.253.140.X
128.252.100. X128.252.150.X 128.253.220.X+----------------+ +----------------+ +----------------+ | | | | | | / \ / \ / \ 128.252.100.10 128.252.150.10 128.253.220.10 \ / \ / \ / | | | +--+-+----------------------+-+----------------------+-+-+ | | | / \ / \ / \ 128.252.130.10 128.252.120.10 128.253.140.10 \ / \ / \ / | | | | | | +-----------------+ +-----------------+ +----------------+ 128.252.130.X 128.252.120.X 128.253.140.X
This is the first example in which the information that is germane for service provider and consumer are not identical. The service consumers are now the individual subnets and the service provider is the facility-wide backbone. A service provider is interested in knowing the contribution of individual subnets to the total traffic of the backbone. In order to ascertain this, a meter on the backbone (the longest line in the center of the illustration) can keep track of flows between subnet pairs. Now the communications between individual hosts on adjacent subnets are aggregated into a single flow that measures activity between subnets.
これはサービスプロバイダーと消費者にとって、適切な情報がどれでないかで同じでない最初の例です。 現在サービス消費者は個々のサブネットです、そして、サービスプロバイダーは施設全体のバックボーンです。 サービスプロバイダーはバックボーンの総トラフィックへの個々のサブネットの貢献を知りたがっています。 これを確かめるために、(イラストのセンターで最も長い系列)が動向をおさえることができるバックボーンの1個のメーターはサブネット組の間を流れます。 現在、隣接しているサブネットの個々のホストのコミュニケーションはサブネットの間の活動を測定するただ一つの流れに集められます。
The service consumers, or subnets, might in turn want to keep track of the communications between individual hosts that use the services of the backbone. An accounting system on the backbone could be configured to monitor traffic among individual host pairs. Alternately an accounting system on each individual subnet could keep track of local and "non-local" traffic. The observed data of the two sets of meters (one for the service provider and one for the service consumers) should have reconcilable data.
サービス消費者、またはサブネットが順番にバックボーンのサービスを利用する個々のホストのコミュニケーションの動向をおさえたがっているかもしれません。 個々のホスト組でトラフィックをモニターするためにバックボーンの会計システムを構成できました。 交互に、それぞれの個々のサブネットの会計システムは地方の、そして、「非地方」のトラフィックの動向をおさえるかもしれません。 2セットのメーター(サービスプロバイダーのためのものとサービス消費者のためのもの)に関する測定値には、和解可能なデータがあるべきです。
Mills, Hirsh, & Ruth [Page 15] RFC 1272 Internet Accounting: Background November 1991
工場、ハーシュ、およびルース[15ページ]RFC1272インターネット会計: バックグラウンド1991年11月
5.3 A Regional Network
5.3 地域ネットワーク
116.125
+-----------------+
|
+
/ \
116.125.10.10
\ /
/ + \
/ \
/ \
/ \
| + + |
| / \ / \ |
128.242 |----- 128.242.10.10 128.252.10.10 -----| 128.252
| \ / \ / |
| + + |
\ /
\ /
\ /
\ + /
/ \
124.110.10.10
\ /
+
+-----------------+
|
124.110
116.125 +-----------------+ | + / \ 116.125.10.10 \ / / + \ / \ / \ / \ | + + | | / \ / \ | 128.242 |----- 128.242.10.10 128.252.10.10 -----| 128.252 | \ / \ / | | + + | \ / \ / \ / \ + / / \ 124.110.10.10 \ / + +-----------------+ | 124.110
In this example we have a regional network consisting of a ring of point-to-point links that interconnect a collection of campus-wide LANs. Again service provider and consumer have differing interests and needs for accounting data. The service provider, the regional network, again will be interested in the contribution of each individual network to the total traffic on the regional network. This interest might extend to include measure of individual link utilization, and not just total offered load to the network as a whole. In this latter case the service provider will require that meters be placed at one end or the other on each link. For the service consumer, the individual campus, relevant measures would include the contribution of individual subnets or hosts to the total "outbound" traffic. Meter(s) placed in (or at) the router that connects the campus- network to the regional network can perform the necessary measurement.
この例では、私たちはキャンパス全体のLANの収集とインタコネクトするポイントツーポイント接続のリングから成る地域ネットワークを持っています。 一方、サービスプロバイダーと消費者には、会計データの異なった関心と必要性があります。 サービスプロバイダー(地域ネットワーク)は再び地域ネットワークの総トラフィックへのそれぞれの個々のネットワークの貢献に興味を持つでしょう。 この関心は、総提供された負荷だけではなく、個々のリンク利用の手段を全体でネットワークに含めるために広がるかもしれません。 この後者の場合では、サービスプロバイダーは、メーターが各リンクに片端かもう片方に置かれるのを必要とするでしょう。 サービス消費者、個々のキャンパスに関しては、関連測定は総「外国行き」のトラフィックに個々のサブネットかホストの貢献を含んでいるでしょう。 メーターはキャンパスネットワークを地域ネットワークに接続するルータを(or at)に置きました。必要な測定を実行できます。
Mills, Hirsh, & Ruth [Page 16] RFC 1272 Internet Accounting: Background November 1991
工場、ハーシュ、およびルース[16ページ]RFC1272インターネット会計: バックグラウンド1991年11月
5.4 A National Backbone
5.4 国家のバックボーン
__________
|
+
| / \ |
|--+ 1 +--|
| \ / |
+
/ \
\ /
/ + \
/ \
_______ / \ _______
| / \ |
+ + + +
| / \ / \ / \ / \ |
|--+ 4 +----\ / 5 \ /-----+ 2 +-|
| \ / + + \ / |
+ \ / +
___|____ \ / ___|____
\ /
\ + /
/ \
\ /
+
| / \ |
|--+ 3 +--|
| \ / |
+
____|____
__________ | + | / \ | |--+ 1 +--| | \ / | + / \ \ / / + \ / \ _______ / \ _______ | / \ | + + + + | / \ / \ / \ / \ | |--+ 4 +----\ / 5 \ /-----+ 2 +-| | \ / + + \ / | + \ / + ___|____ \ / ___|____ \ / \ + / / \ \ / + | / \ | |--+ 3 +--| | \ / | + ____|____
In this last case, the data that the service provider will want to
collect is the traffic between regional networks. The flow that
measures a regional network, or regional network pairs, is defined as
the union of all member-campus network address spaces. This can be
arrived at by keeping multiple individual network address flows and
developing the regional network contribution as post-processing
activity, or by defining a flow that is the union of all the relevant
addresses. (This is a cpu cycles for memory trade-off.) Note that
if the service provider measures individual network contributions,
then this data is, in large
measure, the data that the service consumers would require.
この最後の場合では、サービスプロバイダーが集めたくなるデータは地域ネットワークの間のトラフィックです。 地域ネットワーク、または地域ネットワーク組を測定する流れはすべてのメンバーキャンパスネットワークアドレス空間の組合と定義されます。 これは後工程活動、またはすべての関連アドレスの組合である流れを定義することによって複数の個々のネットワーク・アドレスが流れであることを保つことによって到着して、地域ネットワーク貢献を開発するのをそうすることができます。 (これはメモリトレードオフのためのcpuサイクルです。) サービスプロバイダーが個々のネットワーク貢献を測定するならこのデータがよほどサービス消費者が必要とするデータであることに注意してください。
6. Future Issues
6. 将来の問題
This last section is the collector for ancillary issues that are as yet undefined or out of current scope.
この最後のセクションはまだ未定義の付属の問題か現在の範囲からのコレクタです。
Mills, Hirsh, & Ruth [Page 17] RFC 1272 Internet Accounting: Background November 1991
工場、ハーシュ、およびルース[17ページ]RFC1272インターネット会計: バックグラウンド1991年11月
APPLICATIONS standards: Recommendations for storage, processing and reporting are left out for the moment. Storage and processing of accounting information is dependent on individual network policy. Recommendations for standardizing billing schemes would be premature.
APPLICATIONS規格: ストレージ、処理、および報告のための推薦はさしあたり、省かれます。 課金情報のストレージと処理は独特のネットワーク方針に依存しています。 支払い体系を標準化するための推薦は時期尚早でしょう。
QUOTAS are a form of closed loop feedback that represent an interesting extension of usage reporting. But they will have to wait until the basic accounting technology is reasonably defined and has been the subject of a reasonable amount of experimentation.
QUOTASは用法報告のおもしろい拡大を表すクローズドループフィードバックのフォームです。 しかし、彼らは基本的な会計技術が合理的に定義されて、十分な量の実験の対象になるまで待たなければならないでしょう。
SESSION ACCOUNTING: Detailed auditing of individual sessions across the internet (at level four or higher) will not be addressed by internet accounting. Internet accounting deals only with measuring traffic at the IP level.
セッション会計: インターネット(レベルより多くのfourにおける)の向こう側の個々のセッションの詳細な監査はインターネット会計で扱われないでしょう。 インターネット会計はIPレベルで測定トラフィックだけに対処します。
APPLICATION LEVEL ACCOUNTING: Service hosts and proxy agents have to do their own accounting for services, since the network cannot distinguish on whose behalf they are acting. Alternately, TCP/UDP port numbers could become an optional field in a meter, since the conjunction of a pair of IP addresses and port numbers occurring at a particular time uniquely identifies a pair of communicating processes.
アプリケーションレベル会計: サービス・ホストとプロキシエージェントはサービスのためのそれら自身の会計をしなければなりません、それらがだれの代理を行動させているかに関してネットワークが区別されることができないので。 交互に、TCP/UDPポートナンバーは1メーターの任意の分野になることができました、特定の時に唯一起こる1組のIPアドレスとポートナンバーの接続詞が1組の交信プロセスを特定するので。
The USER has not yet been defined, since an IP option would have to be added to the IP header to provide for this. This option would probably contain two parts - a subscriber identification and a user sub-identification - to allow for the later introduction of quota mechanisms which have both group and individual quotas. The subscriber is the fiscally responsible entity, for example the manager of a research group. In any case, routers must be able to fall back to accounting by host, since there will most certainly be hosts on the network which do not implement a new IP option in a timely fashion.
USERはまだ定義されていません、IPオプションがこれに備えるためにIPヘッダーに加えられなければならないでしょう、したがって。 このオプションは、両方が分類される割当てメカニズムと個々の割当ての後の導入を考慮するために、たぶん、2つの部品(加入者識別とユーザサブ識別)を含んでいるでしょう。 加入者は会計上原因となる実体、例えば、研究グループのマネージャです。 どのような場合でも、ルータがホストによる会計へ後ろへ下がることができなければならない、どれがそうしないかはホストが最も確かにネットワークの一員であるので、直ちに新しいIPオプションを実装します。
7. References
7. 参照
International Standards Organization (ISO), "Management
Framework," Part 4 of Information Processing Systems Open Systems
Interconnection Basic Reference Model,ISO 7498-4, 1984.
世界規格組織(ISO)、「管理フレームワーク」、情報処理システム開放型システム間相互接続基本参照モデル、ISO7498-4、1984年の一部4。
International Standards Organization (ISO), "Security
Architecture," Part 2 of Information Processing Systems Open
Systems Interconnection Basic Reference Model,ISO 7498-2, 1984.
世界規格組織(ISO)、「セキュリティー体系」、情報処理システム開放型システム間相互接続基本参照モデル、ISO7498-2、1984年の第2部。
Mills, Hirsh, & Ruth [Page 18] RFC 1272 Internet Accounting: Background November 1991
工場、ハーシュ、およびルース[18ページ]RFC1272インターネット会計: バックグラウンド1991年11月
Security Considerations
セキュリティ問題
Security issues are discussed in sections 2, 3 and 4.
セクション2、3、および4で安全保障問題について議論します。
Authors' Addresses
作者のアドレス
Cyndi Mills Bolt, Beranek, and Newman 150 Cambridge Park Drive Cambridge, MA 02140
シンディはボルト、Beranek、およびニューマン150・ケンブリッジ公園Driveケンブリッジ、MA 02140を製粉します。
Phone: 617-873-4143 Email: cmills@bbn.com
以下に電話をしてください。 617-873-4143 メールしてください: cmills@bbn.com
Donald Hirsh Meridian Technology Corporation 11 McBride Corporate Center Drive Suite 250 Chesterfield, MO 63005
チェスターフィールド、ドナルドハーシュ子午線技術社11のマックブライドの法人のセンター・ドライブSuite250MO 63005
Phone: 314-532-7708 Email: hirsh@meridian.uucp
以下に電話をしてください。 314-532-7708 メールしてください: hirsh@meridian.uucp
Gregory Ruth Bolt, Beranek, and Newman 150 Cambridge Park Drive Cambridge, MA 02140
グレゴリールースBolt、Beranek、およびニューマン150・ケンブリッジ公園Driveケンブリッジ、MA 02140
Phone: 617-873-3150 Email: gruth@bbn.com
以下に電話をしてください。 617-873-3150 メールしてください: gruth@bbn.com
Mills, Hirsh, & Ruth [Page 19]
工場、ハーシュ、およびルース[19ページ]
一覧
スポンサーリンク
