Network Working Group E. Boschi
Request for Comments: 5473 Hitachi Europe
Category: Informational L. Mark
Fraunhofer IFAM
B. Claise
Cisco Systems, Inc.
March 2009
Reducing Redundancy in IP Flow Information Export (IPFIX)
and Packet Sampling (PSAMP) Reports
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Abstract
抽象
This document describes a bandwidth saving method for exporting Flow or packet information using the IP Flow Information eXport (IPFIX) protocol. As the Packet Sampling (PSAMP) protocol is based on IPFIX, these considerations are valid for PSAMP exports as well.
この文書では、IPフロー情報のエクスポート（IPFIX）プロトコルを使用してフローまたはパケット情報をエクスポートするための帯域幅の節約方法を説明します。パケットサンプリング（PSAMP）プロトコルはIPFIXに基づいているように、これらの考察は、同様PSAMPエクスポートのために有効です。
This method works by separating information common to several Flow Records from information specific to an individual Flow Record. Common Flow information is exported only once in a Data Record defined by an Options Template, while the rest of the specific Flow information is associated with the common information via a unique identifier.
この方法は、個々のフローレコードに固有の情報から、いくつかのフローレコードに共通の情報を分離することによって動作します。具体的なフロー情報の残りの部分は、一意の識別子を介して共通の情報と関連付けられている間に共通流情報は、オプションテンプレートで定義されたデータレコードに一度だけエクスポートされます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. IPFIX Documents Overview ...................................3
1.2. PSAMP Documents Overview ...................................4
2. Terminology .....................................................4
2.1. Terminology Summary Table ..................................5
2.2. IPFIX Flows versus PSAMP Packets ...........................5
3. Specifications for Bandwidth-Saving Information Export ..........5
3.1. Problem Statement and High-Level Solution ..................6
3.2. Data Reduction Technique ...................................7
4. Transport Protocol Choice .......................................8
4.1. PR-SCTP ....................................................9
4.2. UDP ........................................................9
4.3. TCP ........................................................9
5. commonPropertiesID Management ...................................9
6. The Collecting Process Side ....................................10
6.1. UDP .......................................................11
6.2. TCP .......................................................12
7. Advanced Techniques ............................................12
7.1. Multiple Data Reduction ...................................12
7.2. Cascading Common Properties ...............................15
8. Export and Evaluation Considerations ...........................15
8.1. Transport Protocol Choice .................................16
8.2. Reduced Size Encoding .....................................16
8.3. Efficiency Gain ...........................................16
9. Security Considerations ........................................17
10. Acknowledgments ...............................................17
11. References ....................................................17
11.1. Normative References .....................................17
11.2. Informative References ...................................18
Appendix A. Examples ..............................................19
A.1. Per-Flow Data Reduction ...................................19
A.2. Per-Packet Data Reduction .................................23
A.3. Common Properties Withdrawal Message ......................26
The IPFIX working group has specified a protocol to export IP Flow information [RFC5101]. This protocol is designed to export information about IP traffic Flows and related measurement data, where a Flow is defined by a set of key attributes (e.g., source and destination IP address, source and destination port, etc.). However, thanks to its template mechanism, the IPFIX protocol can export any type of information, as long as the Information Element is specified in the IPFIX information model [RFC5101] or registered with IANA.
IPFIXワーキンググループは、IPフロー情報[RFC5101]をエクスポートするプロトコルを指定しています。このプロトコルは、フローはキー属性（例えば、送信元および宛先IPアドレス、送信元および宛先ポート、など）のセットによって定義されたIPトラフィックフローと関連する測定データに関する情報をエクスポートするように設計されています。しかし、そのテンプレート機構のおかげで、IPFIXプロトコルは、情報要素はIPFIX情報モデル[RFC5101]で指定又はIANAに登録されている限り、任意のタイプの情報をエクスポートすることができます。
Regardless of the fields' contents, Flow Records with common properties export the same fields in every single Data Record. These common properties may represent values common to a collection of Flows or packets, or values that are invariant over time. Note that the common properties don't represent the list of Flow Keys, which are used to define a Flow definition; however, the common properties may contain some of the Flow Keys. The reduction of redundant data from the export stream can result in a significant reduction of the transferred data.
かかわらず、フィールドの内容の、共通のプロパティを持つフローレコードは、すべての単一のデータレコードの同じフィールドをエクスポートします。これらの共通の特性は、経時的に不変であるフローまたはパケットの集合に共通の値、または値を表すことができます。共通のプロパティは、フロー定義を定義するために使用されているフローキーのリストを表していないことに注意してください。しかし、一般的な性質は、フローキーの一部が含まれていてもよいです。エクスポート・ストリームから冗長データの削減は、転送されたデータの有意な減少をもたらすことができます。
This document specifies a way to export these invariant or common properties only once, while the rest of the Flow-specific properties are exported in regular Data Records. Unique common properties identifiers are used to link Data Records and the common attributes.
この文書では、フロー固有のプロパティの残りの部分は、通常のデータレコードに輸出されている間、一度だけこれらの不変または共通のプロパティをエクスポートする方法を指定します。ユニークな共通のプロパティ識別子は、データレコードと共通の属性をリンクするために使用されています。
The proposed method is applicable to IPFIX Flow and to PSAMP per-packet information, without any changes to both the IPFIX and PSAMP protocol specifications.
提案された方法は、IPFIXとPSAMPプロトコル仕様の両方を変更することなく、IPFIXフローへとPSAMPパケットごとの情報にも適用可能です。
The IPFIX protocol [RFC5101] provides network administrators with access to IP Flow information. The architecture for the export of measured IP Flow information out of an IPFIX exporting process to a collecting process is defined in the IPFIX Architecture [RFC5470], per the requirements defined in RFC 3917 [RFC3917]. The IPFIX Architecture [RFC5470] specifies how IPFIX Data Records and templates are carried via a congestion-aware transport protocol from IPFIX exporting processes to IPFIX collecting processes. IPFIX has a formal description of IPFIX Information Elements, their names, types, and additional semantic information, as specified in the IPFIX information model [RFC5102]. Finally, the IPFIX applicability statement [RFC5472] describes what type of applications can use the IPFIX protocol and how they can use the information provided. It furthermore shows how the IPFIX framework relates to other architectures and frameworks.
IPFIXプロトコル[RFC5101]はIPフロー情報へのアクセスをネットワーク管理者に提供します。回収プロセスにIPFIXエクスポートプロセスのうち、測定IPフロー情報のエクスポートのためのアーキテクチャは、RFC 3917で定義された要件に従ってIPFIXアーキテクチャ[RFC5470]、[RFC3917]で定義されています。 IPFIXアーキテクチャ[RFC5470]はどのようにIPFIXデータレコードとテンプレートがIPFIX収集プロセスにIPFIXのエクスポートプロセスから渋滞を意識したトランスポートプロトコルを介して運ばれる指定します。 IPFIX情報モデル[RFC5102]で指定されているようIPFIXは、IPFIXの情報エレメント、自分の名前、種類、および追加の意味情報の形式的な記述があります。最後に、IPFIXの適用性声明[RFC5472]はIPFIXプロトコルを使用できるアプリケーションの種類と、彼らが提供された情報を使用する方法について説明します。それはさらに、IPFIXフレームワークは、他のアーキテクチャおよびフレームワークの関係を示します。
The document "A Framework for Packet Selection and Reporting" [RFC5474] 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. The set of packet selection techniques (sampling, filtering, and hashing) supported by PSAMP is described in "Sampling and Filtering Techniques for IP Packet Selection" [RFC5475]. The PSAMP protocol [RFC5476] specifies the export of packet information from a PSAMP exporting process to a PSAMP collecting process. Like IPFIX, PSAMP has a formal description of its Information Elements, their names, types, and additional semantic information. The PSAMP information model is defined in [RFC5477]. Finally, [PSAMP-MIB] describes the PSAMP Management Information Base.
文書「パケット選択のためのフレームワークと報告」[RFC5474]は、統計的及び他の方法でパケットのサブセットを選択するために、コレクタに選択されたパケットの報告のストリームをエクスポートするネットワーク要素のPSAMPフレームワークを記述する。 PSAMPによってサポートされるパケットの選択技術（サンプリング、フィルタリング、およびハッシュ）のセットは、「IPパケットの選択のためのサンプリングとフィルタリング技術」[RFC5475]に記載されています。 PSAMPプロトコル[RFC5476]は収集処理PSAMPに処理をエクスポートPSAMPからパケット情報のエクスポートを指定します。 IPFIXのように、PSAMPは、その情報要素、それらの名前、種類、および追加の意味情報の形式的な記述があります。 PSAMP情報モデルは、[RFC5477]で定義されています。最後に、[PSAMP-MIB]はPSAMP管理情報ベースについて説明します。
IPFIX-specific terminology used in this document is defined in Section 2 of the IPFIX protocol specification [RFC5101] and Section 3 of the PSAMP protocol specification [RFC5476]. As in [RFC5101] and [RFC5476], these IPFIX-specific terms have the first letter of a word capitalized when used in this document.
この文書で使用IPFIX固有の用語は、IPFIXプロトコル仕様[RFC5101]のセクション2とPSAMPプロトコル仕様[RFC5476]のセクション3で定義されています。 [RFC5101]及び[RFC5476]のように、これらIPFIX固有の用語は、本文書で使用される場合、単語の最初の文字が大文字有します。
In addition, the following new terms are defined in this document:
また、次の新しい用語がこの文書で定義されています。
commonPropertiesID: The commonPropertiesID is an identifier of a set of common properties that is locally unique per Observation Domain and Transport Session. Typically, this Information Element is used to link to information reported in separate Data Records. See the IPFIX information model [RFC5102] for the Information Element definition.
commonPropertiesID：commonPropertiesIDは観測ドメインと交通セッションごとにローカルで一意である一般的なプロパティのセットの識別子です。通常、この情報要素は、個別のデータレコードで報告された情報へのリンクに使用されます。情報要素の定義についてはIPFIX情報モデル[RFC5102]を参照してください。
Common Properties: Common Properties are a collection of one or more attributes shared by a set of different Flow Records. Each set of Common Properties is uniquely identifiable by means of a commonPropertiesID.
共通プロパティ：共通プロパティは、異なるフローレコードのセットによって共有される1つの以上の属性のコレクションです。共通プロパティの各セットはcommonPropertiesIDの手段によって一意に識別可能です。
Specific Properties: Specific Properties are a collection of one or more attributes reported in a Flow Record that are not included in the Common Properties defined for that Flow Record.
特定のプロパティ：特定のプロパティは、そのフローレコード用に定義された共通プロパティには含まれていないフローレコードで報告された1つ以上の属性のコレクションです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
+------------------+---------------------------------------------+
| | Contents |
| +--------------------+------------------------+
| Set | Template | Record |
+------------------+--------------------+------------------------+
| Data Set | / | Data Record(s) |
+------------------+--------------------+------------------------+
| Template Set | Template Record(s) | / |
+------------------+--------------------+------------------------+
| Options Template | Options Template | / |
| Set | Record(s) | |
+------------------+--------------------+------------------------+
Terminology Summary Table
用語の概要表
A Data Set is composed of Data Record(s). No Template Record is included. A Template Record or an Options Template Record defines the Data Record.
データセットは、データレコード（複数可）で構成されています。何テンプレートレコードは含まれません。テンプレートレコードまたはオプションテンプレートレコードは、データレコードを定義します。
A Template Set contains only Template Record(s).
テンプレートセットはテンプレートレコード（複数可）が含まれています。
An Options Template Set contains only Options Template Record(s).
オプションテンプレートセットのみのオプションテンプレートレコード（複数可）が含まれています。
As described in the PSAMP protocol specification [RFC5476], the major difference between IPFIX and PSAMP is that the IPFIX protocol exports Flow Records while the PSAMP protocol exports Packet Records. From a pure export point of view, IPFIX will not distinguish a Flow Record composed of several packets aggregated together from a Flow Record composed of a single packet. So, the PSAMP export can be seen as a special IPFIX Flow Record containing information about a single packet.
PSAMPプロトコル仕様[RFC5476]に記載されているように、IPFIXとPSAMPの主な違いは、IPFIXプロトコルはPSAMPプロトコル輸出パケットレコードながら、フローレコードをエクスポートすることです。ビューの純粋な輸出の観点から、IPFIXは、単一のパケットで構成されるフローレコードから一緒に集約複数のパケットから構成されるフローレコードを区別しません。だから、PSAMPの輸出は、単一のパケットについての情報を含む特別なIPFIXフローレコードとして見ることができます。
For this document's clarity, the term Flow Record represents a generic term expressing an IPFIX Flow Record or a PSAMP Packet Record, as foreseen by its definition. However, when appropriate, a clear distinction between Flow Record or Packet Record will be made.
このドキュメントの明確化のために、用語フローレコードは、その定義によって予見として、IPFIXフローレコードまたはPSAMPパケットのレコードを表す一般的な用語を表します。しかしながら、適切な場合、フローレコード又はパケットレコードとの間の明確な区別がなされます。
Several Flow Records often share a set of Common Properties. Repeating the information about these Common Properties for every Flow Record introduces a huge amount of redundancy. This document proposes a method to reduce this redundancy.
いくつかのフローレコードは、多くの場合、共通プロパティのセットを共有します。すべてのフローレコードのためにこれらの共通プロパティに関する情報を繰り返すこと、冗長性の膨大な量を導入しています。この文書では、この冗長性を低減するための方法を提案しています。
The PSAMP specifications are used for the export of per-packet information, exporting the specific observed packet in an IPFIX Flow Record. This can be considered as a special Flow Record case, composed of a single packet. Therefore, the method described in this document is also applicable to per-packet data reduction, e.g., for export of One-Way Delay (OWD) measurements (see Appendix), trajectory sampling, etc.
PSAMP仕様はIPFIXフローレコード内の特定の観測されたパケットを輸出し、パケットごとの情報のエクスポートに使用されています。これは、単一のパケットで構成され、特殊なフローレコードケースとして考えることができます。したがって、本文書に記載された方法等一方向遅延（OWD）測定値（付録を参照）、軌道サンプリングの輸出のために、また、例えばパケット単位のデータの削減にも適用可能です
Consider a set of properties "A", e.g., common sourceAddressA and sourcePortA, equivalent for each Flow Record exported. Figure 1 shows how this information is repeated with classical IPFIX Flow Records, expressing the waste of bandwidth to export redundant information.
各フローレコードをエクスポートするための同等の「A」プロパティのセット、例えば、共通sourceAddressAとsourcePortAを考えます。図1は、この情報が冗長な情報をエクスポートするために、帯域幅の浪費を表現する、古典IPFIXフローレコードで繰り返される方法を示しています。
+----------------+-------------+---------------------------+
| sourceAddressA | sourcePortA | <Flow1 information> |
+----------------+-------------+---------------------------+
| sourceAddressA | sourcePortA | <Flow2 information> |
+----------------+-------------+---------------------------+
| sourceAddressA | sourcePortA | <Flow3 information> |
+----------------+-------------+---------------------------+
| sourceAddressA | sourcePortA | <Flow4 information> |
+----------------+-------------+---------------------------+
| ... | ... | ... |
+----------------+-------------+---------------------------+
Figure 1: Common and Specific Properties Exported Together
図1：一般的なおよび特定のプロパティをまとめてエクスポート
Figure 2 shows how this information is exported when applying the specifications of this document. The Common Properties are separated from the Specific Properties for each Flow Record. The Common Properties would be exported only once in a specific Data Record (defined by an Options Template), while each Flow Record contains a pointer to the Common Properties A, along with its Flow-specific information. In order to maintain the relationship between these sets of properties, we introduce indices (in this case, the index for properties A) for the Common Properties that are unique for all Common Properties entries within an Observation Domain. The purpose of the indices is to serve as a "key" identifying "rows" of the Common Properties table. The rows are then referenced by the Specific Properties by using the appropriate value for the Common Properties identifier.
図2は、この文書の仕様を適用するときにこの情報をエクスポートする方法を示しています。共通プロパティは、各フローレコードのための特定のプロパティから分離されています。各フローレコードは、そのフロー固有情報とともに、共通プロパティAを指すポインタを保持しながら、一般的な特性は、（オプションテンプレートによって定義された）特定のデータレコードに一度だけエクスポートされることになります。プロパティのこれらのセットの間の関係を維持するために、我々はインデックスを紹介する（この場合には、プロパティAのインデックス）観測ドメイン内のすべての共通プロパティのエントリのためのユニークで共通プロパティのために。指標の目的は、共通プロパティテーブルの「行」を特定する「キー」として機能することです。行は、共通プロパティ識別子のために適切な値を使用して、特定のプロパティによって参照されます。
+------------------------+-----------------+-------------+
| index for properties A | sourceAddressA | sourcePortA |
+------------------------+-----------------+-------------+
| ... | ... | ... |
+------------------------+-----------------+-------------+
+------------------------+---------------------------+
| index for properties A | <Flow1 information> |
+------------------------+---------------------------+
| index for properties A | <Flow2 information> |
+------------------------+---------------------------+
| index for properties A | <Flow3 information> |
+------------------------+---------------------------+
| index for properties A | <Flow4 information> |
+------------------------+---------------------------+
Figure 2: Common and Specific Properties Exported Separately
図2：別にエクスポートコモン、特定のプロパティ
This unique export of the Common Properties results in a decrease of the bandwidth requirements for the path between the Exporter and the Collector.
共通プロパティのこのユニークな輸出は、輸出業者とコレクタ間のパスの帯域幅の要件の減少をもたらします。
The IPFIX protocol [RFC5101] is Template based. Templates define how data should be exported, describing data fields together with their type and meaning. IPFIX specifies two types of Templates: the Template Record and the Options Template Record. The difference between the two is that the Options Template Record includes the notion of scope, defining how to scope the applicability of the Data Record. The scope, which is only available in the Options Template Record, gives the context of the reported Information Elements in the Data Records. The Template Records and Options Template Records are necessary to decode the Data Records. Indeed, by only looking at the Data Records themselves, it is impossible to distinguish a Data Record defined by Template Record from a Data Record defined by an Options Template Record. To export information more efficiently, this specification proposes to group Flow Records by their common properties. We define Common Properties as a collection of attributes shared by a set of different Flow Records.
IPFIXプロトコル[RFC5101]はテンプレートベースです。テンプレートは、その種類と意味とともに、データフィールドを記述し、データをエクスポートする方法を定義します。テンプレートレコードとオプションテンプレートレコード：IPFIXはテンプレートの2種類を指定します。 2つの違いは、オプションテンプレートレコードがどのスコープにデータレコードの適用性を定義する、スコープの概念が含まれていることです。オプションテンプレートレコードでのみ使用可能範囲は、データレコードで報告された情報要素のコンテキストを提供します。テンプレートレコードとオプションテンプレートレコードは、データレコードをデコードするために必要です。確かに、唯一のデータレコードで自分自身を見ることによって、オプションテンプレートレコードで定義されたデータレコードからテンプレートレコードで定義されたデータレコードを区別することは不可能です。より効率的に情報をエクスポートするには、この仕様は、彼らの共通のプロパティによってグループフローレコードに提案しています。私たちは、さまざまなフローレコードのセットが共有する属性のコレクションとしての共通プロパティを定義します。
An implementation using the proposed specification MUST follow the IPFIX transport protocol specifications defined in the IPFIX protocol [RFC5101].
提案された仕様を使用して実装では、IPFIXプロトコル[RFC5101]で定義されたIPFIXトランスポートプロトコル仕様に従わなければなりません。
As explained in Figure 3, the information is split into two parts, using two different Data Records. Common Properties MUST be exported via Data Records defined by an Options Template Record. Like Template Records, they MUST be sent only once per SCTP association or TCP connection, and MUST be sent reliably via SCTP if SCTP is the transport protocol. These properties represent values common to several Flow Records (e.g., IP source and destination address). The Common Properties Data Records MUST be sent prior to the corresponding Specific Properties Data Records. The Data Records reporting Specific Properties MUST be associated with the Data Records reporting the Common Properties using a unique identifier for the Common Properties, the commonPropertiesID Information Element [RFC5102]. The commonPropertiesID Information Element MUST be included in the scope of the Options Template Record, and also included in the associated Template Record.
図3で説明したように、情報は、2つの異なるデータレコードを使用して、2つの部分に分割されます。共通プロパティはオプションテンプレートレコードで定義されたデータレコードを経由してエクスポートする必要があります。テンプレートレコードのように、彼らは一度だけSCTPアソシエーションまたはTCP接続ごとに送らなければなりませんし、SCTPがトランスポートプロトコルである場合SCTP経由で確実に送らなければなりません。これらの特性は、いくつかのフローレコード（例えば、IPソースおよび宛先アドレス）に共通の値を表します。共通プロパティデータレコードは、前に対応する特定のプロパティデータレコードに送らなければなりません。特定のプロパティを報告するデータレコードは、データレコードは、共通プロパティ、commonPropertiesID情報エレメント[RFC5102]の一意の識別子を使用して共通プロパティをレポートに関連付ける必要があります。 commonPropertiesID情報要素はオプションテンプレートレコードの範囲に含まれ、また、関連するテンプレートレコードに含まれなければなりません。
+---------------------------+ +---------------------+
| Common Properties | | Specific Properties | Template
| Options Template Record | | Template Record | Definition
| | | |
| scope: commonPropertiesID | | commonPropertiesID |
| Common Properties | | Specific Properties |
+------------+--------------+ +----------+----------+
.............|...............................|.......................
| |
+------------v-------------+ +----------v----------+
| Common Properties | | Specific Properties |+ Exported
| Data Record |------> Data Records || Data
+--------------------------+ +---------------------+| Records
+---------------------+
Figure 3: Template Record and Data Record Dependencies
図3：テンプレートレコードとデータレコードの依存関係
From the IPFIX protocol, there are no differences between the per-Flow or per-packet data reduction, except maybe the terminology where the Specific Properties could be called packet Specific Properties in the previous figure.
IPFIXプロトコルから、フロー単位またはパケットデータ削減の間には違いは固有のプロパティが前の図に、パケット固有のプロパティと呼ばれることができ、多分専門用語を除いて、存在しません。
This document follows the IPFIX transport protocol specifications defined in the IPFIX protocol [RFC5101]. However, depending on the transport protocol choice, this document imposes some additional constraints. If Partial Reliable Stream Control Transmission Protocol (PR-SCTP) [RFC3758] is selected as the IPFIX protocol, the following PR-SCTP subsection specifications MUST be respected. If UDP is selected as the IPFIX protocol, the following UDP subsection specifications MUST be respected. If TCP is selected as the IPFIX protocol, the following TCP subsection specifications MUST be respected.
この文書では、IPFIXプロトコル[RFC5101]で定義されたIPFIXトランスポートプロトコル仕様に従います。しかし、トランスポートプロトコルの選択に応じて、この文書は、いくつかの追加の制約を課します。部分的な信頼性の高いストリーム制御伝送プロトコル（PR-SCTP）[RFC3758]はIPFIXプロトコルとして選択された場合、次のPR-SCTPサブセクション仕様は、尊重されなければなりません。 UDPは、IPFIXプロトコルとして選択されている場合は、以下のサブセクションUDPの仕様が尊重されなければなりません。 TCPは、IPFIXプロトコルとして選択されている場合は、以下のTCPのサブセクションの仕様は、尊重されなければなりません。
The active Common Properties MUST be sent after the SCTP association establishment and before the corresponding Specific Properties Data Records. In the case of SCTP association re-establishment, all active Common Properties MUST be resent before the corresponding Specific Properties Data Records.
アクティブな共通プロパティは、SCTPアソシエーションの確立後に、対応する特定のプロパティデータレコードの前に送らなければなりません。 SCTPアソシエーション再確立の場合は、すべてのアクティブな共通プロパティは、対応する特定のプロパティデータレコードの前に再送信する必要があります。
The Common Properties Data Records MUST be sent reliably.
共通プロパティデータレコードが確実に送らなければなりません。
Common Properties Data Records MUST be resent on a regular basis. The periodicity MUST be configurable. The default value for the frequency of Common Properties transmission (refresh timeout) is 10 minutes.
共通プロパティデータレコードは、定期的に再送信する必要があります。周期性は、構成可能でなければなりません。共通プロパティの送信（リフレッシュタイムアウト）の周波数のデフォルト値は10分です。
The Exporting Process SHOULD transmit the Common Properties definition in advance of any Data Record that uses these Common Properties to help ensure that the Collector has the Common Properties definition before receiving the first associated Data Record.
エクスポートプロセスは、コレクタが最初に関連するデータレコードを受信する前に、共通プロパティの定義を持っていることを確保するために、これらの共通プロパティを使用するすべてのデータレコードの前に共通プロパティ定義を送信しなければなりません。
If a commonPropertiesID is not used anymore, the Exporting Process stops resending the related Common Properties Data Record. The old commonPropertiesID MUST NOT be used until its lifetime (see Section 6.1) has expired.
commonPropertiesIDはもはや使用されていない場合は、エクスポートプロセスは、関連する共通プロパティ・データ・レコードの再送信を停止します。その寿命は（6.1節を参照）を経過するまで古いcommonPropertiesIDを使用してはいけません。
Common Properties MUST be sent after the TCP connection establishment, and before the corresponding Specific Properties Data Records. In the case of TCP connection re-establishment, all active Common Properties MUST be resent before the corresponding Specific Properties Data Records.
共通プロパティは、TCPコネクションの確立後に、対応する特定のプロパティデータレコードの前に送らなければなりません。再確立TCP接続の場合には、すべてのアクティブな共通プロパティは、対応する特定のプロパティデータレコードの前に再送信する必要があります。
The commonPropertiesID is an identifier of a set of common properties that is locally unique per Observation Domain and Transport Session. The Exporting Process MUST manage the commonPropertiesIDs allocations for its Observation Domains and Transport Session. Different
commonPropertiesIDは観測ドメインと交通セッションごとにローカルで一意である一般的なプロパティのセットの識別子です。エクスポートプロセスは、その観測ドメインとトランスポートセッションのためにcommonPropertiesIDs割り当てを管理しなければなりません。異なります
Observation Domains from the same Exporter MAY use the same commonPropertiesID value to refer to different sets of Common Properties.
同じ輸出業者からの観測ドメインは、共通プロパティの異なるセットを参照するために同じcommonPropertiesID値を使用するかもしれません。
The commonPropertiesID values MAY be assigned sequentially, but it is NOT REQUIRED. Particular commonPropertiesID ranges or values MAY have explicit meanings for the IPFIX Device. For example, commonPropertiesID values may be assigned based on the result of a hash function, etc.
commonPropertiesID値を順次割り当ててもよいが、必須ではありません。特定のcommonPropertiesIDは範囲または値は、IPFIXデバイスのための明示的な意味を有していてもよいです。例えば、commonPropertiesID値等、ハッシュ関数の結果に基づいて割り当てることができます
Using a 64-bit commonPropertiesID Information Element allows the export of 2**64 active sets of Common Properties, per Observation Domain and per Transport Session.
64ビットcommonPropertiesID情報要素を使用すると、観測ドメインごとに交通セッションごとに、共通プロパティの2 ** 64のアクティブセットの輸出を可能にします。
commonPropertiesIDs that are not used anymore SHOULD be withdrawn. The Common Properties Withdrawal message is a Data Record defined by an Options Template consisting of only one scope field -- namely, the commonPropertiesID (with a type of 137 [RFC5102]) and no non-scope fields.
もう使用されていないcommonPropertiesIDsが撤回されるべきである（SHOULD）。 （137のタイプ[RFC5102]を使用）、すなわち、commonPropertiesIDなし非スコープフィールド - 共通プロパティ離脱メッセージは、唯一のスコープフィールドから成るオプションテンプレートによって定義されたデータ記録です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 14 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID N | Field Count = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field count = 1 |0| commonPropertiesID = 137 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope 1 Field Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Common Properties Withdrawal Message
図4：共通プロパティの撤退のメッセージ
If UDP is selected as the transport protocol, the Common Properties Withdrawal messages MUST NOT be used, as this method is inefficient due to the unreliable nature of UDP.
UDPは、トランスポートプロトコルとして選択されている場合は、この方法が原因UDPの信頼できない性質のために非効率的であるように、共通プロパティ脱退メッセージは、使用してはいけません。
This section describes the Collecting Process when using SCTP and PR-SCTP as the transport protocol. Any necessary changes to the Collecting Process, specifically related to TCP or UDP transport protocols, are specified in the subsections.
トランスポートプロトコルとしてSCTPとPR-SCTPを使用する場合、このセクションでは、収集プロセスを記載しています。具体的にはTCPまたはUDPトランスポートプロトコルに関連する収集プロセスに必要な変更は、サブセクションで指定されています。
The Collecting Process MUST store the commonPropertiesID information for the duration of the association so that it can interpret the corresponding Data Records that are received in subsequent Data Sets.
それは後続のデータセットで受信され、対応するデータレコードを解釈できるように、収集プロセスは、関連付けの持続時間commonPropertiesID情報を格納しなければなりません。
The Collecting Process can either store the Data Records as they arrive, without reconstructing the initial Flow Record, or reconstruct the initial Flow Record. In the former case, there might be less storage capacity required at the Collector side. In the latter case, the Collector job is more complex and time-consuming due to the higher resource demand for record processing in real time.
収集プロセスは、彼らが到着すると、最初のフローレコードを再構築せずに、データレコードを格納し、または最初のフローレコードを再構築することができます。前者の場合、コレクタ側で必要と少ない記憶容量があるかもしれません。後者の場合には、コレクタ・ジョブは、より複雑で時間のかかるリアルタイムでレコード処理のための高い資源需要によるものです。
If the Collecting Process has received the Specific Properties Data Record before the associated Common Properties Data Record, the Collecting Process SHOULD store the Specific Properties Data Record and await the retransmission or out-of-order arrival of the Common Properties Data Record.
収集プロセスは、関連する共通プロパティ・データ・レコードの前に特定のプロパティデータレコードを受信した場合は、収集プロセスは、特定のプロパティデータレコードを格納し、共通プロパティ・データ・レコードの再送信またはアウトオブオーダー到着を待つべきです。
commonPropertiesIDs are unique per SCTP association and per Observation Domain. If the Collecting Process receives an Options Template Record with a scope containing a commonPropertiesID that has already been received but that has not previously been withdrawn (i.e., a commonPropertiesID from the same Exporter Observation Domain received on the SCTP association), then the Collecting Process MUST shut down the association.
commonPropertiesIDsはSCTP協会あたりと観測ドメインごとに一意です。収集プロセスが既に受信されたcommonPropertiesIDを含む範囲とオプションテンプレートレコードを受信するが、それは以前に引き出されていない場合は、収集プロセスの必要があります（すなわち、同じ輸出観測ドメインからcommonPropertiesIDはSCTPアソシエーション上で受信されました）関連付けをシャットダウンします。
When an SCTP association is closed, the Collecting Process MUST discard all commonPropertiesIDs received over that association and stop decoding IPFIX Messages that use those commonPropertiesIDs.
SCTPアソシエーションが閉じられたときに、収集プロセスは、すべてのcommonPropertiesIDsを破棄しなければならないことアソシエーションを介して受信し、それらcommonPropertiesIDsを使用IPFIXメッセージをデコード停止。
If a Collecting Process receives a Common Properties Withdrawal message, the Collecting Process MUST delete the corresponding Common Properties associated with the specific SCTP association and specific Observation Domain, and stop interpreting Data Records referring to those Common Properties. The receipt of Data Records referring to Common Properties that have been withdrawn MUST be ignored and SHOULD be logged by the Collecting Process.
収集プロセスが共通プロパティ離脱メッセージを受信した場合、収集プロセスは、特定のSCTPアソシエーション及び特定観測ドメインに関連付けられた対応する共通プロパティを削除し、それらの共通プロパティを参照するデータレコードを解釈を停止しなければなりません。取り下げられた共通のプロパティを参照するデータレコードの領収書を無視しなければなりませんし、収集プロセスでログインする必要があります。
If the Collecting Process receives a Common Properties Withdrawal message for Common Properties that it has not received before on this SCTP association, it MUST reset the SCTP association and discard the IPFIX Message, and it SHOULD log the error as it does for malformed IPFIX Messages.
収集プロセスは、それがこのSCTPアソシエーション上で以前に受信していないことを共通プロパティのための共通プロパティの撤退メッセージを受信した場合、それはSCTPアソシエーションをリセットし、IPFIXのメッセージを破棄し、それが不正な形式のIPFIXメッセージの場合と同様に、それはエラーをログに記録すべきであるしなければなりません。
The Collecting Process MUST associate a lifetime with each Common Property received via UDP. Common Properties not refreshed by the Exporting Process within the lifetime are expired at the Collecting Process.
各共通プロパティはUDPを介して受信して収集プロセスは、寿命を関連付ける必要があります。生涯内のエクスポートプロセスによってリフレッシュされない共通プロパティは、収集プロセスで有効期限が切れています。
If the Common Properties are not refreshed before that lifetime has expired, the Collecting Process MUST discard the corresponding definition of the commonPropertiesID and any current and future associated Data Records. In this case, an alarm MUST be logged.
その寿命が満了する前に、共通プロパティがリフレッシュされない場合は、収集プロセスはcommonPropertiesIDと関連する現在および将来のデータレコードの対応する定義を捨てなければなりません。この場合、アラームがログインしている必要があります。
The Collecting Process MUST NOT decode any further Data Records that are associated with the expired Common Properties. If a Common Property is refreshed with a definition that differs from the previous definition, the Collecting Process SHOULD log a warning and replace the previously received Common Property with the new one. The Common Property lifetime at the Collecting Process MUST be at least 3 times higher than the refresh timeout of the Template used to export the Common Property definition, configured on the Exporting Process.
収集プロセスは、期限切れの共通プロパティに関連付けられている任意の更なるデータレコードをデコードしてはなりません。一般的なプロパティは、以前の定義とは異なり定義と更新された場合は、収集プロセスは警告をログに記録し、以前に新しいものと共通の財産を受けた交換する必要があります。収集プロセスでの一般的なプロパティの寿命は、エクスポートプロセスで構成された一般的なプロパティ定義をエクスポートするために使用されるテンプレートのリフレッシュタイムアウト、より少なくとも3倍高くなければなりません。
The Collecting Process SHOULD accept Data Records without the associated Common Properties required to decode the Data Record. If the Common Properties have not been received at the time Data Records are received, the Collecting Process SHOULD store the Data Records for a short period of time and decode them after the Common Properties definitions are received. The short period of time MUST be lower than the lifetime of definitions associated with identifiers considered unique within the UDP session.
収集プロセスは、データレコードを復号化するために必要な関連する共通プロパティせずにデータレコードを受け入れる必要があります。共通プロパティは、データレコードが受信された時点で受信されていない場合は、収集プロセスは時間の短い期間のためのデータレコードを格納する必要がありますし、共通プロパティの定義が受信された後にそれらをデコードします。時間の短い期間は、UDPセッション内で一意の識別子と考えると関連付けられた定義の寿命よりも低くなければなりません。
When the TCP connection is reset, either gracefully or abnormally, the Collecting Processes MUST delete all commonPropertiesID values and associated Common Properties data corresponding to that connection.
TCP接続がいずれかの正常または異常、リセットされた場合、収集プロセスは、その接続に対応するすべてのcommonPropertiesID値とそれに関連する共通プロパティデータを削除しなければなりません。
If a Collection Process receives a Common Properties Withdrawal message, the Collection Process MUST expire the related Common Properties data.
収集プロセスは、共通プロパティ撤退メッセージを受信した場合、収集プロセスは、関連する共通プロパティデータを期限切れにしなければなりません。
A Flow Record can refer to one or more Common Properties sets; the use of multiple Common Properties can lead to more efficient exports. When sets of Common Properties are identified in the data, it may be found that there is more than one set of non-overlapping properties.
フローレコードは、一つ以上の共通プロパティセットを参照することができます。複数の共通プロパティの使用は、より効率的な輸出につながることができます。共通プロパティのセットは、データ内で識別されている場合は、重複しない性質の複数のセットがあることがわかっていてもよいです。
Note that in the case of multiple Common Properties in one Data Record, the different sets of Common Properties MUST be disjoint (i.e., MUST NOT have Information Elements in common) to avoid potential collisions.
1データレコード内に複数の共通プロパティの場合には、共通プロパティの異なるセットが互いに素でなければならないことに注意してください潜在的な衝突を避けるために（すなわち、共通の情報要素を持ってはいけません）。
Consider a set of properties "A", e.g., common sourceAddressA and sourcePortA, and another set of properties "B", e.g., destinationAddressB and destinationPortB. Figure 5 shows how this information is repeated with classical IPFIX export in several Flow Records.
プロパティ「A」の集合、例えば、共通sourceAddressAとsourcePortA、およびプロパティ「B」の別のセット、例えば、destinationAddressBとdestinationPortBを考えます。図5は、この情報は、いくつかのフローレコードで古典IPFIX輸出で繰り返される方法を示しています。
+--------+--------+---------+---------+---------------------+
|srcAddrA|srcPortA|destAddrB|destPortB| <Flow1 information> |
+--------+--------+---------+---------+---------------------+
|srcAddrA|srcPortA|destAddrC|destPortC| <Flow2 information> |
+--------+--------+---------+---------+---------------------+
|srcAddrD|srcPortD|destAddrB|destPortB| <Flow3 information> |
+--------+--------+---------+---------+---------------------+
|srcAddrD|srcPortD|destAddrC|destPortC| <Flow4 information> |
+--------+--------+---------+---------+---------------------+
| ... | ... | ... | ... | ... |
+--------+--------+---------+---------+---------------------+
Figure 5: Common and Specific Properties Exported Together
図5：コモン、特定のプロパティをまとめてエクスポート
Besides A and B, other sets of Properties might be repeated as well (e.g., Properties C and D in the figure above).
A及びBに加えて、プロパティの他のセットは、（上記の図に、例えば、プロパティC及びD）も繰り返されるかもしれません。
We can separate the Common Properties into properties A composed of sourceAddressA and sourcePortA, properties D composed of sourceAddressD and sourcePortD, properties B composed of destinationAddressB and destinationPortB, and properties C composed of destinationAddressC and destinationPortC. These four records can be expanded to four combinations of Data Records to reduce redundancy without the need to define four complete sets of Common Properties (see the figure below). The more Common Properties sets that are defined, the more combinations that are available.
我々はsourceAddressAとsourcePortAからなるプロパティに共通プロパティを分離することができ、特性がsourceAddressDとsourcePortD、destinationAddressCとdestinationPortC成るdestinationAddressBとdestinationPortB成るプロパティB、及び性質のCからなるD。これらの4つのレコードは、共通プロパティ（下図参照）の4つの完全なセットを定義する必要なしに、冗長性を減らすためにデータレコードの4つの組み合わせに拡張することができます。定義されてより多くの共通プロパティセット、利用可能な複数の組合せ。
+-------------------+-----------------+-------------+
| index for prop. A | sourceAddressA | sourcePortA |
+-------------------+-----------------+-------------+
| index for prop. D | sourceAddressD | sourcePortD |
+-------------------+-----------------+-------------+
+-------------------+---------------------+------------------+
| index for prop. B | destinationAddressB | destinationPortB |
+-------------------+---------------------+------------------+
| index for prop. C | destinationAddressC | destinationPortC |
+-------------------+---------------------+------------------+
+------------------+------------------+-----------------------+
|index for prop. A |index for prop. B | <Flow1 information> |
+------------------+------------------+-----------------------+
|index for prop. A |index for prop. C | <Flow2 information> |
+------------------+------------------+-----------------------+
|index for prop. D |index for prop. B | <Flow3 information> |
+------------------+------------------+-----------------------+
|index for prop. D |index for prop. C | <Flow4 information> |
+------------------+------------------+-----------------------+
Figure 6: Multiple Common (above) and Specific Properties (below) Exported Separately
図6：複数の共通（上記）と特定のプロパティ（以下）を別々にエクスポート
The advantage of the multiple Common Properties is that the objective of reducing the bandwidth is met while the number of indices is kept to a minimum. Defining an extra index for all records would not save bandwidth in the case of Figure 5 and is generally a less efficient solution.
複数の共通プロパティの利点は、インデックスの数を最小限に抑えながら、帯域幅を削減する目的が達成されていることです。すべてのレコードのための余分なインデックスを定義すると、図5の場合には、帯域幅を節約し、一般的にあまり効率的なソリューションではないでしょう。
If a set of Flow Records share multiple sets of Common Properties, multiple commonPropertiesID instances MAY be used to increase export efficiency even further, as displayed in Figure 7.
フローレコードのセットは共通プロパティの複数のセットを共有している場合は、図7に表示されているように、複数のcommonPropertiesIDインスタンスは、さらに輸出効率を高めるために使用されるかもしれません。
+--------------------------- + +---------------------+
| Common Properties | | Specific Properties | Template
| Options Template Record | | Template Record | Definition
| | | |
| Scope: commonPropertiesID1 | | commonPropertiesID1 |
| Scope: commonPropertiesID2 | | commonPropertiesID2 |
| Common Properties | | Specific Properties |
+------------+---------------+ +---------+-----------+
.............|...............................|.......................
| |
+------------v-------------+ +----------v----------+
| Common Properties | | Specific Properties |+ Exported
| Data Record |------> Data Records || Data
+------------------------- + +---------------------+| Records
+---------------------+
Figure 7: Multiple Data Reduction
図7：複数のデータ削減
An Exporting Process MUST NOT export any set of Common Properties that contains, either directly or via other cascaded Common Properties, references to itself in its own definition (i.e., a circular definition). When the Collecting Process receives Common Properties that reference other Common Properties, it MUST resolve the references to Common Properties. If the Common Properties aren't available at the time Data Records are received, the Collecting Process SHOULD store the Data Records for a short period of time and decode them after the Common Properties are received.
エクスポートプロセスは、共通プロパティは、それ自体の定義（即ち、円形の定義）自体への参照をカスケード接続し、直接または他を介して、含まれている共通プロパティの任意のセットをエクスポートしてはいけません。収集プロセスは、他の共通プロパティを参照する共通プロパティを受信すると、共通プロパティへの参照を解決しなければなりません。共通プロパティは、データレコードが受信された時点で利用できない場合は、収集プロセスは時間の短い期間のためのデータレコードを格納する必要がありますし、共通プロパティが受信された後にそれらをデコードします。
If the Collecting Process could not decode a cascading Common Properties definition because the referenced Common Properties are not available before the short period of time, then the Collecting Process SHOULD log the error.
参照共通プロパティは、時間の短い期間の前には利用できないので、収集プロセスは、カスケード共通プロパティの定義をデコードすることができなかった場合は、収集プロセスはエラーをログに記録すべきです。
If the Collecting Process could not decode a cascading Common Properties definition because it detects a circular definition, then the Collecting Process SHOULD log the error.
収集プロセスは、カスケード共通プロパティの定義をデコードすることができなかった場合、それは循環定義を検出するので、その後、収集プロセスはエラーをログに記録すべきです。
Information Element ordering MUST be preserved when creating and expanding Common Properties.
情報要素の順序を作成し、共通プロパティを展開したときに保存されなければなりません。
The objective of the method specified in this document is the reduction in the amount of measurement data that has to be transferred from the Exporter to the Collector. Note that the efficiency of this method may vary, as discussed in this section. In addition, there might be less storage capacity required at the Collector side if the Collector decides to store the Data Records as they arrive, without reconstructing the initial Flow Record.
この文書で指定された方法の目的は、コレクタに輸出から転送されなければならない測定データの量の減少です。このセクションで説明したように、この方法の効率が変化してもよいことに留意されたいです。コレクターは、彼らが到着すると、最初のフローレコードを再構築せずに、データレコードを保存することを決定した場合また、コレクタ側で必要な以下のストレージ容量があるかもしれません。
On the other hand, this method requires additional resources on both the Exporter and the Collector. The Exporter has to manage Common Properties information and to assign commonPropertiesID values. The Collector has to process records described by two templates instead of just one. Additional effort is also required when post processing the measurement data, in order to correlate Flow Records with Common Properties information.
一方、この方法では、輸出業者やコレクターの両方に追加のリソースが必要です。輸出業者は、共通プロパティ情報を管理し、commonPropertiesID値を割り当てる必要があります。コレクターは、2つのテンプレートだけではなく1で説明したレコードを処理する必要があります。ポストの測定データを処理する際に、追加の努力にも共通プロパティ情報でフローレコードを相関させるために、必要です。
The proposed method is most effective using a reliable transport protocol for the transfer of the Common Properties. Therefore, the use of PR-SCTP with full reliability or TCP is recommended for the transmission of IPFIX Messages containing Common Properties. Note that use of UDP is less efficient for the transmission of Common Properties, as they have to be resent regularly.
提案手法は、共通プロパティの転送のための信頼できるトランスポートプロトコルを使用して最も効果的です。そのため、完全な信頼性やTCPとPR-SCTPを使用すると、共通プロパティを含むIPFIXメッセージの伝送のために推奨されます。彼らは定期的に再送する必要があるとして、UDPの使用は、共通プロパティの伝送にはあまり効率的であることに注意してください。
The transfer of the commonPropertiesIDs originates some overhead and might even increase the amount of exported data if the length of the commonPropertiesID field is not shorter than the length of the replaced fields.
commonPropertiesIDsの転送は、いくつかのオーバーヘッドを発信し、commonPropertiesIDフィールドの長さは、置き換えフィールドの長さよりも短くない場合でも、エクスポートされたデータの量が増加する可能性があります。
In cases where the range of the commonPropertiesID can be restricted, it is RECOMMENDED to apply reduced size encoding to the commonPropertiesID to achieve a further gain in bandwidth efficiency.
commonPropertiesIDの範囲を制限することができる場合には、帯域幅効率のさらなる増加を達成するためにcommonPropertiesIDに縮小サイズの符号化を適用することが推奨されます。
While the goal of this specification is to reduce the bandwidth, the efficiency might be limited. Indeed, the efficiency gain is based on the abundance of redundant information in Flows and would be directly proportional to the reuse of the defined commonPropertiesID values, with a theoretical limit where all the Data Records would use a single commonPropertiesID. In other words, the more we reuse a commonPropertiesID value, the better the efficiency gain. While the Exporting Process can evaluate the direct gain for the Flow Records to be exported, it cannot predict whether future Flow Records would contain the information specified by active commonPropertiesID values. This implies that the efficiency factor of this specification is higher for specific applications where filtering is involved, such as one-way delay or trajectory sampling.
この仕様の目標は、帯域幅を削減することですが、効率が制限される場合があります。実際、効率の利得は、フローの冗長情報の豊富さに基づいて、すべてのデータレコードが単一commonPropertiesIDを使用する理論的限界と、定義されたcommonPropertiesID値の再利用に正比例するであろう。言い換えれば、より多くの我々はcommonPropertiesID値、優れた効率ゲインを再利用します。フローレコードをエクスポートするためのエクスポートプロセスがダイレクトゲインを評価することができますが、それは将来のフローレコードがアクティブcommonPropertiesID値で指定された情報が含まれているかどうかを予測することはできません。これは、本明細書の効率因子は、このような一方向遅延又は軌道サンプリングとしてフィルタリングが関与している特定のアプリケーションのために高くなることを意味します。
Note that this technique might even lead to an increase in bandwidth usage under certain conditions. Taking into account the overhead of exporting the commonPropertiesID values, if the commonPropertiesID values are not used in future Data Records, this technique would actually increase the export bandwidth. A typical case would be the assignments of Common Properties based on past observed traffic, hoping that future Flows would contain the same characteristics.
この技術でも、一定の条件の下で、帯域幅の使用量の増加につながる可能性があることに注意してください。 commonPropertiesID値は、将来のデータレコードで使用されていない場合は、アカウントにcommonPropertiesID値をエクスポートするのオーバーヘッドを取ると、この技術は、実際に輸出帯域幅を増加させます。典型的なケースは、過去に基づいて共通プロパティの割り当ては将来のフローが同じ特性が含まれているだろうと期待して、トラフィックを観察されるであろう。
The efficiency gain depends also on the difference between the length of the replaced fields and the length of the commonPropertiesID. The shorter the length of the commonPropertiesID is (with respect to the total length of the Common Properties fields), the bigger the gain is.
効率利得は、置換フィールドの長さとcommonPropertiesIDの長さの差にも依存します。 commonPropertiesIDの長さは短い方が、（共通プロパティのフィールドの合計長さに関して）より大きなゲインがされています。
The example in Appendix A.2 below uses IPFIX to export measurement data for each received packet. In that case, for a Flow of 1000 packets, the amount of data can be decreased more than 26 percent.
以下の付録A.2の例では、各受信したパケットの測定データをエクスポートするIPFIXを使用します。その場合には1000のパケットのフローのために、データの量がより多く26％を減少させることができます。
The same security considerations as for the IPFIX protocol [RFC5101] apply.
IPFIXプロトコル[RFC5101]と同じセキュリティ上の考慮事項が適用されます。
The authors would like to thank Guido Pohl for initiating this work and for his contribution to early versions of this document. Thanks also to Andrew Johnson, Gehrard Muenz, Brian Trammell, and Paul Aitken for their comments and feedback.
著者は、この作業を開始するため、このドキュメントの初期バージョンへの彼の貢献のためにグイドPohlのを感謝したいと思います。彼らのコメントやフィードバックのためにもアンドリュー・ジョンソン、Gehrard Muenz、ブライアン・トラメル、そしてポール・エイトケンに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC5101] Claise, B., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008.
[RFC5101] Claise、B.、 "IPトラフィックフロー情報を交換するためのIPフロー情報のエクスポート（IPFIX）プロトコルの仕様"、RFC 5101、2008年1月。
[RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, January 2008.
[RFC5102] Quittek、J.、ブライアント、S.、Claise、B.、エイトケン、P.、およびJ.マイヤー、 "IPフロー情報のエクスポートのための情報モデル"、RFC 5102、2008年1月。
[RFC5476] Claise, B., Ed., "Packet Sampling (PSAMP) Protocol Specifications", RFC 5476, March 2009.
[RFC5476] Claise、B.、エド。、 "パケットサンプリング（PSAMP）プロトコル仕様"、RFC 5476、2009年3月。
[PSAMP-MIB] Dietz, T., Ed. and B. Claise, "Definitions of Managed Objects for Packet Sampling", Work in Progress, June 2006.
[PSAMP-MIB]ディーツ、T.、エド。そしてB. Claise、「パケットサンプリングのための管理オブジェクトの定義」、進歩、2006年6月での作業。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004.
[RFC3758]スチュワート、R.、Ramalho、M.、謝、Q.、Tuexen、M.、およびP.コンラッド、 "ストリーム制御伝送プロトコル（SCTP）部分的な信頼性拡張"、RFC 3758、2004年5月。
[RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export (IPFIX)", RFC 3917, October 2004.
[RFC3917] Quittek、J.、Zseby、T.、Claise、B.、およびS.ザンダー、 "IPフロー情報エクスポート（IPFIX）のための要件"、RFC 3917、2004年10月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]スチュワート、R.、 "ストリーム制御伝送プロトコル"、RFC 4960、2007年9月。
[RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture for IP Flow Information Export", RFC 5470, March 2009.
[RFC5470] Sadasivan、G.、ブラウンリー、N.、Claise、B.、およびJ. Quittek、RFC 5470、2009年3月 "IPフロー情報のエクスポートのためのアーキテクチャ"。
[RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP Flow Information Export (IPFIX) Applicability", RFC 5472, March 2009.
[RFC5472] Zseby、T.、ボスキ、E.、ブラウンリー、N.、およびB. Claise、 "IPフロー情報のエクスポート（IPFIX）の適用"、RFC 5472、2009年3月。
[RFC5474] Duffield, N., Ed., "A Framework for Packet Selection and Reporting", RFC 5474, March 2009.
[RFC5474]ダッフィールド、N.、エド。、 "パケット選択のためのフレームワークとの報告"、RFC 5474、2009年3月。
[RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. Raspall, "Sampling and Filtering Techniques for IP Packet Selection", RFC 5475, March 2009.
[RFC5475] Zseby、T.、モリーナ、M.、ダッフィールド、N.、ニッコリーニ、S.、およびF. Raspall、 "IPパケットの選択のためのサンプリングとフィルタリング技術"、RFC 5475、2009年3月。
[RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. Carle, "Information Model for Packet Sampling Exports", RFC 5477, March 2009.
[RFC5477]ディーツ、T.、Claise、B.、エイトケン、P.、ドレスラー、F.、およびG.カール、RFC 5477 "情報モデルパケットサンプリングの輸出について"、2009年3月。
Appendix A. Examples
付録A.例
A.1. Per-Flow Data Reduction
A.1。フローごとのデータ削減
In this section, we show how Flow information can be exported efficiently using the method described in this document. Let's suppose we have to periodically export data about two IPv6 Flows.
このセクションでは、フロー情報は、この文書に記載された方法を用いて効率的にエクスポートすることができる方法を示しています。我々は定期的にIPv6がフロー2についてのデータをエクスポートすることがあるとしましょう。
In this example, we report the following information:
この例では、以下の情報をレポート：
Flow| dstIPv6Address | dst- |nPkts|nBytes
| | Port | |
----------------------------------------------------------------
A |2001:DB8:80AD:5800:0058:0800:2023:1D71 | 80 | 30 | 6000
| | | |
A |2001:DB8:80AD:5800:0058:0800:2023:1D71 | 80 | 50 | 9500
| | | |
B |2001:DB8:80AD:5800:0058:00AA:00B7:AF2B | 1932 | 60 | 8000
| | | |
A |2001:DB8:80AD:5800:0058:0800:2023:1D71 | 80 | 40 | 6500
| | | |
A |2001:DB8:80AD:5800:0058:0800:2023:1D71 | 80 | 60 | 9500
| | | |
B |2001:DB8:80AD:5800:0058:00AA:00B7:AF2B | 1932 | 54 | 7600
Figure 8: Flow Information Example
図8：フロー情報の例
The Common Properties in this case are the destination IPv6 address and the destination port. We first define an Options Template that contains the following Information Elements:
この場合、共通プロパティは、宛先IPv6アドレスと宛先ポートです。私たちは、最初に以下の情報要素が含まれているオプションテンプレートを定義します。
o Scope: commonPropertiesID in [RFC5102], with a type of 137 and a length of 8 octets.
Oスコープ：[RFC5102]でcommonPropertiesID、137の種類及び8つのオクテットの長さを有します。
o The destination IPv6 address: destinationIPv6Address in [RFC5102], with a type of 28 and a length of 16 octets.
宛先IPv6アドレスO：28の種類及び16オクテットの長さを有する、[RFC5102]にdestinationIPv6Address、。
o The destination port: destinationTransportPort in [RFC5102], with a type of 11, and a length of 2 octets.
宛先ポートO：11の種類、及び2つのオクテットの長さを有する、[RFC5102]にdestinationTransportPort、。
Figure 9 shows the Options Template defining the Common Properties with commonPropertiesID as scope:
図9は、スコープとしてcommonPropertiesIDで共通プロパティを定義するオプションテンプレートを示しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 24 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 257 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field count = 1 |0| commonPropertiesID = 137 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope 1 Field Length = 8 |0| destinationIPv6Address = 28|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 16 |0|destinationTransportPort = 11|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 | (Padding) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Common Properties Options Template
図9：共通プロパティオプションテンプレート
The Specific Properties Template consists of the information not contained in the Options Templates, i.e., Flow-specific information; in this case, the number of packets and the number of bytes to be reported. Additionally, this Template contains the commonPropertiesID. In Data Records, the value of this field will contain one of the unique indices of the Option Records exported before. It contains the following Information Elements (see also Figure 10):
特定のプロパティテンプレートオプションテンプレート、すなわち、フロー固有情報に含まれていない情報から成ります。この場合には、パケットの数とバイト数を報告します。また、このテンプレートはcommonPropertiesIDが含まれています。データレコードでは、このフィールドの値は、前にエクスポートオプションレコードのユニークな指標の一つが含まれています。これは、以下の情報要素を（また図10を参照）が含まれます。
o commonPropertiesID with a length of 8 octets.
O 8つのオクテットの長さでcommonPropertiesID。
o The number of packets of the Flow: inPacketDeltaCount in [RFC5102], with a length of 4 octets.
4つのオクテットの長さを有する、[RFC5102]でinPacketDeltaCount、：フローのパケット数、O。
o The number of octets of the Flow: inOctetDeltaCount in [RFC5102], with a length of 4 octets.
Oフローのオクテットの数：[RFC5102]でinOctetDeltaCount、4つのオクテットの長さを有します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 20 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 258 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| commonPropertiesID = 137 | Field Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| inPacketDeltaCount = 2 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| inOctetDeltaCount = 1 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Specific Properties Template
図10：特定のプロパティテンプレート
Considering the data shown at the beginning of this example, the following two Data Records will be exported:
この例の冒頭で示したデータを考慮すると、以下の二つのデータレコードがエクスポートされます。
Common- | dstAddress | dst-
PropertiesID | | Port
-------------+-----------------------------------------+-------
101 | 2001:DB8:80AD:5800:0058:0800:2023:1D71 | 80
| |
102 | 2001:DB8:80AD:5800:0058:00AA:00B7:AF2B | 1932
Figure 11
図11
The Data Records reporting the Common Properties will look like:
共通プロパティを報告するデータレコードは、次のようになります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 257 | Length = 60 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- 101 -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- 2001:DB8:80AD:5800:0058:0800:2023:1D71 -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 80 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+
| 102 |
+- -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+
| |
+- -+
| 2001:DB8:80AD:5800:0058:00AA:00B7:AF2B |
+- -+
| |
+- -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 1932 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Data Records reporting Common Properties
図12：データレコードは共通プロパティを報告します
The Data Records will in turn be:
データレコードは順番になります。
commonPropertiesID | inPacketDeltaCount | inOctetDeltaCount
---------------------------------------------------------------
101 | 30 | 6000
101 | 50 | 9500
102 | 60 | 8000
101 | 40 | 6500
101 | 60 | 9500
102 | 54 | 7600
Figure 13
図13
Figure 14 shows the first Data Record listed in the table:
図14は、表に列挙された最初のデータレコードを示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 258 | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- 101 -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 30 | 6000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Data Record reporting Common Properties
図14：データレコードは共通プロパティを報告します
A.2. Per-Packet Data Reduction
A.2。パケット単位のデータ削減
An example of the per-packet data reduction is the measurement of One-Way Delay (OWD), where the exact same specific packet must be observed at the source and destination of the path to be measured. The OWD is computed by subtracting the time of observation of the same packet at the two end-points with synchronized clocks. As the OWD is measured for a specific application on which a Service Level Agreement (SLA) is bound, this translates into the observation of multiple packets with Specific Properties. In order to match the identical packet at both Observation Points, a series of packets with a set of properties (for example, all the packets of a specific source and destination IP addresses, of a specific Diffserv codepoint (DSCP) value, and of a specific destination transport port) must be observed at both ends of the measurements. This implies that the source and destination must export a series of Flow Records composed of two types of information: some common information for all packets, and some unique information about each packet in order to generate a unique identifier for each packet passing this Observation Point (for example, a hash value on the invariant fields of the packet). So, the source and destination composing the measurement's end-points can individually and independently apply the redundancy technique described in this document in order to save some bandwidth for their respective Flow Records exports.
パケット単位のデータ削減の一例は、正確に同じ特定のパケットを測定するパスのソースとデスティネーションで観察されなければならない一方向遅延（OWD）の測定です。 OWDは同期クロックで2つのエンドポイントで同じパケットの観察の時間を減算することにより計算されます。 OWDは、サービスレベル契約（SLA）が結合されている特定のアプリケーションのために測定されるように、これは、特定の特性を有する複数のパケットの観察につながります。との、特性（例えば、特定のDiffservコードポイントの特定のソースおよび宛先IPアドレスのすべてのパケット（DSCP）値のセットで、両方の観測点での一連のパケットを同一のパケットを一致させるために特定の宛先トランスポートポート）測定の両端に観察されなければなりません。 （この観測点を通過する各パケットの一意の識別子を生成するために、すべてのパケットのためのいくつかの一般的な情報、および各パケットについてのいくつかのユニークな情報：これは、送信元と宛先は、情報の2種類で構成フローレコードのシリーズをエクスポートする必要があることを意味します例えば、パケットの不変のフィールドに、ハッシュ値）。だから、測定のエンドポイントを構成する送信元と宛先は個別に独立して、それぞれのフローレコードの輸出のためのいくつかの帯域幅を節約するために、このドキュメントで説明する冗長化技術を適用することができます。
The Templates required for exporting measurement data of this kind are illustrated in the figures below. Figure 15 shows the Options Template containing the information concerning Flows using the commonPropertiesID as scope. In the Common Properties Template, we export the following Information Elements: o The source IPv4 Address: sourceIPv4Address in [RFC5102], with a type of 8 and a length of 4 octets.
この種の測定データをエクスポートするために必要なテンプレートは、以下の図に示されています。図15は、スコープとしてcommonPropertiesIDを使用してフローに関する情報を含むオプションテンプレートを示します。共通プロパティのテンプレートでは、以下の情報要素をエクスポート：ソースIPv4アドレス○：[RFC5102]でsourceIPv4Addressを、8の種類と4つのオクテットの長さ。
o The destination IPv4 Address: destinationIPv4Address in [RFC5102], with a type of 12 and a length of 4 octets.
O先のIPv4アドレス：12の種類及び4つのオクテットの長さを有する、[RFC5102]の宛先IPv4アドレス。
o The Class of Service field: ClassOfServiceIPv4 in [RFC5102], with a type of 5 and a length of 1 octet.
[RFC5102]でClassOfServiceIPv4、5の種類及び1つのオクテットの長さ：サービスクラスのフィールドO。
o The Protocol Identifier: protocolIdentifier in [RFC5102], with a type of 4 and a length of 1 octet.
プロトコル識別子O：4の種類及び1つのオクテットの長さを有する、[RFC5102]にプロトコル識別子。
o The source port: sourceTransportPort in [RFC5102], with a type of 7 and a length of 2 octets.
ソースポートO：7の種類及び2つのオクテットの長さを有する、[RFC5102]にsourceTransportPort、。
o The destination port: destinationTransportPort in [RFC5102], with a type of 11 and a length of 2 octets.
宛先ポートO：11の種類及び2つのオクテットの長さを有する、[RFC5102]にdestinationTransportPort、。
The commonPropertiesID Information Element is used as the Scope Field.
commonPropertiesID情報要素は、スコープフィールドとして使用されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 40 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 256 | Field Count = 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field count = 1 |0| commonPropertiesID = 137 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope 1 Field Length = 4 |0| sourceIPv4Address = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 |0| destinationIPv4Address = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 |0| classOfServiceIPv4 = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 1 |0| protocolIdentifier = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 1 |0| transportSourcePort = 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0|transportDestinationPort = 11|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Example Flow Properties Template
図15：例フローのプロパティテンプレート
For passive OWD measurement, the Packet Properties Template or Specific Properties Template consists of at least the timestamp and packet ID. Additionally, this template contains a commonPropertiesID field to associate the packet with a Flow.
受動OWD測定のために、パケットプロパティテンプレートまたは特定のプロパティテンプレートは、少なくともタイムスタンプ及びパケットIDから成ります。また、このテンプレートは、フローのパケットを関連付けるcommonPropertiesIDフィールドが含まれています。
Figure 16 displays the template with the packet properties. In this example, we export the following Information Elements:
図16は、パケットの性質を有するテンプレートを表示します。この例では、以下の情報要素をエクスポートします。
o commonPropertiesID. In this case, reduced size encoding is used, and the Information Element is declared with a length of 4 octets instead of 8.
commonPropertiesID O。この場合、縮小サイズのエンコーディングが使用され、情報要素が4つのオクテットの代わりに、8の長さで宣言されています。
o The packet timestamp: observationTimeMilliseconds in the PSAMP information model [RFC5477], with a type of 323 and a length of 8 octets.
Oパケットのタイムスタンプ：323の種類及び8つのオクテットの長さPSAMP情報モデル[RFC5477]でobservationTimeMilliseconds。
o digestHashValue in the PSAMP information model [RFC5477], with a type of 326 and a length of 8 octets.
O 326の種類及び8つのオクテットの長さPSAMP情報モデル[RFC5477]でdigestHashValue。
o The packet length: ipTotalLength in the IPFIX information model [RFC5102], with a type of 224 and a length of 8 octets.
パケット長O：224の種類及び8つのオクテットの長さIPFIX情報モデルにおけるipTotalLength [RFC5102]。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 36 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 257 | Field Count = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| commonPropertiesID = 137 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| observationTimeMillis.= 323 | Field Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| digestHashValue = 326 | Field Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| ipTotalLength = 224 | Field Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Example Packet Properties Template
図16：例パケットプロパティのテンプレート
At the collection point, packet records from the two measurement points are gathered and correlated by means of the packet ID. The resulting delay Data Records are exported in a similar manner as the packet data. One-Way Delay data is associated with Flow information by the commonPropertiesID field. The OWD properties contain the Packet Pair ID (which is the packet ID of the two contributing packet records), the timestamp of the packet passing the reference monitor point in order to reconstruct a time series, the calculated delay value, and the commonPropertiesID.
収集ポイントで、2つの測定点からのパケットのレコードは、パケットIDによって集められ相関しています。得られた遅延データレコードは、パケットデータと同様に輸出されています。ワンウェイ遅延データはcommonPropertiesIDフィールドによってフロー情報に関連付けられています。 OWD特性は、（二寄与するパケットレコードのパケットIDである）パケットペアID、時系列、算出された遅延値、及びcommonPropertiesIDを再構成するために参照モニター点を通過するパケットのタイムスタンプを含みます。
In this example, using IPFIX to export the measurement data for each received packet, 38 bytes have to be transferred (sourceAddressV4=4, destinationAddressV4=4, classOfServiceV4=1, protocolIdentifier=1, sourceTransportPort=2, destinationTransportPort=2, observationTimeMilliseconds=8, digestHashValue=8, ipTotalLength=8). Without considering the IPFIX protocol overhead, a Flow of 1000 packets produces 38000 bytes of measurement data. Using the proposed optimization, each packet produces an export of only 28 bytes (observationTimeMilliseconds=8, digestHashValue=8, ipTotalLength=8, commonPropertiesID=4). The export of the Flow information produces 18 bytes (sourceAddressV4=4, destinationAddressV4=4, classOfServiceV4=1, protocolIdentifier=1, sourceTransportPort=2, destinationTransportPort=2, commonPropertiesID=4). For a Flow of 1000 packets, this sums to 28018 bytes. This is a decrease of more than 26 percent.
この例では、各受信パケットのための測定データをエクスポートするIPFIXを使用して、38のバイトが転送されなければならない（sourceAddressV4 = 4、destinationAddressV4 = 4、classOfServiceV4 = 1、プロトコル識別子= 1、sourceTransportPort = 2、destinationTransportPort = 2、observationTimeMilliseconds = 8 、digestHashValue = 8、ipTotalLength = 8）。 IPFIXプロトコルオーバーヘッドを考慮せずに1000のパケットのフローは、測定データの38000のバイトを生成します。提案された最適化を使用して、各パケットは、28バイト（observationTimeMilliseconds = 8、digestHashValue = 8、ipTotalLength = 8、commonPropertiesID = 4）の輸出を生成します。フロー情報のエクスポートは、18バイト（sourceAddressV4 = 4、destinationAddressV4 = 4、classOfServiceV4 = 1、プロトコル識別子= 1、sourceTransportPort = 2、destinationTransportPort = 2、commonPropertiesID = 4）を生成します。 1000のパケットの流れのため、これは28018バイトに合計します。これは、以上の26％の減少です。
A.3. Common Properties Withdrawal Message
A.3。共通プロパティ脱退メッセージ
This section shows an example commonPropertiesID Withdrawal message. Figure 17 depicts the Options Template Record with the commonPropertiesID as unique scope field, and no non-scope fields.
このセクションでは、例commonPropertiesID離脱メッセージを示しています。図17は、一意のスコープフィールドとしてcommonPropertiesID、ノー非スコープフィールドとオプションテンプレートレコードを示しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 14 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 259 | Field Count = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field count = 1 |0| commonPropertiesID 137 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope 1 Field Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Example Common Properties Withdrawal Template
図17：例共通プロパティ撤退テンプレート
Figure 18 shows the Option Data Record withdrawing commonPropertiesID N:
図18は、commonPropertiesID N吸引オプションデータレコードを示しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 259 | Length = 12 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- N -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: Record Withdrawing commonPropertiesID N
図18：レコードはcommonPropertiesID Nを抜き出します
Authors' Addresses
著者のアドレス
Elisa Boschi Hitachi Europe c/o ETH Zurich Gloriastrasse 35 8092 Zurich Switzerland
エリサボスキ日立ヨーロッパのC / ETHチューリッヒGloriastrasse 35 8092チューリッヒスイスO
Phone: +41 44 6327057 EMail: elisa.boschi@hitachi-eu.com
電話：+41 44 6327057 Eメール：elisa.boschi@hitachi-eu.com
Lutz Mark Fraunhofer IFAM Wiener Str. 12 28359 Bremen Germany
ルッツマーク・フラウンホーファーIFAMウィーンのStr。12 28359ブレーメンドイツ
Phone: +49 421 2246206 EMail: lutz.mark@ifam.fraunhofer.de
電話：+49 421 2246206 Eメール：lutz.mark@ifam.fraunhofer.de
Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 Diegem 1813 Belgium
ブノワClaiseシスコシステムズ、株式会社デKleetlaan 6aはB1のディーゲム1813ベルギー
Phone: +32 2 704 5622 EMail: bclaise@cisco.com
電話：+32 2 704 5622 Eメール：bclaise@cisco.com