Network Working Group N. Duffield, Ed.
Request for Comments: 5474 AT&T Labs - Research
Category: Informational D. Chiou
University of Texas
B. Claise
Cisco Systems, Inc.
A. Greenberg
Microsoft
M. Grossglauser
EPFL & Nokia
J. Rexford
Princeton University
March 2009
A Framework for Packet Selection and Reporting
Status of This 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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Abstract
抽象
This document specifies a framework for the PSAMP (Packet SAMPling) protocol. The functions of this protocol are to select packets from a stream according to a set of standardized Selectors, to form a stream of reports on the selected packets, and to export the reports to a Collector. This framework details the components of this architecture, then describes some generic requirements, motivated by the dual aims of ubiquitous deployment and utility of the reports for applications. Detailed requirements for selection, reporting, and exporting are described, along with configuration requirements of the PSAMP functions.
この文書は、PSAMP（パケットサンプリング）プロトコルの枠組みを規定します。このプロトコルの機能が選択されたパケットのレポートのストリームを形成するために、コレクタにレポートをエクスポートするために、標準化されたセレクタのセットに従ってストリームからのパケットを選択することです。このフレームワークは、このアーキテクチャのコンポーネントを詳述し、アプリケーションのためのレポートのユビキタス展開とユーティリティの二重の目的が動機、いくつかの一般的な要件について説明します。選択、レポート、およびエクスポートするための詳細な要件は、PSAMP機能の構成要件と一緒に、記載されています。
Table of Contents
目次
1. Introduction ....................................................4
2. PSAMP Documents Overview ........................................4
3. Elements, Terminology, and High-Level Architecture ..............5
3.1. High-Level Description of the PSAMP Architecture ...........5
3.2. Observation Points, Packet Streams, and Packet Content .....5
3.3. Selection Process ..........................................6
3.4. Reporting ..................................................7
3.5. Metering Process ...........................................8
3.6. Exporting Process ..........................................8
3.7. PSAMP Device ...............................................9
3.8. Collector ..................................................9
3.9. Possible Configurations ....................................9
4. Generic Requirements for PSAMP .................................11
4.1. Generic Selection Process Requirements ....................11
4.2. Generic Reporting Requirements ............................12
4.3. Generic Exporting Process Requirements ....................12
4.4. Generic Configuration Requirements ........................13
5. Packet Selection ...............................................13
5.1. Two Types of Selectors ....................................13
5.2. PSAMP Packet Selectors ....................................14
5.3. Selection Fraction Terminology ............................17
5.4. Input Sequence Numbers for Primitive Selectors ............18
5.5. Composite Selectors .......................................19
5.6. Constraints on the Selection Fraction .....................19
6. Reporting ......................................................19
6.1. Mandatory Contents of Packet Reports: Basic Reports .......19
6.2. Extended Packet Reports ...................................20
6.3. Extended Packet Reports in the Presence of IPFIX ..........20
6.4. Report Interpretation .....................................21
7. Parallel Metering Processes ....................................22
8. Exporting Process ..............................................22
8.1. Use of IPFIX ..............................................22
8.2. Export Packets ............................................22
8.3. Congestion-Aware Unreliable Transport .....................22
8.4. Configurable Export Rate Limit ............................23
8.5. Limiting Delay for Export Packets .........................23
8.6. Export Packet Compression .................................24
8.7. Collector Destination .....................................25
8.8. Local Export ..............................................25
9. Configuration and Management ...................................25
10. Feasibility and Complexity ....................................26
10.1. Feasibility ..............................................26
10.1.1. Filtering .........................................26
10.1.2. Sampling ..........................................26
10.1.3. Hashing ...........................................26
10.1.4. Reporting .........................................27
10.1.5. Exporting .........................................27
10.2. Potential Hardware Complexity ............................27
11. Applications ..................................................28
11.1. Baseline Measurement and Drill Down ......................29
11.2. Trajectory Sampling ......................................29
11.3. Passive Performance Measurement ..........................30
11.4. Troubleshooting ..........................................30
12. Security Considerations .......................................31
12.1. Relation of PSAMP and IPFIX Security for
Exporting Process ........................................31
12.2. PSAMP Specific Privacy Considerations ....................31
12.3. Security Considerations for Hash-Based Selection .........32
12.3.1. Modes and Impact of Vulnerabilities ...............32
12.3.2. Use of Private Parameters in Hash Functions .......33
12.3.3. Strength of Hash Functions ........................33
12.4. Security Guidelines for Configuring PSAMP ................34
13. Contributors ..................................................34
14. Acknowledgments ...............................................34
15. References ....................................................34
15.1. Normative References .....................................34
15.2. Informative References ...................................35
This document describes the PSAMP framework for network elements to select subsets of packets by statistical and other methods, and to export a stream of reports on the selected packets to a Collector.
この文書では、統計やその他の方法により、パケットのサブセットを選択するために、コレクターに選択されたパケットに関するレポートのストリームをエクスポートするために、ネットワーク要素のためのPSAMPフレームワークについて説明します。
The motivation for the PSAMP standard comes from the need for measurement-based support for network management and control across multivendor domains. This requires domain-wide consistency in the types of selection schemes available, and the manner in which the resulting measurements are presented and interpreted.
PSAMPの標準のための動機は、マルチベンダーのドメイン間のネットワーク管理および制御のための測定ベースのサポートの必要性から来ています。これは、ドメイン全体の利用可能な選択スキームのタイプの一貫性、得られた測定値が提示され、解釈される方法を必要とします。
The motivation for specific packet selection operations comes from the applications that they enable. Development of the PSAMP standard is open to influence by the requirements of standards in related IETF Working Groups, for example, IP Performance Metrics (IPPM) [RFC2330] and Internet Traffic Engineering (TEWG).
特定のパケットの選択操作のための動機は、彼らが有効なアプリケーションから来ています。 PSAMP標準の開発には、例えば、関連するIETFワーキンググループでの規格の要求事項による影響に開いている、IPパフォーマンス・メトリック（IPPM）[RFC2330]とインターネットトラフィックエンジニアリング（TEWG）。
The name PSAMP is a contraction of the phrase "Packet Sampling". The word "Sampling" captures the idea that only a subset of all packets passing a network element will be selected for reporting. But PSAMP selection operations include random selection, deterministic selection (Filtering), and deterministic approximations to random selection (Hash-based Selection).
名前PSAMPは句「パケットサンプリング」の短縮形です。 「サンプリング」という言葉は、ネットワーク要素を通過するすべてのパケットのサブセットのみが報告のために選択されますアイデアをキャプチャします。しかしPSAMP選択操作がランダムに選択、決定論的選択（フィルタリング）、およびランダムな選択（ハッシュベースの選択）に決定論的な近似値が含まれています。
This document is one out of a series of documents from the PSAMP group.
この文書では、PSAMPグループからの一連の文書のうち一つです。
RFC 5474 (this document): "A Framework for Packet Selection and Reporting" describes the PSAMP framework for network elements to select subsets of packets by statistical and other methods, and to export a stream of reports on the selected packets to a Collector. Definitions of terminology and the use of the terms "must", "should", and "may" in this document are informational only.
RFC 5474（本書）：ネットワーク要素が統計的及び他の方法によるパケットのサブセットを選択するために、コレクタに選択されたパケットのレポートのストリームをエクスポートするための「パケット選択及び報告のためのフレームワーク」PSAMPフレームワークを記述する。用語の定義と用語の使用は、「べき」「しなければならない」、とは、この文書で情報提供のみをしている「こと」。
[RFC5475]: "Sampling and Filtering Techniques for IP Packet Selection" describes the set of packet selection techniques supported by PSAMP.
[RFC5475]：「IPパケットの選択のためのサンプリングとフィルタリング技術は、」PSAMPでサポートされているパケット選択技術のセットを記述します。
[RFC5476]: "Packet Sampling (PSAMP) Protocol Specifications" specifies the export of packet information from a PSAMP Exporting Process to a PSAMP Collecting Process.
[RFC5476]：「パケットサンプリング（PSAMP）プロトコル仕様」収集処理PSAMPにPSAMPエクスポートプロセスからパケット情報のエクスポートを指定します。
[RFC5477]: "Information Model for Packet Sampling Exports" defines an information and data model for PSAMP.
[RFC5477]：PSAMPための情報とデータモデルを定義し、「情報モデルパケットサンプリングのための輸出します」。
Here is an informal high-level description of the PSAMP protocol operating in a PSAMP Device (all terms will be defined presently). A stream of packets is observed at an Observation Point. A Selection Process inspects each packet to determine whether or not it is to be selected for reporting. The Selection Process is part of the Metering Process, which constructs a report on each selected packet, using the Packet Content, and possibly other information such as the packet treatment at the Observation Point or the arrival timestamp. An Exporting Process sends the Packet Reports to a Collector, together with any subsidiary information needed for their interpretation.
ここでPSAMPデバイスで動作PSAMPプロトコルの非公式のハイレベルの記述は、（すべての用語は、現在定義される）です。パケットの流れを観測地点で観測されました。選択プロセスは、それが報告のために選択されるべきであるか否かを決定するために、各パケットを検査します。選択プロセスは、パケットの内容を使用して、選択された各パケットのレポートを構築する計量プロセスの一部、およびそのような観測点におけるパケット処理または到着タイムスタンプなどのおそらく他の情報です。エクスポートプロセスは、それらの解釈のために必要なすべての子会社情報とともに、Collectorにパケットレポートを送信します。
The following figure indicates the sequence of the three processes (Selection, Metering, and Exporting) within the PSAMP device.
次の図は、PSAMP装置内の3つのプロセス（選択、メータリング、およびエクスポート）のシーケンスを示しています。
+------------------+
| Metering Process |
| +-----------+ | +-----------+
Observed | | Selection | | | Exporting |
Packet--->| | Process |--------->| Process |--->Collector
Stream | +-----------+ | +-----------+
+------------------+
The following sections give detailed definitions of each of the objects just named.
次のセクションでは、単に名前付きオブジェクトのそれぞれの詳細な定義を与えます。
This section contains the definition of terms relevant to obtaining the packet input to the Selection Process.
このセクションでは、選択プロセスへのパケット入力を得ることに関連する用語の定義が含まれています。
* Observation Point
*観測点
An Observation Point is a location in the network where IP packets can be observed. Examples include 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、ルータの単一ポート、またはルータの（物理的または論理的な）インターフェイスのセットとプローブが結合している線、共有媒体を含みます。
Note that every Observation Point is associated with an Observation Domain and that one Observation Point may be a superset of several other Observation Points. For example, one Observation Point can be an entire line card. That would be the superset of the individual Observation Points at the line card's interfaces.
すべての観測点が観測ドメインに関連付けられていることと、1観測点は、他のいくつかの観測点のスーパーセットであることに注意してください。例えば、1つの観測点は、全体のラインカードとすることができます。これは、ラインカードのインターフェイスで、個々の観測点のスーパーセットになります。
* Observed Packet Stream
*観測されたパケットストリーム
The Observed Packet Stream is the set of all packets observed at the Observation Point.
観測されたパケットストリームの観測点で観測されたすべてのパケットのセットです。
* Packet Stream
*パケットストリーム
A Packet Stream denotes a set of packets from the Observed Packet Stream that flows past some specified point within the Metering Process. An example of a Packet Stream is the output of the Selection Process. Note that packets selected from a stream, e.g., by Sampling, do not necessarily possess a property by which they can be distinguished from packets that have not been selected. For this reason, the term "stream" is favored over "flow", which is defined as a set of packets with common properties [RFC3917].
パケットストリームは、計量プロセス内のいくつかの指定された点を通過して流れる観測されたパケットストリームからのパケットの集合を表します。パケットストリームの例は、選択処理の出力です。ストリームから選択されたパケットは、例えば、サンプリングによって、必ずしもそれらが選択されていないパケットと区別することが可能な性質を有していないことに留意されたいです。この理由のために、用語「ストリーム」とは、共通のプロパティ[RFC3917]を有するパケットの集合として定義される「フロー」よりも好まれます。
* Packet Content
*パケットの内容
The Packet Content denotes the union of the packet header (which includes link layer, network layer, and other encapsulation headers) and the packet payload.
パケット内容は、パケットペイロード（リンク層、ネットワーク層、及び他のカプセル化ヘッダを含む）は、パケットヘッダの和集合を表します。
This section defines the Selection Process and related objects.
このセクションでは、選択プロセスと関連するオブジェクトを定義します。
* Selection Process
*選択プロセス
A Selection Process takes the Observed Packet Stream as its input and selects a subset of that stream as its output.
選択プロセスは、その入力として、観測されたパケットストリームを受け取り、その出力として、そのストリームのサブセットを選択します。
* Selection State
*選択状態
A Selection Process may maintain state information for use by the Selection Process. At a given time, the Selection State may depend on packets observed at and before that time, and other variables. Examples include:
選択プロセスは、選択プロセスで使用するための状態情報を維持することができます。与えられた時点で、選択状態はその時と前に観測されたパケット、および他の変数に依存してもよいです。例としては、
(i) sequence numbers of packets at the input of Selectors;
（I）セレクタの入力でのパケットのシーケンス番号。
(ii) a timestamp of observation of the packet at the Observation Point;
（ii）の観測点におけるパケットの観察のタイムスタンプ。
(iii) iterators for pseudorandom number generators;
（III）擬似乱数のためのイテレータ。
(iv) hash values calculated during selection;
（iv）の選択中に計算されたハッシュ値と、
(v) indicators of whether the packet was selected by a given Selector.
（V）パケットが指定されたセレクタによって選択されたかどうかのインジケータ。
Selection Processes may change portions of the Selection State as a result of processing a packet. Selection State for a packet reflects the state after processing the packet.
選択プロセスは、パケットを処理した結果として、選択状態の部分を変更してもよいです。パケットの選択状態は、パケットを処理した後の状態を反映しています。
* Selector
*セレクタ
A Selector defines the action of a Selection Process on a single packet of its input. If selected, the packet becomes an element of the output Packet Stream.
セレクタは、その入力の単一のパケットに対して選択処理の動作を規定します。選択された場合、パケットは出力パケットストリームの要素となります。
The Selector can make use of the following information in determining whether a packet is selected:
セレクタは、パケットが選択されているかどうかを決定する際に、以下の情報を利用することができます。
(i) the Packet Content;
（I）パケットの内容。
(ii) information derived from the packet's treatment at the Observation Point;
（ⅱ）Observation Pointのパケットの治療から得られる情報を、
(iii) any Selection State that may be maintained by the Selection Process.
（iii）選択プロセスによって維持され得る任意の選択状態が。
* Composite Selector
*コンポジットセレクター
A Composite Selector is an ordered composition of Selectors, in which the output Packet Stream issuing from one Selector forms the input Packet Stream to the succeeding Selector.
複合セレクタは、一のセレクタから出る出力パケットストリームは、後続のセレクタに入力パケットストリームを形成する、セレクタの順序付けられた組成物です。
* Primitive Selector
*プリミティブセレクター
A Selector is primitive if it is not a Composite Selector.
それはコンポジットセレクタでない場合、セレクタは原始的です。
* Packet Reports
*パケットレポート
Packet Reports comprise a configurable subset of a packet's input to the Selection Process, including the Packet Content, information relating to its treatment (for example, the output interface), and its associated Selection State (for example, a hash of the Packet Content).
パケットレポートがその処理（例えば、出力インターフェース）、及びその関連する選択状態に関する情報、パケットの内容を含む、選択プロセスへのパケットの入力の設定可能なサブセットを含む（例えば、パケットの内容のハッシュ） 。
* Report Interpretation
*レポートの解釈
Report Interpretation comprises subsidiary information, relating to one or more packets, that is used for interpretation of their Packet Reports. Examples include configuration parameters of the Selection Process.
レポートの解釈は、そのパケットのレポートを解釈するために使用される1つまたは複数のパケットに関連する、子会社の情報を含んでいます。例としては、選択プロセスの構成パラメータを含みます。
* Report Stream
*レポートストリーム
The Report Stream is the output of a Metering Process, comprising two distinct types of information: Packet Reports and Report Interpretation.
パケットレポートおよびレポート解釈報告ストリームは、情報の2つの異なるタイプを含む、計量プロセスの出力です。
A Metering Process selects packets from the Observed Packet Stream using a Selection Process, and produces as output a Report Stream concerning the selected packets.
計量プロセスは、選択プロセスを使用して観測されたパケットストリームからパケットを選択し、選択されたパケットについての出力として報告ストリームを生成します。
The PSAMP Metering Process can be viewed as analogous to the IPFIX Metering Process [RFC5101], which produces Flow Records as its output, with the difference that the PSAMP Metering Process always contains a Selection Process. The relationship between PSAMP and IPFIX is further described in [RFC5477] and [RFC5474].
PSAMP計量プロセスはPSAMP計量プロセスは、常に選択プロセスを含むことを違いと、その出力として、フローレコードを生成IPFIX計量プロセスに類似する[RFC5101]、と見なすことができます。 PSAMPとIPFIXとの間の関係は、さらに、[RFC5477]及び[RFC5474]に記載されています。
* Exporting Process
*エクスポートプロセス
An Exporting Process sends, in the form of Export Packets, the output of one or more Metering Processes to one or more Collectors.
エクスポートプロセスは、一つ以上のコレクタに、エクスポートパケットの形で、一つ以上の計量プロセスの出力を送信します。
* Export Packets
*エクスポートパケット
An Export Packet is a combination of Report Interpretation(s) and/or one or more Packet Reports that are bundled by the Exporting Process into an Export Packet for exporting to a Collector.
エクスポートパケットレポート解釈及び/又はコレクタにエクスポートするためのエクスポートパケットにエクスポートプロセスによってバンドルされた1つの以上のパケットレポートの組み合わせです。
A PSAMP Device is a device hosting at least an Observation Point, a Metering Process (which includes a Selection Process), and an Exporting Process. Typically, corresponding Observation Point(s), Metering Process(es), and Exporting Process(es) are co-located at this device, for example, at a router.
PSAMPデバイスは、少なくとも観測ポイントをホストデバイス、（選択プロセスを含む）計量プロセス、およびエクスポートプロセスです。典型的には、ルータで、例えば、このデバイスに同じ場所に配置されている観測点（複数可）、計量プロセス（ES）、およびエクスポートプロセス（ES）に対応します。
A Collector receives a Report Stream exported by one or more Exporting Processes. In some cases, the host of the Metering and/or Exporting Processes may also serve as the Collector.
コレクタは、一つ以上のエクスポート・プロセスによってエクスポートされたレポートストリームを受信します。いくつかのケースでは、メータリングおよび/またはエクスポートプロセスのホストは、集電体として機能することができます。
Various possibilities for the high-level architecture of these elements are as follows.
次のようにこれらの要素のハイレベル・アーキテクチャのための様々な可能性があります。
MP = Metering Process, EP = Exporting process
MP =計量プロセス、EP =エクスポートプロセス
PSAMP Device
+---------------------+ +------------------+
|Observation Point(s) | | Collector(1) |
|MP(s)--->EP----------+---------------->| |
|MP(s)--->EP----------+-------+-------->| |
+---------------------+ | +------------------+
|
PSAMP Device |
+---------------------+ | +------------------+
|Observation Point(s) | +-------->| Collector(2) |
|MP(s)--->EP----------+---------------->| |
+---------------------+ +------------------+
PSAMP Device
+---------------------+
|Observation Point(s) |
|MP(s)--->EP---+ |
| | |
|Collector(3)<-+ |
+---------------------+
The most simple Metering Process configuration is composed of:
最も簡単な計量プロセスの設定が構成されています。
+------------------------------------+
| +----------+ |
| |Selection | |
Observed | |Process | Packet |
Packet-->| |(Primitive|-> Stream -> |--> Report Stream
^
Stream | | Selector)| |
^
| +----------+ |
| Metering Process |
+------------------------------------+
A Metering Process with a Composite Selector is composed of:
複合セレクタと計量プロセスは、から構成されています。
+--------------------------------------------------...
| +-----------------------------------+
| | +----------+ +----------+ |
| | |Selection | |Selection | |
Observed | | |Process | |Process | |
Packet-->| | |(Primitive|-Packet->|(Primitive|---> Packet ...
^ ^
Stream | | |Selector1)| Stream |Selector2)| | Stream
^ ^
| | +----------+ +----------+ |
| | Composite Selector |
| +-----------------------------------+
| Metering Process
+--------------------------------------------------...
...-------------+
|
|
|
|
|---> Report Stream
|
|
|
|
|
...-------------+
This section describes the generic requirements for the PSAMP protocol. A number of these are realized as specific requirements in later sections.
このセクションでは、PSAMPプロトコルのための一般的な要件について説明します。これらの番号は、後のセクションで特定の要件として実現されます。
(a) Ubiquity: The Selectors must be simple enough to be implemented ubiquitously at maximal line rate.
（a）はユビキタス：セレクタは最大ラインレートで普遍的に実装するのに十分な簡単なものでなければなりません。
(b) Applicability: The set of Selectors must be rich enough to support a range of existing and emerging measurement-based applications and protocols. This requires a workable trade-off between the range of traffic engineering applications and operational tasks it enables, and the complexity of the set of capabilities.
（b）の適用性：セレクタのセットは、既存および新興の測定ベースのアプリケーションとプロトコルの範囲をサポートするのに十分な金持ちでなければなりません。これは、トラフィックエンジニアリングアプリケーションの範囲と、それが有効に運用タスク、および機能のセットの複雑さとの間に実行可能なトレードオフが必要です。
(c) Extensibility: The protocol must be able to accommodate additional packet Selectors not currently defined.
（c）の拡張：プロトコルは、現在定義されていない追加のパケット・セレクタを収容することができなければなりません。
(d) Flexibility: The protocol must support selection of packets using various network protocols or encapsulation layers, including Internet Protocol Version 4 (IPv4) [RFC0791], Internet Protocol Version 6 (IPv6) [RFC2460], and Multiprotocol Label Switching (MPLS) [RFC3031].
（D）柔軟性：プロトコルは、インターネットプロトコルバージョン4（IPv4）の[RFC0791]、インターネットプロトコルバージョン6（IPv6）の[RFC2460]、およびマルチプロトコルラベルスイッチング（MPLS）を含む種々のネットワークプロトコルまたはカプセル化層を使用してパケットの選択をサポートしなければなりません[RFC3031]。
(e) Robust Selection: Packet selection must be robust against attempts to craft an Observed Packet Stream from which packets are selected disproportionately (e.g., to evade selection or overload measurement systems).
（e）のロバスト選択：パケット選択（例えば、選択又は過負荷測定システムを回避する）パケットが偏っ選択され、そこから観測されたパケットストリームを作るための試みに対してロバストでなければなりません。
(f) Parallel Metering Processes: The protocol must support simultaneous operation of multiple independent Metering Processes at the same host.
（F）を並列計量プロセス：プロトコルは、同じホストで複数の独立した計量プロセスの同時動作をサポートしなければなりません。
(g) Causality: The selection decision for each packet should depend only weakly, if at all, upon future packets' arrivals. This promotes ubiquity by limiting the complexity of the selection logic.
（g）の因果関係：各パケットの選択決定は、将来、パケットの到着時に、すべての場合、弱くのみに依存すべきです。これは、選択ロジックの複雑さを制限することにより、ユビキタス性を促進します。
(h) Encrypted Packets: Selectors that interpret packet fields must be configurable to ignore (i.e., not select) encrypted packets, when they are detected.
（H）暗号化されたパケット：セレクタパケットフィールドを解釈し、それらが検出された場合（すなわち、選択しない）暗号化されたパケットを無視するように構成可能でなければなりません。
Specific Selectors are outlined in Section 5, and described in more detail in the companion document [RFC5475].
特定のセレクタは、第5節で概説、及び仲間ドキュメント[RFC5475]に詳細に記載されています。
(i) Self-Defining: The Report Stream must be complete in the sense that no additional information need be retrieved from the Observation Point in order to interpret and analyze the reports.
（ⅰ）自己定義：レポートストリームには、追加情報が報告書を解釈し、分析するために、観測ポイントから取得する必要がないという意味で、完全でなければなりません。
(j) Indication of Information Loss: The Report Stream must include sufficient information to indicate or allow the detection of loss occurring within the Selection, Metering, and/or Exporting Processes, or in transport. This may be achieved by the use of sequence numbers.
情報損失の（J）表示：レポートストリームおよび/またはプロセスをエクスポートする、または輸送に、指示や選択、メーター内で発生する損失の検出を可能にするのに十分な情報を含まなければなりません。これは、シーケンス番号を使用することによって達成することができます。
(k) Accuracy: The Report Stream must include information that enables the accuracy of measurements to be determined.
（K）精度報告ストリームが決定される測定の精度を可能にする情報を含まなければなりません。
(l) Faithfulness: All reported quantities that relate to the packet treatment must reflect the router state and configuration encountered by the packet at the time it is received by the Metering Process.
（L）忠実：パケットの処理に関連するすべての報告された量は、計量プロセスによって受信された時点でパケットが遭遇するルータの状態と設定を反映しなければなりません。
(m) Privacy: Although selection of the content of Packet Reports must be responsive to the needs of measurement applications, it must also conform with [RFC2804]. In particular, full packet capture of arbitrary Packet Streams is explicitly out of scope.
（M）プライバシー：パケットレポートのコンテンツの選択は、測定アプリケーションのニーズに応じなければならないが、それはまた、[RFC2804]に準拠しなければなりません。具体的には、任意のパケットストリームのフルパケットキャプチャは、明示的に範囲外です。
See Section 6 for further discussions on Reporting.
報告に関する更なる議論については、セクション6を参照してください。
(n) Timeliness: Configuration must allow for limiting of buffering delays for the formation and transmission for Export Packets. See Section 8.5 for further details.
（n）を適時：設定エクスポートパケットの形成及び送信のためにバッファリング遅延の制限を可能にしなければなりません。詳細については、セクション8.5を参照してください。
(o) Congestion Avoidance: Export of a Report Stream across a network must be congestion avoiding in compliance with [RFC2914]. This is discussed further in Section 8.3.
（O）輻輳回避：ネットワーク全体レポートストリームのエクスポートが[RFC2914]に準拠して輻輳回避しなければなりません。これは、8.3節で詳しく説明されています。
(p) Secure Export
（P）セキュアエクスポート
(i) confidentiality: The option to encrypt exported data must
be provided.
(ii) integrity: Alterations in transit to exported data must be detectable at the Collector.
（ⅱ）整合性を：エクスポートされたデータへの輸送中の変化はコレクターで検出可能でなければなりません。
(iii) authenticity: Authenticity of exported data must be verifiable by the Collector in order to detect forged data.
（iii）の真正性：エクスポートされたデータの真正性は、偽造データを検出するために、コレクタによって検証可能でなければなりません。
The motivation here is the same as for security in IPFIX export; see Sections 6.3 and 10 of [RFC3917].
ここでの動機は、IPFIXエクスポートでセキュリティと同じです。セクション6.3と[RFC3917]の10を参照してください。
(q) Ease of Configuration: This applies to ease of configuration of Sampling and export parameters, e.g., for automated remote reconfiguration in response to collected reports.
（q）は設定の容易さ：これは、収集したレポートに応じて、自動化された遠隔再構成のために、例えば、サンプリングおよびエクスポートパラメータの設定を容易にするために適用されます。
(r) Secure Configuration: The option to configure via protocols that prevent unauthorized reconfiguration or eavesdropping on configuration communications must be available. Eavesdropping on configuration might allow an attacker to gain knowledge that would be helpful in crafting a Packet Stream to evade subversion or overload the measurement infrastructure.
（r）はセキュアな構成：構成の通信上の不正な再構成や盗聴を防止するためのプロトコルを経由して設定するためのオプションが利用可能でなければなりません。設定上の盗聴は、攻撃者が転覆を回避または測定インフラをオーバーロードするためにパケットストリームを作り上げるには参考になる知識を得ることができる場合があります。
Configuration is discussed in Section 9.
コンフィギュレーションは、第9章で説明されています。
This section details specific requirements for the Selection Process, motivated by the generic requirements of Section 3.3.
このセクションでは、セクション3.3の一般的な要件によって動機付け選択プロセスのための特定の要件を、詳しく説明します。
PSAMP categorizes Selectors into two types:
PSAMPは二つのタイプにセレクタを分類します：
* Filtering: A filter is a Selector that selects a packet deterministically based on the Packet Content, or its treatment, or functions of these occurring in the Selection State. Two examples are:
*フィルター：フィルターは決定論パケットの内容に基づいて、パケット、またはその治療、または選択州で発生したこれらの機能を選択するセレクタです。二つの例は以下のとおりです。
(i) Property Match Filtering: A packet is selected if a
specific field in the packet equals a predefined value.
(ii) Hash-based Selection: A hash function is applied to the Packet Content, and the packet is selected if the result falls in a specified range.
（ii）のハッシュベースの選択：ハッシュ関数は、パケットの内容に適用され、その結果は、指定された範囲内にある場合、パケットが選択されます。
* Sampling: A Selector that is not a filter is called a Sampling operation. This reflects the intuitive notion that if the selection of a packet cannot be determined from its content alone, there must be some type of Sampling taking place.
*サンプリング：サンプリング動作と呼ばれるフィルターではありませんセレクタ。これは、パケットの選択だけではその内容から判断できない場合は、サンプリングが行われ、いくつかのタイプが存在しなければならないという直感的な概念を反映しています。
Sampling operations can be divided into two subtypes:
サンプリング動作は、2つのサブタイプに分けることができます。
(i) Content-independent Sampling, which does not use Packet
Content in reaching Sampling decisions. Examples include systematic Sampling, and uniform pseudorandom Sampling
driven by a pseudorandom number whose generation is
independent of Packet Content. Note that in content-
independent Sampling, it is not necessary to access the
Packet Content in order to make the selection decision.
(ii) Content-dependent Sampling, in which the Packet Content is used in reaching selection decisions. An application is pseudorandom selection with a probability that depends on the contents of a packet field, e.g., Sampling packets with a probability dependent on their TCP/UDP port numbers. Note that this is not a filter.
パケットの内容は、選択決定に到達するに使用される式（II）の含有量に依存するサンプリング、。アプリケーションは、そのTCP / UDPポート番号に依存確率でパケットをサンプリング、例えば、パケットフィールドの内容に依存確率で擬似ランダム選択です。これは、フィルタではないことに注意してください。
A spectrum of packet Selectors is described in detail in [RFC5475]. Here we only briefly summarize the meanings for completeness.
パケットセレクタのスペクトルは、[RFC5475]に詳細に記載されています。ここでは簡単にしか完全性についての意味をまとめたもの。
A PSAMP Selection Process must support at least one of the following Selectors.
PSAMP選択プロセスは、以下のセレクタのうち少なくとも一つをサポートしなければなりません。
* systematic count-based Sampling: Packet selection is triggered periodically by packet count, a number of successive packets being selected subsequent to each trigger.
*系統的カウントベースのサンプリング：パケット選択がパケット数、各トリガに続く選択される連続するパケットの数で定期的にトリガされます。
* systematic time-based Sampling: This is similar to systematic count-based Sampling except that selection is reckoned with respect to time rather than count. Packet selection is triggered at periodic instants separated by a time called the spacing. All packets that arrive within a certain time of the trigger (called the interval length) are selected.
*系統的な時間ベースのサンプリング：これは、その選択は時間に対してではなく、カウントを数えている以外、系統的、カウントベースのサンプリングに似ています。パケットの選択は、間隔と呼ばれる時間によって分離された周期的な瞬間にトリガされます。 （インターバルの長さと呼ばれる）トリガの一定時間内に到着するすべてのパケットが選択されます。
* probabilistic n-out-of-N Sampling: From each count-based successive block of N packets, n are selected at random.
*確率Nアウト・オブ・Nサンプリング：nはランダムに選択されたN個のパケットのそれぞれカウントベースの連続ブロック、から。
* uniform probabilistic Sampling: Packets are selected independently with fixed Sampling probability p.
*均一な確率的サンプリング：パケットは、固定サンプリング確率pで独立して選択されています。
* non-uniform probabilistic Sampling: Packets are selected independently with probability p that depends on Packet Content.
*不均一な確率的サンプリング：パケットは、パケットの内容に依存確率pで独立して選択されています。
* Property Match Filtering
*プロパティマッチフィルタリング
With this Filtering method, a packet is selected if a specific field within the packet and/or on properties of the router state equal(s) a predefined value. Possible filter fields are all IPFIX Flow attributes specified in [RFC5102]. Further fields can be defined by vendor-specific extensions.
このフィルタリング方法では、パケットは、パケット内の特定のフィールド場合及び/又はルータ状態等しい（S）予め定義された値の特性に選択されます。可能なフィルタフィールドは、[RFC5102]で指定されたすべてのIPFIXフロー属性です。さらに、フィールドはベンダー固有の拡張機能によって定義することができます。
A packet is selected if Field=Value. Masks and ranges are only supported to the extent to which [RFC5102] allows them, e.g., by providing explicit fields like the netmasks for source and destination addresses.
フィールド=値場合、パケットが選択されます。マスクおよび範囲のみ[RFC5102]は、送信元と宛先アドレスのネットマスクのような明示的なフィールドを提供することによって、例えば、それらを可能にする程度に支持されています。
AND operations are possible by concatenating filters, thus producing a composite selection operation. In this case, the ordering in which the Filtering happens is implicitly defined (outer filters come after inner filters). However, as long as the concatenation is on filters only, the result of the cascaded filter is independent from the order, but the order may be important for implementation purposes, as the first filter will have to work at a higher rate. In any case, an implementation is not constrained to respect the filter ordering, as long as the result is the same, and it may even implement the composite Filtering in one single step.
AND演算は、このように複合選択操作を生成、フィルタを連結することによって可能です。この場合、フィルタリングが発生している順序は、暗黙的に（外フィルタは、内部のフィルターの後に来る）が定義されています。しかし、限り、連結がフィルタのみであるとして、カスケードフィルタの結果は、オーダーから独立しているが、第一のフィルタは、高いレートで動作する必要がありますよう順序は、実装の目的のために重要であるかもしれません。いずれの場合においても、実装があれば、結果が同じであるように、フィルタの順序を尊重するように制約されず、それも一つの工程で複合フィルタを実装することができます。
OR operations are not supported with this basic model. More sophisticated filters (e.g., supporting bitmasks, ranges, or OR operations) can be realized as vendor-specific schemes.
OR演算は、この基本的なモデルではサポートされていません。より洗練されたフィルタ（例えば、支持ビットマスク、範囲、またはOR演算）は、ベンダー固有のスキームとして実現することができます。
Property match operations should be available for different protocol portions of the packet header:
プロパティマッチ操作は、パケットヘッダの異なるプロトコル部分のために利用可能であるべきです。
(i) IP header (excluding options in IPv4, stacked headers in
IPv6)
(ii) transport header
（ii）は、トランスポートヘッダ
(iii) encapsulation headers (e.g., the MPLS label stack, if present)
（iii）のカプセル化ヘッダー（例えば、MPLSラベルスタック、存在する場合）
When the PSAMP Device offers Property Match Filtering, and, in its usual capacity other than in performing PSAMP functions, identifies or processes information from IP, transport, or encapsulation protocols, then the information should be made available for Filtering. For example, when a PSAMP Device is a router that routes based on destination IP address, that field should be made available for Filtering. Conversely, a PSAMP Device that does not route is not expected to be able to locate an IP address within a packet, or make it available for Filtering, although it may do so.
PSAMPデバイスは、プロパティマッチフィルタリング提供、および、PSAMP機能を実行する以外の通常の容量で、識別またはIP、輸送、またはカプセル化プロトコルからの情報を処理する場合、その情報は、フィルタリングのために利用できるようにすべきです。 PSAMPデバイスはルートが宛先IPアドレスに基づいてルータである場合、例えば、そのフィールドは、フィルタリングのために利用可能にされるべきです。それはそうかもしれないが、逆に、ルートが期待されていないないPSAMPデバイスは、パケット内のIPアドレスを探し、またはフィルタリングのためにそれを利用できるようにすることができるようにします。
Since packet encryption alters the meaning of encrypted fields, Property Match Filtering must be configurable to ignore encrypted packets when detected.
パケットの暗号化は、暗号化されたフィールドの意味を変えるので、プロパティマッチフィルタリングは、検出されたときに暗号化されたパケットを無視するように設定可能でなければなりません。
The Selection Process may support Filtering based on the properties of the router state:
選択プロセスは、ルータの状態のプロパティに基づいてフィルタリングをサポートすることがあります。
(i) Ingress interface at which packet arrives equals a
specified value
(ii) Egress interface to which packet is routed to equals a specified value
パケットにルーティングされる（ii）の出力インターフェイスは、指定された値に等しいです
(iii) Packet violated Access Control List (ACL) on the router
（ⅲ）パケットは、ルータのアクセス制御リスト（ACL）を違反しました
(iv) Failed Reverse Path Forwarding (RPF). Packets that match the Failed Reverse Path Forwarding (RPF) condition are packets for which ingress Filtering failed as defined in [RFC3704].
（IV）は、リバースパス転送（RPF）を失敗しました。失敗リバースパス転送（RPF）の条件に一致するパケットは、[RFC3704]で定義されるようにフィルタ処理が失敗した進入のためのパケットです。
(v) Failed Resource Reservation Protocol (RSVP). Packets that match the Failed RSVP condition are packets that do not fulfill the RSVP specification as defined in [RFC2205].
（v）は、リソース予約プロトコル（RSVP）に失敗しました。失敗RSVP条件に一致するパケットは、[RFC2205]で定義されているRSVP仕様を満たさないパケットです。
(vi) No route found for the packet
（VI）のパケットが見つかりませんルート
(vii) Origin Border Gateway Protocol (BGP) Autonomous System (AS) [RFC4271] equals a specified value or lies within a given range
（VII）を原点ボーダーゲートウェイプロトコル（BGP）は、自律システム（AS）[RFC4271]は、指定された値と等しいまたは所定の範囲内にあります
(viii) Destination BGP AS equals a specified value or lies within a given range
（VIII）宛先BGP ASは、指定された値に等しいまたは所定の範囲内にあります
Router architectural considerations may preclude some information concerning the packet treatment being available at line rate for selection of packets. For example, the Selection Process may not be implemented in the fast path that is able to access router state at line rate. However, when Filtering follows Sampling (or some other selection operation) in a Composite Selector, the rate of the Packet Stream output from the sampler and input to the filter may be sufficiently low that the filter could select based on router state.
ルータアーキテクチャの考慮事項は、パケットの選択のためのラインレートで利用可能であるパケットの処理に関するいくつかの情報を排除することができます。例えば、選択プロセスは、ラインレートでルータの状態にアクセスすることができるファストパスに実装されなくてもよいです。フィルタリング複合セレクタでサンプリング（またはいくつかの他の選択動作）以下しかし、フィルタのサンプラーと、入力からのパケットストリームの出力の速度は、フィルタがルータ状態に基づいて選択することができることを十分に低くすることができます。
* Hash-based Selection:
*ハッシュベースの選択：
Hash-based Selection will employ one or more hash functions to be standardized. A hash function is applied to a subset of Packet Content, and the packet is selected if the resulting hash falls in a specified range. The stronger the hash function, the more closely Hash-based Selection approximates uniform random Sampling. Privacy of hash selection range and hash function parameters obstructs subversion of the Selector by packets that are crafted either to avoid selection or to be selected. Privacy of the hash function is not required. Robustness and security considerations of Hash-based Selection are further discussed in [RFC5475]. Applications of hash-based Sampling are described in Section 11.
ハッシュベースの選択は、標準化される1つのまたは複数のハッシュ関数を使用します。ハッシュ関数は、パケットの内容のサブセットに適用され、得られたハッシュが指定された範囲内にある場合にパケットが選択されます。ハッシュ関数より強く、より密接にハッシュベースの選択は、一様ランダムサンプリングを近似します。ハッシュ選択範囲とハッシュ関数のパラメータのプライバシーは選択を避けるために、または選択されるいずれかで作られているパケットによってセレクタの転覆を妨げます。ハッシュ関数のプライバシーが必要とされていません。ハッシュベースの選択の堅牢性とセキュリティの考慮事項は、さらに、[RFC5475]に記載されています。ハッシュベースサンプリングのアプリケーションは、セクション11に記載されています。
* Population:
*人口：
A Population is a Packet Stream, or a subset of a Packet Stream. A Population can be considered as a base set from which packets are selected. An example is all packets in the Observed Packet Stream that are observed within some specified time interval.
人口は、パケットストリーム、またはパケットストリームのサブセットです。人口は、パケットが選択される基本セットとみなすことができます。例えば、いくつかの指定された時間間隔内で観察された観測されたパケットストリーム内のすべてのパケットです。
* Population Size
* 人口規模
The Population Size is the number of all packets in a Population.
人口規模は人口のすべてのパケットの数です。
* Sample Size
* サンプルサイズ
The Sample Size is the number of packets selected from the Population by a Selector.
サンプルサイズは、セレクタにより集団から選択されたパケットの数です。
* Configured Selection Fraction
*構成された選択画
The Configured Selection Fraction is the expected ratio of the Sample Size to the Population Size, as based on the configured selection parameters.
構成された選択パラメータに基づくように構成された選択画分は、集団サイズのサンプルサイズの期待される比率です。
* Attained Selection Fraction
*達成セレクション分数
The Attained Selection Fraction is the ratio of the actual Sample Size to the Population Size.
達成の選択画分は集団の大きさに、実際のサンプルサイズの比率です。
For some Sampling methods, the Attained Selection Fraction can differ from the Configured Selection Fraction due to, for example, the inherent statistical variability in Sampling decisions of probabilistic Sampling and Hash-based Selection. Nevertheless, for large Population Sizes and properly configured Selectors, the Attained Selection Fraction usually approaches the Configured Selection Fraction.
いくつかのサンプリング方法のために、達成選択画分は、例えば、構成された選択画分から起因して異なることが、確率的サンプリングとハッシュベースの選択のサンプリング決定に固有の統計的変動。それにもかかわらず、大規模な人口サイズと適切に設定セレクタのために、達成の選択画分は、通常、構成された選択フラクションに近づきます。
The notions of Configured/Attained Selection Fractions extend beyond Selectors. An illustrative example is the Configured Selection Fraction of the composition of the Metering Process with the Exporting Process. Here the Population is the Observed Packet Stream or a subset thereof. The Configured Selection Fraction is the fraction of the Population for which Packet Reports are expected to reach the Collector. This quantity may reflect additional parameters, not necessarily described in the PSAMP protocol, that determine the degree of loss suffered by Packet Reports en route to the Collector, e.g., the transmission bandwidth available to the Exporting Process. In this example, the Attained Selection Fraction is the fraction of Population packets for which reports did actually reach the Collector, and thus incorporates the effect of any loss of Packet Reports due, e.g., to resource contention at the Observation Point or during transmission.
設定済み/達成セレクション画分の概念は、セレクタを超えて拡張します。例示的な例は、エクスポートプロセスと計量プロセスの組成物の構成された選択割合です。ここで人口が観察されたパケットストリームまたはそのサブセットです。構成された選択フラクションは、パケットレポートはコレクターに達すると予想される人口の割合です。この量は、コレクタへの途中でパケットレポートが被る損失の程度を決定必ずしもPSAMPプロトコルで説明されている追加のパラメータを反映することができる、例えば、エクスポートプロセスに利用可能な伝送帯域幅。この例では、達成の選択画分は、報告書は、実際の観測点で、または送信中に競合資源化に、例えば、コレクターに達し、ひいてはによるパケットレポートの任意の損失の影響を取り入れたのいる人口パケットの割合です。
Each instance of a Primitive Selector must maintain a count of packets presented at its input. The counter value is to be included as a sequence number for selected packets. The sequence numbers are considered as part of the packet's Selection State.
プリミティブセレクタの各インスタンスは、その入力で発表されたパケットの数を維持する必要があります。カウンタの値が選択されたパケットのシーケンス番号として含まれるべきです。シーケンス番号は、パケットの選択状態の一部として考えられています。
Use of input sequence numbers enables applications to determine the Attained Selection Fraction, and hence correctly normalize network usage estimates regardless of loss of information, regardless of whether this loss occurs because of discard of Packet Reports in the Metering Process (e.g., due to resource contention in the host of these processes), or loss of export packets in transmission or collection. See [RFC3176] for further details.
入力シーケンス番号の使用が達成セレクション画分を決定するためのアプリケーションを可能にし、ひいては正確にかかわらず、この損失は、競合資源化に起因する計量プロセス（例えば、中にため、パケットレポートの破棄が原因で発生するかどうかのに関わらず、情報の損失のネットワーク使用量の推定値を正規化これらのプロセスのホストで）、または伝送またはコレクション内のエクスポートパケットの損失。詳細については、[RFC3176]を参照してください。
As an example, consider a set of n consecutive Packet Reports r1, r2,... , rn, selected by a Sampling operation and received at a Collector. Let s1, s2,..., sn be the input sequence numbers reported by the packets. The Attained Selection Fraction for the composite of the measurement and Exporting Processes, taking into account both packet Sampling at the Observation Point and loss in transmission, is computed as R = (n-1)/(sn-s1). (Note that R would be 1 if all packets were selected and there were no transmission loss.)
一例として、n個の連続パケットレポートR1、R2、···、RN、サンプリング動作によって選択され、コレクタで受信のセットを考えます。パケットによって報告された入力シーケンス番号SNも、S1、S2、...してみましょう。アカウントに送信の両方のパケット観測ポイントでサンプリングし、損失を取って測定し、エクスポートプロセスの複合のための達成の選択画分を、R =（N-1）/（SN-S1）として計算されます。 （すべてのパケットが選択されない伝送損失が存在しなかった場合はR 1であろうことに留意されたいです。）
The Attained Selection Fraction can be used to estimate the number of bytes present in a portion of the Observed Packet Stream. Let b1, b2,..., bn be the number of bytes reported in each of the packets that reached the Collector, and set B = b1+b2+...+bn. Then the total bytes present in packets in the Observed Packet Stream whose input sequence numbers lie between s1 and sn is estimated by B/R, i.e., scaling up the measured bytes through division by the Attained Selection Fraction.
達成選択画分が観測されたパケットストリームの一部に存在するバイトの数を推定するために使用することができます。 B1、B2を聞かせ、...、BNコレクタに到達したパケットのそれぞれに報告バイト数、および設定B = B1 + B2 + ... + BNです。次いで、入力シーケンス番号S1とSNとの間にある観測されたパケットストリーム内のパケットの中に存在する全バイトが達成選択画分で除算して測定バイトをスケールアップ、B / R、すなわち、によって推定されます。
With Composite Selectors, an input sequence number must be reported for each Selector in the composition.
複合セレクタと、入力されたシーケンス番号は、組成物中の各セレクタのために報告されなければなりません。
The ability to compose Selectors in a Selection Process should be provided. The following combinations appear to be most useful for applications:
選択プロセスでセレクタを構成する機能が提供されるべきです。以下の組み合わせは、アプリケーションのために最も有用であることが表示されます。
* concatenation of Property Match Filters. This is useful for constructing the AND of the component filters.
*プロパティマッチフィルタの連結。これは、成分フィルタのANDを構築するために有用です。
* Filtering followed by Sampling.
*フィルタリングはサンプリングが続きます。
* Sampling followed by Filtering.
*サンプリングはフィルタリングが続きます。
Composite Selectors are useful for drill-down applications. The first component of a Composite Selector can be used to reduce the load on the second component. In this setting, the advantage to be gained from a given ordering can depend on the composition of the Packet Stream.
コンポジットセレクタは、ドリルダウン用途に有用です。複合セレクターの第一の成分は、第二成分の負荷を軽減するために使用することができます。この設定では、与えられた順序から得られるという利点は、パケットストリームの組成に依存することができます。
Sampling at full line rate, i.e., with probability 1, is not excluded in principle, although resource constraints may not permit it in practice.
資源制約は、実際にそれを許可しないかもしれないが、フルラインレートでサンプリング、すなわち、確率1で、原則的に除外されていません。
This section details specific requirements for reporting, motivated by the generic requirements of Section 3.4.
このセクションでは、3.4節の一般的な要件が動機と報告のための特定の要件を、詳しく説明します。
Packet Reports must include the following:
パケットのレポートには、以下を含める必要があります。
(i) the input sequence number(s) of any Selectors that acted on
the packet in the instance of a Metering Process that
produced the report.
(ii) the identifier of the Metering Process that produced the selected packet.
（ii）は、選択されたパケットを生成した計量プロセスの識別子。
The Metering Process must support inclusion of the following in each Packet Report, as a configurable option:
計量プロセスは、設定可能なオプションとして、各パケット報告書に次を含めることをサポートする必要があります。
(iii) a basic report on the packet, i.e., some number of
contiguous bytes from the start of the packet, including
the packet header (which includes network layer and any encapsulation headers) and some subsequent bytes of the
packet payload.
Some devices may not have the resource capacity or functionality to provide more detailed Packet Reports than those in (i), (ii), and (iii) above. Using this minimum required reporting functionality, the Metering Process places the burden of interpretation on the Collector or on applications that it supplies. Some devices may have the capability to provide extended Packet Reports, described in the next section.
いくつかのデバイスは、（i）におけるものよりもより詳細なパケットレポートを提供するためにリソース容量または機能を有していなくてもよい（II）、および（iii）上記。この最低限必要なレポート機能を使用して、計量プロセスは、コレクタの上またはそれが提供するアプリケーション上の解釈の負担を配置します。一部のデバイスは、次のセクションで説明した拡張パケットのレポートを提供する能力を有していてもよいです。
The Metering Process may support inclusion in Packet Reports of the following information, inclusion of any or all being configurable as an option.
計量プロセスは、以下の情報のパケットレポート、オプションとして構成され、任意のまたはすべての包含に含めることをサポートすることができます。
(iv) fields relating to the following protocols used in the
packet: IPv4, IPV6, transport protocols, and encapsulation
protocols including MPLS.
(v) packet treatment, including:
（v）は、パケット処理、を含みます：
- identifiers for any input and output interfaces of the Observation Point that were traversed by the packet
- パケットが横断した観測ポイントの任意の入力および出力インターフェースの識別子
- source and destination BGP AS
- 送信元と宛先BGP AS
(vi) Selection State associated with the packet, including:
（VI）を含むパケットに関連付けられている選択状態、：を
- the timestamp of observation of the packet at the Observation Point. The timestamp should be reported to microsecond resolution.
- Observation Pointのパケットの観測のタイムスタンプ。タイムスタンプは、マイクロ秒の解像度に報告しなければなりません。
- hash values, where calculated.
- 計算されたハッシュ値。
It is envisaged that selection of fields for Extended Packet Reporting may be used to reduce reporting bandwidth, in which case the option to report information in (iii) may not be exercised.
拡張パケットレポートのフィールドの選択は、（III）に情報を報告するためのオプションが行使されない場合があり、その場合、報告帯域幅を減少させるために使用され得ることが想定されます。
If an IPFIX Metering Process is supported at the Observation Point, then in order to be PSAMP compliant, Extended Packet Reports must be able to include all fields required in the IPFIX information model [RFC5102], with modifications appropriate to reporting on single packets rather than Flows.
IPFIX計量プロセスは、観測点で支持されている場合、PSAMP準拠し、拡張パケットレポートであるために、単一のパケットで報告はなくへの適切な変更を加えてIPFIX情報モデルに必要なすべてのフィールド[RFC5102]を含むことができなければなりません流れ。
The Report Interpretation must include:
レポートの解釈が含まれている必要があります
(i) configuration parameters of the Selectors of the packets
reported on;
(ii) format of the Packet Report;
（ii）のパケットレポートのフォーマット。
(iii) indication of the inherent accuracy of the reported quantities, e.g., of the packet timestamp.
（iii）のパケットのタイムスタンプの報告された量の固有の精度、例えば、の指示。
The accuracy measure in (iii) is of fundamental importance for estimating the likely error attached to estimates formed from the Packet Reports by applications.
（III）の精度の尺度は、アプリケーションによるパケットレポートから形成された推定値に付着可能性エラーを推定するための基本的に重要です。
The requirements for robustness and transparency are motivations for including Report Interpretation in the Report Stream: it makes the Report Stream self-defining. The PSAMP framework excludes reliance on an alternative model in which interpretation is recovered out of band. This latter approach is not robust with respect to undocumented changes in Selector configuration, and may give rise to future architectural problems for network management systems to coherently manage both configuration and data collection.
堅牢性と透明性の要件は、レポートストリームでのレポートの解釈を含むための動機です：それはレポートストリーム自己定義になります。 PSAMPフレームワークは、解釈が帯域外で回収された別のモデルへの依存を排除します。この後者のアプローチは、セレクタ構成で文書化されていない変化に対してロバストではなく、コヒーレントの両方の構成およびデータ収集を管理するネットワーク管理システムの将来のアーキテクチャ上の問題を生じ得ます。
It is not envisaged that all Report Interpretation be included in every Packet Report. Many of the quantities listed above are expected to be relatively static; they could be communicated periodically, and upon change.
すべてのレポートの解釈は、すべてのパケット報告書に含まれていることを想定されていません。上記の量の多くは比較的静的であると予想されます。彼らは定期的に伝え、および変更時にすることができます。
Because of the increasing number of distinct measurement applications with varying requirements, it is desirable to set up parallel Metering Processes on a given Observed Packet Stream. A device capable of hosting a Metering Process should be able to support more than one independently configurable Metering Process simultaneously. Each such Metering Process should have the option of being equipped with its own Exporting Process; otherwise, the parallel Metering Processes may share the same Exporting Process.
なぜなら変化する要件と明確な測定アプリケーションの増加のために、それは、所与の観測されたパケットストリーム上で平行計量プロセスを設定することが望ましいです。計量プロセスをホストすることが可能なデバイスは、同時に複数の独立設定計量プロセスをサポートすることができなければなりません。それぞれのそのような計量プロセスは、独自のエクスポートプロセスを装備しているのオプションを持っている必要があります。そうでない場合は、パラレル計量プロセスは、同じエクスポートプロセスを共有することができます。
Each of the parallel Metering Processes should be independent. However, resource constraints may prevent complete reporting on a packet selected by multiple Selection Processes. In this case, reporting for the packet must be complete for at least one Metering Process; other Metering Processes need only record that they selected the packet, e.g., by incrementing a counter. The priority among Metering Processes under resource contention should be configurable.
パラレル計量プロセスのそれぞれは独立していなければなりません。ただし、リソースの制約は、複数の選択プロセスによって選択されたパケットに対して完全な報告を防ぐことができます。この場合、パケットのレポートは、少なくとも1つの計量プロセスのために完全でなければなりません。他の計量プロセスは、彼らがカウンタをインクリメントすることにより、例えば、パケットを選択したことだけレコードが必要です。リソースの競合下の計量プロセスの中での優先順位は、設定する必要があります。
It is not proposed to standardize the number of parallel Metering Processes.
並列計量プロセスの数を標準化することが提案されていません。
This section details specific requirements for the Exporting Process, motivated by the generic requirements of Section 3.6.
このセクションでは、セクション3.6の一般的な要件によって動機付けエクスポートプロセスのための特定の要件を、詳しく説明します。
PSAMP will use the IP Flow Information Export (IPFIX) protocol for export of the Report Stream. The IPFIX protocol is well suited for this purpose, because the IPFIX architecture matches the PSAMP architecture very well and the means provided by the IPFIX protocol are sufficient for PSAMP purposes. On the other hand, not all features of the IPFIX protocol will need to be implemented by some PSAMP Devices. For example, a device that offers only content-independent Sampling and basic PSAMP reporting has no need to support IPFIX capabilities based on packet fields.
PSAMPは、レポートストリームの輸出のためのIPフロー情報のエクスポート（IPFIX）プロトコルを使用します。 IPFIXアーキテクチャは非常によくPSAMPアーキテクチャと一致し、IPFIXプロトコルによって提供される手段は、PSAMPの目的のために十分であるため、IPFIXプロトコルは、この目的に適しています。一方、IPFIXプロトコルのではないすべての機能がいくつかPSAMPデバイスで実装する必要があります。例えば、コンテンツのみに依存しないサンプリングと基本的なPSAMPのレポートを提供していますデバイスはパケットのフィールドに基づいてIPFIX機能をサポートする必要がありません。
Export Packets may contain one or more Packet Reports, and/or Report Interpretation. Export Packets must also contain:
エクスポートパケットは、一つ以上のパケットレポートが含まれている、および/または解釈を報告することがあります。エクスポートパケットも含まれている必要があります：
(i) an identifier for the Exporting Process
（I）エクスポートプロセスの識別子
(ii) an Export Packet sequence number
（ii）のエクスポートパケットシーケンス番号
An Export Packet sequence number enables the Collector to identify loss of Export Packets in transit. Note that some transport protocols, e.g., UDP, do not provide sequence numbers. Moreover, having sequence numbers available at the application level enables the Collector to calculate the packet loss rate for use, e.g., in estimating original traffic volumes from Export Packets that reach the Collector.
エクスポートパケットシーケンス番号は、輸送中にエクスポートパケットの損失を識別するためにコレクタを可能にします。いくつかのトランスポート・プロトコルは、例えば、UDPは、シーケンス番号を提供しないことに注意してください。また、アプリケーション・レベルで使用可能なシーケンス番号を有するコレクタに到達エクスポートパケットから元のトラフィック量を推定する際に、例えば、使用するためのパケット損失率を計算するためにコレクタを可能にします。
The export of the Report Stream does not require reliable export. Section 5.4 shows that the use of input sequence numbers in packet Selectors means that the ability to estimate traffic rates is not impaired by export loss. Export Packet loss becomes another form of Sampling, albeit a less desirable, and less controlled, form of Sampling.
レポートストリームの輸出は、信頼性の高い輸出を必要としません。 5.4節では、パケットのセレクタで入力シーケンス番号の使用は、トラフィックレートを推定する能力は、輸出損失によって損なわれないことを意味していることを示しています。エクスポートパケット損失は、サンプリングの、あまり望ましく、そしてより少ない制御された形態にもかかわらず、サンプリングの別の形態になります。
In distinction, retransmission of lost Export Packets consumes additional network resources. The requirement to store unacknowledged data is an impediment to having ubiquitous support for PSAMP.
区別では、失われたエクスポートパケットの再送信は、追加のネットワークリソースを消費します。未確認のデータを格納するための要件はPSAMPためのユビキタス支持体を有するの障害です。
In order to jointly satisfy the timeliness and congestion avoidance requirements of Section 4.3, a congestion-aware unreliable transport protocol may be used. IPFIX is compatible with this requirement, since it mandates support of the Stream Control Transmission Protocol (SCTP) [RFC4960] and the SCTP Partial Reliability Extension [RFC3758].
共同で4.3節の適時および輻輳回避の要件を満たすために、混雑認識信頼できないトランスポートプロトコルを使用することができます。それはストリーム制御伝送プロトコル（SCTP）[RFC4960]及びSCTP部分信頼拡張[RFC3758]のサポートを義務付けためIPFIXは、この要件と互換性があります。
IPFIX also allows the use of the User Datagram Protocol (UDP) [RFC0768], although it is not a congestion-aware protocol. However, in this case, the Export Packets must remain wholly within the administrative domains of the operators [RFC5101]. The PSAMP Exporting Process is equipped with a configurable export rate limit (see Section 8.4) that can be used to limit the export rate when a congestion-aware transport protocol is not used. The Collector, upon detection of Export Packet loss through missing export sequence numbers, may reconfigure the export rate limit downwards in order to avoid congestion.
それは混雑対応プロトコルないがIPFIXはまた、ユーザ・データグラム・プロトコル（UDP）[RFC0768]の使用を可能にします。しかし、この場合には、エクスポートパケットは、[RFC5101]のオペレータの管理ドメイン内に完全に維持しなければなりません。 PSAMPエクスポートプロセスは、混雑認識トランスポートプロトコルが使用されない場合、輸出率を制限するために使用することができる構成エクスポートレート制限（セクション8.4を参照）を備えています。コレクタは、不足しているエクスポートシーケンス番号を介してエクスポートパケットロスを検出すると、輻輳を回避するために下方にエクスポートレート制限を再構成することができます。
The Exporting Process must have an export rate limit, configurable per Exporting Process. This is useful for two reasons:
エクスポートプロセスは、プロセスをエクスポートごとに設定輸出レート制限を、持っている必要があります。これは、2つの理由のために有用です：
(i) Even without network congestion, the rate of packet
selection may exceed the capacity of the Collector to
process reports, particularly when many Exporting Processes
feed a common Collector. Use of an Export Rate Limit
allows control of the global input rate to the Collector.
(ii) IPFIX provides export using UDP as the transport protocol in some circumstances. An Export Rate Limit allows the capping of the export rate to match both path link speeds and the capacity of the Collector.
（II）IPFIXは、いくつかの状況では、トランスポートプロトコルとしてUDPを使用してエクスポートを提供します。エクスポートレートリミットは、輸出比率のキャッピングは、パスのリンク速度とコレクターの容量の両方を一致させることができます。
Low measurement latency allows the traffic monitoring system to be more responsive to real-time network events, for example, in quickly identifying sources of congestion. Timeliness is generally a good thing for devices performing the Sampling since it minimizes the amount of memory needed to buffer samples.
低い測定待ち時間は、トラフィック監視システムが迅速に輻輳の発生源を識別する際に、例えば、リアルタイムネットワークイベントに対してより応答することを可能にします。適時性は、一般的には、サンプルをバッファリングするために必要なメモリの量を最小限に抑えるため、サンプリングを実施するデバイスのために良いことです。
Keeping the packet dispatching delay small has other benefits besides limiting buffer requirements. For many applications, a resolution of 1 second is sufficient. Applications in this category would include identifying sources associated with congestion, tracing Denial-of-Service (DoS) attacks through the network, and constructing traffic matrices. Furthermore, keeping dispatch delay within the resolution required by applications eliminates the need for timestamping by synchronized clocks at Observation Points, or for the Observation Points and Collector to maintain bidirectional communication in order to track clock offsets. The Collector can simply process Packet Reports in the order that they are received, using its own clock as a "global" time base. This avoids the complexity of buffering and reordering samples. See [DuGeGr02] for an example.
小さな遅延を派遣パケットを維持するバッファ要件を制限する以外にも利点があります。多くの用途のために、1秒の分解能で十分です。このカテゴリのアプリケーションは、混雑に関連した情報源を特定するネットワークを介して、サービス拒否（DoS）攻撃を追跡し、トラフィック行列を構築含まれます。また、アプリケーションによって必要とされる分解能内ディスパッチ遅延を維持する観測点での同期クロックによってタイムスタンプの必要性を排除する、または観測ポイントとコレクタのクロックオフセットを追跡するために、双方向通信を維持します。コレクターは、単に彼らは「グローバル」タイムベースとして独自のクロックを使用して、受信された順番にパケットレポートを処理することができます。これは、バッファリングと並べ替えのサンプルの複雑さを避けることができます。例えば[DuGeGr02]を参照してください。
The delay between observation of a packet and transmission of an Export Packet containing a report on that packet has several components. It is difficult to standardize a given numerical delay requirement, since in practice the delay may be sensitive to processor load at the Observation Point. Therefore, PSAMP aims to control that portion of the delay within the Observation Point that is due to buffering in the formation and transmission of Export Packets.
パケットの観察とそのパケットにレポートを含むエクスポートパケットの送信の間の遅延は、いくつかの構成要素を有しています。実際に遅延が観測点におけるプロセッサ負荷に敏感であり得るので、与えられた数値の遅延要件を標準化することは困難です。したがって、PSAMPエクスポートパケットの形成及び送信におけるバッファリングに起因する観測点内の遅延の部分を制御することを目的とします。
In order to limit delay in the formation of Export Packets, the Exporting Process must provide the ability to close out and enqueue for transmission any Export Packet during formation as soon as it includes one Packet Report.
エクスポートパケットの形成の遅延を制限するために、エクスポートプロセスはすぐにそれが1件のパケット報告を含むように形成中の任意のエクスポートパケットを閉じて、送信のためにエンキューする能力を提供しなければなりません。
In order to limit the delay in the transmission of Export Packets, a configurable upper bound to the delay of an Export Packet prior to transmission must be provided. If the bound is exceeded, the Export Packet is dropped. This functionality can be provided by the timed reliability service of the SCTP Partial Reliability Extension [RFC3758].
エクスポートパケットの送信に遅延を制限するために、送信前にエクスポートパケットの遅延に設定上限を設けなければなりません。バウンドを超えた場合は、エクスポートパケットはドロップされます。この機能は、SCTP部分信頼拡張[RFC3758]の時限信頼性サービスによって提供することができます。
The Exporting Process may enqueue the Report Stream in order to export multiple Packet Reports in a single Export Packet. Any consequent delay must still allow for timely availability of Packet Reports as just described. The timed reliability service of the SCTP Partial Reliability Extension [RFC3758] allows the dropping of packets from the export buffer once their age in the buffer exceeds a configurable bound. A suitable default value for the bound should be used in order to avoid a low transmission rate due to misconfiguration.
エクスポートプロセスは、単一のエクスポートパケット内に複数のパケットレポートをエクスポートするために、レポートストリームをエンキューします。いずれの結果としての遅延はまだ今述べたように、パケットのレポートのタイムリーな可用性を可能にしなければなりません。バッファ内の自分の年齢が設定可能なバウンドを超えるとSCTP部分信頼拡張[RFC3758]のタイミング信頼性サービスは、輸出バッファからのパケットのドロップすることができます。バウンドに適したデフォルト値が設定ミスによる低い伝送レートを避けるために使用すべきです。
To conserve network bandwidth and resources at the Collector, the Export Packets may be compressed before export. Compression is expected to be quite effective since the selected packets may share many fields in common, e.g., if a filter focuses on packets with certain values in particular header fields. Using compression, however, could impact the timeliness of Packet Reports. Any consequent delay must not violate the timeliness requirement for availability of Packet Reports at the Collector.
コレクターでネットワーク帯域幅とリソースを節約するために、エクスポートパケットは、輸出前に圧縮することができます。フィルタは、特定のヘッダフィールドの特定の値を持つパケットに焦点を当てていた場合に選択されたパケットは、例えば、一般的に多くのフィールドを共有することができるので、圧縮が非常に有効であると予想されます。圧縮を使用して、しかし、パケットレポートの適時に影響を与える可能性があります。いずれの結果としての遅延は、コレクターでパケットのレポートの可用性のための適時性要件に違反してはなりません。
When exporting to a remote Collector, the Collector is identified by IP address, transport protocol, and transport port number.
リモートコレクタにエクスポートする場合、コレクタは、IPアドレス、トランスポートプロトコル、およびトランスポートのポート番号によって識別されます。
The Report Stream may be directly exported to on-board measurement-based applications, for example, those that form composite statistics from more than one packet. Local Export may be presented through an interface directly to the higher-level applications, i.e., through an API, rather than employing the transport used for off-board export. Specification of such an API is outside the scope of the PSAMP framework.
レポートストリームが直接、例えば、オンボード測定ベースのアプリケーションにエクスポートすることができる、複数のパケットの複合統計を形成するもの。ローカルエクスポートはなく、オフボードのエクスポートのために使用されるトランスポートを使用するよりも、APIを介して、すなわち、より高いレベルのアプリケーションに直接インターフェースを介して提示されてもよいです。そのようなAPIの仕様は、PSAMPのフレームワークの範囲外です。
A possible example of Local Export could be that packets selected by the PSAMP Metering Process serve as the input for the IPFIX protocol, which then forms Flow Records out of the stream of selected packets.
ローカルエクスポートの可能な例は、PSAMP計量プロセスによって選択されたパケットは、次に選択されたパケットのストリームからフローレコードを形成IPFIXプロトコルのための入力として働くことがあり得ます。
A key requirement for PSAMP is the easy reconfiguration of the parameters of the Metering Process, including those for selection and Packet Reports, and of the Exporting Process. An important example is to support measurement-based applications that want to adaptively drill-down on traffic detail in real time.
PSAMPのための重要な要件は、選択およびパケットレポートのため、およびエクスポートプロセスのものを含む計量プロセスのパラメータの容易な再構成です。重要な例は、適応的にリアルタイムでトラフィック詳細にドリルダウンしたい測定ベースのアプリケーションをサポートすることです。
To facilitate retrieval and monitoring of parameters, they are to reside in a Management Information Base (MIB). Mandatory monitoring objects will cover all mandatory PSAMP functionality. Alarming of specific parameters could be triggered with thresholding mechanisms such as the RMON (Remote Network Monitoring) event and alarm [RFC2819] or the event MIB [RFC2981].
パラメータの検索および監視を容易にするために、それらは、管理情報ベース（MIB）に存在することです。必須監視オブジェクトは、すべての必須PSAMPの機能をカバーします。特定のパラメータの警報は、RMON（リモートネットワークモニタリング）イベントとアラーム[RFC2819]またはイベントMIB [RFC2981]として閾値化機構をトリガすることができます。
For configuring parameters of the Metering Process, several alternatives are available including a MIB module with writeable objects, as well as other configuration protocols. For configuring parameters of the Exporting Process, the Packet Report, and the Report Interpretation, which is an IFPIX task, the IPFIX configuration method(s) should be used.
計量プロセスのパラメータを設定するために、いくつかの選択肢が書き込み可能なオブジェクトとMIBモジュール、ならびに他の構成プロトコルを含む利用可能です。エクスポートプロセスのパラメータを設定するため、IFPIXタスクのパケットレポート、およびレポートの解釈は、IPFIXの構成方法（複数可）が使用されるべきです。
Although management and configuration of Collectors is out of scope, a PSAMP Device, to the extent that it employs IPFIX as an export protocol, inherits from IPFIX the capability to detect and recover from Collector failure; see Section 8.2 of [RFC5470].
コレクターの管理および設定の範囲外であるが、PSAMPデバイスは、それがエクスポートプロトコルとしてIPFIXを使用する程度まで、IPFIXから検出し、コレクタ障害から回復する能力を継承します。 [RFC5470]のセクション8.2を参照してください。
In order for PSAMP to be supported across the entire spectrum of networking equipment, it must be simple and inexpensive to implement. One can envision easy-to-implement instances of the mechanisms described within this document. Thus, for that subset of instances, it should be straightforward for virtually all system vendors to include them within their products. Indeed, Sampling and Filtering operations are already realized in available equipment.
ネットワーク機器の全体のスペクトル全体でサポートするPSAMPためには、実現するのは簡単で安価でなければなりません。一つは、この文書内に記述メカニズムを簡単に実装できるインスタンスを想像することができます。このように、インスタンスのサブセットのために、それは彼らの製品の中にそれらを含めるために、事実上すべてのシステム・ベンダーのために簡単です。確かに、サンプリングとフィルタリング操作は、すでに利用可能な装置で実現されています。
Here we give some specific arguments to demonstrate feasibility and comment on the complexity of hardware implementations. We stress here that the point of these arguments is not to favor or recommend any particular implementation, or to suggest a path for standardization, but rather to demonstrate that the set of possible implementations is not empty.
ここでは、実現可能性を実証し、ハードウェア実装の複雑さにコメントするにはいくつかの特定の引数を与えます。私たちは、これらの引数のポイントは、賛成か、お勧め任意の特定の実装を、または標準化のためのパスを示唆するのではなく、可能な実装のセットが空でないことを実証するためにされていないことをここで強調しています。
Filtering consists of a small number of mask (bit-wise logical), comparison, and range (greater than) operations. Implementation of at least a small number of such operations is straightforward. For example, filters for security Access Control Lists (ACLs) are widely implemented. This could be as simple as an exact match on certain fields, or involve more complex comparisons and ranges.
フィルタリングは、小さなマスクの数（ビット単位論理）、比較、および範囲（より大きい）の動作から成ります。このような操作の少なくとも少数の実装は簡単です。例えば、セキュリティアクセス制御リスト（ACL）のためのフィルタが広く実装されています。これは、特定のフィールドに完全に一致するような単純なもの、またはより複雑な比較や範囲を伴う可能性があります。
Sampling based on either counters (counter set, decrement, test for equal to zero) or range matching on the hash of a packet (greater than) is possible given a small number of Selectors, although there may be some differences in ease of implementation for hardware vs. software platforms.
いずれかのカウンタ（カウンタのセット、デクリメント、ゼロに等しいための試験）パケットのハッシュに又は範囲マッチングに基づくサンプリング（より大きい）の実装を容易にするためにいくつかの違いがあるかもしれないが、セレクタ少数の所与可能ですソフトウェアプラットフォーム対ハードウェア。
Hashing functions vary greatly in complexity. Execution of a small number of sufficiently simple hash functions is implementable at line rate. Concerning the input to the hash function, hop-invariant IP header fields (IP address, IP identification) and TCP/UDP header fields (port numbers, TCP sequence number) drawn from the first 40 bytes of the packet have been found to possess a considerable variability; see [DuGr01].
ハッシュ関数は複雑で大きく変化します。十分に簡単なハッシュ関数の数が少ないの実行は、ラインレートで実装可能です。ハッシュ関数への入力、ホップ不変のIPヘッダフィールド（IPアドレス、IP識別）及びTCP / UDPヘッダフィールドに関するパケットの最初の40バイトから引き出さ（ポート番号、TCPシーケンス番号）を有することが見出されていますかなりの変動; [DuGr01]を参照してください。
The simplest Packet Report would duplicate the first n bytes of the packet. However, such an uncompressed format may tax the bandwidth available to the Exporting Process for high Sampling rates; reporting selected fields would save on this bandwidth. Thus, there is a trade-off between simplicity and bandwidth limitations.
最も単純なパケット報告書は、パケットの最初のnバイトを複製します。しかしながら、そのような非圧縮形式は、高いサンプリングレートのためのエクスポートプロセスに利用可能な帯域幅を負担することができます。選択したフィールドを報告することは、この帯域幅を節約します。このように、シンプルさと帯域幅の制限との間にトレードオフがあります。
Ease of exporting Export Packets depends on the system architecture. Most systems should be able to support export by insertion of Export Packets, even through the software path.
エクスポートパケットを輸出しやすさは、システムのアーキテクチャに依存します。ほとんどのシステムでもソフトウェアの経路を通って、エクスポートパケットの挿入によって輸出を支援することができるはずです。
Achieving low constants for performance while minimizing hardware resources is, of course, a challenge, especially at very high clock frequencies. Most of the Selectors, however, are very basic and their implementations very well understood; in fact, the average Application-Specific Integrated Circuit (ASIC) designer simply uses canned library instances of these operations rather than design them from scratch. In addition, networking equipment generally does not need to run at the fastest clock rates, further reducing the effort required to get reasonably efficient implementations.
ハードウェアリソースを最小限に抑えながら、パフォーマンスのための低定数を達成することは、特に非常に高いクロック周波数で、当然のことながら、挑戦です。セレクタのほとんどは、しかし、非常に基本的であり、その実装は非常によく理解し、実際には、平均的な特定用途向け集積回路（ASIC）設計者は、単に最初からそれらをデザインするのではなく、これらの操作の缶詰ライブラリインスタンスを使用しています。また、ネットワーク機器は、一般的に、さらに合理的に効率的な実装を取得するために必要な労力を削減する、最速のクロック速度で実行する必要はありません。
Simple bit-wise logical operations are easy to implement in hardware. Such operations (NAND/NOR/XNOR) directly translate to four-transistor gates. Each bit of a multiple-bit logical operation is completely independent and thus can be performed in parallel incurring no additional performance cost above a single-bit operation.
単純なビット単位の論理演算をハードウェアで実装するのは簡単です。このような動作（NAND / NOR / XNOR）を直接4トランジスタのゲートに変換します。複数ビットの論理演算の各ビットが完全に独立であり、従って、平行単一ビット演算上記追加のパフォーマンスコストを招かないで行うことができます。
Comparisons (EQ/NEQ) take O(log(M)) stages of logic, where M is the number of bits involved in the comparison. The log(M) is required to accumulate the result into a single bit.
比較（EQ / NEQ）は、Mは、比較に関与するビットの数がO（ログ（M））ロジックの段階を取ります。ログ（M）は、単一のビットに結果を蓄積する必要があります。
Greater-than operations, as used to determine whether a hash falls in a selection range, are a determination of the most significant not-equivalent bit in the two operands. The operand with that most-significant-not-equal bit set to be one is greater than the other.
大なり操作、ハッシュは、選択範囲内にあるかどうかを決定するために使用されるように、2つのオペランドの中で最も重要相当しないビットの決意です。その最上位等しくないビットが設定されたオペランドは、一方が他方よりも大きいことができます。
Thus, a greater-than operation is also an O(log(M)) stages-of-logic operation. Optimized implementations of arithmetic operations are also O(log(M)) due to propagation of the carry bit.
したがって、大なり操作もO（ログ（M））段階-の論理演算です。算術演算の最適化されたインプリメンテーションが原因キャリー・ビットの伝搬にもO（ログ（M））です。
Setting a counter is simply loading a register with a state. Such an operation is simple and fast O(1). Incrementing or decrementing a counter is a read, followed by an arithmetic operation, followed by a store. Making the register dual-ported does take additional space, but it is a well-understood technique. Thus, the increment/decrement is also an O(log(M)) operation.
カウンタを設定すると、単に状態をレジスタにロードされます。そのような操作が簡単かつ迅速O（1）です。カウンタをインクリメントまたはデクリメントするストアが続く、演算に続いてリードです。レジスタはデュアル・ポート作ることは、追加のスペースを取りませんが、それはよく理解技術です。したがって、インクリメント/デクリメントもO（ログ（M））の動作です。
Hashing functions come in a variety of forms. The computation involved in a standard Cyclic Redundancy Check (CRC), for example, is essentially a set of XOR operations, where the intermediate result is stored and XORed with the next chunk of data. There are only O(1) operations and no log complexity operations. Thus, a simple hash function, such as CRC or generalizations thereof, can be implemented in hardware very efficiently.
ハッシング関数は、様々な形で来ます。標準的な巡回冗長検査（CRC）に関与する計算は、例えば、本質的に中間結果データの次のチャンクが格納さとXORさXOR演算の集合です。 O（1）操作なしログ複雑操作のみがあります。したがって、このようなCRCまたは一般化などの単純なハッシュ関数は、それらの、非常に効率的にハードウェアで実装することができます。
At the other end of the range of complexity, the MD5 function uses a large number of bit-wise conditional operations and arithmetic operations. The former are O(1) operations and the latter are O(log(M)). MD5 specifies 256 32 bit ADD operations per 16 bytes of input processed. Consider processing 10 Gb/sec at 100 MHz (this processing rate appears to be currently available). This requires processing 12.5 bytes/cycle, and hence at least 200 adders, a sizeable number. Because of data dependencies within the MD5 algorithm, the adders cannot be simply run in parallel, thus requiring either faster clock rates and/or more advanced architectures. Thus, selection hashing functions as complex as MD5 may be precluded for ubiquitous use at full line rate. This motivates exploring the use of selection hash functions with complexity somewhere between that of MD5 and CRC. In some applications (see Section 11), a second hash may be calculated on only selected packets; MD5 is feasible for this purpose if the rate of production of selected packets is sufficiently low.
複雑さの範囲の他端には、MD5機能は、ビット単位の条件付き演算と算術演算の多数を使用します。前者はO（1）操作であり、後者は、O（（M）の対数）です。 MD5は、256ビット32は、処理された入力の16バイトごとに操作を追加指定します。 100MHzでの10Gb /秒の処理を考える（この処理速度は、現在利用可能であるように見えます）。これにより、処理12.5バイト/サイクルを必要とし、従って少なくとも200個の加算器、かなりの数。そのためMD5アルゴリズム内のデータの依存関係のため、加算器は、単にので、より高速のクロックレートおよび/またはより高度なアーキテクチャのいずれかを必要とし、並行して実行することはできません。したがって、MD5などの錯体として選択ハッシュ関数は、フルラインレートでユビキタス使用のために除外されてもよいです。これはどこかにMD5とCRCのそれとの間の複雑さに選択ハッシュ関数の使用を模索動機。いくつかの用途（セクション11を参照）において、第2のハッシュは、選択されたパケットに基づいて計算されてもよいです。選択されたパケットの生成速度が十分に低い場合MD5は、この目的のために実現可能です。
We first describe several representative operational applications that require traffic measurements at various levels of temporal and spatial granularity. Some of the goals here appear similar to those of IPFIX, at least in the broad classes of applications supported. The major benefit of PSAMP is the support of new network management applications, specifically, those enabled by the packet Selectors that it supports.
まず、時間的および空間的粒度のさまざまなレベルでトラフィック測定を必要とするいくつかの代表的な業務アプリケーションを記述する。ここでの目標のいくつかは、少なくともアプリケーションの幅広いクラスでサポートされ、IPFIXのものと同様に表示されます。 PSAMPの主な利点は、新たなネットワーク管理アプリケーション、それがサポートするパケットセレクタで有効になっ具体的には、これらのサポートです。
Packet Sampling is ideally suited to determine the composition of the traffic across a network. The approach is to enable measurement on a cut-set of the network links such that each packet entering the network is seen at least once, for example, on all ingress links. Unfiltered Sampling with a relatively low selection fraction establishes baseline measurements of the network traffic. Packet Reports include packet attributes of common interest: source and destination address and port numbers, prefix, protocol number, type of service, etc. Traffic matrices are indicated by reporting source and destination AS matrices. Absolute traffic volumes are estimated by renormalizing the sampled traffic volumes through division by either the Configured Selection Fraction or the Attained Selection Fraction (as derived from input packet counters included in the Report Stream).
パケットサンプリングは、理想的には、ネットワーク上のトラフィックの組成を決定するために適しています。アプローチは、ネットワークに入る各パケットは少なくとも一度見られるように、ネットワークリンクのカットセットに、例えば、すべての入力リンク上の測定を可能にすることです。比較的低い選択画分とフィルタリングされていないサンプリングは、ネットワークトラフィックのベースライン測定を確立します。送信元と送信先アドレスとポート番号、プレフィックス、プロトコル番号、サービスの種類、など交通行列が行列AS送信元と送信先の報告で示されますパケットレポートは、パケットの共通の関心の属性が含まれます。絶対トラフィックボリュームが構成された選択画分または達成選択率（レポートストリームに含まれる入力パケットカウンタから誘導される）のいずれかによって分割されサンプリングされたトラフィック量を再正規化することによって推定されます。
Suppose an operator or a measurement-based application detects an interesting subset of a Packet Stream, as identified by a particular packet attribute. Real-time drill down to that subset is achieved by instantiating a new Metering Process on the same Observed Packet Stream from which the subset was reported. The Selection Process of the new Metering Process filters according to the attribute of interest, and composes with Sampling if necessary to manage the attained fraction of packets selected.
特定のパケット属性によって識別されるオペレータまたは測定ベースのアプリケーションは、パケットストリームの興味深いサブセットを検出すると仮定する。リアルタイムそのサブセットにドリルダウンしたサブセットが報告されたのと同じ観測されたパケットストリームに新しい計量プロセスをインスタンス化することによって達成されます。新しい計量プロセスの選択プロセスは、対象の属性に応じてフィルタリングし、選択されたパケットの到達割合を管理するために必要に応じてサンプリングして構成します。
The goal of trajectory Sampling is the selection of a subset of packets at all enabled Observation Points at which these packets are observed in a network domain. Thus, the selection decisions are consistent in the sense that each packet is selected either at all enabled Observation Points or at none of them. Trajectory Sampling is realized by Hash-based Selection if all enabled Observation Points apply a common hash function to a portion of the Packet Content that is invariant along the packet path. (Thus, fields such at TTL and CRC are excluded.)
軌道サンプリングの目標は、これらのパケットがネットワークドメインで観察されるすべての有効な観測点でのパケットのサブセットの選択です。このように、選択決定は、各パケットが有効になっているすべての観測点で、またはそれらのどれものいずれかで選択されているという意味で一致しています。すべての有効な観測ポイントは、パケット・パスに沿って不変であるパケットの内容の一部に共通のハッシュ関数を適用した場合の軌道サンプリングは、ハッシュベースの選択によって実現されます。 （したがって、TTLおよびCRCにおけるそのようなフィールドは除外されます。）
The trajectory followed by a packet is reconstructed from Packet Reports on it that reach the Collector. Reports on a given packet are associated by matching either a label comprising the invariant reported Packet Content or possibly some digest of it. The reconstruction of trajectories and methods for dealing with possible ambiguities due to label collisions (identical labels reported by different packets) and potential loss of reports in transmission are dealt with in [DuGr01], [DuGeGr02], and [DuGr04].
パケットが続く軌道がコレクターに達することでのパケットのレポートから再構築されます。与えられたパケットのレポートは不変報告パケットの内容や、おそらくそれのいくつかのダイジェストを備えたラベルのいずれかを照合することによって関連しています。ラベルの衝突の可能な曖昧性（異なるパケットによって報告された同一のラベル）および送信内のレポートの潜在的な損失に対処するための軌道と方法の再構成は[DuGr04] [DuGeGr02]、[DuGr01]で取り扱われており。
Trajectory Sampling enables the tracking of the performance experience by customer traffic, customers identified by a list of source or destination prefixes, or by ingress or egress interfaces. Operational uses include the verification of Service Level Agreements (SLAs), and troubleshooting following a customer complaint.
軌道サンプリングは、送信元または宛先プレフィックスのリストで識別されるお客様、または入力または出力インターフェイスにより、顧客のトラフィックによる性能の経験の追跡を可能にします。業務用途には、顧客の苦情、次のサービスレベル契約（SLA）の検証、およびトラブルシューティングが含まれます。
In this application, trajectory Sampling is enabled at all network ingress and egress interfaces. Rates of loss in transit between ingress and egress are estimated from the proportion of trajectories for which no egress report is received. Note that loss of customer packets is distinguishable from loss of Packet Reports through use of report sequence numbers. Assuming synchronization of clocks between different entities, delay of customer traffic across the network may also be measured; see [Zs02].
このアプリケーションでは、軌道サンプリングは、すべてのネットワーク入力および出力インターフェイスで有効になっています。入力および出力の間で輸送中の損失の料金は一切出力レポートが受信されないための軌道の割合から推定されています。顧客パケットの損失はパケットレポートの損失からレポートシーケンス番号を使用して識別可能であることに注意してください。異なるエンティティ間のクロックの同期を仮定すると、ネットワークを介して顧客のトラフィックの遅延を測定してもよいです。 [Zs02]を参照してください。
Extending hash selection to all interfaces in the network would enable attribution of poor performance to individual network links.
ネットワーク内のすべてのインターフェイスにハッシュの選択を拡張する個々のネットワークリンクにパフォーマンス低下の帰属を可能にします。
PSAMP Packet Reports can also be used to diagnose problems whose occurrence is evident from aggregate statistics, per interface utilization and packet loss statistics. These statistics are typically moving averages over relatively long time windows, e.g., 5 minutes, and serve as a coarse-grain indication of operational health of the network. The most common method of obtaining such measurements is through the appropriate SNMP MIBs (MIB-II [RFC1213] and vendor-specific MIBs).
PSAMPパケットレポートはまた、その発生集約統計から、インターフェイスの使用率とパケット損失統計ごとに明らかである問題を診断するために使用することができます。これらの統計は、典型的には、比較的長い時間ウィンドウ、例えば、5分かけて移動平均、およびネットワークの運用健康の粗粒指標として機能しています。そのような測定値を得るための最も一般的な方法は、適切なSNMPのMIB（MIB-II [RFC1213]とベンダー固有のMIB）を介して行われます。
Suppose an operator detects a link that is persistently overloaded and experiences significant packet drop rates. There is a wide range of potential causes: routing parameters (e.g., OSPF link weights) that are poorly adapted to the traffic matrix, e.g., because of a shift in that matrix; a DoS attack, a flash crowd, or a routing problem (link flapping). In most cases, aggregate link statistics are not sufficient to distinguish between such causes and to decide on an appropriate corrective action. For example, if routing over two links is unstable, and the links flap between being overloaded and inactive, this might be averaged out in a 5-minute window, indicating moderate loads on both links.
オペレータが持続的に過負荷になり、大幅なパケットのドロップ率を経験されたリンクを検出したとします。潜在的な原因の広い範囲がある：ルーティングパラメータ（例えば、OSPFリンク重み）乏しいため、その行列のシフト、例えばトラフィック行列、に適合されます。 DoS攻撃、フラッシュ・クラウド、またはルーティング問題（リンクフラッピング）。ほとんどの場合、集約リンク統計は、このような原因を区別することは、適切な是正措置を決定するのに十分ではありません。 2上のリンクをルーティングが不安定であり、リンクが過負荷と不活性である間にフラップたとえば、これは、両方のリンク上で適度の負荷を示し、5分のウィンドウで平均化されるかもしれません。
Baseline PSAMP measurement of the congested link, as described in Section 11.1, enables measurements that are fine grained in both space and time. The operator has to be able to determine how many bytes/packets are generated for each source/destination address, port number, and prefix, or other attributes, such as protocol number,
セクション11.1で説明したように輻輳リンクのベースラインPSAMP測定は、空間と時間の両方における細粒である測定を可能にします。オペレータは、バイト/パケットが各送信元/宛先アドレス、ポート番号、および接頭辞、またはそのようなプロトコル番号など、他の属性のために生成されたどのように多くの決定することができなければなりません
MPLS forwarding equivalence class (FEC), type of service, etc. This allows the precise determination of the nature of the offending traffic. For example, in the case of a Distributed Denial of Service (DDoS) attack, the operator would see a significant fraction of traffic with an identical destination address.
等MPLS転送等価クラス（FEC）、サービスの種類は、これは問題のトラフィックの性質を正確に決意することを可能にします。例えば、分散型サービス拒否（DDoS攻撃）攻撃の場合には、オペレータは、同一の宛先アドレスのトラフィックのかなりの部分を見るであろう。
In certain circumstances, precise information about the spatial flow of traffic through the network domain is required to detect and diagnose problems and verify correct network behavior. In the case of the overloaded link, it would be very helpful to know the precise set of paths that packets traversing this link follow. This would readily reveal a routing problem such as a loop, or a link with a misconfigured weight. More generally, complex diagnosis scenarios can benefit from measurement of traffic intensities (and other attributes) over a set of paths that is constrained in some way. For example, if a multihomed customer complains about performance problems on one of the access links from a particular source address prefix, the operator should be able to examine in detail the traffic from that source prefix that also traverses the specified access link towards the customer.
特定の状況では、ネットワークドメインを介してトラフィックの空間的な流れについての正確な情報を検出し、問題を診断し、正しいネットワークの動作を検証する必要があります。オーバーロードされたリンクの場合は、このリンクのフォローを通過するパケットの経路の正確なセットを知ることは非常に参考になります。これは、容易にこのようなループ、または誤って設定量を有するリンクとしてルーティングの問題を明らかにする。より一般的には、複雑な診断シナリオは、何らかの方法で拘束されているパスのセットを介してトラフィック強度（及び他の属性）の測定から利益を得ることができます。マルチホーム顧客が特定の送信元アドレスのプレフィックスからのアクセスリンクの1つ上のパフォーマンスの問題を訴えた場合、オペレータは詳細に、顧客への指定されたアクセスリンクを横断そのソースプレフィックスからのトラフィックを調べることができるはずです。
While it is in principle possible to obtain the spatial flow of traffic through auxiliary network state information, e.g., by downloading routing and forwarding tables from routers, this information is often unreliable, outdated, voluminous, and contingent on a network model. For operational purposes, a direct observation of traffic flow provided by trajectory Sampling is more reliable, as it does not depend on any such auxiliary information. For example, if there was a bug in a router's software, direct observation would allow the diagnosis the effect of this bug, while an indirect method would not.
それは補助ネットワーク状態情報を通過するトラフィックの空間的な流れを得ることが原理的に可能であるが、例えば、ルーティングをダウンロードしてルータからテーブルを転送することによって、この情報は、多くの場合、信頼できない時代遅れの、多量、及びネットワークモデルに偶発的です。それはそのような補助情報に依存しないよう運用の目的のために、軌道サンプリングが提供する交通流の直接観察は、より信頼性の高いです。バグがルータのソフトウェアであった場合、間接的な方法はないだろうが、例えば、直接観察は、診断にこのバグの影響を可能にします。
As detailed in Section 4.3, PSAMP shares with IPFIX security requirements for export, namely, confidentiality, integrity, and authenticity of the exported data; see also Sections 6.3 and 10 of [RFC3917]. Since PSAMP will use IPFIX for export, it can employ the IPFIX protocol [RFC5101] to meet its requirements.
4.3節、輸出のためのIPFIXセキュリティ要件、つまり、機密性、完全性、およびエクスポートされたデータの信憑性とPSAMP株式で詳述したように、セクション6.3と[RFC3917]の10をも参照。 PSAMPは輸出用IPFIXを使用しますので、その要件を満たすためにIPFIXプロトコル[RFC5101]を採用することができます。
In distinction with IPFIX, a PSAMP Device may, in some configurations, report some number of initial bytes of the packet, which may include some part of a packet payload. This option is conformant with the requirements of [RFC2804] since it does not
IPFIXと区別して、PSAMPデバイスは、いくつかの構成において、パケットペイロードの一部を含むことができるパケットの最初のバイト、いくつかの数を報告することができます。このオプションは、それがないので、[RFC2804]の要件に準拠しています
mandate configurations that would enable capture of an entire Packet Stream of a Flow: neither a unit Sampling rate (1 in 1 Sampling) nor reporting a specific number of initial bytes is required by the PSAMP protocol.
フロー全体のパケットストリームの捕捉を可能にする構成を強制：単位サンプリング（1サンプリング1）速度もPSAMPプロトコルによって必要とされる最初のバイトの具体的な数を報告もありません。
To preserve privacy of any users acting as sender or receiver of the observed traffic, the contents of the Packet Reports must be able to remain confidential in transit between the exporting PSAMP Device and the Collector. PSAMP will use IPFIX as the exporting protocol, and the IPFIX protocol must provide mechanisms to ensure confidentiality of the Exporting Process, for example, encryption of Export Packets [RFC5101].
観測されたトラフィックの送信者や受信機として動作するすべてのユーザーのプライバシーを保護するために、パケットのレポートの内容は、エクスポートPSAMPデバイスとコレクターの間で輸送中に極秘ことができなければなりません。 PSAMPはエクスポートプロトコルとしてIPFIXを使用し、IPFIXプロトコルは、エクスポートパケット[RFC5101]の暗号化、例えば、エクスポートプロセスの機密性を確保するためのメカニズムを提供しなければなりません。
A concern for Hash-based Selection is whether some large set of related packets could be disproportionately sampled, either
ハッシュベースの選択のための関心は、関連するパケットのいくつかの大規模なセットが偏っいずれかで、サンプリングすることができるかどうかであります
(i) through unanticipated behavior in the hash function, or
（I）ハッシュ関数で予期しない動作を介して、または
(ii) because the packets had been deliberately crafted to have this property.
（ⅱ）のパケットが意図的にこの特性を持つように細工されたため。
As detailed below, only cryptographic hash functions (e.g., one based on MD5) employing a private parameter are sufficiently strong to withstand the range of conceivable attacks. However, implementation considerations may preclude operating the strongest hash functions at line rate. For this reason, PSAMP is not expected to standardize around a cryptographic hash function at the present time. The purpose of this section is to inform discussion of the vulnerabilities and trade-offs associated with different hash function choices. Section 6.2.2 of [RFC5475] does this in more detail.
以下に詳述するように、プライベート・パラメータを使用するだけ暗号ハッシュ関数（MD5に基づいて、例えば、1つ）が考えられる攻撃の範囲に耐えるのに十分に強いです。しかし、実装上の考慮事項は、ラインレートで最強のハッシュ関数を動作させる妨げることがあります。このため、PSAMPは現時点で暗号学的ハッシュ関数を中心に標準化することが期待されていません。このセクションの目的は、異なるハッシュ関数の選択に関連した脆弱性とトレードオフの議論を知らせることです。 [RFC5475]のセクション6.2.2は、より詳細にこれを行います。
An attacker able to predict packet Sampling outcomes could craft a Packet Stream that could evade selection, or another that could overwhelm the measurement infrastructure with all its packets being selected. An attacker may attempt to do this based on knowledge of the hash function. An attacker could employ knowledge of selection outcomes of a known Packet Stream to reverse engineer parameters of the hash function. This knowledge could be gathered, e.g., from billing information, reactions of intrusion detection systems, or observation of a Report Stream.
パケットサンプリング結果を予測することができる攻撃者が選択を回避する可能性がパケットストリームを作ることができ、又はそのすべてのパケットの測定インフラストラクチャを圧倒することができることを別の選択されています。攻撃者は、ハッシュ関数の知識に基づいてこれを実行しようとすることができます。攻撃者は、ハッシュ関数のエンジニアパラメータを逆に知られているパケットストリームの選択結果の知識を利用することができます。この知識は、課金情報、侵入検知システムの反応、またはレポートストリームの観測から、例えば、収集することができます。
Since Hash-based Selection is deterministic, it is vulnerable to replay attacks. Repetition of a single packet may be noticeable to other measurement methods if employed (e.g., collection of Flow statistics), whereas a set of distinct packets that appears statistically similar to regular traffic may be less noticeable. The impact of replay attacks on Hash-based Selection may be mitigated by repeated changing of hash function parameters.
ハッシュベースの選択が決定的であるので、リプレイ攻撃に対して脆弱です。使用される場合、単一のパケットの繰り返しが他の測定方法に顕著であってもよい（例えば、フロー統計情報の収集）、一方、通常のトラフィックに統計的に類似した表示異なるパケットのセットが目立たなくすることができます。ハッシュベースの選択でリプレイ攻撃の影響は、ハッシュ関数のパラメータを繰り返し変更することによって軽減することができます。
Because hash functions for Hash-based Selection are to be standardized and hence public, the packet selection decision must be controlled by some private quantity associated with the Hash-based Selection Selector. Making private the range of hash values for which packets are selected is not alone sufficient to prevent an attacker crafting a stream of distinct packets that are disproportionately selected. A private parameter must be used within the hash function, for example, a private modulus in a hash function, or by concatenating the hash input with a private string prior to hashing.
ハッシュベースの選択のためのハッシュ関数は、標準化され、したがって、公開されることになるので、パケット選択決定は、ハッシュベースの選択セレクタに関連付けられているいくつかの民間の量によって制御されなければなりません。パケットが選択されているハッシュ値のプライベート範囲を作ることのみ偏って選択される別個のパケットの流れを作り上げる攻撃を防止するのに十分ではありません。プライベート・パラメータは、例えば、ハッシュ関数にプライベートモジュラス、またはハッシュの前にプライベート文字列でハッシュ入力を連結することによって、ハッシュ関数内で使用しなければなりません。
The specific choice of hash function and its usage determines the types of potential vulnerability:
ハッシュ関数とその使用方法の特定の選択は、潜在的な脆弱性の種類を決定します。
* Cryptographic hash functions: when a private parameter is used, future selection outcomes cannot be predicted even by an attacker with knowledge of past selection outcomes.
*暗号ハッシュ関数は：プライベート・パラメータを使用した場合、将来の選択の結果は、過去の選択の結果の知識を持つ攻撃者によってさえ予測することはできません。
* Non-cryptographic hash functions:
*非暗号学的ハッシュ関数：
Using knowledge of past selection outcomes: some well-known hash functions, e.g., CRC-32, are vulnerable to attacks, in the sense that their private parameter can be determined with knowledge of sufficiently many past selections, even when a private parameter is used; see [GoRe07].
過去の選択の結果の知識を使用する：いくつかのよく知られているハッシュ関数、例えば、CRC-32は、プライベート・パラメータを使用した場合であっても、彼らのプライベート・パラメータが十分に多くの過去の選択の知識を用いて決定することができるという意味で、攻撃に対して脆弱です; [GoRe07]を参照してください。
No knowledge of past selection outcomes: using a private parameter hardened the hash function to classes of attacks that work when the parameter is public, although vulnerability to future attacks is not precluded.
過去の選択の結果の知識：プライベート・パラメータを使用して、将来の攻撃に対する脆弱性が排除されないが、パラメータは、公開されているときに動作し、攻撃のクラスにハッシュ関数を硬化させません。
Hash function parameters configured in a PSAMP Device are sensitive information, which must be kept private. As well as using probing techniques to discover parameters of non-cryptographic hash functions as described above, implementation and procedural weaknesses may lead to attackers discovering parameters, whatever class of hash function is used. The following measures may prevent this from occurring:
PSAMPデバイスで構成ハッシュ関数パラメータは、プライベートに保たれなければならない機密情報です。同様に、上述のように、非暗号ハッシュ関数のパラメータを発見するためにプロービング技術を使用するなど、実装及び手続き弱点は、ハッシュ関数のクラスを使用しているものは何でも、パラメータを発見攻撃につながる可能性があります。次のような対策がこれを防ぐことがあります。
Hash function parameters must not be displayable in cleartext on PSAMP Devices. This reduces the chance for the parameters to be discovered by unauthorized access to the PSAMP Device.
ハッシュ関数のパラメータは、PSAMPデバイスで平文で表示可能であってはなりません。これは、パラメータがPSAMPデバイスへの不正アクセスによって発見されるための機会を減少させます。
Hash function parameters must not be remotely set in cleartext over a channel that may be eavesdropped.
ハッシュ関数のパラメータは、リモートで盗聴することができるチャネルを介してクリアテキストに設定されてはなりません。
Hash function parameters must be changed regularly. Note that such changes must be synchronized over all PSAMP Devices in a domain under which trajectory Sampling is employed in order to maintain consistent Sampling of packets over the domain.
ハッシュ関数のパラメータは、定期的に変更する必要があります。このような変化は軌道サンプリングがドメイン上でパケットの一貫性のあるサンプリングを維持するために採用されたの下で、ドメイン内のすべてのPSAMPのデバイス上で同期させなければならないことに注意してください。
Default hash function parameter values should be initialized randomly, in order to avoid predictable values that attackers could exploit.
デフォルトのハッシュ関数のパラメータ値は、攻撃者が悪用する可能性があり予測可能な値を避けるために、ランダムに初期化する必要があります。
Sharon Goldberg contributed to Section 12.3 on security considerations for Hash-based Selection.
シャロン・ゴールドバーグは、ハッシュベースの選択のためのセキュリティの考慮事項のセクション12.3に貢献しました。
Sharon Goldberg Department of Electrical Engineering Princeton University F210-K EQuad Princeton, NJ 08544 USA EMail: goldbe@princeton.edu
電気のシャロン・ゴールドバーグ工学科プリンストン大学F210-K EQuadプリンストン、NJ 08544 USA電子メール：goldbe@princeton.edu
The authors would like to thank Peram Marimuthu and Ganesh Sadasivan for their input in early working drafts of this document.
作者はこのドキュメントの初期の草案に彼らの入力をPeram MarimuthuとガネーシュSadasivanに感謝したいと思います。
[RFC5476] Claise. B., Ed., "Packet Sampling (PSAMP) Protocol Specifications", RFC 5476, March 2009.
[RFC5476] Claise。 B.、エド。、 "パケットサンプリング（PSAMP）プロトコル仕様"、RFC 5476、2009年3月。
[RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. Carle, "Information Model for Packet Sampling Exports", RFC 5477, March 2009.
[RFC5477]ディーツ、T.、Claise、B.、エイトケン、P.、ドレスラー、F.、およびG.カール、RFC 5477 "情報モデルパケットサンプリングの輸出について"、2009年3月。
[RFC5101] Claise, B., Ed., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008.
[RFC5101] Claise、B.、エド。、RFC 5101、2008年1月 "IPトラフィックフロー情報を交換するためのIPフロー情報のエクスポート（IPFIX）プロトコルの仕様"。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, January 2008.
[RFC5102] Quittek、J.、ブライアント、S.、Claise、B.、エイトケン、P.、およびJ.マイヤー、 "IPフロー情報のエクスポートのための情報モデル"、RFC 5102、2008年1月。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]スチュワート、R.、エド。、 "ストリーム制御伝送プロトコル"、RFC 4960、2007年9月。
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004.
[RFC3758]スチュワート、R.、Ramalho、M.、謝、Q.、Tuexen、M.、およびP.コンラッド、 "ストリーム制御伝送プロトコル（SCTP）部分的な信頼性拡張"、RFC 3758、2004年5月。
[RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. Raspall, " Sampling and Filtering Techniques for IP Packet Selection", RFC 5475, March 2009.
[RFC5475] Zseby、T.、モリーナ、M.、ダッフィールド、N.、ニッコリーニ、S.、およびF. Raspall、 "IPパケットの選択のためのサンプリングとフィルタリング技術"、RFC 5475、2009年3月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]ベイカー、F.およびP. Savola、 "マルチホームネットワークの入力フィルタリング"、BCP 84、RFC 3704、2004年3月。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]ブレーデン、R.、エド、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1の機能的な仕様"。、RFC 2205、9月1997。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[DuGeGr02] N.G. Duffield, A. Gerber, M. Grossglauser, "Trajectory Engine: A Backend for Trajectory Sampling", IEEE Network Operations and Management Symposium 2002, Florence, Italy, April 15-19, 2002.
【DuGeGr02] N.G.ダッフィールド、A.ガーバー、M. Grossglauser、「軌道エンジン：軌道サンプリングのためのバックエンド」、IEEEネットワークオペレーションとマネジメントシンポジウム2002、フィレンツェ、イタリア、4月15-19、2002。
[DuGr04] N. G. Duffield and M. Grossglauser, "Trajectory Sampling with Unreliable Reporting", Proc IEEE Infocom 2004, Hong Kong, March 2004.
[DuGr04] N. G.ダッフィールドとM. Grossglauser、 "信頼できない報告と軌道サンプリング"、PROC IEEEインフォコム2004年、香港、2004年3月。
[DuGr08] N. G. Duffield and M. Grossglauser, "Trajectory Sampling with Unreliable Reporting", IEEE/ACM Trans. on Networking, 16(1), February 2008.
【DuGr08】N. G.ダフィールドとM. Grossglauser、IEEE / ACMトランス "信頼できない報告と軌道サンプリング"。ネットワーク上の、16（1）、2008年2月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2914]フロイド、S.、 "輻輳制御の原理"、BCP 41、RFC 2914、2000年9月。
[GoRe07] S. Goldberg, J. Rexford, "Security Vulnerabilities and Solutions for Packet Sampling", IEEE Sarnoff Symposium, Princeton, NJ, May 2007.
[GoRe07] S.ゴールドバーグ、J. Rexfordの、 "セキュリティの脆弱性とパケットサンプリングのためのソリューション"、IEEEサーノフシンポジウム、プリンストン、NJ、2007年5月。
[RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May 2000.
[RFC2804] IABとIESG、 "盗聴のIETF方針"、RFC 2804、2000年5月。
[RFC2981] Kavasseri, R., Ed., "Event MIB", RFC 2981, October 2000.
[RFC2981] Kavasseri、R.、エド。、 "イベントMIB"、RFC 2981、2000年10月。
[RFC1213] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets:MIB-II", STD 17, RFC 1213, March 1991.
[RFC1213] McCloghrie、K.とM.ローズ、 "TCP / IPベースのインターネットのネットワーク管理のための管理情報ベース：MIB-II"、STD 17、RFC 1213、1991年3月。
[RFC3176] Phaal, P., Panchen, S., and N. McKee, "InMon Corporation's sFlow: A Method for Monitoring Traffic in Switched and Routed Networks", RFC 3176, September 2001.
[RFC3176] Phaal、P.、パンチェン、S.、およびN.マッキー、 "米国InMon Corp.のsFlowの：スイッチおよびルーティングされたネットワークのトラフィックを監視するための方法"、RFC 3176、2001年9月。
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998.
[RFC2330]パクソン、V.、Almes、G.、Mahdavi、J.、およびM.マティス、 "IPパフォーマンス・メトリックのためのフレームワーク"、RFC 2330、1998年5月。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768]ポステル、J.、 "ユーザ・データグラム・プロトコル"、STD 6、RFC 768、1980年8月。
[RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export (IPFIX)", RFC 3917, October 2004.
[RFC3917] Quittek、J.、Zseby、T.、Claise、B.、およびS.ザンダー、 "IPフロー情報エクスポート（IPFIX）のための要件"、RFC 3917、2004年10月。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y.、エド。、李、T.、エド。、およびS.野兎、編、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 4271、2006年1月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]ローゼン、E.、Viswanathanの、A.、およびR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、RFC 3031、2001年1月。
[RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture for IP Flow Information Export", RFC 5470, March 2009.
[RFC5470] Sadasivan、G.、ブラウンリー、N.、Claise、B.、およびJ. Quittek、RFC 5470、2009年3月 "IPフロー情報のエクスポートのためのアーキテクチャ"。
[RFC2819] Waldbusser, S., "Remote Network Monitoring Management Information Base", STD 59, RFC 2819, May 2000.
[RFC2819] Waldbusser、S.、 "リモートネットワーク監視管理情報ベース"、STD 59、RFC 2819、2000年5月。
[Zs02] T. Zseby, "Deployment of Sampling Methods for SLA Validation with Non-Intrusive Measurements", Proceedings of Passive and Active Measurement Workshop (PAM 2002), Fort Collins, CO, USA, March 25-26, 2002.
[Zs02] T. Zseby、 "非侵入型測定とSLAの検証のためのサンプリング法の展開"、パッシブとアクティブ計測ワークショップ（PAM 2002）、フォートコリンズ、CO、USA 3月25-26日、2002年の議事。
Authors' Addresses
著者のアドレス
Derek Chiou Department of Electrical and Computer Engineering University of Texas at Austin 1 University Station, Stop C0803, ENS Building room 135, Austin TX, 78712 USA
電気のデレクChiou部門とオースティン1大学駅、ストップC0803、ENSビルルーム135、オースティンTX、78712 USAのテキサスコンピュータ工学大学
Phone: +1 512 232 7722 EMail: Derek@ece.utexas.edu
電話：+1 512 232 7722 Eメール：Derek@ece.utexas.edu
Benoit Claise Cisco Systems De Kleetlaan 6a b1 1831 Diegem Belgium
ブノワClaiseシスコシステムズデKleetlaan 6aはB1 1831ディーゲムベルギー
Phone: +32 2 704 5622 EMail: bclaise@cisco.com
電話：+32 2 704 5622 Eメール：bclaise@cisco.com
Nick Duffield, Editor AT&T Labs - Research Room B139 180 Park Ave Florham Park NJ 07932 USA
ニックダッフィールド、エディタAT＆T研究所 - 研究室B139 180パークアベニューフローラムパークNJ 07932 USA
Phone: +1 973-360-8726 EMail: duffield@research.att.com
電話：+1 973-360-8726電子メール：duffield@research.att.com
Albert Greenberg One Microsoft Way Redmond, WA 98052-6399 USA
アルバート・グリーンバーグ1つのマイクロソフト道、レッドモンド、WA 98052-6399 USA
Phone: +1 425-722-8870 EMail: albert@microsoft.com
電話：+1 425-722-8870電子メール：albert@microsoft.com
Matthias Grossglauser School of Computer and Communication Sciences EPFL 1015 Lausanne Switzerland
コンピュータとコミュニケーション科学EPFL 1015ローザンヌスイスのマティアスGrossglauser学校
EMail: matthias.grossglauser@epfl.ch
メールアドレス：matthias.grossglauser@epfl.ch
Jennifer Rexford Department of Computer Science Princeton University 35 Olden Street Princeton, NJ 08540-5233 USA
コンピュータサイエンスのジェニファー・レックスフォード部門プリンストン大学35オルデンストリートプリンストン、NJ 08540から5233 USA
Phone: +1 609-258-5182 EMail: jrex@cs.princeton.edu
電話：+1 609-258-5182電子メール：jrex@cs.princeton.edu