RFC3917 日本語訳
3917 Requirements for IP Flow Information Export (IPFIX). J. Quittek,T. Zseby, B. Claise, S. Zander. October 2004. (Format: TXT=81615 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Quittek
Request for Comments: 3917 NEC Europe Ltd.
Category: Informational T. Zseby
Fraunhofer FOKUS
B. Claise
Cisco Systems
S. Zander
Swinburne University
October 2004
Quittekがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 3917年のNECヨーロッパ株式会社カテゴリ: 情報のT.のシスコシステムズS.ザンダースウィンバーン大学ZsebyフラウンホーファーFOKUS B.Claise2004年10月
Requirements for IP Flow Information Export (IPFIX)
IP流れ情報輸出のための要件(IPFIX)
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(C)インターネット協会(2004)。
Abstract
要約
This memo defines requirements for the export of measured IP flow information out of routers, traffic measurement probes, and middleboxes.
このメモはトラフィック測定のルータ、徹底的調査、およびmiddleboxesから測定IP流れ情報の輸出のための要件を定義します。
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. IP Traffic Flow. . . . . . . . . . . . . . . . . . . . 3
2.2. Observation Point. . . . . . . . . . . . . . . . . . . 4
2.3. Metering Process . . . . . . . . . . . . . . . . . . . 4
2.4. Flow Record. . . . . . . . . . . . . . . . . . . . . . 5
2.5. Exporting Process. . . . . . . . . . . . . . . . . . . 5
2.6. Collecting Process . . . . . . . . . . . . . . . . . . 5
3. Applications Requiring IP Flow Information Export . . . . . . 6
3.1. Usage-based Accounting . . . . . . . . . . . . . . . . 6
3.2. Traffic Profiling. . . . . . . . . . . . . . . . . . . 7
3.3. Traffic Engineering. . . . . . . . . . . . . . . . . . 7
3.4. Attack/Intrusion Detection . . . . . . . . . . . . . . 7
3.5. QoS Monitoring . . . . . . . . . . . . . . . . . . . . 8
4. Distinguishing Flows. . . . . . . . . . . . . . . . . . . . . 8
4.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Interfaces . . . . . . . . . . . . . . . . . . . . . . 9
1. 序論。 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. 用語. . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1。 IP交通の流れ。 . . . . . . . . . . . . . . . . . . . 3 2.2. 観測所。 . . . . . . . . . . . . . . . . . . 4 2.3. 過程. . . . . . . . . . . . . . . . . . . 4 2.4を計量します。 記録的に、流れてください。 . . . . . . . . . . . . . . . . . . . . . 5 2.5. 過程を輸出します。 . . . . . . . . . . . . . . . . . . 5 2.6. 過程. . . . . . . . . . . . . . . . . . 5 3を集めます。 IP流れ情報を必要とするアプリケーションが.63.1を輸出します。 用法ベースの会計. . . . . . . . . . . . . . . . 6 3.2。 交通プロフィール。 . . . . . . . . . . . . . . . . . . 7 3.3. 交通工学。 . . . . . . . . . . . . . . . . . 7 3.4. 攻撃/押しつけ検出. . . . . . . . . . . . . . 7 3.5。 QoSモニター. . . . . . . . . . . . . . . . . . . . 8 4。 区別は流れます。 . . . . . . . . . . . . . . . . . . . . 8 4.1. 暗号化. . . . . . . . . . . . . . . . . . . . . . 9 4.2。 インタフェース. . . . . . . . . . . . . . . . . . . . . . 9
Quittek, et al. Informational [Page 1] RFC 3917 IPFIX Requirements October 2004
Quittek、他 [1ページ]情報のRFC3917IPFIX要件2004年10月
4.3. IP Header Fields . . . . . . . . . . . . . . . . . . . 9
4.4. Transport Header Fields. . . . . . . . . . . . . . . . 10
4.5. MPLS Label . . . . . . . . . . . . . . . . . . . . . . 10
4.6. DiffServ Code Point. . . . . . . . . . . . . . . . . . 10
5. Metering Process. . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Reliability. . . . . . . . . . . . . . . . . . . . . . 10
5.2. Sampling . . . . . . . . . . . . . . . . . . . . . . . 11
5.3. Overload Behavior. . . . . . . . . . . . . . . . . . . 11
5.4. Timestamps . . . . . . . . . . . . . . . . . . . . . . 12
5.5. Time Synchronization . . . . . . . . . . . . . . . . . 12
5.6. Flow Expiration. . . . . . . . . . . . . . . . . . . . 13
5.7. Multicast Flows. . . . . . . . . . . . . . . . . . . . 13
5.8. Packet Fragmentation . . . . . . . . . . . . . . . . . 13
5.9. Ignore Port Copy . . . . . . . . . . . . . . . . . . . 13
6. Data Export . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Information Model. . . . . . . . . . . . . . . . . . . 14
6.2. Data Model . . . . . . . . . . . . . . . . . . . . . . 16
6.3. Data Transfer. . . . . . . . . . . . . . . . . . . . . 16
6.3.1. Congestion Awareness. . . . . . . . . . . . . . 16
6.3.2. Reliability . . . . . . . . . . . . . . . . . . 17
6.3.3. Security. . . . . . . . . . . . . . . . . . . . 18
6.4. Push and Pull Mode Reporting . . . . . . . . . . . . . 18
6.5. Regular Reporting Interval . . . . . . . . . . . . . . 18
6.6. Notification on Specific Events. . . . . . . . . . . . 18
6.7. Anonymization. . . . . . . . . . . . . . . . . . . . . 18
7. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Configuration of the Metering Process. . . . . . . . . 19
7.2. Configuration of the Exporting Process . . . . . . . . 19
8. General Requirements. . . . . . . . . . . . . . . . . . . . . 20
8.1. Openness . . . . . . . . . . . . . . . . . . . . . . . 20
8.2. Scalability. . . . . . . . . . . . . . . . . . . . . . 20
8.3. Several Collecting Processes . . . . . . . . . . . . . 20
9. Special Device Considerations . . . . . . . . . . . . . . . . 20
10. Security Considerations . . . . . . . . . . . . . . . . . . . 23
10.1. Disclosure of Flow Information Data. . . . . . . . . . 23
10.2. Forgery of Flow Records. . . . . . . . . . . . . . . . 24
10.3. Denial of Service (DoS) Attacks. . . . . . . . . . . . 24
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
12. Appendix: Derivation of Requirements from Applications. . . . 26
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
13.1. Normative References . . . . . . . . . . . . . . . . . 31
13.2. Informative References . . . . . . . . . . . . . . . . 31
14. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 32
15. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 33
4.3. IPヘッダーフィールド. . . . . . . . . . . . . . . . . . . 9 4.4。 ヘッダーフィールドを輸送してください。 . . . . . . . . . . . . . . . 10 4.5. MPLSは.104.6をラベルします。 DiffServはポイントをコード化します。 . . . . . . . . . . . . . . . . . 10 5. 過程を計量します。 . . . . . . . . . . . . . . . . . . . . . . 10 5.1. 信頼性。 . . . . . . . . . . . . . . . . . . . . . 10 5.2. 標本抽出. . . . . . . . . . . . . . . . . . . . . . . 11 5.3。 振舞いを積みすぎてください。 . . . . . . . . . . . . . . . . . . 11 5.4. タイムスタンプ. . . . . . . . . . . . . . . . . . . . . . 12 5.5。 時間同期化. . . . . . . . . . . . . . . . . 12 5.6。 流れ満了。 . . . . . . . . . . . . . . . . . . . 13 5.7. マルチキャストは流れます。 . . . . . . . . . . . . . . . . . . . 13 5.8. パケット断片化. . . . . . . . . . . . . . . . . 13 5.9。 ポートコピー. . . . . . . . . . . . . . . . . . . 13 6を無視してください。 データは.146.1を輸出します。 情報モデル。 . . . . . . . . . . . . . . . . . . 14 6.2. データは.166.3をモデル化します。 データ転送。 . . . . . . . . . . . . . . . . . . . . 16 6.3.1. 混雑認識。 . . . . . . . . . . . . . 16 6.3.2. 信頼性. . . . . . . . . . . . . . . . . . 17 6.3の.3。 セキュリティ。 . . . . . . . . . . . . . . . . . . . 18 6.4. モード報告. . . . . . . . . . . . . 18 6.5を押して、引いてください。 一定の報告間隔. . . . . . . . . . . . . . 18 6.6。 特定の出来事に関する通知。 . . . . . . . . . . . 18 6.7. Anonymization。 . . . . . . . . . . . . . . . . . . . . 18 7. 構成. . . . . . . . . . . . . . . . . . . . . . . . 19 7.1。 計量の過程の構成。 . . . . . . . . 19 7.2. 輸出の過程. . . . . . . . 19 8の構成。 一般要件。 . . . . . . . . . . . . . . . . . . . . 20 8.1. 風通しの良. . . . . . . . . . . . . . . . . . . . . . . 20 8.2さ。 スケーラビリティ。 . . . . . . . . . . . . . . . . . . . . . 20 8.3. 数個の収集が.209を処理します。 特別な装置問題. . . . . . . . . . . . . . . . 20 10。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 23 10.1。 流れインフォメーション・データの公開。 . . . . . . . . . 23 10.2. 流れ記録の偽造。 . . . . . . . . . . . . . . . 24 10.3. サービス妨害(DoS)は攻撃されます。 . . . . . . . . . . . 24 11. 承認. . . . . . . . . . . . . . . . . . . . . . . 25 12。 付録: アプリケーションからの要件の派生。 . . . 26 13. 参照. . . . . . . . . . . . . . . . . . . . . . . . . 31 13.1。 引用規格. . . . . . . . . . . . . . . . . 31 13.2。 有益な参照. . . . . . . . . . . . . . . . 31 14。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 32 15。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 33
Quittek, et al. Informational [Page 2] RFC 3917 IPFIX Requirements October 2004
Quittek、他 [2ページ]情報のRFC3917IPFIX要件2004年10月
1. Introduction
1. 序論
There are several applications that require flow-based IP traffic measurements. Such measurements could be performed by a router while forwarding the traffic, by a middlebox [RFC3234], or by a traffic measurement probe attached to a line or a monitored port. This memo defines requirements for exporting traffic flow information out of these boxes for further processing by applications located on other devices. They serve as input to the standardization of the IPFIX protocol specifications.
流れベースのIPトラフィック測定を必要とするいくつかの利用があります。 ルータはmiddlebox[RFC3234]、または線かモニターされたポートに取り付けられたトラフィック測定徹底的調査で交通を進めている間、そのような測定を実行できました。 このメモはさらなる処理のためのこれらの箱から対向機器で見つけられたアプリケーションで輸出交通の流れ情報のための要件を定義します。 それらはIPFIXプロトコル仕様の標準化に入力されるように役立ちます。
In section 3, a selection of such applications is presented. The following sections list requirements derived from these applications.
セクション3では、そのようなアプリケーションの品揃えは示されます。 以下のセクションはこれらのアプリケーションから得られた要件をリストアップします。
In its early discussions the IPFIX Working Group chose to evaluate existing flow export protocols at the same time it was developing this 'requirements' document.
早めの議論では、IPFIX作業部会は、それがこの'要件'ドキュメントを開発していた同時代に既存の流れ輸出プロトコルを評価するのを選びました。
Flow export, however, is not performed by a protocol acting alone, it also requires a system of co-operating processes. In producing IPFIX requirements, therefore, the Working Group decided to specify what was required by these various processes - the metering process, the exporting process, etc. In these specifications we use lower-case for the words must, may, and should, to indicate that IPFIX implementors have some freedom as to how to meet the requirements.
しかしながら、流れ輸出は単独に行動するプロトコルによって実行されません、また、それが協力の過程をシステムに要求します。 したがって、IPFIX要件を作り出す際に、作業部会は、これらの様々な過程によって必要とされたことを指定すると決めました--計量の過程、輸出の過程など これらの仕様、私たち、単語における、小文字の使用が持たなければならない、IPFIX作成者には、それを示すために、どう条件を満たすかに関して何らかの自由があるべきであるかもしれません。
The Working Group's goal is to produce standards-track RFCs describing the IPFIX information model and export protocol RFCs. As well as meeting the requirements set out in this document, the information model and protocol documents will provide a full specification of the IPFIX system, and will use uppercase keywords as in [RFC 2119].
作業部会の目標は、IPFIX情報モデルについて説明する標準化過程RFCsを生産して、プロトコルRFCsを輸出することです。 本書では出された必要条件を満たすことと同様に、情報モデルとプロトコルドキュメントは、IPFIXシステムの完全な仕様を提供して、[RFC2119]のように大文字しているキーワードを使用するでしょう。
2. Terminology
2. 用語
The following terminology is used in this document:
以下の用語は本書では使用されます:
2.1. IP Traffic Flow
2.1. IP交通の流れ
There are several definitions of the term 'flow' being used by the Internet community. Within this document we use the following one:
インターネットコミュニティによって使用される'流れ'という用語のいくつかの定義があります。 このドキュメントの中では、私たちは以下の1つを使用します:
A flow is defined as a set of IP packets passing an observation point in the network during a certain time interval. All packets belonging to a particular flow have a set of common properties. Each property is defined as the result of applying a function to the values of:
流れはある一定の時間間隔の間ネットワークで観測所を通り過ぎる1セットのIPパケットと定義されます。 特定の流れに属すすべてのパケットが1セットの通有性を持っています。 各特性は以下の値に機能を適用するという結果と定義されます。
Quittek, et al. Informational [Page 3] RFC 3917 IPFIX Requirements October 2004
Quittek、他 [3ページ]情報のRFC3917IPFIX要件2004年10月
1. one or more packet header field (e.g., destination IP address),
transport header field (e.g., destination port number), or
application header field (e.g., RTP header fields [RFC3550])
1. 1つ以上のパケットヘッダーフィールド(例えば、送付先IPアドレス)、輸送ヘッダーフィールド(例えば、目的地ポートナンバー)、またはアプリケーションヘッダーフィールド(例えば、RTPヘッダーフィールド[RFC3550])
2. one or more characteristics of the packet itself (e.g., number
of MPLS labels, etc.)
2. パケット自体の1つ以上の特性(例えば、MPLSラベルなどの数)
3. one or more of fields derived from packet treatment (e.g., next
hop IP address, the output interface, etc.)
3. パケット処理から得られた野原の1つ以上(例えば、次のホップIPアドレス、出力インタフェースなど)
A packet is defined to belong to a flow if it completely satisfies all the defined properties of the flow.
流れのすべての定義された特性を完全に満たすなら、パケットは、流れに属すために定義されます。
This definition covers the range from a flow containing all packets observed at a network interface to a flow consisting of just a single packet between two applications with a specific sequence number. Please note that the flow definition does not necessarily match a general application-level end-to-end stream. However, an application may derive properties of application-level streams by processing measured flow data. Also, please note that although packet properties may depend on application headers, there is no requirement defined in this document related to application headers.
この定義はネットワーク・インターフェースで観察されたすべてのパケットを含む流れから特定の一連番号でまさしく2つのアプリケーションの間の単一のパケットから成る流れまでの範囲をカバーしています。 フロー定義は必ずアプリケーションレベル終わりから終わりへの一般的な流れに合っているというわけではありません。 しかしながら、アプリケーションは、測定フロー・データを処理することによって、アプリケーションレベルの流れの特性を引き出すかもしれません。 また、パケットの特性をアプリケーションヘッダーに頼るかもしれませんが、アプリケーションヘッダーに伝えるこのドキュメントで定義された要件が全くありません。
2.2. Observation Point
2.2. 観測所
The observation point is a location in the network where IP packets can be observed. Examples are a line to which a probe is attached, a shared medium such as an Ethernet-based LAN, a single port of a router, or a set of interfaces (physical or logical) of a router.
観測所はIPパケットを観察できるネットワークで位置です。 例は徹底的調査がどれであるかに取り付けられた線、イーサネットベースのLAN、ルータの単一のポート、またはルータにおける(物理的であるか論理的)のインタフェースの1セットなどの共有された媒体です。
Note that one observation point may be a superset of several other observation points. For example one observation point can be an entire line card. This would be the superset of the individual observation points at the line card's interfaces.
1つの観測所が他のいくつかの観測所のスーパーセットであるかもしれないことに注意してください。 例えば、1つの観測所が全体の線カードであるかもしれません。 これは線カードのインタフェースの個々の観測所のスーパーセットでしょう。
2.3. Metering Process
2.3. 計量の過程
The metering process generates flow records. Input to the process are packet headers observed at an observation point and packet treatment at the observation point, for example the selected output interface. The metering process consists of a set of functions that includes packet header capturing, timestamping, sampling, classifying, and maintaining flow records.
計量の過程は流れ記録を発生させます。 過程に入力されているのは、観測所(例えば、選択された出力インタフェース)での観測所とパケット処理のときに観察されたパケットのヘッダーです。 計量の過程は流れ記録を捕らえて、timestampingして、抽出して、分類して、保守しているパケットのヘッダーを含んでいる関数群から成ります。
The maintenance of flow records may include creating new records, updating existing ones, computing flow statistics, deriving further flow properties, detecting flow expiration, passing flow records to the exporting process, and deleting flow records.
流れ記録の維持は、新しい記録を作成するのを含むかもしれません、既存のものをアップデートして、流れ統計を計算して、さらなる流れの特性を引き出して、流れ満了を検出して、流れ記録を輸出の過程に通過して、流れ記録を削除して。
Quittek, et al. Informational [Page 4] RFC 3917 IPFIX Requirements October 2004
Quittek、他 [4ページ]情報のRFC3917IPFIX要件2004年10月
The sampling function and the classifying function may be applied more than once with different parameters. Figure 1 shows the sequence in which the functions are applied. Sampling is not illustrated in the figure; it may be applied before any other function.
標本抽出機能と分類機能は異なったパラメタによる一度より適用されるかもしれません。 図1は機能が適用されている系列を示しています。 標本抽出は図で例証されません。 それはいかなる他の機能の前にも適用されるかもしれません。
packet header capturing
|
timestamping
|
v
+----->+
| |
| classifying
| |
+------+
|
maintaining flow records
|
v
パケットのヘッダーの捕らえること| timestampingします。| +に対して----->+| | | 分類| | +------+ | 流れ記録を保守します。| v
Figure 1: Functions of the metering process
図1: 計量の過程の関数
2.4. Flow Record
2.4. 流れ記録
A flow record contains information about a specific flow that was metered at an observation point. A flow record contains measured properties of the flow (e.g., the total number of bytes of all packets of the flow) and usually characteristic properties of the flow (e.g., source IP address).
流れ記録は観測所で計量された特定の流れの情報を含んでいます。 流れ記録は流れの測定特性(例えば、流れのすべてのパケットのバイトの総数)と流れの通常独特の特性(例えば、ソースIPアドレス)を含んでいます。
2.5. Exporting Process
2.5. 輸出の過程
The exporting process sends flow records to one or more collecting processes. The flow records are generated by one or more metering processes.
輸出の過程は1つ以上の収集の過程に流れ記録を送ります。 流れ記録は、1時までに発生するか、または過程をさらに計量しています。
2.6. Collecting Process
2.6. 収集の過程
The collecting process receives flow records from one or more exporting processes. The collecting process might store received flow records or further process them, but these actions are out of the scope of this document.
収集の過程は1つ以上の輸出の過程から流れ記録を受け取ります。 収集の過程は、受信された流れ記録を格納するか、またはさらにそれらを処理するかもしれませんが、このドキュメントの範囲の外にこれらの動作があります。
Quittek, et al. Informational [Page 5] RFC 3917 IPFIX Requirements October 2004
Quittek、他 [5ページ]情報のRFC3917IPFIX要件2004年10月
3. Applications Requiring IP Flow Information Export
3. IP流れ情報輸出を必要とするアプリケーション
This section describes a selection of applications requiring IP flow information export. Because requirements for flow export listed in further sections below are derived from these applications, their selection is crucial. The goal of this requirements document is not to cover all possible applications with all their flow export requirements, but to cover applications which are considered to be of significant importance in today's and/or future IP networks, and for which requirements can be met with reasonable technical effort.
このセクションはIP流れ情報輸出を必要とするいくつかのアプリケーションについて説明します。 これらのアプリケーションから下のさらなるセクションで記載された流れ輸出のための要件を得るので、彼らの選択は重要です。 この要件ドキュメントの目標はそれらのすべての流れ輸出要件ですべての可能なアプリケーションをカバーするのではなく、今日、そして/または、将来のIPネットワークには重要な重要性があると考えて、合理的な技術的な努力で必要条件を満たすことができるアプリケーションをカバーすることです。
The list of applications should lead to a better understanding of the requirements which is particularly important when designing or implementing traffic flow metering functions. A detailed overview of which requirement was derived from which application(s) is given in the appendix.
アプリケーションのリストは要件の交通の流れ計量機能を設計するか、または実行するとき特に重要なより良い理解に通じるはずです。 どの要件の詳細な概観は付録でどのアプリケーションを与えるかから引き出されたか。
Please note that the described applications can have a large number of differing implementations. Requirement details or requirement significance (required (must), recommended (should), optional (may)) could differ for specific implementations and/or for specific application scenarios. Therefore we derive the requirements from the general functionality of the selected applications. Some particular cases will even mandate more stringent requirements than the ones defined in this document. For example, usage-based accounting is certainly the application that will probably mandate the highest degree of reliability amongst the applications discussed below. The reliability requirements defined in sections 5.1 and 6.3.2. are not sufficient to guarantee the level of reliability that is needed for many usage-based accounting systems. Particular reliability requirements for accounting systems are discussed in [RFC2975].
説明されたアプリケーションは多くの異なった実現を持つことができます。 要件の詳細か要件意味、(必要な(must)、お勧めの(should)、任意の(may))は特定の実現特定のアプリケーションシナリオのために異なることができました。 したがって、私たちが要件に選択されたアプリケーションの一般的な機能性に由来しています。 いくつかの特定のケースが本書では定義されたものより厳しい要件を強制さえするでしょう。 例えば、確かに、用法ベースの会計はたぶん以下で議論したアプリケーションの中で最も高度の信頼性を強制するアプリケーションです。 セクション5.1と6.3で.2に定義された信頼度要求事項は多くの用法ベースの会計システムに必要である信頼性のレベルを保証できません。[RFC2975]で会計システムのための特定の信頼度要求事項について議論します。
3.1. Usage-based Accounting
3.1. 用法ベースの会計
Several new business models for selling IP services and IP-based services are currently under investigation. Beyond flat rate services which do not need accounting, accounting can be based on time or volume. Accounting data can serve as input for billing systems. Accounting can be performed per user or per user group, it can be performed just for basic IP service or individually per high- level service and/or per content type delivered. For advanced/future services, accounting may also be performed per class of service, per application, per time of day, per (label switched) path used, etc.
IPサービスを販売するための数個の新しいビジネスモデルとIPベースのサービスは現在、調査中です。 説明する必要はない均一料金サービスを超えて、会計は時間かボリュームに基づくことができます。 会計データは支払いシステムのために入力されるように勤めることができます。ユーザかユーザ・グループ単位で会計を実行できるでしょうか、まさしく基本的なIPサービスのためにそれを実行できましたか、または個別に、タイプは高値レベルサービス内容に従って配送しました。 高度であるか今後のサービスのために、また、会計は、1時刻あたりのアプリケーションあたりのサービスのクラス単位で実行されて、(ラベルは切り替わりました)経路単位で使用されるかもしれませんなど。
Quittek, et al. Informational [Page 6] RFC 3917 IPFIX Requirements October 2004
Quittek、他 [6ページ]情報のRFC3917IPFIX要件2004年10月
3.2. Traffic Profiling
3.2. 交通プロフィール
Traffic profiling is the process of characterizing IP flows by using a model that represents key parameters of the flows such as flow duration, volume, time, and burstiness. It is a prerequisite for network planning, network dimensioning, trend analysis, business model development, and other activities. It depends heavily on the particular traffic profiling objective(s), which statistics, and which accuracy are required from the measurements. Typical information needed for traffic profiling is the distribution of used services and protocols in the network, the amount of packets of a specific type (e.g., percentage of IPv6 packets) and specific flow profiles.
交通プロフィールは流れ持続時間や、ボリュームや、時間や、burstinessなどの流れの主要なパラメタを表すモデルを使うことによってIP流れを特徴付ける過程です。 それはネットワーク計画、ネットワーク寸法決定、傾向変動分析、ビジネスモデル開発、および他の活動のための前提条件です。 それは大いにどの統計、およびその精度が測定値から必要である目的の輪郭を描く特定の交通によります。 交通プロフィールに必要である典型的な情報は、中古にサービスの分配とネットワーク、特定のタイプ(例えば、IPv6パケットの割合)と特定の流れプロフィールのパケットの量がプロトコルです。
Since objectives for traffic profiling can vary, this application requires a high flexibility of the measurement infrastructure, especially regarding the options for measurement configuration and packet classification.
交通プロフィールのための目的が異なることができるので、このアプリケーションは測定構成とパケット分類のための特にオプションに関する測定インフラストラクチャの高い柔軟性を必要とします。
3.3. Traffic Engineering
3.3. 交通工学
Traffic Engineering (TE) comprises methods for measurement, modelling, characterization and control of a network. The goal of TE is the optimization of network resource utilization and traffic performance [RFC2702]. Since control and administrative reaction to measurement results requires access to the involved network nodes, TE mechanisms and the required measurement function usually are performed within one administrative domain. Typical parameters required for TE are link utilization, load between specific network nodes, number, size and entry/exit points of the active flows and routing information.
交通Engineering(TE)はネットワークの測定、モデル化、特殊化、およびコントロールのための方法を包括します。 TEの目標はネットワーク資源利用とトラフィック性能[RFC2702]の最適化です。 制御してください。そうすれば、測定結果への管理反応がかかわったネットワーク・ノードへのアクセスを必要とするので、通常、TEメカニズムと必要な測定機能は1つの管理ドメインの中で実行されます。 TEに必要である典型的なパラメタはリンク利用、アクティブな流れとルーティング情報の特定のネットワーク・ノードと、数と、サイズとエントリー/エキジットポイントの間の負荷です。
3.4. Attack/Intrusion Detection
3.4. 攻撃/押しつけ検出
Capturing flow information plays an important role for network security, both for detection of security violation, and for subsequent defense. In case of a Denial of Service (DOS) attack, flow monitoring can allow detection of unusual situations or suspicious flows. In a second step, flow analysis can be performed in order to gather information about the attacking flows, and for deriving a defense strategy.
流れ情報を得るのはネットワークセキュリティ、安全の侵害の検出、およびその後のディフェンスのために重要な役割を果たします。 サービス妨害(DOS)攻撃の場合には、流れモニターは異例の状況か疑わしげな流れの検出を許すことができます。 第2のステップでは、攻撃流れの周りと、そして、防衛戦略を引き出すことように情報を収集するためにフロー分析を実行できます。
Intrusion detection is a potentially more demanding application which would not only look at specific characteristics of flows, but may also use a stateful packet flow analysis for detecting specific, suspicious activities, or unusually frequent activities. Such activities may be characterized by specific communication patterns, detectable by characteristic sequences of certain packet types.
押しつけ検出はまた、特定の、そして、疑わしげな活動、または異常に頻繁な活動を検出するのにstatefulパケットフロー分析を使用するかもしれないのを除いて、流れの特定の特性を見るだけではない潜在的により過酷なアプリケーションです。 そのような活動はあるパケットタイプの独特の系列で検出可能な特定のコミュニケーションパターンによって特徴付けられるかもしれません。
Quittek, et al. Informational [Page 7] RFC 3917 IPFIX Requirements October 2004
Quittek、他 [7ページ]情報のRFC3917IPFIX要件2004年10月
3.5. QoS Monitoring
3.5. QoSモニター
QoS monitoring is the passive measurement of quality parameters for IP flows. In contrast to active measurements, passive measurements utilize the existing traffic in the network for QoS analysis. Since no test traffic is sent, passive measurements can only be applied in situations where the traffic of interest is already present in the network. One example application is the validation of QoS parameters negotiated in a service level specification. Note that passive/active measurement is also referred to as non- intrusive/intrusive measurement or as measurement of observed/synthetic traffic.
QoSモニターはIPにおける上質のパラメタの受け身の測定が流れるということです。 アクティブな測定値と対照して、受け身の測定値はネットワークの既存の交通をQoS分析に利用します。 テスト交通を全く送らないので、興味がある交通がネットワークで既に存在している状況で受け身の測定を適用できるだけです。 1つの例のアプリケーションはサービスレベル仕様で交渉されたQoSパラメタの合法化です。 非押しつけがましいか押しつけがましい測定と呼ばれるか、観測されたか合成の交通の測定としても受け身の、または、活発な測定があることに注意してください。
Passive measurements cannot provide the kind of controllable experiments that can be achieved with active measurements. On the other hand passive measurements do not suffer from undesired side effects caused by sending test traffic (e.g., additional load, potential differences in treatment of test traffic and real customer traffic).
受け身の測定値はアクティブな測定値で達成できる制御可能な実験の種類を提供できません。 他方では、受け身の測定値はテスト交通(例えば、追加負荷、テスト交通と本当の顧客交通の処理における電位差)を送ることによって引き起こされた望まれない副作用に苦しみません。
QoS monitoring often requires the correlation of data from multiple observation points (e.g., for measuring one-way metrics). This requires proper clock synchronization of the involved metering processes. For some measurements, flow records and/or notifications on specific events at the different observation points must be correlated, for example the arrival of a certain packet. For this, the provisioning of post-processing functions (e.g., the generation of packet IDs) at the metering processes would be useful. Since QoS monitoring can lead to a huge amount of measurement result data, it would highly benefit from mechanisms to reduce the measurement data, like aggregation of results and sampling.
QoSモニターはしばしば複数の観測所(例えば、測定の片道測定基準のための)からのデータの相関関係を必要とします。 これはかかわった計量の過程の適切な時計同期を必要とします。 いくつかの測定値に関しては、異なった観測所の特定の出来事に関する流れ記録、そして/または、通知は関連しなければなりません、例えば、あるパケットの到着。 これに、計量の過程における後工程機能(例えば、パケットIDの世代)の食糧を供給するのは役に立つでしょう。 以来、QoSモニターは膨大な量の測定結果データに通じることができて、それは、結果と標本抽出の集合のように測定データを減らすために非常にメカニズムの利益を得るでしょう。
Please note that not all requirements for QoS monitoring are covered by the IPFIX requirements specified in the following sections. The IPFIX requirements are targeted at per flow information including summaries of per-packet properties for packets within a flow, but not per-packet information itself. For example jitter measurement requires timestamping each packet and reporting of all timestamps of a flow, but the IPFIX requirements only cover timestamps of first and last packet of a flow.
QoSモニターのためのすべての要件が以下のセクションで指定されたIPFIX要件でカバーされているというわけではありません。 IPFIX要件は含んでいるのに流れ情報あたり狙って、パケットのための1パケットあたりの特性の概要がaの中を流れて、1パケットあたりの唯一の情報がそれ自体でないということです。 例えば、ジター測定は、各パケットと報告をtimestampingするのを流れに関するすべてのタイムスタンプを要求しますが、IPFIX要件は1番目に関するタイムスタンプと流れの最後のパケットをカバーするだけです。
4. Distinguishing Flows
4. 区別は流れます。
Packets are mapped to flows by evaluating their properties. Packets with common properties are considered to belong to the same flow. A packet showing at least one difference in the set of properties is considered to belong to a different flow.
パケットは、彼らの特性を評価することによって、流れに写像されます。 通有性があるパケットが同じ流れに属すと考えられます。 特性のセットの少なくとも1つの差異があるパケットが異なった流れに属すと考えられます。
Quittek, et al. Informational [Page 8] RFC 3917 IPFIX Requirements October 2004
Quittek、他 [8ページ]情報のRFC3917IPFIX要件2004年10月
The following subsections list a set of properties which a metering process must, should, or may be able to evaluate for mapping packets to flows. Please note that requiring the ability to evaluate a certain property does not imply that this property must be evaluated for each packet. In other words, meeting the IPFIX requirements means that the metering process in general must be able, via its configuration, to somehow support to distinguish flows via all the must fields, even if in certain circumstances/for certain applications, only a subset of the must fields is needed and effectively used to distinguish flows.
評価するべきであるか、以下の小区分は計量の過程が記載しなければならない1セットの特性を記載して、またはマッピングのために流れにパケットを評価できるかもしれません。 ある特性を評価する能力を必要とするのは、各パケットのためにこの特性を評価しなければならないのを含意しません。 言い換えれば、IPFIX必要条件を満たすのは、一般に、計量の過程がすべての必須分野を通って流れを区別するために構成でどうにかサポートするのにできなければならないことを意味します、必須分野の部分集合だけが、あるアプリケーションのためのある事情/で必要であり、流れを区別するのに事実上使用されても。
Which combination of properties is used for distinguishing flows and how these properties are evaluated depends on the configuration of the metering process. The configured choice of evaluated properties strongly depends on the environment and purpose of the measurement and on the information required by the collecting process. But in any case, a collecting process must be able to clearly identify, for each received flow record, which set of properties was used for distinguishing this flow from other ones.
特性のどの組み合わせが区別するのに使用されるかは流れます、そして、これらの特性がどう評価されるかは計量の過程の構成に依存します。 評価の特性の選択が測定と情報で強く環境と目的に依存する構成が収集の過程が必要です。 しかし、どのような場合でも、収集の過程は、それぞれの受信された流れ記録のためにどのセットの特性が他のものとこの流れを区別するのに使用されたかを明確に特定できなければなりません。
For specific deployments, only a subset of the required properties listed below can be used to distinguish flows. For example, in order to aggregate the flow records and reduce the number of flow records exported. On the other hand, some other deployments will require distinguishing flows by some extra parameters, such as the TTL field of the IP header or the BGP Autonomous System number [RFC1771] of the IP destination address.
特定の展開において、流れを区別するのに以下に記載された必要な特性の部分集合しか使用できません。 例えば、流れ記録に集めて、流れの数を減少させるために、記録は輸出されました。 他方では、ある他の展開は、いくつかの余分なパラメタで流れを区別するのを必要とするでしょう、IPヘッダーのTTL分野や受信者IPアドレスのBGP Autonomous System番号[RFC1771]のように。
4.1. Encryption
4.1. 暗号化
If encryption is used, the metering process might not be able to access all header fields. A metering process must meet the requirements stated in this section 4 only for packets that have the relevant header fields not encrypted.
暗号化が使用されているなら、計量の過程はすべてのヘッダーフィールドにアクセスできるかもしれないというわけではありません。 計量の過程は分野がコード化しなかった関連ヘッダーがあるパケットのためだけにこのセクション4で述べられた必要条件を満たさなければなりません。
4.2. Interfaces
4.2. インタフェース
The metering process must be able to separate flows by the incoming interface or by the outgoing interface or by both of them.
計量の過程は入って来るインタフェースか外向的なインタフェースかそれらの両方で流れを切り離すことができなければなりません。
4.3. IP Header Fields
4.3. IPヘッダーフィールド
The metering process must be able to separate flows by the following fields of the IP header:
過程が切り離すことができなければならない計量はIPヘッダーの以下の分野のそばを流れます:
1. source IP address
1. ソースIPアドレス
2. destination IP address
2. 送付先IPアドレス
Quittek, et al. Informational [Page 9] RFC 3917 IPFIX Requirements October 2004
Quittek、他 [9ページ]情報のRFC3917IPFIX要件2004年10月
3. protocol type (TCP, UDP, ICMP, ...)
3. プロトコルタイプ(TCP、UDP、ICMP)
For source address and destination address, separating by full match must be supported as well as separation by prefix match.
ソースアドレスと送付先アドレスにおいて、接頭語マッチによる分離と同様に完全なマッチで分離するのを支持しなければなりません。
The metering process should be able to separate flows by the IP version number if the observation point is located at a device that is supporting more than one IP version.
観測所が1つ以上のIPバージョンを支持している装置に位置しているなら、計量の過程はIPバージョン番号で流れを切り離すことができるべきです。
4.4. Transport Header Fields
4.4. 輸送ヘッダーフィールド
The metering process must be able to separate flows by the port numbers of the transport header in case of TCP or UDP being used as transport protocol. The metering process should be able to separate flows by the port numbers of the transport header in case of SCTP [RFC2960].
TCPかUDPの場合に計量の過程は輸送ヘッダーのポートナンバーでトランスポート・プロトコルとして使用されるのにおいて流れを切り離すことができなければなりません。 計量の過程はSCTP[RFC2960]の場合に輸送ヘッダーのポートナンバーで流れを切り離すことができるべきです。
For separation, both, source and destination port number must be supported for distinguishing flows, individually as well as in combination.
分離において、流れを区別する、個別、および組み合わせで両方、ソース、および目的地ポートナンバーをサポートしなければなりません。
4.5. MPLS Label
4.5. MPLSラベル
If the observation point is located at a device supporting Multiprotocol Label Switching (MPLS, see [RFC3031]) then the metering process must be able to separate flows by the MPLS label.
観測所がMultiprotocol Label Switchingを支持しながら装置に位置しているなら(MPLS、[RFC3031]を見てください)、計量の過程はMPLSラベルで流れを切り離すことができなければなりません。
4.6. DiffServ Code Point
4.6. DiffServコード・ポイント
If the observation point is located at a device supporting Differentiated Services (DiffServ) then the metering process must be able to separate flows by the DiffServ Code Point (DSCP, see [RFC2474]).
観測所がDifferentiated Services(DiffServ)を支持しながら装置に位置しているなら、計量の過程はDiffServ Code Pointで流れを切り離すことができなければなりません(DSCP、[RFC2474]を見てください)。
5. Metering Process
5. 計量の過程
The following are requirements for the metering process. All measurements must be conducted from the point of view of the observation point.
↓これは計量の過程のための要件です。 観測所の観点からすべての測定値を行わなければなりません。
5.1. Reliability
5.1. 信頼性
The metering process must either be reliable or the absence of reliability must be known and indicated. The metering process is reliable if each packet passing the observation point is metered according to the configuration of the metering process. If, e.g.,
計量の過程が信頼できるに違いないか、信頼性の欠如を知られて、示さなければなりません。 計量の過程の構成に従って観測所を通り過ぎる各パケットが計量されるなら、計量の過程は信頼できます。 例えば
Quittek, et al. Informational [Page 10] RFC 3917 IPFIX Requirements October 2004
Quittek、他 [10ページ]情報のRFC3917IPFIX要件2004年10月
due to some overload, not all passing packets can be included into the metering process, then the metering process must be able to detect this failure and to report it.
何らかのオーバーロードのため、パケットをすべて通過しないのを計量プロセスに含めることができて、計量プロセスは、この失敗を検出して、次に、それを報告できなければなりません。
5.2. Sampling
5.2. 標本抽出
Sampling describes the systematic or random selection of a subset of elements (the sample) out of a set of elements (the parent population). Usually the purpose of applying sampling techniques is to estimate a parameter of the parent population by using only the elements of the subset. Sampling techniques can be applied for instance to select a subset of packets out of all packets of a flow or to select a subset of flows out of all flows on a link. Sampling methods differ in their sampling strategy (e.g., systematic or random) and in the event that triggers the selection of an element. The selection of one packet can for instance be triggered by its arrival time (time-based sampling), by its position in the flow (count-based sampling) or by the packet content (content-based sampling).
標本抽出は1セットの要素(母集団)から要素(サンプル)の部分集合の系統的であるか無作為の選択について説明します。 通常、サンプリング技法を適用する目的は部分集合の原理だけを使用することによって母集団のパラメタを見積もることです。 例えば、流れのすべてのパケットからパケットの部分集合を選択するか、またはリンクにおけるすべての流れから流れの部分集合を選択するためにサンプリング技法を適用できます。 標本抽出メソッドがそれらのサンプリング戦略において異なる、(例えば、系統的であるか無作為である、)、要素の選択の引き金となります。 例えば、到着時間(時間ベースの標本抽出)までに1つのパケットの選択を引き起こすことができます、流れ(カウントベースの標本抽出)かパケット含有量(内容ベースの標本抽出)による位置のそばで。
The metering process may support packet sampling. If sampling is supported, the sampling configuration must be well defined. The sampling configuration includes the sampling method and all its parameters.
計量プロセスはパケット標本抽出をサポートするかもしれません。 標本抽出がサポートされるなら、標本抽出構成をよく定義しなければなりません。 標本抽出構成は標本抽出メソッドとそのすべてのパラメタを含んでいます。
If the sampling configuration is changed during operation, the new sampling configuration with its parameters must be indicated to all collecting processes receiving the affected flow records. Changing the sampling configuration includes: adding a sampling function to the metering process, removing a sampling function from the metering process, change sampling method, and change sampling parameter(s).
操作の間、標本抽出構成を変えるなら、影響を受ける流れ記録を受け取りながらプロセスを集めながら、パラメタがある新しい標本抽出構成をすべてに示さなければなりません。 標本抽出構成を変えるは: 計量プロセスから標本抽出機能を取り除いて、計量プロセスに標本抽出機能を加えて、メソッド、および変化標本抽出パラメタを抽出しながら、変化してください。
In case of any change in the sampling configuration, all flow records metered by the previous sampling configuration must be terminated and exported according to the export configuration. The metering process must not merge the flow records generated with the new sampling configuration with the flow records generated with the previous sampling configuration.
標本抽出構成におけるどんな変化の場合には、輸出構成に従って、前の標本抽出構成によって計量されたすべての流れ記録を、終えられて、エクスポートしなければなりません。 計量プロセスは流れ記録が前の標本抽出構成で生成されている状態で新しい標本抽出構成で生成された流れ記録を合併してはいけません。
5.3. Overload Behavior
5.3. 振舞いを積みすぎてください。
In case of an overload, for example lack of memory or processing power, the metering process may change its behavior in order to cope with the lack of resources. Possible reactions include:
オーバーロード、例えば、メモリか処理能力の不足の場合には、計量プロセスは、財源不足に対処するために振舞いを変えるかもしれません。 起こりうる反応は:
Quittek, et al. Informational [Page 11] RFC 3917 IPFIX Requirements October 2004
Quittek、他 [11ページ]情報のRFC3917IPFIX要件2004年10月
- Reduce the number of flows to be metered. This can be
achieved by more coarse-grained flow measurement or by a
restriction of the flow records to a subset of the set of
original ones.
- 流れの数を減少させて、計量されてください。 より下品な流量測定かオリジナルのもののセットの部分集合への流れ記録の制限でこれを達成できます。
- Start sampling packets before they are processed by the
metering process or - if sampling is already performed -
reduce the sampling frequency.
- それらが計量プロセスによって処理される前にパケットを抽出し始めますか、または標本抽出が既に実行されるなら、サンプリング周波数を減少させてください。
- Stop metering.
- 計量するのを止めてください。
- Reducing the resource usage of competing processes on the
same device. Example: reducing the packet forwarding
throughput
- 競争するリソース用法を減少させるのは同じデバイスで処理されます。 例: パケット推進スループットを減らします。
Overload behavior is not restricted to the four options listed above. But in case the overload behavior induces a change of the metering process behavior, the overload behavior must be clearly defined.
オーバーロードの振舞いは上に記載された4つのオプションに制限されません。 しかし、オーバーロードの振舞いが計量プロセス挙動の変化を引き起こすといけないので、明確にオーバーロードの振舞いを定義しなければなりません。
For some flows, the change of behavior might have an impact on the data that would be stored in the associated flow records after the change, for example if the packet classification is changed or the sampling frequency. These flows must be considered as terminated and the associated flow records must be exported separately from new ones generated after the behavior change. The terminated flow records and new ones generated after the behavior change must not be merged by the metering process. The collecting process must be able to distinguish the affected flow records generated before and after the change of behavior. This requirement does not apply to flows and associated flow records not affected by the change of metering process behavior.
いくつかの流れのために、振舞いの変化には、例えば、パケット分類を変えるなら変化の後の関連流れ記録に保存するデータに関する影響かサンプリング周波数があるかもしれません。 終えられるとこれらの流れをみなさなければなりません、そして、別々に行動変化の後に生成された新しいものから関連流れ記録をエクスポートしなければなりません。 行動変化の後に生成された終えられた流れ記録と新しい計量プロセスによって合併されてはいけません。 収集プロセスは振舞いの変化の前後に生成された影響を受ける流れ記録を区別できなければなりません。 この要件は記録が計量プロセス挙動の変化で影響しなかった流れと関連流れに適用されません。
5.4. Timestamps
5.4. タイムスタンプ
The metering process must be able to generate timestamps for the first and the last observation of a packet of a flow at the observation point. The timestamp resolution must be at least the one of the sysUpTime [RFC3418], which is one centisecond.
計量プロセスは観測所で流れのパケットの1番目と最後の観測のためのタイムスタンプを生成することができなければなりません。 タイムスタンプ解決はsysUpTime[RFC3418]の1つであるに違いありません。(sysUpTimeは1つのセンチセカンドです)。
5.5. Time Synchronization
5.5. 時間同期化
It must be possible to synchronize timestamps generated by a metering process with Coordinated Universal Time (UTC).
計量プロセスによって生成されたタイムスタンプを協定世界時(UTC)と同期させるのは可能であるに違いありません。
Note that the possibility of synchronizing timestamps of each single metering process with UTC implies the possibility of synchronizing timestamps generated by different metering processes.
それぞれの単一の計量プロセスに関するタイムスタンプをUTCと同期させる可能性が異なった計量プロセスによって生成されたタイムスタンプを同期させる可能性を含意することに注意してください。
Quittek, et al. Informational [Page 12] RFC 3917 IPFIX Requirements October 2004
Quittek、他 [12ページ]情報のRFC3917IPFIX要件2004年10月
Note that this does not necessarily imply that timestamps generated by the metering process are UTC timestamps. For example, this requirement can be met by using local system clock values as timestamps and adding an additional timestamp when exporting a report to a collecting process. Then the collecting process can synchronize the timestamps by calculating the offset between UTC and the system clock of the metering process.
これが、計量プロセスによって生成されたタイムスタンプがUTCタイムスタンプであることを必ず含意するというわけではないことに注意してください。 例えば、タイムスタンプとしてローカルシステム時計値を使用して、収集プロセスにレポートをエクスポートするとき追加タイムスタンプを加えることによって、この必要条件を満たすことができます。 そして、収集プロセスは、UTCと計量プロセスのシステムクロックの間でオフセットを計算することによって、タイムスタンプを同期させることができます。
5.6. Flow Expiration
5.6. 流れ満了
The metering process must be able to detect flow expirations. A flow is considered to be expired if no packet of this flow has been observed for a given timeout interval. The metering process may support means for detecting the expiration of a flow before a timeout occurs, for example by detecting the FIN or RST bits in a TCP connection. The procedure for detecting a flow expiration must be clearly defined.
計量プロセスは流れを検出できなければなりません。満期。 この流れのパケットが全く与えられたタイムアウト間隔の間、観察されていないなら、流れが吐き出されると考えられます。 計量プロセスはタイムアウトが起こる前に流れの満了を検出するための手段をサポートするかもしれません、例えば、TCP接続でFINかRSTビットを検出することによって。 明確に流れ満了を検出するための手順を定義しなければなりません。
5.7. Multicast Flows
5.7. マルチキャスト流れ
For multicast flows containing packets replicated to multiple output interfaces, the metering process should be able to maintain discrete flow records per different output interface. For example, the metering process should be able to report an incoming multicast packet that is replicated to four output interfaces in four different flow records that differ by the output interface.
複数の出力インタフェース、計量プロセスに模写されたパケットを含む流れが維持できるべきであるマルチキャストのために、異なった出力あたりの離散的な流れ記録は連結します。 例えば、計量プロセスは出力インタフェースで異なる4つの異なった流れ記録で4つの出力インタフェースに模写される入って来るマルチキャストパケットを報告するはずであることができます。
5.8. Packet Fragmentation
5.8. パケット断片化
In case of IP packet fragmentation and depending on the classification scheme, only the zero-offset fragment of a single initial packet might contain sufficient information to classify the packet. Note that this fragment should be the first one generated by the router imposing the fragmentation [RFC791], but might not be the first one observed by the IPFIX device, due to reordering reasons. The metering process may keep state of IP packet fragmentation in order to map fragments that do not contain sufficient header information correctly to flows.
IPパケット断片化と分類体系によることの場合には、単一の初期のパケットのゼロオフセット断片だけがパケットを分類されることができるくらいの情報を含むかもしれません。 理由を再命令するためIPFIXデバイスによって観測されなかった最初のものであるかもしれないのを除いて、どんなこの断片が断片化[RFC791]を課すルータによって生成された最初のものであるべきであることに注意してください。 計量プロセスは、正しく十分なヘッダー情報を流れように含まない断片を写像するためにIPパケット断片化の状態を維持するかもしれません。
5.9. Ignore Port Copy
5.9. ポートコピーを無視してください。
The metering process may be able to ignore packets which are generated by a port copy function acting at the device where the observation point of a flow is located.
計量プロセスは流れの観測所が位置しているデバイスで行動するポートコピー機能によって生成されるパケットを無視できるかもしれません。
Quittek, et al. Informational [Page 13] RFC 3917 IPFIX Requirements October 2004
Quittek、他 [13ページ]情報のRFC3917IPFIX要件2004年10月
6. Data Export
6. データ輸出
The following are requirements for exporting flow records out of the exporting process. Beside requirements on the data transfer, we separate requirements concerning the information model from requirements concerning the data model. Furthermore, we list requirements on reporting times and notification on specific events, and on anonymization of flow records.
↓これは、輸出プロセスから流れが記録であるとエクスポートするための要件です。 データ転送に関する要件の横で、私たちは情報モデルに関してデータモデルに関して要件と要件を切り離します。 その上、私たちは特定のイベントに関する回を報告して、通知の上と、そして、流れ記録のanonymizationの上に要件をリストアップします。
6.1. Information Model
6.1. 情報モデル
The information model for the flow information export is the list of attributes of a flow to be contained in the report (including the semantics of the attributes).
流れ情報輸出のための情報モデルはレポートに含まれるべき流れの属性のリスト(属性の意味論を含んでいて)です。
This section lists attributes an exporting process must, should or may be able to report. This does not imply that each exported flow record must contain all required attributes. But it implies that it must be possible to configure the exporting process in a way that the information of all required attributes can be transmitted from the exporting process to the receiving collecting process(es) for each exported flow.
報告するべきであるか、このセクションは輸出プロセスが記載しなければならない属性を記載して、または報告できるかもしれません。 これは、それぞれのエクスポートしている流れ記録がすべての必要な属性を含まなければならないのを含意しません。 しかし、それは、流れであるとエクスポートされたそれぞれのためにプロセス(es)を集めながら輸出プロセスから受信まですべての必要な属性の情報を伝えることができる方法で輸出プロセスを構成するのが可能であるに違いないことを含意します。
In other words, meeting the IPFIX requirements means that the exporting process in general must be able, via its configuration, to somehow support to report all the must fields, even if in certain circumstances or for certain applications, only a subset of the set of all must fields is needed and effectively reported.
言い換えれば、IPFIX必要条件を満たすのは、一般に、輸出プロセスがすべての必須分野を報告するために構成でどうにかサポートするのにできなければならないことを意味します、すべての必須分野のセットの部分集合だけが、ある事情かあるアプリケーションにおいて必要であり、事実上報告されても。
Beyond that, the exporting process might offer to report further attributes not mentioned here. A particular flow record may contain some of the "required" attributes as well as some additional ones, for example covering future technologies.
それを超えて、輸出プロセスは、属性にここに言及されていないとさらに報告すると申し出るかもしれません。 特定の流れ記録はいくつかの追加ものと同様に「必要な」属性のいくつかを含むかもしれません、例えば、未来の技術をカバーしていて。
This document does not impose that the following attributes are reported for every single flow record, especially for repetitive attributes. For example, if the observation point is the incoming packet stream at the IP interface with the ifIndex value 3, then this observation point does not have to be exported as part of every single flow record. Exporting it just once might give sufficient information to the collecting process.
このドキュメントはでしゃばりません。以下の属性はあらゆる流れ記録と、特に反復性の属性のために報告されます。 例えば、観測所がifIndex値3とのIPインタフェースの入って来るパケットストリームであるなら、この観測所はあらゆる流れ記録の一部としてエクスポートされる必要はありません。 一度だけそれをエクスポートすると、十分な情報は収集プロセスに与えられるかもしれません。
The exporting process must be able to report the following attributes for each metered flow:
輸出プロセスは、それぞれに計量されたので以下の属性が流れると報告できなければなりません:
1. IP version number
This requirement only applies if the observation point is
located at a device supporting more than one version of IP.
1. 観測所がIPの1つ以上のバージョンをサポートしながらデバイスに位置している場合にだけ、IPバージョン数のThis要件は適用されます。
Quittek, et al. Informational [Page 14] RFC 3917 IPFIX Requirements October 2004
Quittek、他 [14ページ]情報のRFC3917IPFIX要件2004年10月
2. source IP address
3. destination IP address
4. IP protocol type (TCP,UDP,ICMP,...)
5. if protocol type is TCP or UDP: source TCP/UDP port number
6. if protocol type is TCP or UDP: destination TCP/UDP port
number
7. packet counter
If a packet is fragmented, each fragment is counted as an
individual packet.
8. byte counter
The sum of the total length in bytes of all IP packets
belonging to the flow. The total length of a packet covers IP
header and IP payload.
9. type of service octet (in case of IPv4), traffic class octet
(in case of IPv6). According to [RFC2474], these octets
include the DiffServ Code Point that has a length of 6 bits.
10. in case of IPv6: Flow Label
11. if MPLS is supported at the observation point: the top MPLS
label or the corresponding forwarding equivalence class (FEC,
[RFC3031]) bound to that label. The FEC is typically defined
by an IP prefix.
12. timestamp of the first packet of the flow
13. timestamp of the last packet of the flow
14. if sampling is used: sampling configuration
15. unique identifier of the observation point
16. unique identifier of the exporting process
2. ソースIPアドレス3送付先IPアドレス4。 IPプロトコルタイプ(TCP、UDP、ICMP) 5. プロトコルタイプはTCPであるか、そして、UDP: ソースTCP/UDPは6 プロトコルタイプがTCPかUDPであるなら数を移植します: 目的地TCP/UDPポートナンバー7パケットカウンタIf aパケットは断片化されて、各断片は個々のパケットにみなされます。 8. バイトは流れに属すすべてのIPパケットのバイトで表現される全長の合計を打ち返します。 パケットの全長はIPヘッダーとIPペイロードを含んでいます。 9. サービス八重奏(IPv4の場合の)、トラフィッククラス八重奏(IPv6の場合の)のタイプ。 [RFC2474]に従って、これらの八重奏は6ビットの長さを持っているDiffServ Code Pointを含んでいます。 10.、IPv6の場合に: MPLSが観測のときにサポートされるなら、流れLabel11は指します: MPLSがラベルする先端か対応する推進同値類(FEC、[RFC3031])がそのラベルにバウンドします。 FECはIP接頭語によって通常定義されます。 12. 14 抽出するなら、流れの最後のパケットに関する流れ13タイムスタンプの最初のパケットのタイムスタンプは使用されています: 観測の構成の15のユニークな識別子を抽出して、輸出プロセスの16のユニークな識別子を指してください。
The exporting process should be able to report the following attributes for each metered flow:
輸出プロセスは、それぞれに計量されたので以下の属性が流れると報告するはずであることができます:
17. if protocol type is ICMP: ICMP type and code
18. input interface (ifIndex)
This requirement does not apply if the observation point is
located at a probe device.
19. output interface (ifIndex)
This requirement does not apply if the observation point is
located at a probe device.
20. multicast replication factor
the number of outgoing packets originating from a single
incoming multicast packet. This is a dynamic property of
multicast flows, that may change over time. For unicast flows
it has the constant value 1. The reported value must be the
value of the factor at the time the flow record is exported.
17. プロトコルタイプがICMPであるなら: ICMPはタイプします、そして、観測所が徹底的調査デバイスに位置しているなら、この要件がするコード18入力インタフェース(ifIndex)は適用されません。 19. 観測所が徹底的調査デバイスに位置しているなら、この要件がする出力インタフェース(ifIndex)は適用しません。 20. マルチキャスト模写は単一の入って来るマルチキャストパケットから発する出発しているパケットの数を因数分解します。 これがマルチキャスト流れの動的性質である、それは時間がたつにつれて、変化するかもしれません。 定数がそれで1に評価するユニキャスト流れのために 流れ記録がエクスポートされるとき、報告された値は要素の値でなければなりません。
The exporting process may be able to report the following attributes for each metered flow:
輸出プロセスは、それぞれに計量されたので以下の属性が流れると報告できるかもしれません:
21. Time To Live (in case of IPv4) or Hop Limit (in case of IPv6)
21. 時間To Live(IPv4の場合の)かHop Limit(IPv6の場合の)
Quittek, et al. Informational [Page 15] RFC 3917 IPFIX Requirements October 2004
Quittek、他 [15ページ]情報のRFC3917IPFIX要件2004年10月
22. IP header flags
23. TCP header flags
24. dropped packet counter at the observation point
If a packet is fragmented, each fragment must be counted as an
individual packet.
25. fragmented packet counter
counter of all packets for which the fragmented bit is set in
the IP header
26. next hop IP address
27. source BGP Autonomous System number (see [RFC1771])
28. destination BGP Autonomous System number
29. next hop BGP Autonomous System number
22. IPヘッダーは23に旗を揚げさせます。 TCPヘッダーはパケットが断片化されて、個々のパケットに各断片をみなさなければならないという観測ポイントIfで24の下げられたパケットカウンタに旗を揚げさせます。 25. 断片化しているビットがIPヘッダーに次の26ホップIPアドレス27ソースBGP Autonomous System番号([RFC1771]を見る)28目的地BGP Autonomous System No.29次のホップBGP Autonomous System番号を設定することであるすべてのパケットの断片化しているパケットカウンタカウンタ
6.2. Data Model
6.2. データモデル
The data model describes how information is represented in flow records.
データモデルは情報が流れ記録にどう表されるかを説明します。
The data model must be extensible for future attributes to be added. Even if a set of attributes is fixed in the flow record, the data model must provide a way of extending the record by configuration or for certain implementations.
将来の属性が加えられるのにおいてデータモデルは広げることができるに違いありません。 1セットの属性が流れ記録で修理されていても、データモデルは構成かある実装のための記録を広げる方法を提供しなければなりません。
The data model used for exporting flow information must be flexible concerning the flow attributes contained in flow records. A flexible record format would offer the possibility of defining records in a flexible (customizable) way regarding the number and type of contained attributes.
流れが情報であるとエクスポートするのに使用されるデータモデルは流れ記録に含まれた流れ属性に関してフレキシブルであるに違いありません。 フレキシブルなレコード形式は含まれた属性の数とタイプに関するフレキシブルな(カスタマイズ可能な)方法で記録を定義する可能性を提供するでしょう。
The data model should be independent of the underlying transport protocol, i.e., the data transfer.
データモデルはすなわち、基本的なトランスポート・プロトコル、データ転送から独立しているべきです。
6.3. Data Transfer
6.3. データ転送
Requirements for the data transfer include reliability, congestion awareness, and security requirements. For meeting these requirements the exporting process can utilize existing security features provided by the device hosting the process and/or provided by the transport network. For example it can use existing security technologies for authentication and encryption or it can rely on physical protection of a separated network for transferring flow information.
データ転送のための要件は信頼性、混雑認識、およびセキュリティ要件を含んでいます。 これらの必要条件を満たすために、輸出プロセスはプロセスを接待するデバイスで提供する、そして/または、転送ネットワークによって提供された既存のセキュリティ機能を利用できます。 認証と暗号化に既存のセキュリティー技術を使用できますか、またはそれは、流れ情報を移すために切り離されたネットワークの物理的防護に依存できます。
6.3.1. Congestion Awareness
6.3.1. 混雑認識
For the data transfer, a congestion aware protocol must be supported.
データ転送において、混雑の意識しているプロトコルをサポートしなければなりません。
Quittek, et al. Informational [Page 16] RFC 3917 IPFIX Requirements October 2004
Quittek、他 [16ページ]情報のRFC3917IPFIX要件2004年10月
6.3.2. Reliability
6.3.2. 信頼性
Loss of flow records during the data transfer from the exporting process to the collecting process must be indicated at the collecting process. This indication must allow the collecting process to gauge the number of flow records lost. Possible reasons for flow records loss include but are not limited to:
収集プロセスで輸出プロセスから収集プロセスまでのデータ転送の間の流れ記録の損失を示さなければなりません。 この指示で、収集プロセスは記録が失った流れの数を測ることができなければなりません。 しかし記録の損失が含む流れの可能な理由は以下のことのために制限されません。
1. Metering process limitations: lack of memory, processing power,
etc. These limitations are already covered in section 5.1.
1. 計量して、制限を処理してください: メモリの不足、処理能力など これらの制限はセクション5.1で既にカバーされています。
2. Exporting process limitations: lack of memory, processing
power, etc.
2. 輸出プロセス制限: メモリの不足、処理能力など
3. Data transfer problems: packets that carry flow records sent
from the exporting process to the collecting process, are
dropped by the network. Examples are connection failures and
losses by a transport protocol that specifically offers
congestion avoidance without persistent transport-level
reliability.
3. データ転送問題: 流れ記録を運ぶパケットが、輸出プロセスから収集プロセスまで発信して、ネットワークによって下げられます。 例は、永続的な輸送レベルの信頼性なしで輻輳回避を明確に提供するトランスポート・プロトコルによる、接続失敗と損失です。
4. Collecting process limitations: it may be experiencing
congestion and not able to buffer new flows records.
4. 集まって、制限を処理してください: それは、混雑を経験していて、新しい流れ記録をバッファリングできないかもしれません。
5. Operation and Maintenance: the collecting process is taken down
for maintenance or other administrative purposes.
5. 維持管理: 収集プロセスはメインテナンスか他の管理目的のために降ろされます。
Please note that if an unreliable transport protocol is used, reliability can be provided by higher layers. If reliability is provided by higher layers, only lack of overall reliability must be indicated. For example reordering could be dealt with by adding a sequence number to each packet.
頼り無いトランスポート・プロトコルが使用されているなら、より高い層のそばで信頼性を提供できます。 より高い層のそばで信頼性を提供するなら、総合的な信頼性の不足だけを示さなければなりません。 各パケットに一連番号を加えることによって、例えば、再命令に対処できるでしょう。
The data transfer between exporting process and collecting process must be open to reliability extensions including at least
プロセスをエクスポートして、プロセスを集めることの間のデータ転送は少なくとも信頼性の拡大包含に開かれているに違いありません。
- retransmission of lost flow records,
- detection of disconnection and fail-over, and
- acknowledgement of flow records by the collecting process.
- そして、無くなっている流れ記録の「再-トランスミッション」--断線とフェイルオーバーの検出、--収集プロセスによる流れ記録の承認。
This extensibility may be used to provide additional reliability. The extended protocol must still meet the requirements described in this section, particularly, it must still be congestion aware. Therefore, extensions using retransmissions must use exponential backoff.
この伸展性は、追加信頼性を提供するのに使用されるかもしれません。 特に、それは混雑拡張プロトコルがまだこのセクションで説明された必要条件を満たさなければならないのをまだ意識していなければなりません。 したがって、「再-トランスミッション」を使用する拡大は指数のbackoffを使用しなければなりません。
Quittek, et al. Informational [Page 17] RFC 3917 IPFIX Requirements October 2004
Quittek、他 [17ページ]情報のRFC3917IPFIX要件2004年10月
6.3.3. Security
6.3.3. セキュリティ
Confidentiality of IPFIX data transferred from an exporting process to a collecting process must be ensured.
輸出プロセスから収集プロセスまで移されたIPFIXデータの秘密性を確実にしなければなりません。
Integrity of IPFIX data transferred from an exporting process to a collecting process must be ensured.
輸出プロセスから収集プロセスまで移されたIPFIXデータの保全を確実にしなければなりません。
Authenticity of IPFIX data transferred from an exporting process to a collecting process must be ensured.
輸出プロセスから収集プロセスまで移されたIPFIXデータの信憑性を確実にしなければなりません。
The security requirements have been derived from an analysis of potential security threads. The analysis is summarized in Section 10.
潜在的セキュリティスレッドの分析からセキュリティ要件を得ました。 分析はセクション10にまとめられます。
6.4. Push and Pull Mode Reporting
6.4. モード報告を押して、引いてください。
In general, there are two ways of deciding on reporting times: push mode and pull mode. In push mode, the exporting process decides without an external trigger when to send flow records. In pull mode, sending flow records is triggered by an explicit request from a collecting process. The exporting process must support push mode reporting, it may support pull mode reporting.
一般に、回を報告すると決める2つの方法があります: モードを押してください、そして、モードを引いてください。 プッシュモードで、輸出プロセスは、外部トリガーなしでいつ流れ記録を送るかを決めます。 牽引力のモードで、流れ記録を送るのは収集プロセスからの明白な要求で引き起こされます。 輸出プロセスはプッシュモード報告をサポートしなければならなくて、それは牽引力のモード報告をサポートするかもしれません。
6.5. Regular Reporting Interval
6.5. 一定の報告間隔
The exporting process should be capable of reporting measured traffic data regularly according to a given interval length.
与えられた間隔の長さに従って、輸出プロセスは定期的に測定トラフィックデータを報告できるべきです。
6.6. Notification on Specific Events
6.6. 特定のイベントに関する通知
The exporting process may be capable of sending notifications to a collecting process, if a specific event occurs. Such an event can be, for instance, the arrival of the first packet of a new flow, or the termination of a flow after flow timeout.
特定のイベントが起こるなら、輸出プロセスは収集プロセスに通告を送ることができるかもしれません。 例えば、そのようなイベントは、新しい流れの最初のパケットの到着、または流れタイムアウトの後の流れの終了であるかもしれません。
6.7. Anonymization
6.7. Anonymization
The exporting process may be capable of anonymizing source and destination IP addresses in flow data before exporting them. It may support anonymization of port numbers and other fields. Please note that anonymization is not originally an application requirement, but derived from general requirements for treatment of measured traffic data within a network.
それらをエクスポートする前に、輸出プロセスはフロー・データでソースと送付先IPアドレスをanonymizingすることができるかもしれません。 それはポートナンバーと他の分野のanonymizationをサポートするかもしれません。 ネットワークの中でanonymizationは元々のアプリケーション要件ではなく、測定されることの処理のための一般的な要件から派生しているトラフィックデータです。
For several applications anonymization cannot be applied, for example for accounting and traffic engineering. However, for protecting the network user's privacy, anonymization should be applied whenever
いくつかのアプリケーションにおいて、例えば、会計学と交通工学のためにanonymizationを適用できません。 しかしながら、ネットワーク利用者のプライバシーを保護するのにおいて、anonymizationが適用されるべきである、いつ
Quittek, et al. Informational [Page 18] RFC 3917 IPFIX Requirements October 2004
Quittek、他 [18ページ]情報のRFC3917IPFIX要件2004年10月
possible. In many cases it is sufficient if anonymization is performed at the collecting process after flow information has been exported. This provides a reasonable protection of privacy as long as confidentiality of the export is provided.
可能。 多くの場合、流れ情報がエクスポートされた後にanonymizationが収集プロセスで実行されるなら、十分です。 輸出の秘密性を提供する限り、これは合理的なプライバシーの保護を提供します。
It would be desirable to request that all IPFIX exporters provide anonymization of flow records, but algorithms for anonymization are still a research issue. Several are known but the security they provide and their other properties are not yet studied sufficiently. Also, there is no standardized method for anonymization. Therefore, the requirement for the exporting process supporting anonymization is qualified with 'may' and not with 'must'.
すべてのIPFIX輸出業者が流れ記録のanonymizationを提供するよう要求するのが望ましいでしょうが、それでも、anonymizationのためのアルゴリズムは研究課題です。 数個が知られていますが、彼らが提供するセキュリティと彼らの他の特性はまだ十分研究されていません。 また、anonymizationのための標準化法が全くありません。 したがって、anonymizationをサポートする輸出プロセスのための要件は'must'で資格があるのではなく、'may'で資格があります。
If anonymized flow data is exported, this must be clearly indicated to all receiving collecting processes, such that they can distinguish anonymized data from non-anonymized data.
anonymizedフロー・データがエクスポートされるなら、プロセスを集めながら、明確にすべての受信にこれを示さなければなりません、彼らが非anonymizedされたデータとanonymizedデータを区別できるように。
7. Configuration
7. 構成
If configuration is done remotely, security should be provided for the configuration process covering confidentiality, integrity, and authenticity. The means used for remote configuration are out of the scope of this document.
構成が離れて完了しているなら、秘密性、保全、および信憑性を含んでいるコンフィギュレーションプロセスにセキュリティを提供するべきです。 このドキュメントの範囲の外にリモート構成に使用される手段があります。
7.1. Configuration of the Metering Process
7.1. 計量プロセスの構成
The metering process must provide a way of configuring traffic measurement. The following parameters of the metering process should be configurable:
計量プロセスはトラフィック測定を構成する方法を提供しなければなりません。 計量プロセスの以下のパラメタは構成可能であるべきです:
1. specification of the observation point
e.g., an interface or a list of interfaces to be monitored.
2. specifications of flows to be metered
3. flow timeouts
1. 観測の仕様は、モニターされるために例えば、インタフェースかインタフェースのリストを指します。 2. 計量された3流れタイムアウトである流れの仕様
The following parameters may be configurable:
以下のパラメタは構成可能であるかもしれません:
4. sampling method and parameters, if feature is supported
5. overload behavior, if feature is supported
4. 特徴がサポートされるなら特徴が5 オーバーロードの振舞いであるとサポートされるなら、メソッドとパラメタを抽出します。
7.2. Configuration of the Exporting Process
7.2. 輸出プロセスの構成
The exporting process must provide a way of configuring the data export. The following parameters of the exporting process should be configurable:
輸出プロセスはデータ輸出を構成する方法を提供しなければなりません。 輸出プロセスの以下のパラメタは構成可能であるべきです:
1. reporting data format
Specifying the reporting data format must include a
1. データの形式Specifyingを報告して、報告データの形式はaを含まなければなりません。
Quittek, et al. Informational [Page 19] RFC 3917 IPFIX Requirements October 2004
Quittek、他 [19ページ]情報のRFC3917IPFIX要件2004年10月
selection of attributes to be reported for each flow.
2. the collecting process(es) to which flows are reported
3. the reporting interval
This requirement only applies if the exporting process
supports reporting in regular intervals.
4. notifications to be sent to the collecting process(es)
This requirement only applies if the exporting process
supports notifications.
5. flow anonymization
This requirement only applies if the exporting process
supports flow anonymization.
各流れのために報告されるべき属性の品揃え。 2. 流れが3 報告されて、報告している間隔This要件が輸出プロセスである場合にだけ適用されるということである収集プロセス(es)は一定の間隔での報告をサポートします。 4. 輸出プロセスが通知をサポートするなら、収集に送られる通知はこの要件が適用するだけである(es)を処理します。 5. 輸出プロセスが、流れがanonymizationであるとサポートする場合にだけ、流れanonymization This要件は適用されます。
8. General Requirements
8. 一般要件
8.1. Openness
8.1. 風通しの良さ
IPFIX specifications should be open to future technologies. This includes extensibility of configuration of the metering process and the exporting process.
IPFIX仕様は未来の技術に開かれているべきです。 これは計量プロセスと輸出プロセスの構成の伸展性を含んでいます。
Openness is also required concerning the extensibility of the data model, as stated in section 6.2.
また、風通しの良さがセクション6.2で述べられているようにデータモデルの伸展性に関して必要です。
8.2. Scalability
8.2. スケーラビリティ
Data collection from hundreds of different exporting processes must be supported. The collecting process must be able to distinguish several hundred exporting processes by their identifiers.
何百もの異なった輸出プロセスからのデータ収集をサポートしなければなりません。 収集プロセスはそれらの識別子で数100の輸出プロセスを区別できなければなりません。
8.3. Several Collecting Processes
8.3. いくつかの収集プロセス
The exporting process may be able to export flow information to more than one collecting process. If an exporting process is able to export flow records to multiple collecting processes then it must be able to ensure that the flow records can be identified so that duplicates can be detected between different collecting processes and double counting problems can be avoided.
輸出プロセスは、流れが情報であると1つ以上の収集プロセスにエクスポートすることができるかもしれません。 輸出プロセスが、流れが記録であると複数の収集プロセスにエクスポートすることができるなら、異なった収集プロセスの間に写しを検出できて、二重計算問題を避けることができるように流れ記録を特定できるのを保証できなければなりません。
9. Special Device Considerations
9. 特別なデバイス問題
This document intends to avoid constraining the architecture of probes, routers, and other devices hosting observation points, metering processes, exporting processes, and/or collecting processes. It can be expected that typically observation point, metering process, and exporting process are co-located at a single device. However, the requirements defined in this document do not exclude devices that derive from this configuration. Figure 2 shows some examples.
このドキュメントは、観測所を接待する徹底的調査、ルータ、および対向機器のアーキテクチャを抑制するのを避けるつもりです、プロセスを計量して、プロセスをエクスポートする、そして/または、プロセスを集めて。 通常観測ポイントと、計量プロセスと、プロセスをエクスポートするのが単一のデバイスに共同位置していると予想できます。 しかしながら、本書では定義された要件はこの構成に由来しているデバイスを除きません。 図2はいくつかの例を示しています。
Quittek, et al. Informational [Page 20] RFC 3917 IPFIX Requirements October 2004
Quittek、他 [20ページ]情報のRFC3917IPFIX要件2004年10月
All examples are composed of one or more of the following elements: observation point (O), metering process (M), exporting process (E), and collecting process (C). The observation points shown in the figure are always the most fine-granular ones supported by the respective device.
すべての例が以下の要素の1つ以上で構成されます: 観測所(O)、プロセス(E)をエクスポートして、プロセス(M)を計量して、および収集は(C)を処理します。 図に示された観測所はそれぞれのデバイスによってサポートされたいつも最も多くのすばらしい粒状のものです。
+---+ +-----+ +---------+ +---------+
| E-+-> | E--+-> | E----+-> <-+--E E--+->
| | | | | | | / \ | | | | |
| M | | M | | M M | | M M |
| | | | /|\ | | /|\ /|\ | | /|\ /|\ |
| O | | OOO | | OOO OOO | | OOO OOO |
+---+ +-----+ +---------+ +---------+
Probe Basic Complex Multiple
Router Router Exporting
Processes
+---+ +-----+ +---------+ +---------+ | 電子+の>。| E--+->。| E----+-><-+--E E--+->。| | | | | | | / \ | | | | | | M| | M| | M M| | M M| | | | | /|\ | | /|\ /|\ | | /|\ /|\ | | O| | OOO| | OOO OOO| | OOO OOO| +---+ +-----+ +---------+ +---------+ 徹底的調査の基本的な複合体の複数のルータルータ輸出プロセス
+---+ +---+ +---+
| E-+-> | E-+-> | E-+------------->---+
| | | | | | | | | +---+ +-+-----+
+-+-+ | M | | M | | E-+------->-+-C-M-E-+->
| | | | | | | | | | +---+ +-+-----+
+-+-+ +-+-+ | O | | M | | E-+->---+
| | | | +---+ | | | | | |
| M | +-+-+ | O | | M |
| | | | | | +---+ | | | +-----+
| O | | O | | O | ->-+-C-E-+->
+---+ +---+ +---+ +-----+
+---+ +---+ +---+ | 電子+の>。| 電子+の>。| 電子+------------->--+ | | | | | | | | | +---+ +-+-----+ +-+-+ | M| | M| | 電子+------->。+C M電子+の>。| | | | | | | | | | +---+ +-+-----+ +-+-+ +-+-+ | O| | M| | 電子+の>。---+ | | | | +---+ | | | | | | | M| +-+-+ | O| | M| | | | | | | +---+ | | | +-----+ | O| | O| | O| ->。+C電子+の>+---+ +---+ +---+ +-----+
Protocol Remote Concentrator Proxy
Converter Observation
プロトコルリモート・コンセントレータプロキシコンバータ観測
Figure 2: IPFIX-related Devices
図2: IPFIX関連のデバイス
A very simple device is a probe. A typical probe contains a single observation point, a single metering process, and a single exporting process.
非常に簡単なデバイスは徹底的調査です。 典型的な徹底的調査は単一の観測所、単一の計量プロセス、および単一の輸出プロセスを含んでいます。
A basic router extends this structure by multiple observation points. Here, the observation point of a particular flow may be one of the displayed most fine-granular observation points, but also it may be a set of them.
基本的なルータは複数の観測所のそばでこの構造を広げています。 ここで、特定の流れの観測所は表示されたすばらしい最も粒状の観測所の1つであるかもしれませんが、それは1セットのまたそれらであるかもしれません。
A more complex router may host more than one metering process, for example one per line card. Please note that here, the observation point of a single flow cannot exceed the set of most fine-granular observation points linked to a single metering process, because only the metering process can merge packets observed at different fine-
より複雑なルータは1つ以上の計量プロセス、例えば、系列カードあたり1つを接待するかもしれません。 ここで、ただ一つの流れの観測所が単一の計量プロセスにリンクされたほとんどのすばらしい粒状の観測所のセットを超えることができないことに注意してください、計量プロセスだけが異なった罰金で観察されたパケットを合併できるので
Quittek, et al. Informational [Page 21] RFC 3917 IPFIX Requirements October 2004
Quittek、他 [21ページ]情報のRFC3917IPFIX要件2004年10月
granular observation points to a joint flow. An observation point containing all most fine-granular observation points of this router is not possible with this structure. Alternatively, a complex router may host different exporting processes for flow records generated by different metering processes.
粒状の観測は共同流れを示します。 このルータのすべてのほとんどのすばらしい粒状の観測所を含む観測所はこの構造で可能ではありません。 あるいはまた、複雑なルータは異なった計量プロセスによって生成された流れ記録のために異なった輸出プロセスを接待するかもしれません。
A protocol converter makes use of a metering process that can be accessed only by protocol(s) other than the one defined for IPFIX, for example, the SNMP and the Meter MIB module [RFC2720]. Then the exporting process receives flow records from a remote metering process and exports these records using the IPFIX protocol. Please note that this document does not make any particular assumption on how metering processes and export processes exchange information, as long as all individual requirements for these processes are met. Also the locations of metering processes are not of any relevance for this document (in contrast to the locations of observation points and the exporting processes).
IPFIX、例えば、SNMPのために定義されたものとMeter MIBモジュール[RFC2720]を除いて、プロトコルコンバータはプロトコルだけからアクセスできる計量プロセスを利用します。 次に、輸出プロセスは、リモート計量プロセスから流れ記録を受け取って、IPFIXプロトコルを使用することでこれらの記録をエクスポートします。 このドキュメントがプロセスを計量して、輸出プロセスがどう情報交換するかに関する少しの特定の仮定もしないことに注意してください、これらのプロセスのためのすべての個々の必要条件が満たされる限り。 また、計量プロセスの位置はこのドキュメント(観測所の位置と輸出プロセスと対照して)のための少しの関連性のものではありません。
In the example of remote packet observation in Figure 2 the metering process and the observation point are not co-located. Packet headers captured at an observation point may be exported as raw data to a device hosting metering process and exporting process. Again, this document does not make any particular assumption on how packet headers are transferred from observation points to metering processes, as long as all requirements for the metering processes are met.
図2におけるリモートパケット観測に関する例では、計量プロセスと観測所は共同位置していません。 観測所で捕らわれているパケットのヘッダーは、計量を接待するデバイスへの未加工データが処理されるのでエクスポートされて、プロセスをエクスポートしているかもしれません。 一方、このドキュメントは観測所から計量プロセスまでどうパケットのヘッダーを移すかに関する少しの特定の仮定もしません、計量プロセスのためのすべての必要条件が満たされる限り。
An intermediate structure between protocol converter and remote observation (not shown in the Figure) would be a split metering process, for example performing timestamping and sampling at the device hosting the observation point and performing packet classification at another device hosting the exporting process.
プロトコルコンバータとリモート観測(図では、目立たない)の間の中間的構造は分裂計量プロセスでしょう、例えば、観測所を接待するデバイスのtimestampingと標本抽出を実行して、輸出プロセスを接待しながら別のデバイスでパケット分類を実行して。
A concentrator receives flow records via the IPFIX protocol, merges them into more aggregated flow records, and exports them again using the IPFIX protocol. Please note that for the final flow records the resulting observation point may be a superset of the more fine- granular observation points at the first level devices. The metering process of the final flow records is composed by the (partial) metering processes at the first level devices and the partial metering process at the concentrator.
集中装置は、IPFIXプロトコルで流れ記録を受け取って、さらに集められた流れ記録にそれらを合併して、再びIPFIXプロトコルを使用することでそれらをエクスポートします。 最終的な流れが結果として起こる観測所を記録するので、それは最初の平らなデバイスの、よりすばらしい粒状の観測所のスーパーセットであるかもしれません。 最終的な流れ記録の計量プロセスは最初の平らなデバイスの(部分的)の計量プロセスと集中装置の部分的な計量プロセスによって構成されます。
Finally, a very simple IPFIX-related device is a proxy. It just receives flow records using the IPFIX protocol and sends them further using the same protocol. A proxy might be useful for traversing firewalls or other gateways.
最終的に、非常に簡単なIPFIX関連のデバイスはプロキシです。 それは、IPFIXプロトコルを使用することで流れ記録をただ受け取って、さらに同じプロトコルを使用することでそれらを送ります。 プロキシはファイアウォールか他のゲートウェイを横断することの役に立つかもしれません。
Quittek, et al. Informational [Page 22] RFC 3917 IPFIX Requirements October 2004
Quittek、他 [22ページ]情報のRFC3917IPFIX要件2004年10月
10. Security Considerations
10. セキュリティ問題
An IPFIX protocol must be capable of transporting data over the public Internet. Therefore it cannot be excluded that an attacker captures or modifies packets or inserts additional packets.
IPFIXプロトコルは公共のインターネットの上でデータを輸送できなければなりません。 したがって、それを除くことができません。攻撃者は、パケットか差し込みの追加パケットをキャプチャするか、または変更します。
This section describes security requirements for IPFIX. Like other requirements, the security requirements differ among the considered applications. The incentive to modify collected data for accounting or intrusion detection for instance is usually higher than the incentive to change data collected for traffic profiling. A detailed list of the required security features per application can be found in the appendix.
このセクションはIPFIXのためのセキュリティ要件について説明します。 他の要件のように、セキュリティ要件は考えられたアプリケーションの中で異なります。 通常、例えば、会計か侵入検出のための集まっているデータを変更する誘因はデータを変える誘因がトラフィックプロフィールの寄付を募ったより高いです。 付録で1アプリケーションあたりの必要なセキュリティ機能の詳細なリストを見つけることができます。
The suggestion of concrete solutions for achieving the required security properties should be part of an IPFIX architecture and protocol. It is out of scope of this document. Also methods for remote configuration of the metering processes and exporting processes are out of scope. Therefore, threats that are caused by data exchange for remote configuration are not considered here.
必要なセキュリティの特性を獲得するための具体的なソリューションの提案はIPFIXアーキテクチャとプロトコルの一部であるべきです。 このドキュメントの範囲の外にそれはあります。 また、範囲の外に計量プロセスと輸出プロセスのリモート構成のためのメソッドがあります。 したがって、リモート構成へのデータ交換で引き起こされる脅威はここで考えられません。
The following potential security hazards for an IPFIX protocol have been identified: disclosure of IP flow information, forgery of flow records, and Denial of Service (DoS) attacks.
IPFIXプロトコルのための以下の潜在的セキュリティ危険は特定されました: IP流れ情報、流れ記録の偽造、およびサービス妨害(DoS)の公開は攻撃されます。
10.1. Disclosure of Flow Information Data
10.1. 流れインフォメーション・データの公開
The content of data exchanged by an IPFIX protocol (for example IPFIX flow records) should be kept confidential between the involved parties (exporting process and collecting process). Observation of IPFIX flow records gives an attacker information about the active flows in the network, communication endpoints and traffic patterns. This information cannot only be used to spy on user behavior but also to plan and conceal future attacks. Therefore, the requirements specified in section 6.3.3. include confidentiality of the transferred data. This can be achieved for instance by encryption.
IPFIXプロトコル(例えば、IPFIX流れ記録)によって交換されたデータの内容は関係者の間で秘密にされるべきです(プロセスをエクスポートして、収集は処理されます)。 IPFIX流れ記録の観測は、ネットワークのアクティブな流れの攻撃者情報、コミュニケーションに終点を与えて、パターンをトラフィックに与えます。 この情報は、ユーザの振舞いを探るのに使用できるだけではなく、今後の攻撃を計画して、隠すのに使用もされます。 したがって、セクション6.3で.3に指定された要件はわたっているデータの秘密性を含んでいます。 例えば、暗号化でこれを達成できます。
Also the privacy of users acting as sender or receiver of the measured traffic needs to be protected when they use the Internet. In many countries the right to store user-specific data (including the user's traffic profiles) is restricted by law or by regulations.
また、彼らがインターネットを使用すると、送付者として務めているユーザのプライバシーか測定トラフィックの受信機が、保護される必要があります。 多くの国では、ユーザ特有のデータ(ユーザのトラフィックプロフィールを含んでいる)を保存する権利が法か規則によって制限されます。
In addition to encryption, this kind of privacy can also be protected by anonymizing flow records. For many traffic flow measurements, anonymized data is as useful as precise data. Therefore, it is desirable to support anonymization in IPFIX implementations. It is beyond the scope of the IPFIX Working Group to develop and
また、暗号化に加えて、流れ記録をanonymizingすることによって、この種類のプライバシーを保護できます。 多くのトラフィック流量測定に、anonymizedデータは正確な資料と同じくらい役に立ちます。 したがって、IPFIX実装でanonymizationをサポートするのは望ましいです。 そしてそれが開発するIPFIX作業部会の範囲を超えている。
Quittek, et al. Informational [Page 23] RFC 3917 IPFIX Requirements October 2004
Quittek、他 [23ページ]情報のRFC3917IPFIX要件2004年10月
standardize anonymization methods. However, the requirements for extensibility of the IPFIX protocol are sufficient to support anonymized flow records when appropriate methods are standardized.
anonymizationメソッドを標準化してください。 しかしながら、IPFIXプロトコルの伸展性のための要件は、適切なメソッドが標準化されるとき、anonymized流れが記録であるとサポートするために十分です。
10.2. Forgery of Flow Records
10.2. 流れ記録の偽造
If flow records are used in accounting and/or security applications, there are potentially strong incentives to forge exported IPFIX flow records (for example, to save money or prevent the detection of an attack). This can be done either by altering flow records on the path or by injecting forged flow records that pretend to be originated by the original exporting process.
流れ記録が会計、そして/または、セキュリティアプリケーションで使用されるなら、エクスポートしているIPFIX流れ記録(例えば、お金を貯めるか、または攻撃の検出を防ぐ)を作り出す強い動機が潜在的にあります。 経路に関する流れ記録を変更するか、またはオリジナルの輸出プロセスによって溯源されるふりをする偽造流れ記録を注入することによって、これができます。
Special caution is required if security applications rely on flow measurements. With forged flow records it is possible to trick security applications. For example, an application may be lead to falsely conclude that a DoS attack is in progress. If such an injection of IPFIX traffic flow records fools the security application, causing it to erroneously conclude that a DoS attack is underway, then the countermeasures employed by the security application may actually deny useful non-malicious services.
セキュリティアプリケーションが流量測定に依存するなら、特別な警告が必要です。 偽造流れ記録では、セキュリティアプリケーションをだますのは可能です。 例えば、アプリケーションは、DoS攻撃が進行していると間違って結論を下すためにはリードであるかもしれません。 DoS攻撃が進行中であると誤って結論を下すことを引き起こして、IPFIX交通の流れ記録のそのような注射がセキュリティアプリケーションをだますなら、セキュリティアプリケーションで使われた対策は実際に役に立つ非悪意があるサービスを否定するかもしれません。
In order to make an IPFIX protocol resistant against such attacks, authentication and integrity must be provided, as specified in section 6.3.3.
IPFIXプロトコルをそのような攻撃に対して抵抗力があるようにするように、認証と保全を提供しなければなりません、セクション6.3.3で指定されるように。
10.3. Denial of Service (DoS) Attacks
10.3. サービス妨害(DoS)攻撃
DoS attacks on routers or other middleboxes that have the IPFIX protocol implemented would also affect the IPFIX protocol and impair the sending of IPFIX records. Nevertheless, since such hazards are not induced specifically by the IPFIX protocol the prevention of such attacks is out of scope of this document.
ルータに対するDoS攻撃かIPFIXプロトコルを実装させる他のmiddleboxesがまた、IPFIXプロトコルに影響して、IPFIX記録の発信を損なうでしょう。 それにもかかわらず、そのような危険が特にIPFIXプロトコルによって引き起こされていないので、このドキュメントの範囲の外にそのような攻撃の防止があります。
However, IPFIX itself also causes potential hazards for DoS attacks. All processes that expect the reception of traffic can be target of a DoS attack. With the exporting process this is only the case if it supports the pull mode (which can be an optional feature of the IPFIX protocol according to this document). The collecting process always expects data and therefore can be flooded by flow records.
しかしながら、また、IPFIX自身はDoS攻撃のために潜在的な危険を引き起こします。 トラフィックのレセプションを予想するすべてのプロセスがDoS攻撃の目標であるかもしれません。 輸出プロセスで、牽引力がモード(このドキュメントに従ったIPFIXプロトコルに関するオプション機能であるかもしれない)であるとサポートするなら、唯一のこれはそうです。 収集プロセスは、いつもデータを予想して、したがって、流れ記録であふれさせることができます。
Quittek, et al. Informational [Page 24] RFC 3917 IPFIX Requirements October 2004
Quittek、他 [24ページ]情報のRFC3917IPFIX要件2004年10月
11. Acknowledgments
11. 承認
Many thanks to Georg Carle for contributing to the application analysis, to K.C. Norseth for several fine-tunings, to Sandra Tartarelli for checking the appendix, and to a lot of people on the mailing list for providing valuable comments and suggestions including Nevil Brownlee, Carter Bullard, Paul Calato, Ram Gopal, Tal Givoly, Jeff Meyer, Reinaldo Penno, Sonia Panchen, Simon Leinen, David Plonka, Ganesh Sadasivan, Kevin Zhang, and many more.
付録をチェックするためにアプリケーション分析、いくつかの微調整のためのK.C.Norseth、サンドラTartarelliに貢献するためのゲオルクCarleと、そして、ネヴィル・ブラウンリー、カーター・ブラード、ポールCalato、Ramゴパル、タルGivoly、ジェフ・マイヤー、レイナルド・ペンノ、ソニア・パンチェン、サイモンLeinen、デヴィッドPlonka、ガネッシュSadasivan、ケビン・チャン、およびずっと多くを含む貴重なコメントと提案を提供するためのメーリングリストの多くの人々をありがとうございます。
Quittek, et al. Informational [Page 25] RFC 3917 IPFIX Requirements October 2004
Quittek、他 [25ページ]情報のRFC3917IPFIX要件2004年10月
12. Appendix: Derivation of Requirements from Applications
12. 付録: アプリケーションからの要件の派生
The following table documents, how the requirements stated in sections 3-7 are derived from requirements of the applications listed in section 2.
以下はドキュメントを見送ります、セクション2で記載されたアプリケーションの要件からセクション3-7で述べられた要件をどう得るか。
Used abbreviations:
M = must
S = should
O = may (optional)
- = DONT CARE
中古の略語: = =がそうする○(任意の)--ドントと等しいのが気にかけるなら、Mは必須Sと等しいです。
-----------------------------------------------------------------------.
IPFIX |
----------------------------------------------------------------. |
E: QoS Monitoring | |
----------------------------------------------------------. | |
D: Attack/Intrusion Detection | | |
----------------------------------------------------. | | |
C: Traffic Engineering | | | |
----------------------------------------------. | | | |
B: Traffic Profiling | | | | |
----------------------------------------. | | | | |
A: Usage-based Accounting | | | | | |
----------------------------------. | | | | | |
| | | | | | |
| Sect. | Requirement | A | B | C | D | E | IPFIX|
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 4. | DISTINGUISHING FLOWS |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 4. | Combination of | M | M | M | M | M | M |
| | required attributes | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 4.1. | in/out IF | S | M | M | S | S | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 4.2. | src/dst address | M | M | M | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 4.2. | Masking of IP addresses | M | M | M | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 4.2. | transport protocol | M | M | - | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 4.2. | version field | - | S | S | O | O | S |
| | | | | (b) | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
-----------------------------------------------------------------------. IPFIX| ----------------------------------------------------------------. | E: QoSモニター| | ----------------------------------------------------------. | | D: 攻撃/侵入検出| | | ----------------------------------------------------. | | | C: 交通工学| | | | ----------------------------------------------. | | | | B: トラフィックプロフィール| | | | | ----------------------------------------. | | | | | A: 用法ベースの会計| | | | | | ----------------------------------. | | | | | | | | | | | | | | セクト。 | 要件| A| B| C| D| E| IPFIX| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 4. | 区別は流れます。| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 4. | 組み合わせ| M| M| M| M| M| M| | | 必要な属性| | | | | | | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 4.1. | コネ/アウト| S| M| M| S| S| M| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 4.2. | src/dstアドレス| M| M| M| M| M| M| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 4.2. | IPアドレスのマスキング| M| M| M| M| M| M| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 4.2. | トランスポート・プロトコル| M| M| - | M| M| M| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 4.2. | バージョン分野| - | S| S| O| O| S| | | | | | (b) | | | | |-------+-------------------------+-----+-----+-----+-----+-----+------|
Quittek, et al. Informational [Page 26] RFC 3917 IPFIX Requirements October 2004
Quittek、他 [26ページ]情報のRFC3917IPFIX要件2004年10月
|-------+-------------------------+-----+-----+-----+-----+-----+------| | Sect. | Requirement | A | B | C | D | E | IPFIX| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 4.3. | src/dst port | M | M | - | M | M | M | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 4.4. | MPLS label (a) | S | S | M | O | S | M | | | | | | (c) | | | | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 4.5. | DSCP (a) | M | S | M | O | M | M | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 5. | METERING PROCESS | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 5.1. | Reliability | M | S | S | S | S | | |-------+-------------------------+-----+-----+-----+-----+-----+ M | | 5.1. | Indication of | - | M | M | M | M | | | | missing reliability | | | | | | | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 5.2. | Sampling (d,e) | O | O | O | O | O | O | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 5.3. | Overload Behavior (f) | O | O | O | O | O | O | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 5.4. | Timestamps | M | O | O | S | M | M | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 5.5. | Time synchronization | M | S | S | S | M | M | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 5.6. | Flow timeout | M | S | - | O | O | M | | | | (g) | | | | | | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 5.7. | Multicast flows | S | O | O | O | S | S | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 5.8. | Packet fragmentation | O | O | - | - | - | O | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 5.9. | Ignore port copy | O | O | O | O | O | O | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6. | DATA EXPORT | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.1. | INFORMATION MODEL | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.1. | IP Version | - | M | M | O | O | M | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.1. | src/dst address | M | M | M | M | M | M | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.1. | transport protocol | M | M | - | M | M | M | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.1. | src/dst port | M | M | - | M | M | M | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.1. | Packet counter (h) | S | M | M | S | S | M | |-------+-------------------------+-----+-----+-----+-----+-----+------|
|-------+-------------------------+-----+-----+-----+-----+-----+------| | セクト。 | 要件| A| B| C| D| E| IPFIX| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 4.3. | src/dstポート| M| M| - | M| M| M| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 4.4. | MPLSラベル(a)| S| S| M| O| S| M| | | | | | (c) | | | | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 4.5. | DSCP(a)| M| S| M| O| M| M| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 5. | 計量プロセス| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 5.1. | 信頼性| M| S| S| S| S| | |-------+-------------------------+-----+-----+-----+-----+-----+ M| | 5.1. | 指示| - | M| M| M| M| | | | なくなった信頼性| | | | | | | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 5.2. | 標本抽出(d、e)| O| O| O| O| O| O| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 5.3. | 振舞い(f)を積みすぎてください。| O| O| O| O| O| O| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 5.4. | タイムスタンプ| M| O| O| S| M| M| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 5.5. | 時間同期化| M| S| S| S| M| M| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 5.6. | 流れタイムアウト| M| S| - | O| O| M| | | | (g) | | | | | | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 5.7. | マルチキャスト流れ| S| O| O| O| S| S| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 5.8. | パケット断片化| O| O| - | - | - | O| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 5.9. | ポートコピーを無視してください。| O| O| O| O| O| O| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6. | データ輸出| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.1. | 情報モデル| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.1. | IPバージョン| - | M| M| O| O| M| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.1. | src/dstアドレス| M| M| M| M| M| M| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.1. | トランスポート・プロトコル| M| M| - | M| M| M| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.1. | src/dstポート| M| M| - | M| M| M| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.1. | パケットカウンタ(h)| S| M| M| S| S| M| |-------+-------------------------+-----+-----+-----+-----+-----+------|
Quittek, et al. Informational [Page 27] RFC 3917 IPFIX Requirements October 2004
Quittek、他 [27ページ]情報のRFC3917IPFIX要件2004年10月
|-------+-------------------------+-----+-----+-----+-----+-----+------| | Sect. | Requirement | A | B | C | D | E | IPFIX| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.1. | Byte counter | M | M | M | S | S | M | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.1. | ToS (IPv4) or traffic | M | S | M | O | M | M | | | class octet (IPv6) | | | | | | | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.1. | Flow Label (IPv6) | M | S | M | O | M | M | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.1. | MPLS label (a) | S | S | M | O | S | M | | | | | | (c) | | | | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.1. | Timestamps for | M | O | O | S | S | M | | | first/last packet | | | | | | | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.1. | Sampling configuration | M | M | M | M | M | M | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.1. | observation point | M | M | M | M | M | M | | | identifier | | | | | | | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.1. | export process | M | M | M | M | M | M | | | identifier | | | | | | | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.1. | ICMP type and code (i) | S | S | - | S | S | S | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.1. | input/output interface | S | S | S | S | S | S | | | (j) | | | | | | | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.1. | Multicast | O | S | S | - | S | S | | | replication factor | | | | | | | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.1. | TTL | O | O | O | O | O | O | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.1. | IP header flags | - | O | O | O | O | O | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.1. | TCP header flags | - | O | O | O | - | O | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.1. | Dropped Packet | O | O | O | O | O | O | | | Counter (h,k) | | | | | | | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.1. | Fragment counter | - | O | O | O | O | O | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.1. | next hop IP address | O | O | O | O | - | O | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.1. | src / dst / next hop | - | O | O | - | - | O | | | BGP AS # | | | | | | | |-------+-------------------------+-----+-----+-----+-----+-----+------|
|-------+-------------------------+-----+-----+-----+-----+-----+------| | セクト。 | 要件| A| B| C| D| E| IPFIX| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.1. | バイトカウンタ| M| M| M| S| S| M| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.1. | ToS(IPv4)かトラフィック| M| S| M| O| M| M| | | クラス八重奏(IPv6)| | | | | | | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.1. | 流れラベル(IPv6)| M| S| M| O| M| M| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.1. | MPLSラベル(a)| S| S| M| O| S| M| | | | | | (c) | | | | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.1. | タイムスタンプ| M| O| O| S| S| M| | | 最後の最初/のパケット| | | | | | | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.1. | 標本抽出構成| M| M| M| M| M| M| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.1. | 観測所| M| M| M| M| M| M| | | 識別子| | | | | | | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.1. | 輸出プロセス| M| M| M| M| M| M| | | 識別子| | | | | | | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.1. | ICMPタイプとコード(i)| S| S| - | S| S| S| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.1. | I/Oインターフェース| S| S| S| S| S| S| | | (j) | | | | | | | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.1. | マルチキャスト| O| S| S| - | S| S| | | 模写要素| | | | | | | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.1. | TTL| O| O| O| O| O| O| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.1. | IPヘッダー旗| - | O| O| O| O| O| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.1. | TCPヘッダー旗| - | O| O| O| - | O| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.1. | 下げられたパケット| O| O| O| O| O| O| | | (h、k)を打ち返してください。| | | | | | | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.1. | 断片カウンタ| - | O| O| O| O| O| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.1. | 次のホップIPアドレス| O| O| O| O| - | O| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.1. | 次のsrc / dst /は跳びます。| - | O| O| - | - | O| | | #としてのBGP| | | | | | | |-------+-------------------------+-----+-----+-----+-----+-----+------|
Quittek, et al. Informational [Page 28] RFC 3917 IPFIX Requirements October 2004
Quittek、他 [28ページ]情報のRFC3917IPFIX要件2004年10月
|-------+-------------------------+-----+-----+-----+-----+-----+------| | Sect. | Requirement | A | B | C | D | E | IPFIX| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.2. | DATA MODEL | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.2. | Flexibility | M | S | M | M | M | M | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.2. | Extensibility | M | S | M | M | M | M | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.3. | DATA TRANSFER | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.3.1.| Congestion aware | M | M | M | M | M | M | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.3.2.| Reliability | M | S | S | S | S | M | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.3.3.| Confidentiality | M | S | S | M | S | M | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.3.4.| Integrity | M | M | M | M | M | M | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.3.5.| Authenticity | M | M | M | M | M | M | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.4. | REPORTING TIMES | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.4. | Push mode | M | O | O | M | S | M | | | | | (l) | (l) | |(l,m)| | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.4. | Pull mode | O | O | O | O | O | O | | | | | (l) | (l) | | (l) | | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.4.1.| Regular interval | S | S | S | S | S | S | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.6. | Notifications | O | O | O | O | O | O | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.7. | Anonymization (n) | O | O | O | O | O | O | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 7. | CONFIGURATION | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 7. | Secure remote | S | S | S | S | S | S | | | configuration (a) | | | | | | | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 7.1. | Config observation point| S | S | S | S | S | S | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 7.1. | Config flow | S | S | S | S | S | S | | | specifications | | | | | | | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 7.1. | Config flow timeouts | S | S | S | S | O | S | |-------+-------------------------+-----+-----+-----+-----+-----+------|
|-------+-------------------------+-----+-----+-----+-----+-----+------| | セクト。 | 要件| A| B| C| D| E| IPFIX| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.2. | データモデル| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.2. | 柔軟性| M| S| M| M| M| M| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.2. | 伸展性| M| S| M| M| M| M| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.3. | データ転送| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.3.1. | 混雑、意識| M| M| M| M| M| M| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.3.2. | 信頼性| M| S| S| S| S| M| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.3.3. | 秘密性| M| S| S| M| S| M| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.3.4. | 保全| M| M| M| M| M| M| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.3.5. | 信憑性| M| M| M| M| M| M| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.4. | 回を報告します。| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.4. | モードを押してください。| M| O| O| M| S| M| | | | | (l) | (l) | |(l、m)| | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.4. | モードを引いてください。| O| O| O| O| O| O| | | | | (l) | (l) | | (l) | | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.4.1. | 一定の間隔| S| S| S| S| S| S| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.6. | 通知| O| O| O| O| O| O| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 6.7. | Anonymization(n)| O| O| O| O| O| O| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 7. | 構成| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 7. | 安全である、リモート| S| S| S| S| S| S| | | 構成(a)| | | | | | | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 7.1. | コンフィグ観測所| S| S| S| S| S| S| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 7.1. | コンフィグ流動| S| S| S| S| S| S| | | 仕様| | | | | | | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 7.1. | コンフィグ流れタイムアウト| S| S| S| S| O| S| |-------+-------------------------+-----+-----+-----+-----+-----+------|
Quittek, et al. Informational [Page 29] RFC 3917 IPFIX Requirements October 2004
Quittek、他 [29ページ]情報のRFC3917IPFIX要件2004年10月
|-------+-------------------------+-----+-----+-----+-----+-----+------| | Sect. | Requirement | A | B | C | D | E | IPFIX| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 7.1. | Config sampling | O | O | O | O | O | O | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 7.1. | Config overload | O | O | O | O | O | O | | | behavior (a) | | | | | | | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 7.2. | Config report | S | S | S | S | S | S | | | data format | | | | | | | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 7.2. | Config | S | S | S | S | S | S | | | notifications | | | | | | | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 8. | GENERAL REQUIREMENTS | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 8.1. | Openness | S | S | S | S | S | S | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 8.2. | Scalability: | | | | | | | | | data collection | M | S | M | O | S | M | | | from hundreds of | | | | | | | | | measurement devices | | | | | | | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 8.3. | Several collectors | O | O | O | O | O | O | |-------+-------------------------+-----+-----+-----+-----+-----+------|
|-------+-------------------------+-----+-----+-----+-----+-----+------| | セクト。 | 要件| A| B| C| D| E| IPFIX| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 7.1. | コンフィグ標本抽出| O| O| O| O| O| O| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 7.1. | コンフィグオーバーロード| O| O| O| O| O| O| | | 振舞い(a)| | | | | | | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 7.2. | コンフィグレポート| S| S| S| S| S| S| | | データの形式| | | | | | | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 7.2. | コンフィグ| S| S| S| S| S| S| | | 通知| | | | | | | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 8. | 一般的な要件| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 8.1. | 風通しの良さ| S| S| S| S| S| S| |-------+-------------------------+-----+-----+-----+-----+-----+------| | 8.2. | スケーラビリティ: | | | | | | | | | データ収集| M| S| M| O| S| M| | | 何百| | | | | | | | | 測定デバイス| | | | | | | |-------+-------------------------+-----+-----+-----+-----+-----+------| | 8.3. | 数人のコレクタ| O| O| O| O| O| O| |-------+-------------------------+-----+-----+-----+-----+-----+------|
Remarks:
所見:
(a) If feature is supported.
(b) The differentiation of IPv4 and IPv6 is for TE of importance.
So we tended to make this a must. Nevertheless, a should
seems to be sufficient to perform most TE tasks and allows us
to have a should for IPFIX instead of a must.
(c) For TE in an MPLS network the label is essential. Therefore a
must is given here leading to a must in IPFIX.
(d) If sampling is supported, the methods and parameters must be
well defined.
(e) If sampling is supported, sampling configuration changes must
be indicated to all collecting processes.
(f) If overload behavior is supported and it induces changes in
the metering process behavior, the overload behavior must be
clearly defined.
(g) Precise time-based accounting requires reaction to a flow
timeout.
(h) If a packet is fragmented, each fragment is counted as an
individual packet.
(i) If protocol type is ICMP.
(a) 特徴が支持されるなら。 (b) IPv4とIPv6の分化は重要なTEのためのものです。 それで、私たちは、この絶対に必要なものを作る傾向がありました。 それにもかかわらず、aは思えるべきです。絶対に必要なものの代わりにIPFIXに関して実行できるくらい、TEがaを持っているのを私たちに仕事を課して、許容する大部分がそうするべきであるように思えます。 (c) MPLSネットワークにおけるTEに関しては、ラベルは不可欠です。 したがって、IPFIXの絶対に必要なものに通じながら、絶対に必要なものをここに与えます。 (d) 標本抽出が支持されるなら、方法とパラメタをよく定義しなければなりません。 (e) 標本抽出が支持されるなら、すべての収集の過程に標本抽出構成変更を示さなければなりません。 (f) オーバーロードの振舞いが支持されて、計量プロセス挙動における変化を引き起こすなら、明確にオーバーロードの振舞いを定義しなければなりません。 (g) 正確な時間ベースの会計は流れタイムアウトへの反応を必要とします。 (h) パケットが断片化されるなら、各断片は個々のパケットにみなされます。 (i) プロトコルタイプがICMPであるなら。
Quittek, et al. Informational [Page 30] RFC 3917 IPFIX Requirements October 2004
Quittek、他 [30ページ]情報のRFC3917IPFIX要件2004年10月
(j) This requirement does not apply if the observation point is
located at a probe device.
(k) Only if measurement is done on data path i.e., has access to
forwarding decision.
(l) Either push or pull has to be supported.
(m) Required, in order to immediately report drop indications for
SLA validation.
(n) Anonymization must be clearly indicated to all receiving
collecting processes.
(j) 観測所が徹底的調査装置に位置しているなら、この要件は適用されません。 (k) すなわち、データ経路における測定します。唯一、推進決定に近づく手段を持っています。 (l) プッシュか牽引力のどちらかが支えられなければなりません。 (m) 必要であることで、すぐに報告するためにSLA合法化のための指摘を落としてください。 (n) 過程を集めながら、明確にすべての受信にAnonymizationを示さなければなりません。
13. References
13. 参照
13.1. Normative References
13.1. 引用規格
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000.
[RFC2960] スチュワート、R.、シェ、Q.、K.の、そして、鋭いMorneault、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カッラ、M.、チャン、L.、および「流れの制御伝動プロトコル」、RFC2960(2000年10月)対パクソン
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] ローゼンとE.とViswanathan、A.とR.Callon、「Multiprotocolラベル切り換え構造」、RFC3031、2001年1月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, December
1998.
[RFC2474] ニコルズ、K.、ブレーク、S.、ベイカー、F.、およびD.黒、「IPv4とIPv6ヘッダーとの微分されたサービス分野(DS分野)の定義」、RFC2474(1998年12月)。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
13.2. Informative References
13.2. 有益な参照
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
Issues", RFC 3234, February 2002.
[RFC3234]大工、B.、およびS.があふれそうになる、「Middleboxes:」 「分類学と問題」、RFC3234、2月2002日
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、2003年7月。
[RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to
Accounting Management", RFC 2975, October 2000.
2000年10月の[RFC2975]AbobaとB.とArkko、J.とD.ハリントン、「会計管理への紹介」RFC2975。
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over
MPLS", RFC 2702, September 1999.
[RFC2702]AwducheとD.とマルコムとJ.とAgogbuaとJ.とオデル、M.とJ.マクマナス、「MPLSの上の交通工学のための要件」RFC2702(1999年9月)。
Quittek, et al. Informational [Page 31] RFC 3917 IPFIX Requirements October 2004
Quittek、他 [31ページ]情報のRFC3917IPFIX要件2004年10月
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
(BGP-4)", RFC 1771, March 1995.
1995年の[RFC1771]RekhterとY.とT.李、「ボーダ・ゲイトウェイ・プロトコル4(BGP-4)」、RFC1771行進。
[RFC3418] Presuhn, R., "Management Information Base (MIB) for the
Simple Network Management Protocol (SNMP)", STD 62, RFC
3418, December 2002.
[RFC3418] Presuhn、R.、「簡単なネットワーク管理プロトコル(SNMP)のための管理情報ベース(MIB)」、STD62、RFC3418、2002年12月。
[RFC2720] Brownlee, N., "Traffic Flow Measurement: Meter MIB", RFC
2720, October 1999.
[RFC2720]ブラウンリー、N.、「流量測定を取引してください」 「メーターMIB」、1999年10月のRFC2720。
14. Authors' Addresses
14. 作者のアドレス
Juergen Quittek NEC Europe Ltd., Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany
ユルゲンQuittek NECヨーロッパLtd.、ネットワーク研究所Kurfuersten-原基36 69115ハイデルベルグドイツ
Phone: +49 6221 90511 15 EMail: quittek@netlab.nec.de
以下に電話をしてください。 +49 6221 90511 15はメールされます: quittek@netlab.nec.de
Tanja Zseby Fraunhofer Institute for Open Communication Systems (FOKUS) Kaiserin-Augusta-Allee 31 10589 Berlin Germany
オープンコミュニケーションシステム(FOKUS)皇后オーガスタ並木道31 10589ベルリンドイツのターニャZsebyフラウンホーファー研究所
Phone: +49 30 3463 7153 EMail: zseby@fokus.fhg.de
以下に電話をしてください。 +49 30 3463 7153はメールされます: zseby@fokus.fhg.de
Benoit Claise Cisco Systems De Kleetlaan 6a b1 1831 Diegem Belgium
ブノワClaiseシスコシステムズDe Kleetlaan 6a b1 1831Diegemベルギー
Phone: +32 2 704 5622 EMail: bclaise@cisco.com
以下に電話をしてください。 +32 2 704 5622はメールされます: bclaise@cisco.com
Sebastian Zander Centre for Advanced Internet Architectures, Mail H31 Swinburne University of Technology PO Box 218 John Street, Hawthorn Victoria 3122, Australia
高度なインターネット構造のためのセバスチャンザンダーセンター、技術PO Box218ジョン通り、サンザシビクトリア3122、オーストラリアのメールH31スウィンバーン大学
Phone: +61 3 9214 8089 EMail: szander@swin.edu.au
以下に電話をしてください。 +61 3 9214 8089はメールされます: szander@swin.edu.au
Quittek, et al. Informational [Page 32] RFC 3917 IPFIX Requirements October 2004
Quittek、他 [32ページ]情報のRFC3917IPFIX要件2004年10月
15. Full Copyright Statement
15. 完全な著作権宣言文
Copyright (C) The Internet Society (2004).
Copyright(C)インターネット協会(2004)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でIETF Documentsの権利に関するIETFの手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Quittek, et al. Informational [Page 33]
Quittek、他 情報[33ページ]
一覧
スポンサーリンク
