[要約] RFC 5473は、IPFIXとPSAMPレポートでの冗長性を削減するためのガイドラインです。その目的は、ネットワークトラフィックの情報を効率的に収集し、冗長なデータを削減することです。
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
IPフロー情報エクスポート（IPFIX）およびパケットサンプリング（PSAMP）レポートの冗長性の削減
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 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.
この方法は、いくつかのフローレコードに共通の情報を個々のフローレコードに固有の情報から分離することで機能します。一般的なフロー情報は、オプションテンプレートで定義されたデータレコードで1回のみエクスポートされますが、特定のフロー情報の残りの部分は一意の識別子を介して共通情報に関連付けられています。
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.
このドキュメントは、これらの不変性または一般的なプロパティを1回だけエクスポートする方法を指定しますが、残りのフロー固有のプロパティは通常のデータレコードにエクスポートされます。一意の一般的なプロパティ識別子は、データレコードと共通属性をリンクするために使用されます。
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フロー情報へのアクセスを提供します。RFC 3917 [RFC3917]で定義されている要件に従って、IPFIXエクスポートプロセスから収集プロセスへの測定されたIPフロー情報のエクスポートのアーキテクチャは、IPFIXアーキテクチャ[RFC5470]で定義されています。IPFIXアーキテクチャ[RFC5470]は、IPFIXのデータレコードとテンプレートが、IPFIXのエクスポートプロセスからIPFIXの収集プロセスへの混雑認識輸送プロトコルを介してどのように携帯されるかを指定します。IPFIXには、IPFIX情報モデル[RFC5102]で指定されているように、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つ以上の属性のコレクションです。一般的なプロパティの各セットは、一般的なPropertiesIDを使用して一意に識別できます。
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.
エクスポートされる各フローレコードに相当する、一般的な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は、このドキュメントの仕様を適用する際のこの情報がどのようにエクスポートされるかを示しています。共通の特性は、各フローレコードの特定の特性から分離されています。一般的なプロパティは、特定のデータレコード（オプションテンプレートで定義されている）で1回だけエクスポートされますが、各フローレコードには、フロー固有の情報とともに共通プロパティ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 AssociationまたはTCP接続ごとに1回だけ送信する必要があり、SCTPが輸送プロトコルである場合はSCTPを介して確実に送信する必要があります。これらのプロパティは、いくつかのフローレコード（IPソースや宛先アドレスなど）に共通する値を表します。対応する特定のプロパティデータレコードの前に、一般的なプロパティデータレコードを送信する必要があります。特定のプロパティを報告するデータレコードは、共通プロパティの一意の識別子である共通プロパティエイド情報要素[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.
Active Commonプロパティは、SCTP協会の確立の後、および対応する特定のプロパティデータレコードの前に送信する必要があります。SCTP Associationの再確立の場合、対応する特定のプロパティデータレコードの前に、すべてのアクティブな共通プロパティがresする必要があります。
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.
一般的なプロパティデータレコードは、定期的にresする必要があります。周期性は構成可能でなければなりません。Common Properties Transmission（更新タイムアウト）の頻度のデフォルト値は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がもはや使用されていない場合、エクスポートプロセスは、関連する共通プロパティデータレコードの控除を停止します。古いCommonPropertiesIDは、その寿命（セクション6.1を参照）が失効するまで使用してはなりません。
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接続の再確立の場合、対応する特定のプロパティデータレコードの前に、すべてのアクティブな共通プロパティがresする必要があります。
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 Observation Domains from the same Exporter MAY use the same commonPropertiesID value to refer to different sets of Common Properties.
CommonPropertiesIDは、観察ドメインと輸送セッションごとに局所的に一意の共通プロパティのセットの識別子です。エクスポートプロセスは、観測ドメインと輸送セッションのCommonPropertiesIDSの割り当てを管理する必要があります。同じ輸出業者からの異なる観測ドメインは、同じ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.
もはや使用されていないCommonPropertiesIDは撤回する必要があります。Common Propertiesの引き出しメッセージは、1つのスコープフィールド、つまりCommonPropertiesID（137 [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 = 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.
収集プロセスは、協会の期間中に一般的なPropertiesID情報を保存して、後続のデータセットで受信した対応するデータレコードを解釈できるようにする必要があります。
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を含むスコープを備えたオプションテンプレートレコードを受信します（つまり、SCTP協会で受信した同じ輸出者観測ドメインからCommonPropertiesID）。協会をシャットダウンします。
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アソシエーションが閉鎖された場合、収集プロセスは、その関連性を介して受信したすべての一般的なプロパリティサイドを破棄し、それらの一般的なPropertiesIDSを使用する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接続が優雅にまたは異常にリセットされている場合、収集プロセスは、その接続に対応するすべての一般的なPropertiesID値と関連する共通プロパティデータを削除する必要があります。
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.
フローレコードは、1つ以上の一般的なプロパティセットを指すことができます。複数の共通プロパティを使用すると、より効率的なエクスポートにつながる可能性があります。データで共通のプロパティのセットが識別されると、複数の非重複プロパティがあることがわかります。
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で構成されるプロパティD、DestinationAddressBとDestinationPortBで構成されるプロパティB、およびDestinationAddresscおよびDestinationPortcで構成されるプロパティCで構成されます。これらの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に示すように、エクスポート効率をさらに向上させるために、複数の一般的なプロパティ型インスタンスを使用することができます。
+--------------------------- + +---------------------+
| 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値を割り当てる必要があります。コレクターは、1つだけでなく2つのテンプレートで記述されたレコードを処理する必要があります。フローレコードを共通のプロパティ情報と相関させるために、測定データをポスト処理する場合には、追加の努力が必要です。
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の使用は、定期的にresする必要があるため、一般的な特性の伝達により効率が低いことに注意してください。
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値によって指定された情報が含まれるかどうかを予測することはできません。これは、この仕様の効率係数が、一元配置遅延や軌道サンプリングなど、フィルタリングが関与する特定のアプリケーションでより高いことを意味します。
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.
著者は、この作業を開始し、この文書の初期バージョンへの貢献についてGuido Pohlに感謝したいと思います。また、コメントとフィードバックをしてくれたアンドリュー・ジョンソン、ゲラード・ムエンツ、ブライアン・トラメル、ポール・エイトケンにも感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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.、Bryant、S.、Claise、B.、Aitken、P。、およびJ. Meyer、「IPフロー情報エクスポートの情報モデル」、RFC 5102、2008年1月。
[RFC5476] Claise, B., Ed., "Packet Sampling (PSAMP) Protocol Specifications", RFC 5476, March 2009.
[RFC5476] Claise、B.、ed。、「パケットサンプリング（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] Dietz、T.、ed。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.、Frederick、R。、およびV. Jacobson、「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] Stewart、R.、Ramalho、M.、Xie、Q.、Tuexen、M。、およびP. Conrad、「ストリーム制御伝送プロトコル（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. Zander、「IP Flow Information Export（IPFIX）の要件」、RFC 3917、2004年10月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R。、「Stream Control Transmission Protocol」、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.、Brownlee、N.、Claise、B。、およびJ. Quittek、「IPフロー情報エクスポートのアーキテクチャ」、RFC 5470、2009年3月。
[RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP Flow Information Export (IPFIX) Applicability", RFC 5472, March 2009.
[RFC5472] Zseby、T.、Boschi、E.、Brownlee、N。、およびB. Claise、「IP Flow Information Export（IPFIX）Applicability」、RFC 5472、2009年3月。
[RFC5474] Duffield, N., Ed., "A Framework for Packet Selection and Reporting", RFC 5474, March 2009.
[RFC5474] Duffield、N.、ed。、「パケット選択とレポートのフレームワーク」、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.、Molina、M.、Duffield、N.、Niccolini、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] Dietz、T.、Claise、B.、Aitken、P.、Dressler、F.、およびG. Carle、「パケットサンプリングエクスポートの情報モデル」、RFC 5477、2009年3月。
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.
このセクションでは、このドキュメントで説明した方法を使用して、フロー情報を効率的にエクスポートする方法を示します。2つのIPv6フローに関するデータを定期的にエクスポートする必要があるとしましょう。
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.
o 宛先IPv6アドレス：[RFC5102]のDestinationIPv6Address、28オクテットのタイプと長さ。
o The destination port: destinationTransportPort in [RFC5102], with a type of 11, and a length of 2 octets.
o 宛先ポート：[RFC5102]のDestinationTransportport、11のタイプと2オクテットの長さ。
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が含まれています。データレコードでは、このフィールドの値には、以前にエクスポートされたオプションレコードの一意のインデックスの1つが含まれます。次の情報要素が含まれています（図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.
o フローのパケットの数：[RFC5102]のInpacketdeltacount、4オクテットの長さ。
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:
この例の冒頭に示されているデータを考慮すると、次の2つのデータレコードがエクスポートされます。
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：一般的なプロパティを報告するデータレコード
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）がバインドされる特定のアプリケーションに対して測定されるため、これは特定のプロパティを持つ複数のパケットの観測に変換されます。両方の観測点で同一のパケットを一致させるために、一連のプロパティを備えた一連のパケット（たとえば、特定のソースおよび宛先IPアドレスのすべてのパケット、特定のDiffserv CodePoint（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をスコープとして使用したフローに関する情報を含むオプションテンプレートを示しています。Common Propertiesテンプレートでは、次の情報要素をエクスポートします。Oソース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アドレス：[RFC5102]のdestinationIPv4Address、12のタイプと4オクテットの長さ。
o The Class of Service field: ClassOfServiceIPv4 in [RFC5102], with a type of 5 and a length of 1 octet.
o サービスフィールドのクラス：[RFC5102]のClassOfServiceIPv4、5のタイプと1オクテットの長さ。
o The Protocol Identifier: protocolIdentifier in [RFC5102], with a type of 4 and a length of 1 octet.
o プロトコル識別子：[RFC5102]のプロトコリネディファイア、4のタイプと長さ1オクテット。
o The source port: sourceTransportPort in [RFC5102], with a type of 7 and a length of 2 octets.
o ソースポート：[RFC5102]のsourcetransportport、7と長さ2オクテット。
o The destination port: destinationTransportPort in [RFC5102], with a type of 11 and a length of 2 octets.
o 宛先ポート：[RFC5102]のDestinationTransportport、11のタイプと2オクテットの長さ。
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.
o CommonPropertiesID。この場合、縮小サイズのエンコードが使用され、情報要素は8ではなく4オクテットの長さで宣言されます。
o The packet timestamp: observationTimeMilliseconds in the PSAMP information model [RFC5477], with a type of 323 and a length of 8 octets.
o パケットタイムスタンプ：PSAMP情報モデル[RFC5477]の観察timemilliseconds、323のタイプと8オクテットの長さ。
o digestHashValue in the PSAMP information model [RFC5477], with a type of 326 and a length of 8 octets.
o PSAMP情報モデル[RFC5477]の消化障害、326のタイプと8オクテットの長さ。
o The packet length: ipTotalLength in the IPFIX information model [RFC5102], with a type of 224 and a length of 8 octets.
o パケットの長さ：IPFIX情報モデル[RFC5102]のIptotAllength、224のタイプと8オクテットの長さ。
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（2つの寄与パケットレコードのパケット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、destioningaddressv4 = 4、classofservicev4 = 1、protocolidentifier = 1、sourcetransportport = 2、destinationtransportport = 2、observationtimilliseconds = 8、Digesthashvalue = 8、iptotallength = 8）。IPFIXプロトコルオーバーヘッドを考慮せずに、1000パケットのフローは38000バイトの測定データを生成します。提案された最適化を使用して、各パケットはわずか28バイトのエクスポートを生成します（観察Timemilliseconds = 8、Digesthashvalue = 8、IptotAllength = 8、CommonPropertiesID = 4）。フロー情報のエクスポートは、18バイト（sourceaddressv4 = 4、destinationaddressv4 = 4、classofservicev4 = 1、protocolidentifier = 1、sourcetransportport = 2、destinationtransportport = 2、commonpropertiesid = 4）を生成します。1000パケットのフローの場合、これは28018バイトに合計されます。これは26％以上の減少です。
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
Elisa Boschi Hitachi Europe c/o eth zurich gloriastrasse 35 8092チューリッヒスイス
Phone: +41 44 6327057
EMail: elisa.boschi@hitachi-eu.com
Lutz Mark Fraunhofer IFAM Wiener Str. 12 28359 Bremen Germany
Lutz Mark Fraunhofer Ifam Wiener str。12 28359ブレーメンドイツ
Phone: +49 421 2246206
EMail: lutz.mark@ifam.fraunhofer.de
Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 Diegem 1813 Belgium
Benoit Claise Cisco Systems、Inc。De Kleetlaan 6a B1 Diegem 1813 Belgium
Phone: +32 2 704 5622
EMail: bclaise@cisco.com