[要約] RFC 5474は、パケットの選択と報告のためのフレームワークを提供するものであり、ネットワーク管理者がトラフィックの特定のパケットを選択し、それに関する情報を報告するためのガイドラインを提供します。目的は、ネットワークのトラフィック分析やトラブルシューティングを支援し、ネットワークのパフォーマンスやセキュリティの向上に役立つことです。
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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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グループの一連のドキュメントの1つです。
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フレームワークを説明しています。このドキュメントの用語の定義と「必須」、「必須」、および「5月」という用語の使用は、情報のみです。
[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プロトコルの非公式の高レベルの説明です（すべての用語は現在定義されます）。パケットのストリームは、観測点で観察されます。選択プロセスは、各パケットを検査して、レポート用に選択されるかどうかを判断します。選択プロセスは、選択した各パケットに関するレポートを作成し、パケットコンテンツを使用して、観測点や到着タイムスタンプでのパケット処理などの他の情報を構築する計測プロセスの一部です。エクスポートプロセスは、パケットレポートをコレクターに送信し、解釈に必要な子会社情報とともに送信します。
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;
（ii）観測点でのパケットの処理から派生した情報。
(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.
複合セレクターは、1つのセレクターから発行される出力パケットストリームが入力パケットストリームを後続のセレクターに形成するセレクターの順序付けられた構成です。
* 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メータープロセスは、IPFIXメータープロセス[RFC5101]に類似していると見なすことができます。これは、PSAMPメータリングプロセスに常に選択プロセスが含まれているという違いがある場合、その出力としてフローレコードを生成します。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.
エクスポートプロセスは、エクスポートパケットの形で、1つ以上のコレクターに1つ以上のメータープロセスの出力を送信します。
* 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.
コレクターは、1つ以上のエクスポートプロセスによってエクスポートされるレポートストリームを受け取ります。場合によっては、計量プロセスおよび/またはエクスポートプロセスのホストもコレクターとして機能する場合があります。
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.
(i) 自己定義：レポートを解釈および分析するために、観測点から追加情報を取得する必要がないという意味で、レポートストリームは完全でなければなりません。
(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.
(i) 機密性：エクスポートされたデータを暗号化するオプションを提供する必要があります。
(ii) integrity: Alterations in transit to exported data must be detectable at the Collector.
（ii）整合性：エクスポートされたデータへの輸送の変更は、コレクターで検出可能でなければなりません。
(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エクスポートのセキュリティと同じです。[RFC3917]のセクション6.3および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は、セレクターを2つのタイプに分類します。
* 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:
* フィルタリング：フィルターは、パケットコンテンツ、またはその処理、または選択状態で発生するこれらの機能に基づいて決定論的にパケットを選択するセレクターです。2つの例は次のとおりです。
(i) Property Match Filtering: A packet is selected if a specific field in the packet equals a predefined value.
(i) プロパティマッチフィルタリング：パケット内の特定のフィールドが事前定義された値に等しい場合、パケットが選択されます。
(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.
(i) サンプリングの決定に到達する際にパケットコンテンツを使用しないコンテンツに依存しないサンプリング。例には、系統的なサンプリング、および生成がパケットコンテンツとは無関係の擬似ランダム数によって駆動される均一な擬似ランダムサンプリングが含まれます。コンテンツに依存しないサンプリングでは、選択の決定を下すためにパケットコンテンツにアクセスする必要はないことに注意してください。
(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選択プロセスは、次のセレクターの少なくとも1つをサポートする必要があります。
* 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-out-of-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.
このフィルタリング方法では、パケット内の特定のフィールドまたはルーター状態のプロパティ上の特定のフィールドが事前定義された値に等しい場合にパケットが選択されます。可能なフィルターフィールドはすべて、[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.
フィルターを連結することで操作が可能であるため、複合選択操作が生成されます。この場合、フィルタリングが発生する順序は暗黙的に定義されます（外側フィルターは内側のフィルターの後に来ます）。ただし、連結がフィルターのみにある限り、カスケードフィルターの結果は順序から独立していますが、最初のフィルターはより高いレートで動作する必要があるため、順序は実装目的で重要かもしれません。いずれにせよ、結果が同じである限り、実装はフィルターの順序を尊重するように制約されておらず、1つのステップで複合フィルタリングを実装することさえできます。
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.
または、この基本モデルでは操作がサポートされていません。より洗練されたフィルター（たとえば、ビットマスク、範囲、または操作をサポートする）は、ベンダー固有のスキームとして実現できます。
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)
(i) IPヘッダー（IPv4のオプションを除く、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
(i) パケットが到着するインターフェースは、指定された値に等しくなります
(ii) Egress interface to which packet is routed to equals a specified value
（ii）パケットが指定された値に等しくなるようにルーティングされる出力インターフェース
(iii) Packet violated Access Control List (ACL) on the router
（iii）ルーター上のパケット違反アクセス制御リスト（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）Origin Border Gateway Protocol（BGP）自律システム（AS）[RFC4271]は、特定の範囲内に指定された値に等しいか、
(viii) Destination BGP AS equals a specified value or lies within a given range
（viii）宛先BGPは指定された値に等しいか、特定の範囲内にあります
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.
構成/達成された選択分数の概念は、セレクターを超えて拡張されます。実例の例は、輸出プロセスを使用した計量プロセスの構成の構成された選択分数です。ここでは、母集団は観察されたパケットストリームまたはそのサブセットです。構成された選択分数は、パケットレポートがコレクターに届くと予想される母集団の割合です。この数量は、コレクターに向かう途中でパケットレポートが被った損失の程度を決定する追加のパラメーターを、必ずしもエクスポートプロセスで利用可能な送信帯域幅を決定する追加のパラメーターを反映している可能性があります。この例では、達成された選択分数は、レポートが実際にコレクターに到達した母集団パケットの割合であり、したがって、たとえば、観測点でのリソースの競合または伝送中のパケットレポートの損失の影響を組み込んでいます。
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.)
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.
* プロパティマッチフィルターの連結。これは、コンポーネントフィルターの構築に役立ちます。
* 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.
複合セレクターは、ドリルダウンアプリケーションに役立ちます。複合セレクターの最初のコンポーネントを使用して、2番目のコンポーネントの負荷を減らすことができます。この設定では、特定の注文から得られる利点は、パケットストリームの構成に依存する可能性があります。
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.
(i) レポートを作成した計量プロセスのインスタンスでパケットに作用したセレクターの入力シーケンス番号。
(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.
（iii）パケットに関する基本レポート、つまり、パケットヘッダー（ネットワークレイヤーとカプセル化ヘッダーを含む）およびその後のパケットペイロードのバイトを含む、パケットの開始からのいくつかの連続バイト。
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.
（iv）パケットで使用される次のプロトコルに関連するフィールド：IPv4、IPv6、輸送プロトコル、および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.
- 観測点でのパケットの観測のタイムスタンプ。タイムスタンプは、マイクロ秒解像度に報告する必要があります。
- 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;
(i) 報告されたパケットのセレクターの構成パラメーター。
(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:
エクスポートパケットには、1つ以上のパケットレポートが含まれている場合があります。また、解釈をレポートします。エクスポートパケットにも含める必要があります。
(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の適時性と混雑回避要件を共同で満たすために、輻輳を意識した信頼性のない輸送プロトコルを使用することができます。IPFIXは、ストリーム制御伝送プロトコル（SCTP）[RFC4960]およびSCTP部分信頼性拡張[RFC3758]のサポートを義務付けているため、この要件と互換性があります。
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.
(i) ネットワークの輻輳がなくても、特に多くのエクスポートプロセスが共通のコレクターに供給される場合、パケット選択の速度はレポートを処理する容量を超える可能性があります。エクスポートレート制限を使用すると、コレクターへのグローバル入力レートを制御できます。
(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ヘッダーフィールド（ポート番号、TCPシーケンス番号）は、パケットの最初の40バイトから描かれています。かなりのばらつき。[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）は、論理のO（log（m））段階を取ります。ここで、mは比較に関与するビットの数です。結果を1ビットに蓄積するには、ログ（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つのオペランドで最も重要な非同等のビットの決定である。1つになるように設定された最も重要ではないビットを備えたオペランドは、他のものよりも大きくなります。
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（log（m））段階の操作でもあります。算術操作の最適化された実装は、キャリービットの伝播によるO（log（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（log（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操作のセットであり、中間結果が次のデータの塊で保存され、Xoredが保存されます。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（log（m））です。MD5は、入力処理された16バイトあたり256 32ビット追加操作を指定します。100 MHzで10 GB/秒を処理することを検討してください（この処理速度は現在利用可能であると思われます）。これには、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.
最初に、時間的および空間的な粒度のさまざまなレベルでトラフィック測定を必要とするいくつかの代表的な運用アプリケーションについて説明します。ここでの目標のいくつかは、少なくともサポートされている幅広いアプリケーションの目標と同様に見えます。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).
パケットサンプリングは、ネットワーク全体のトラフィックの構成を決定するのに理想的です。アプローチは、ネットワークリンクのカットセットで測定を有効にすることで、ネットワークに入る各パケットが少なくとも一度は、たとえばすべてのイングレスリンクで見られます。比較的低い選択画分を備えたフィルタリングされていないサンプリングは、ネットワークトラフィックのベースライン測定を確立します。パケットレポートには、共通の関心のあるパケット属性が含まれます。ソースおよび宛先アドレスとポート番号、プレフィックス、プロトコル番号、サービスの種類などが含まれます。トラフィックマトリックスは、ソースと宛先をマトリックスとして報告することによって示されます。絶対トラフィック量は、設定された選択画分または達成された選択分数（レポートストリームに含まれる入力パケットカウンターから派生した）のいずれかによって、分割を通じてサンプリングされたトラフィック量を繰り返します。
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].
パケットが続く軌跡に続くパケットは、コレクターに届くパケットレポートから再構築されます。特定のパケットのレポートは、不変の報告されたパケットコンテンツを含むラベルまたはおそらくその消化率のいずれかを一致させることによって関連付けられます。ラベルの衝突（異なるパケットによって報告された同一のラベル）および伝送における報告の潜在的な損失による可能性のある曖昧さを扱うための軌跡と方法の再構築は、[DUGR01]、[DugeGr02]、および[DUGR04]で対処されます。
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 MIBS（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, 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.
セクション11.1で説明されているように、混雑したリンクのベースラインPSAMP測定では、空間と時間の両方で細かい粒子の測定が可能になります。オペレーターは、各ソース/宛先アドレス、ポート番号、プレフィックス、またはプロトコル番号、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で詳述されているように、PSAMPは、エクスポートのためのIPFIXセキュリティ要件と共有します。[RFC3917]のセクション6.3および10も参照してください。PSAMPはExportに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 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.
IPFIXと区別すると、PSAMPデバイスは、一部の構成では、パケットの一部のパケットペイロードの一部が含まれる場合があるパケットのいくつかの初期バイトを報告する場合があります。このオプションは[RFC2804]の要件に適合しています。これは、フローのパケットストリーム全体をキャプチャできる構成を義務付けていないためです。単位サンプリングレート（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.
（ii）パケットがこのプロパティを持つように意図的に作成されていたためです。
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に基づくものなど）のみが、考えられる攻撃の範囲に耐えるのに十分な強さです。ただし、実装の考慮事項により、最強のハッシュ関数をラインレートで動作させる可能性があります。このため、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デバイスのClearTextで表示してはなりません。これにより、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.
Sharon Goldbergは、ハッシュベースの選択のセキュリティに関する考慮事項について、セクション12.3に貢献しました。
Sharon Goldberg Department of Electrical Engineering Princeton University F210-K EQuad Princeton, NJ 08544 USA EMail: goldbe@princeton.edu
シャロンゴールドバーグ電気工学部プリンストン大学F210-Kエクアドプリンストン、ニュージャージー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とGanesh Sadasivanに、この文書の早期作業ドラフトでの入力について感謝したいと思います。
[RFC5476] Claise. B., Ed., "Packet Sampling (PSAMP) Protocol Specifications", RFC 5476, March 2009.
[RFC5476]句。B.、ed。、「パケットサンプリング（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] Dietz、T.、Claise、B.、Aitken、P.、Dressler、F.、およびG. Carle、「パケットサンプリングエクスポートの情報モデル」、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.、ed。、「IPトラフィックフロー情報の交換のためのIPフロー情報エクスポート（IPFIX）プロトコルの仕様」、RFC 5101、2008年1月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791] Postel、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.、Bryant、S.、Claise、B.、Aitken、P。、およびJ. Meyer、「IPフロー情報エクスポートの情報モデル」、RFC 5102、2008年1月。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R.、ed。、「Stream Control Transmission Protocol」、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] Stewart、R.、Ramalho、M.、Xie、Q.、Tuexen、M。、およびP. Conrad、「ストリーム制御伝送プロトコル（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.、Molina、M.、Duffield、N.、Niccolini、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] Baker、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] Braden、R.、Ed。、Zhang、L.、Berson、S.、Herzog、S.、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、9月1997年。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、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.Duffield、A。Gerber、M。Grossglauser、「軌跡エンジン：軌道サンプリングのためのバックエンド」、IEEEネットワーク運用および管理シンポジウム2002、フィレンツェ、イタリア、2002年4月15〜19日。
[DuGr04] N. G. Duffield and M. Grossglauser, "Trajectory Sampling with Unreliable Reporting", Proc IEEE Infocom 2004, Hong Kong, March 2004.
[Dugr04] N. G. DuffieldおよびM. Grossglauser、「信頼性の低い報告による軌跡サンプリング」、Proc Ieee Infocom 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. DuffieldおよびM. Grossglauser、「信頼性の低いレポートによる軌跡サンプリング」、IEEE/ACM Trans。ネットワーキング、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. Goldberg、J。Rexford、「パケットサンプリングのセキュリティの脆弱性とソリューション」、IEEE Sarnoff Symposium、プリンストン、ニュージャージー州、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.、ed。、「Event 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. Rose、「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.、Panchen、S。、およびN. McKee、「Inmon CorporationのSflow：Switched and Routed Networksのトラフィックを監視する方法」、RFC 3176、2001年9月。
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998.
[RFC2330] Paxson、V.、Almes、G.、Mahdavi、J。、およびM. Mathis、「IPパフォーマンスメトリックのフレームワーク」、RFC 2330、1998年5月。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768] Postel、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. Zander、「IP Flow Information Export（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.、Ed。、Li、T.、ed。、およびS. Hares、ed。、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、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.、Brownlee、N.、Claise、B。、およびJ. Quittek、「IPフロー情報エクスポートのアーキテクチャ」、RFC 5470、2009年3月。
[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）、フォートコリンズ、米国、米国、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
テキサス州電気およびコンピューター工学部のデレク・チオウオースティン1ユニバーシティステーション、STOP C0803、ENSビルディングルーム135、オースティンテキサス州78712 USA
Phone: +1 512 232 7722
EMail: Derek@ece.utexas.edu
Benoit Claise Cisco Systems De Kleetlaan 6a b1 1831 Diegem Belgium
Benoit Claise Cisco Systems de Kleetlaan 6a B1 1831 Diegem Belgium
Phone: +32 2 704 5622
EMail: bclaise@cisco.com
Nick Duffield, Editor AT&T Labs - Research Room B139 180 Park Ave Florham Park NJ 07932 USA
Nick Duffield、編集者AT＆Tラボ - リサーチルームB139 180パークアベニューフローハムパークNJ 07932 USA
Phone: +1 973-360-8726
EMail: duffield@research.att.com
Albert Greenberg One Microsoft Way Redmond, WA 98052-6399 USA
アルバート・グリーンバーグ・ワン・マイクロソフト・ウェイ・レドモンド、ワシントン州98052-6399 USA
Phone: +1 425-722-8870 EMail: albert@microsoft.com Matthias Grossglauser School of Computer and Communication Sciences EPFL 1015 Lausanne Switzerland
電話：1 425-722-8870メール：albert@microsoft.com Matthias Grossglauser School of Computer and Communication Sciences EPFL 1015 Lausanne Switzerland
EMail: matthias.grossglauser@epfl.ch
Jennifer Rexford Department of Computer Science Princeton University 35 Olden Street Princeton, NJ 08540-5233 USA
ジェニファー・レックスフォードコンピュータサイエンスの部門プリンストン大学35オールドレンストリートプリンストン、ニュージャージー08540-5233 USA
Phone: +1 609-258-5182
EMail: jrex@cs.princeton.edu