RFC1672 日本語訳
1672 Accounting Requirements for IPng. N. Brownlee. August 1994. (Format: TXT=6185 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group N. Brownlee Request for Comments: 1672 The University of Auckland Category: Informational August 1994
コメントを求めるワーキンググループN.ブラウンリーの要求をネットワークでつないでください: 1672 オークランド大学カテゴリ: 情報の1994年8月
Accounting Requirements for IPng
IPngのための会計要件
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This document was submitted to the IETF IPng area in response to RFC 1550. Publication of this document does not imply acceptance by the IPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list.
RFC1550に対応してIETF IPng領域にこのドキュメントを提出しました。 このドキュメントの公表はどんな考えのIPng領域のそばでも中で言い表された状態で承認を含意しません。 big-internet@munnari.oz.au メーリングリストにコメントを提出するべきです。
Summary
概要
This white paper discusses accounting requirements for IPng. It recommends that all IPng packets carry accounting tags, which would vary in size. In the simplest case a tag would simply be a voucher identifying the party responsible for the packet. At other times tags should also carry other higher-level accounting information.
この白書は、IPngのための要件を説明するのを議論します。 それは、すべてのIPngパケットが会計タグを運ぶことを勧めます。(タグは大小の差があるでしょう)。 最も簡単な場合では、タグは単にパケットに責任があるパーティーを特定するバウチャーでしょう。 また、他の時に、タグは他の、よりハイレベルの課金情報を運ぶはずです。
Background
バックグラウンド
The Internet Accounting Model - described in RFC 1272 - specifies how accounting information is structured, and how it is collected for use by accounting aplications. The model is very general, with accounting variables being defined for various layers of a protocol stack. The group's work has so far concentrated on the lower layers, but the model can be extended simply by defining the variables required, e.g., for session and application layers.
インターネットAccounting Model(RFC1272では、説明される)は、課金情報がどのように構造化されるか、そして、それが会計aplicationsによる使用のためにどのように集められるかを指定します。 会計変数がプロトコル・スタックの様々な層のために定義されている状態で、モデルは非常に一般的です。 グループの仕事は今までのところ、下層で集中していた状態で広げましたが、単に例えば、セッションと応用層に必要である変数を定義することによって、モデルを広げることができます。
Brian Carpenter [1] suggests that IPng packets should carry authenticated (source, destination, transaction) triplets, which could be used for policy-based routing and accounting. The following sections explain how the transaction field - hereafter called an 'accounting tag' - could be used.
ブライアンCarpenter[1]は、IPngパケットが認証された(ソース、目的地、トランザクション)三つ子を運ぶはずであると示唆します。(方針ベースのルーティングと会計にその三つ子を使用できました)。 以下のセクションはどう、トランザクション分野(今後'会計タグ'と呼ばれる)を使用できたかを説明します。
Lower-layer (Transport) Accounting
下層(輸送)会計
At the lower (network) layers the tag would simply be a voucher. This means it is an arbitrary string which identifies the party
低級(ネットワーク)層では、タグは単にバウチャーでしょう。 これは、それがパーティーを特定する任意のストリングであることを意味します。
Brownlee [Page 1] RFC 1672 Accounting Requirements for IPng August 1994
1994年8月にIPngのための要件を説明するブラウンリー[1ページ]RFC1672
responsible, i.e., willing to pay for, a packet. It would initially be set by the host which originates the packet, hence at that stage the tag would identify the user who sent it.
責任がある、すなわち、考え代価を払っても構わないのをaパケット それは初めはホストによって設定されるでしょう、(パケットを溯源します)したがって、その段階では、タグはそれを送ったユーザを特定するでしょう。
A tag could be changed at various points along a packet's path. This could be done as part of the routing policy processing so as to reflect changes of the party responsible over each section of the path. For example:
パケットの経路に沿った様々なポイントでタグを変えることができました。 経路の各セクションにわたって責任があるパーティーの変化を反映するためにルーティング方針処理の一部としてこれができました。 例えば:
user - provider tag identifies user provider A - provider B tag identifies provider A
ユーザ--プロバイダータグはユーザプロバイダーAを特定します--プロバイダーBタグはプロバイダーAを特定します。
The tag could be used by accounting meters to identify the party responsible for a traffic flow, without having to deduce this using tables of rules. This should considerably simplify accounting for transit traffic across intermediate networks.
タグは会計メーターによって使用されて、交通の流れに責任があるパーティーを特定できました、規則のテーブルを使用することでこれを推論する必要はなくて。 これは中間ネットワークの向こう側にトランジットトラフィックのための会計をかなり簡素化するべきです。
Higher-layer (Session and Application) Accounting
より高い層(セッションとアプリケーション)の会計
At higher layers there is a clear need to measure accounting variables and communicate them to various points along a packet's path, for example an application server may wish to inform a client about its usage of resources. A tag containing this information could be read by meters at any point along the packet's path for charging purposes, and could also be used by the client to inform the user of charges incurred.
より高い層に、パケットの経路に沿って会計変数を測定して、様々なポイントにそれらを伝える明確な必要があります、例えば、アプリケーション・サーバーはリソースの用法に関してクライアントに知らせたがっているかもしれません。 この情報を含むタグを、充電目的のためにパケットの経路に沿った任意な点でメーターで読むことができて、また、クライアントは、被られた充電についてユーザに知らせるのに使用できました。
It would make the collection of accounting data much simpler if this information was carried in a standard tag within each packet, rather than having different protocols provide this service in differing ways.
それで、この情報が異なったプロトコルにこのサービスを異なった方法で提供させるより各パケットの中で標準のタグでむしろ運ばれるなら、会計データの収集ははるかに簡単になるでしょうに。
For 'old' applications which remain unaware of the tag field, a meter could be placed at a gateway for the application's host. This 'gateway' meter could determine what the application is by watching its streams of packets, then set an appropriate value in thir tag fields.
タグ・フィールドに気づかないままである'古い'アプリケーションにおいて、アプリケーションのホストのために1個のメーターをゲートウェイに置くことができました。 この'ゲートウェイ'メーターは、パケットの流れを見ることによってアプリケーションが何であるかを決定して、次に、thirタグ・フィールドに適切な値をはめ込むかもしれません。
Structure of the accounting tag
会計タグの構造
The two uses of tags outlined above must be able to coexist. Since many - indeed most - of the packets will only carry a voucher, it seems simplest to keep this as part of the routing tuple (see below).
上に概説されたタグの2つの用途が共存できなければなりません。 パケットの多く(本当に大部分)がバウチャーを運ぶだけであるので、ルーティングtupleの一部としてこれを保つのは最も簡単に思えます(以下を見てください)。
For the application variables, a separate tag seems sensible. This would simply contain a list of the variables. Having two tags in this way would keep separate the management of routers and meters.
アプリケーション変数に関しては、別々のタグは分別があるように思えます。 これは単に変数のリストを含んでいるでしょう。 このようにタグが続ける有twoはルータとメーターの管理を切り離します。
Brownlee [Page 2] RFC 1672 Accounting Requirements for IPng August 1994
1994年8月にIPngのための要件を説明するブラウンリー[2ページ]RFC1672
If the encryption/digital signature overhead of the second tag proves to be too high, it should be possible to combine this with the voucher.
2番目のタグの暗号化/デジタル署名オーバーヘッドが高過ぎると判明するなら、これをバウチャーに結合するのは可能であるべきです。
The fine detail of this, or at least the way variables are packed into the tags, could be standardised by the Accounting Working Group in due course. For the purpose of IPng all that is required is the ability to carry one or two variable-size objects in every packet.
Accounting作業部会はやがてこの詳しい詳細、または変数がタグに詰め込まれる少なくとも方法を標準化できました。 IPngの目的のための、そのすべてによる必要であるのが、1つを運ぶ能力であるということであるか2の可変サイズはあらゆるパケットで反対します。
References
参照
[1] Carpenter, B., "IPng White Paper on Transition and Other Considerations", RFC 1671, CERN, August 1994.
[1] 大工、B.、「変遷と他の問題に関するIPng白書」、RFC1671、CERN、1994年8月。
Security Considerations
セキュリティ問題
For IPng to provide reliable transport in a hostile environment, routing and accounting information, i.e., the (source, dest, network-tag) and (application-tag) tuples, must be tamper-proof. Routers and meters which need to use the tuples will need to hold appropriate keys for them. Network operators will have to plan for this, for example by determining which routers need which sets of keys. This will be neccessary in any case for reliable policy-based routing, so the extra work required to set up accounting meters should be acceptable.
すなわち、IPngが敵対的環境、ルーティング、および課金情報に信頼できる輸送を提供する、(destであって、タグをネットワークでつないでいるソース)と(アプリケーションタグ)tuplesは干渉防止しているに違いありません。 tuplesを使用する必要があるルータとメーターは、それらのための適切なかぎを握る必要があるでしょう。 例えば、どのルータがどのセットのキーを必要とするかを決定することによって、ネットワーク・オペレータはこれの計画を立てなければならないでしょう。 これが信頼できる方針ベースのルーティングのためにどのような場合でもneccessaryになるので、会計メーターをセットアップするのに必要である時間外労働は許容できるべきです。
Author's Address
作者のアドレス
Nevil Brownlee Deputy Director Computer Centre, The University of Auckland Private Bag 92019, Auckland, New Zealand
ネヴィルブラウンリー次長コンピュータセンター、オークランド大学の個人的なバッグ92019、オークランド、ニュージーランド
Phone: +64 9 373 7599 Fax: +64 9 373 7425 EMail: n.brownlee@auckland.ac.nz
以下に電話をしてください。 +64 9 373 7599Fax: +64 9 373 7425はメールされます: n.brownlee@auckland.ac.nz
Brownlee [Page 3]
ブラウンリー[3ページ]
一覧
スポンサーリンク