[要約] 要約： RFC 7119は、IPFIXメディエータ上でのIP Flow Information Export（IPFIX）プロトコルの動作に関するガイドラインです。IPFIXメディエータの役割と機能を説明し、IPFIXデータの収集、処理、転送に関する手順を提供しています。目的： 1. IPFIXメディエータの役割と機能を理解する。 2. IPFIXデータの収集、処理、転送に関する手順を提供する。 3. IPFIXメディエータの適切な運用を確保するためのガイドラインを提供する。
Internet Engineering Task Force (IETF) B. Claise
Request for Comments: 7119 Cisco Systems, Inc.
Category: Standards Track A. Kobayashi
ISSN: 2070-1721 NTT
B. Trammell
ETH Zurich
February 2014
Operation of the IP Flow Information Export (IPFIX) Protocol on IPFIX Mediators
IPFIXメディエーターでのIPフロー情報エクスポート（IPFIX）プロトコルの操作
Abstract
概要
This document specifies the operation of the IP Flow Information Export (IPFIX) protocol specific to IPFIX Mediators, including Template and Observation Point management, timing considerations, and other Mediator-specific concerns.
このドキュメントでは、テンプレートと観測ポイントの管理、タイミングの考慮事項、およびその他のメディエーター固有の懸念事項を含む、IPFIXメディエーターに固有のIPフロー情報エクスポート（IPFIX）プロトコルの操作について説明します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7119.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7119で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
1.1. IPFIX Documents Overview ...................................3
1.2. IPFIX Mediator Documents Overview ..........................4
1.3. Relationship with the IPFIX and PSAMP Protocols ............5
2. Terminology .....................................................5
3. Handling IPFIX Message Headers ..................................8
4. Template Management ............................................10
4.1. Passing Unmodified Templates through an IPFIX Mediator ....11
4.1.1. Template Mapping and Information Element Ordering ..15
4.2. Creating New Templates at an IPFIX Mediator ...............17
4.3. Handling Unknown Information Elements .....................17
5. Preserving Original Observation Point Information ..............17
5.1. originalExporterIPv4Address Information Element ...........20
5.2. originalExporterIPv6Address Information Element ...........20
6. Managing Observation Domain IDs ................................20
6.1. originalObservationDomainId Information Element ...........21
7. Timing Considerations ..........................................21
8. Transport Considerations .......................................23
9. Collecting Process Considerations ..............................23
10. Specific Reporting Requirements ...............................23
10.1. Intermediate Process Reliability Statistics
Options Template .........................................24
10.2. Flow Key Options Template ................................26
10.3. intermediateProcessId Information Element ................26
10.4. ignoredDataRecordTotalCount Information Element ..........27
11. Operations and Management Considerations ......................27
12. Security Considerations .......................................28
13. IANA Considerations ...........................................28
14. Acknowledgments ...............................................29
15. References ....................................................29
15.1. Normative References .....................................29
15.2. Informative References ...................................30
The IPFIX architectural components in [RFC5470] consist of IPFIX Devices and IPFIX Collectors communicating using the IPFIX protocol [RFC7011], which specifies how to export IP Flow information. 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.).
[RFC5470]のIPFIXアーキテクチャコンポーネントは、IPFIXプロトコル[RFC7011]を使用して通信するIPFIXデバイスとIPFIXコレクターで構成され、IPフロー情報のエクスポート方法を指定します。このプロトコルは、IPトラフィックフローおよび関連する測定データに関する情報をエクスポートするように設計されています。フローは、一連の主要な属性（送信元と宛先のIPアドレス、送信元と宛先のポートなど）によって定義されます。
However, thanks to its Template mechanism, the IPFIX protocol can export any type of information, as long as the relevant Information Element is specified in the IPFIX Information Model [RFC7012], registered with IANA, or specified as an enterprise-specific Information Element. The IPFIX protocol [RFC7011] was not originally written with IPFIX Mediators in mind. Therefore, the IPFIX protocol must be adapted for Intermediate Processes, as defined in the IPFIX Mediation Reference Model as specified in Figure A of [RFC6183], which is based on the IPFIX Mediation Problem Statement [RFC5982].
ただし、テンプレートメカニズムのおかげで、IPFIXプロトコルは、関連する情報要素がIPFIX情報モデル[RFC7012]で指定されているか、IANAに登録されているか、企業固有の情報要素として指定されている限り、あらゆるタイプの情報をエクスポートできます。 IPFIXプロトコル[RFC7011]は、もともとIPFIXメディエーターを考慮して書かれていませんでした。したがって、[IPC調停問題ステートメント[RFC5982]に基づく[RFC6183]の図Aで指定されているIPFIX調停参照モデルで定義されているように、IPFIXプロトコルを中間プロセスに適合させる必要があります。
This document specifies the IP Flow Information Export (IPFIX) protocol in the context of the implementation and deployment of IPFIX Mediators. The use of the IPFIX protocol within an IPFIX Mediator -- a device that contains both a Collecting Process and an Exporting Process -- has an impact on the technical details of the usage of the protocol. An overview of the technical problem is covered in Section 6 of [RFC5982]: loss of original Exporter information, loss of base time information, transport sessions management, loss of Options Template Information, Template Id management, considerations for network topology, IPFIX mediation interpretation, and considerations for aggregation.
このドキュメントでは、IPFIX Mediatorの実装と展開のコンテキストでIPフロー情報エクスポート（IPFIX）プロトコルを指定します。 IPFIX Mediator（収集プロセスとエクスポートプロセスの両方を含むデバイス）内でIPFIXプロトコルを使用すると、プロトコルの使用法の技術的な詳細に影響を与えます。技術的な問題の概要は、[RFC5982]のセクション6で説明されています。元のエクスポーター情報の損失、ベースタイム情報の損失、トランスポートセッション管理、オプションテンプレート情報の損失、テンプレートID管理、ネットワークトポロジーに関する考慮事項、IPFIXメディエーション解釈、および集計に関する考慮事項。
The specifications in this document are based on the IPFIX protocol specifications [RFC7011], but they are adapted according to the IPFIX Mediation Framework [RFC6183].
このドキュメントの仕様はIPFIXプロトコル仕様[RFC7011]に基づいていますが、IPFIXメディエーションフレームワーク[RFC6183]に従って適合されています。
The IPFIX protocol [RFC7011] provides network administrators with access to IP Flow information.
IPFIXプロトコル[RFC7011]は、ネットワーク管理者にIPフロー情報へのアクセスを提供します。
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 the IPFIX Requirements document, [RFC3917].
IPFIXエクスポートプロセスから収集プロセスへの測定IPフロー情報のエクスポートのアーキテクチャは、IPFIX要件ドキュメント[RFC3917]で定義されている要件に従って、IPFIXアーキテクチャ[RFC5470]で定義されています。
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アーキテクチャ[RFC5470]は、IPFIXデータレコードとテンプレートが、IPFIXエクスポートプロセスからIPFIX収集プロセスへの輻輳認識トランスポートプロトコルを介してどのように運ばれるかを指定します。
IPFIX has a formal description of IPFIX Information Elements, their
names, types, and additional semantic information, as specified in
the IPFIX Information Model [RFC7012]. The IPFIX Information Element
registry [IANA-IPFIX] is maintained by IANA. New Information Element
definitions can be added to this registry subject to an Expert Review
[RFC5226], with additional process considerations described in
[RFC7013]; that document also provides guidelines for authors and
reviewers of new Information Element definitions. The inline export
of the Information Element type information is specified in
[RFC5610].
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の適用に関する声明[RFC5472]では、IPFIXプロトコルを使用できるアプリケーションの種類と、提供される情報をどのように使用できるかについて説明しています。さらに、IPFIXフレームワークが他のアーキテクチャーやフレームワークとどのように関連しているかを示しています。
"IP Flow Information Export (IPFIX) Mediation: Problem Statement" [RFC5982] provides an overview of the applicability of IPFIX Mediators and defines requirements for IPFIX Mediators in general terms. This document is of use largely to define the problems to be solved through the deployment of IPFIX Mediators and to provide scope to the role of IPFIX Mediators within an IPFIX collection infrastructure.
「IPフロー情報エクスポート（IPFIX）メディエーション：問題ステートメント」[RFC5982]は、IPFIXメディエーターの適用性の概要を提供し、一般的な用語でIPFIXメディエーターの要件を定義します。このドキュメントは、IPFIXメディエーターの展開を通じて解決される問題を定義し、IPFIX収集インフラストラクチャー内のIPFIXメディエーターの役割に範囲を提供するために主に使用されます。
"IP Flow Information Export (IPFIX) Mediation: Framework" [RFC6183], which details the IPFIX Mediation reference model and the components of an IPFIX Mediator, provides more architectural details of the arrangement of Intermediate Processes within an IPFIX Mediator.
「IPフロー情報エクスポート（IPFIX）メディエーション：フレームワーク」[RFC6183]では、IPFIXメディエーションの参照モデルとIPFIXメディエーターのコンポーネントについて詳しく説明し、IPFIXメディエーター内の中間プロセスの配置に関するアーキテクチャの詳細を提供します。
Documents specifying the operations of specific Intermediate Processes cover the operation of these Processes within the IPFIX Mediator framework and comply with the specifications given in this document; additionally, they may specify the operation of the process independently, outside the context of an IPFIX Mediator, when this is appropriate. The details of specific Intermediate Processes, when they have additional export specifications (e.g., metadata about the intermediate processing conveyed through IPFIX Options Templates), are each addressed in their own document. As of today, these documents are:
特定の中間プロセスの操作を指定するドキュメントは、IPFIX Mediatorフレームワーク内のこれらのプロセスの操作をカバーし、このドキュメントに記載されている仕様に準拠しています。さらに、適切な場合は、IPFIXメディエーターのコンテキスト外で、プロセスの操作を個別に指定できます。特定の中間プロセスの詳細は、追加のエクスポート仕様（IPFIXオプションテンプレートを介して伝達される中間処理に関するメタデータなど）がある場合、それぞれ独自のドキュメントで扱われます。現在、これらのドキュメントは次のとおりです。
1. "IP Flow Anonymization Support", [RFC6235], which describes anonymization techniques for IP flow data and the export of anonymized data using the IPFIX protocol.
1. 「IP Flow Anonymization Support」、[RFC6235]。IPフローデータの匿名化手法と、IPFIXプロトコルを使用した匿名化データのエクスポートについて説明しています。
2. "Flow Selection Techniques" [RFC7014], which describes the process of selecting a subset of Flows from all Flows observed at an Observation Point, the flow selection motivations, and some specific flow selection techniques.
2. 「フロー選択手法」[RFC7014]。観測ポイントで観測されたすべてのフローからフローのサブセットを選択するプロセス、フロー選択の動機、およびいくつかの特定のフロー選択手法について説明しています。
3. "Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol" [RFC7015], which describes Aggregated Flow export within the framework of IPFIX Mediators and defines an interoperable, implementation-independent method for Aggregated Flow export.
3. 「IPフロー情報エクスポート（IPFIX）プロトコルのフロー集約」[RFC7015]。IPFIXメディエーターのフレームワーク内の集約フローエクスポートについて説明し、集約フローエクスポートの相互運用可能な実装に依存しない方法を定義します。
This document specifies the IP Flow Information Export (IPFIX) protocol specific to Mediation, to which all Intermediate Processes must comply. Some extra specifications might be required per Intermediate Process type (in which case, the document specific to the Intermediate Process would apply).
このドキュメントでは、すべての中間プロセスが準拠する必要のある、メディエーションに固有のIPフロー情報エクスポート（IPFIX）プロトコルを指定します。中間プロセスタイプごとに追加の仕様が必要になる場合があります（この場合、中間プロセスに固有のドキュメントが適用されます）。
The specification in this document is based on the IPFIX protocol specification [RFC7011]. All specifications from [RFC7011] apply unless specified otherwise in this document.
このドキュメントの仕様は、IPFIXプロトコル仕様[RFC7011]に基づいています。このドキュメントで特に指定されていない限り、[RFC7011]のすべての仕様が適用されます。
As the Packet Sampling (PSAMP) protocol specifications [RFC5476] are based on the IPFIX protocol specifications, the specifications in this document are also valid for the PSAMP protocol. Therefore, the method specified by this document also applies to PSAMP.
パケットサンプリング（PSAMP）プロトコル仕様[RFC5476]はIPFIXプロトコル仕様に基づいているため、このドキュメントの仕様はPSAMPプロトコルにも有効です。したがって、このドキュメントで指定されている方法はPSAMPにも適用されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[RFC2119]で説明されているように解釈されます。
IPFIX-specific terms, such as Observation Domain, Flow, Flow Key, Metering Process, Exporting Process, Exporter, IPFIX Device, Collecting Process, Collector, Template, IPFIX Message, Message Header, Template Record, Data Record, Options Template Record, Set, Data Set, Information Element, Scope and Transport Session, used in this document are defined in [RFC7011]. The PSAMP-specific terms used in this document, such as Filtering and Sampling, are defined in [RFC5476].
観測ドメイン、フロー、フローキー、計測プロセス、エクスポートプロセス、エクスポーター、IPFIXデバイス、収集プロセス、コレクター、テンプレート、IPFIXメッセージ、メッセージヘッダー、テンプレートレコード、データレコード、オプションテンプレートレコード、セットなどのIPFIX固有の用語、データセット、情報要素、スコープ、およびこのドキュメントで使用されるトランスポートセッションは、[RFC7011]で定義されています。このドキュメントで使用されている、フィルタリングやサンプリングなどのPSAMP固有の用語は、[RFC5476]で定義されています。
IPFIX Mediation terms related to aggregation, such as the Interval, Aggregated Flow and Aggregated Function, are defined in [RFC7015].
インターバル、集約フロー、集約関数など、集約に関連するIPFIXメディエーション用語は、[RFC7015]で定義されています。
The terminology specific to IPFIX Mediation that is used in this document is defined in "IP Flow Information Export (IPFIX) Mediation: Problem Statement" [RFC5982] and reused in "IP Flow Information Export (IPFIX) Mediation: Framework" [RFC6183]. However, since both of those documents are Informational RFCs, the definitions have been reproduced and elaborated on here.
このドキュメントで使用されているIPFIXメディエーションに固有の用語は、「IPフロー情報エクスポート（IPFIX）メディエーション：問題ステートメント」[RFC5982]で定義され、「IPフロー情報エクスポート（IPFIX）メディエーション：フレームワーク」[RFC6183]で再利用されています。ただし、これらのドキュメントはどちらも情報RFCであるため、ここで定義が再現され、詳しく説明されています。
Similarly, since [RFC6235] is an Experimental RFC, the Anonymization Record, Anonymized Data Record, and Intermediate Anonymization Process terms, specified in [RFC6235], are also reproduced here.
同様に、[RFC6235]は試験的なRFCであるため、[RFC6235]で指定されている匿名化レコード、匿名化データレコード、および中間匿名化プロセスの用語もここで再現されます。
In this document, as in [RFC7011], [RFC5476], [RFC7015], and [RFC6235], the first letter of each IPFIX-specific and PSAMP-specific term is capitalized along with the IPFIX Mediation-specific term defined here.
このドキュメントでは、[RFC7011]、[RFC5476]、[RFC7015]、および[RFC6235]のように、各IPFIX固有およびPSAMP固有の用語の最初の文字が、ここで定義されているIPFIXメディエーション固有の用語とともに大文字になっています。
In this document, we call a stream of records carrying flow- or packet-based information a "record stream". The records may be encoded as IPFIX Data Records or any other format.
このドキュメントでは、フローベースまたはパケットベースの情報を運ぶレコードのストリームを「レコードストリーム」と呼びます。レコードは、IPFIXデータレコードまたはその他の形式でエンコードできます。
Transport Session: The Transport Session is specified in [RFC7011]. In Stream Control Transmission Protocol (SCTP), the Transport Session information is the SCTP association. In TCP and UDP, the Transport Session information corresponds to a 5-tuple {Exporter IP address, Collector IP address, Exporter transport port, Collector transport port, transport protocol}.
輸送セッション：輸送セッションは[RFC7011]で指定されます。ストリーム制御伝送プロトコル（SCTP）では、トランスポートセッション情報はSCTPアソシエーションです。 TCPおよびUDPでは、トランスポートセッション情報は5タプル{エクスポーターIPアドレス、コレクターIPアドレス、エクスポータートランスポートポート、コレクタートランスポートポート、トランスポートプロトコル}に対応します。
Original Exporter: An Original Exporter is the source from which a Mediator receives its record stream. For simple IPFIX mediation without protocol conversion, this is an IPFIX Device that hosts the Observation Points where the metered IP packets are observed.
元のエクスポーター：元のエクスポーターは、メディエーターがレコードストリームを受け取るソースです。プロトコル変換なしの単純なIPFIXメディエーションの場合、これは、計測されたIPパケットが監視される監視ポイントをホストするIPFIXデバイスです。
Original Observation Point: An Observation Point on a Metering Process associated with the Original Exporter. In the case of the Intermediate Aggregation Process on an IPFIX Mediator, the Original Observation Point can be composed of, but not limited to, a (set of) specific Exporter(s), a (set of) specific interface(s) on an Exporter, a (set of) line card(s) on an Exporter, or any combinations of these.
元の観測ポイント：元のエクスポーターに関連付けられた測定プロセスの観測ポイント。 IPFIXメディエーターでの中間集約プロセスの場合、元の観測ポイントは、特定のエクスポーター（のセット）、特定のインターフェース（のセット）で構成できますが、これらに限定されません。エクスポーター、エクスポーターの（一連の）ラインカード、またはこれらの任意の組み合わせ。
IPFIX Mediation: IPFIX Mediation is the manipulation and conversion of a record stream for subsequent export using the IPFIX protocol.
IPFIXメディエーション：IPFIXメディエーションは、IPFIXプロトコルを使用して後でエクスポートするためのレコードストリームの操作と変換です。
Template Mapping: A mapping from Template Records and/or Options Template Records received by an IPFIX Mediator to Template Records and/or Options Template Records sent by that IPFIX Mediator. Each entry in a Template Mapping is scoped by incoming or outgoing Transport Session and Observation Domain, as with Templates and Options Templates in the IPFIX Protocol.
テンプレートマッピング：IPFIXメディエーターが受信したテンプレートレコードやオプションテンプレートレコードから、そのIPFIXメディエーターが送信したテンプレートレコードやオプションテンプレートレコードへのマッピング。テンプレートマッピングの各エントリは、IPFIXプロトコルのテンプレートおよびオプションテンプレートと同様に、着信または発信トランスポートセッションおよび監視ドメインによってスコープが設定されます。
Anonymization Record: A record that defines the properties of the anonymization applied to a single Information Element within a single Template or Options Template, as in [RFC6235].
匿名化レコード：[RFC6235]のように、単一のテンプレートまたはオプションテンプレート内の単一の情報要素に適用される匿名化のプロパティを定義するレコード。
Anonymized Data Record: A Data Record within a Data Set containing at least one Information Element with anonymized values. The Information Element(s) within the Template or Options Template describing this Data Record SHOULD have a corresponding Anonymization Record, as in [RFC6235].
匿名化されたデータレコード：匿名化された値を持つ少なくとも1つの情報要素を含むデータセット内のデータレコード。このデータレコードを記述するテンプレートまたはオプションテンプレート内の情報要素には、[RFC6235]のように、対応する匿名化レコードが必要です（SHOULD）。
The following terms are used in this document to describe the architectural entities used by IPFIX Mediation.
このドキュメントでは、IPFIXメディエーションで使用されるアーキテクチャエンティティを説明するために、次の用語が使用されています。
Intermediate Process: An Intermediate Process takes a record stream as its input from Collecting Processes, Metering Processes, IPFIX File Readers, other Intermediate Processes, or other record sources; performs some transformations on this stream, based upon the content of each record, states maintained across multiple records, or other data sources; and passes the transformed record stream as its output to Exporting Processes, IPFIX File Writers, or other Intermediate Processes, in order to perform IPFIX Mediation. Typically, an Intermediate Process is hosted by an IPFIX Mediator. Alternatively, an Intermediate Process may be hosted by an Original Exporter.
中間プロセス：中間プロセスは、収集プロセス、メータリングプロセス、IPFIXファイルリーダー、その他の中間プロセス、またはその他のレコードソースからの入力としてレコードストリームを受け取ります。各レコードのコンテンツ、複数のレコードにわたって維持されている状態、またはその他のデータソースに基づいて、このストリームに対していくつかの変換を実行します。 IPFIXメディエーションを実行するために、変換されたレコードストリームをその出力としてエクスポートプロセス、IPFIXファイルライター、またはその他の中間プロセスに渡します。通常、中間プロセスはIPFIXメディエーターによってホストされます。あるいは、中間プロセスは、元のエクスポーターによってホストされる場合があります。
IPFIX Mediator: An IPFIX Mediator is an IPFIX Device that provides IPFIX Mediation by receiving a record stream from some data sources, hosting one or more Intermediate Processes to transform that stream, and exporting the transformed record stream into IPFIX Messages via an Exporting Process. In the common case, an IPFIX Mediator receives a record stream from a Collecting Process, but it could also receive a record stream from data sources not encoded using IPFIX, e.g., in the case of conversion from the NetFlow V9 protocol [RFC3954] to IPFIX protocol.
IPFIXメディエーター：IPFIXメディエーターは、一部のデータソースからレコードストリームを受信し、そのストリームを変換する1つ以上の中間プロセスをホストし、変換されたレコードストリームをエクスポートプロセスを介してIPFIXメッセージにエクスポートすることにより、IPFIXメディエーションを提供するIPFIXデバイスです。一般的なケースでは、IPFIXメディエーターは収集プロセスからレコードストリームを受信しますが、IPFIXを使用してエンコードされていないデータソースからレコードストリームを受信することもできます（例：NetFlow V9プロトコル[RFC3954]からIPFIXへの変換の場合）。プロトコル。
Specific Intermediate Processes are described below.
特定の中間プロセスを以下に説明します。
Intermediate Conversion Process (as in [RFC6183]): An Intermediate Conversion Process is an Intermediate Process that transforms non-IPFIX into IPFIX or manages the relation among Templates and states of incoming/outgoing Transport Sessions in the case of transport protocol conversion (e.g., from UDP to SCTP).
中間変換プロセス（[RFC6183]と同様）：中間変換プロセスは、非IPFIXをIPFIXに変換したり、トランスポートプロトコル変換（例： UDPからSCTPへ）。
Intermediate Aggregation Process (as in [RFC7015]): an Intermediate Process (IAP), as in [RFC6183], that aggregates records, based upon a set of Flow Keys or functions applied to fields from the record.
中間集約プロセス（[RFC7015]など）：レコードのフィールドに適用される一連のフローキーまたは関数に基づいてレコードを集約する[RFC6183]のような中間プロセス（IAP）。
Intermediate Correlation Process (as in [RFC6183]): An Intermediate Correlation Process is an Intermediate Process that adds information to records, noting correlations among them, or generates new records with correlated data from multiple records (e.g., the production of bidirectional flow records from unidirectional flow records).
中間相関プロセス（[RFC6183]のように）：中間相関プロセスは、レコード間の相関を記録する情報をレコードに追加するか、複数のレコードから相関データを使用して新しいレコードを生成する中間プロセスです（たとえば、からの双方向フローレコードの生成）。単方向フローレコード）。
Intermediate Anonymization Process (as in [RFC6235]): An intermediate process that takes Data Records and transforms them into Anonymized Data Records.
中間匿名化プロセス（[RFC6235]のように）：データレコードを取得して匿名化データレコードに変換する中間プロセス。
Intermediate Selection Process (as in [RFC6183]): An Intermediate Selection Process is an Intermediate Process that selects records from a sequence based upon criteria-evaluated record values and passes only those records that match the criteria (e.g., Filtering only records from a given network to a given Collector).
中間選択プロセス（[RFC6183]のように）：中間選択プロセスは、基準から評価されたレコード値に基づいてシーケンスからレコードを選択し、基準に一致するレコードのみを渡す中間プロセスです（たとえば、特定の特定のコレクタへのネットワーク）。
Intermediate Flow Selection Process (as in [RFC7014]: An Intermediate Flow Selection Process is an Intermediate Process, as in [RFC6183] that takes Flow Records as its input and selects a subset of this set as its output. The Intermediate Flow Selection Process is a more general concept than the Intermediate Selection Process as defined in [RFC6183]. While an Intermediate Selection Process selects Flow Records from a sequence based upon criteria-evaluated Flow record values and only passes on those Flow Records that match the criteria, an Intermediate Flow Selection Process selects Flow Records using selection criteria applicable to a larger set of Flow characteristics and information.
中間フロー選択プロセス（[RFC7014]など）：中間フロー選択プロセスは、[RFC6183]のように、フローレコードを入力として受け取り、このセットのサブセットを出力として選択する中間プロセスです。中間フロー選択プロセスは、 [RFC6183]で定義されている中間選択プロセスよりも一般的なコンセプトです。中間選択プロセスは、基準から評価されたフローレコード値に基づいてシーケンスからフローレコードを選択し、基準に一致するフローレコードのみを渡しますが、中間フロー選択プロセスは、フローの特性と情報のより大きなセットに適用可能な選択基準を使用してフローレコードを選択します。
Note: for more information on the difference between Intermediate Flow Selection Process and Intermediate Selection Process, see Section 4 in [RFC7014].
注：中間フロー選択プロセスと中間選択プロセスの違いの詳細については、[RFC7014]のセクション4をご覧ください。
The format of the IPFIX Message Header as exported by an IPFIX Mediator is shown in Figure 1. This is identical to the format defined for IPFIX in [RFC7011], though Export Time and Observation Domain ID may be handled differently at certain Mediators, as noted below.
IPFIXメディエーターによってエクスポートされたIPFIXメッセージヘッダーのフォーマットを図1に示します。これは、[RFC7011]でIPFIXに対して定義されたフォーマットと同じですが、エクスポート時間と監視ドメインIDは特定のメディエーターで異なる方法で処理される場合があります未満。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Export Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Observation Domain ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: IPFIX Message Header format
図1：IPFIXメッセージヘッダーの形式
The header fields as exported by an IPFIX Mediator are described below.
IPFIX Mediatorによってエクスポートされるヘッダーフィールドについては、以下で説明します。
Version:
バージョン：
Version of IPFIX to which this Message conforms. The value of this field is 0x000a for the current version, incrementing by one the version used in the NetFlow services export version 9 [RFC3954].
このメッセージが準拠するIPFIXのバージョン。このフィールドの値は、現在のバージョンでは0x000aであり、NetFlowサービスエクスポートバージョン9 [RFC3954]で使用されているバージョンを1つ増やします。
Length:
長さ：
Total length of the IPFIX Message, measured in octets, including Message Header and Set(s).
IPFIXメッセージの全長（メッセージヘッダーとセットを含む、オクテットで測定）。
Export Time:
エクスポート時間：
Time at which the IPFIX Message Header leaves the IPFIX Mediator, expressed in seconds since the UNIX epoch of 1 January 1970 at 00:00 UTC, encoded as an unsigned 32-bit integer.
IPFIXメッセージヘッダーがIPFIXメディエーターを離れる時刻。1970年1月1日の00:00 UTCのUNIXエポックからの秒数で表され、符号なし32ビット整数としてエンコードされます。
However, in the specific case of an IPFIX Mediator containing an Intermediate Conversion Process, the IPFIX Mediator MAY use the export time received from the incoming Transport Session.
ただし、中間変換プロセスを含むIPFIXメディエーターの特定のケースでは、IPFIXメディエーターは、着信トランスポートセッションから受信したエクスポート時間を使用できます（MAY）。
Sequence Number:
シーケンス番号：
Incremental sequence counter modulo 2^32 of all IPFIX Data Records sent in the current stream from the current Observation Domain by the Exporting Process. Each SCTP Stream counts sequence numbers separately, while all messages in a TCP connection or UDP Transport Session are considered to be part of the same stream. This value can be used by the Collecting Process to identify whether any IPFIX Data Records have been missed. Template and Options Template Records do not increase the Sequence Number.
エクスポートプロセスによって現在の観測ドメインから現在のストリームで現在のストリームで送信されたすべてのIPFIXデータレコードの2 ^ 32を法とする増分シーケンスカウンター。各SCTPストリームはシーケンス番号を個別にカウントしますが、TCP接続またはUDPトランスポートセッションのすべてのメッセージは同じストリームの一部と見なされます。収集プロセスはこの値を使用して、IPFIXデータレコードが失われたかどうかを識別できます。テンプレートとオプションテンプレートレコードはシーケンス番号を増やしません。
Observation Domain ID:
観測ドメインID：
A 32-bit identifier of the Observation Domain that is locally unique to the Exporting Process. The Exporting Process uses the Observation Domain ID to uniquely identify to the Collecting Process the Observation Domain that metered the Flows. It is RECOMMENDED that this identifier also be unique per IPFIX Device. Collecting Processes can use the Transport Session and the Observation Domain ID field to separate different export streams originating from the same Exporter. The Observation Domain ID is set to 0 when no specific Observation Domain ID is relevant for the entire IPFIX Message, for example, when exporting the Exporting Process Statistics, or in case of a hierarchy of Collectors when aggregated Data Records are exported.
ローカルでエクスポートプロセスに固有の監視ドメインの32ビットの識別子。エクスポートプロセスは、観測ドメインIDを使用して、フローを計測した観測ドメインを収集プロセスに対して一意に識別します。この識別子もIPFIXデバイスごとに一意であることが推奨されます。収集プロセスは、トランスポートセッションと監視ドメインIDフィールドを使用して、同じエクスポーターから発信された異なるエクスポートストリームを分離できます。監視ドメインIDは、IPFIXメッセージ全体に関連する特定の監視ドメインIDがない場合、たとえば、エクスポートプロセス統計をエクスポートする場合、または集約されたデータレコードがエクスポートされる場合にコレクターの階層の場合、0に設定されます。
See Section 4.1 for special considerations for Observation Domain management while passing unmodified templates through an IPFIX Mediator, and Section 5 for guidelines for preservation of original Observation Domain information at an IPFIX Mediator.
変更されていないテンプレートをIPFIXメディエーターを介して渡す際の観測ドメイン管理に関する特別な考慮事項についてはセクション4.1を、IPFIXメディエーターで元の観測ドメイン情報を保持するためのガイドラインについてはセクション5を参照してください。
The following specifications, copied over from [RFC7011] have some implications in this document:
[RFC7011]からコピーされた次の仕様は、このドキュメントにいくつかの意味があります。
Template Withdrawals MAY appear interleaved with Template Sets, Options Template Sets, and Data Sets within an IPFIX Message. In this case, the Templates and Template Withdrawals shall be interpreted as taking effect in the order in which they appear in the IPFIX Message.
テンプレートの引き出しは、IPFIXメッセージ内のテンプレートセット、オプションテンプレートセット、およびデータセットと交互に表示される場合があります。この場合、テンプレートとテンプレートの引き出しは、IPFIXメッセージに表示される順序で有効になると解釈されます。
If an IPFIX Mediator receives an IPFIX Message composed of Template Withdrawals and Template Sets, and if the IPFIX Mediator forwards this IPFIX Message, it MUST NOT modify the Set order. If an IPFIX Mediator receives IPFIX Messages composed of Template Withdrawals and Template Sets, and if the IPFIX Mediator forwards these IPFIX Messages, it MUST NOT modify the IPFIX Message order. Note that the Template Mapping (see Section 4.1) is the authoritative source of information on the IPFIX Mediator to decide whether the entire IPFIX Messages can be forwarded as such.
IPFIXメディエーターがテンプレートの撤回とテンプレートセットで構成されるIPFIXメッセージを受信し、IPFIXメディエーターがこのIPFIXメッセージを転送する場合、セットの順序を変更してはなりません。 IPFIXメディエーターがテンプレートの取り消しとテンプレートセットで構成されるIPFIXメッセージを受信し、IPFIXメディエーターがこれらのIPFIXメッセージを転送する場合、IPFIXメッセージの順序を変更してはなりません。テンプレートマッピング（セクション4.1を参照）は、IPFIXメッセージ全体をそのように転送できるかどうかを決定するIPFIXメディエーターに関する信頼できる情報源であることに注意してください。
How an IPFIX Mediator handles the Templates it receives from the Original Exporter depends entirely on the nature of the Intermediate Process running on that IPFIX Mediator. There are two cases here:
IPFIXメディエーターが元のエクスポーターから受け取ったテンプレートを処理する方法は、そのIPFIXメディエーターで実行されている中間プロセスの性質に完全に依存します。ここには2つのケースがあります。
1. IPFIX Mediators that pass substantially the same Data Records from the Original Exporter downstream (e.g., an Intermediate Selection Process), pass unmodified Templates as described in Section 4.1; this section describes a Template Mapping required to make this work in the general case, and the correlation between the received and generated IPFIX Message Withdrawals.
1. 元のエクスポーターから実質的に同じデータレコードをダウンストリーム（中間選択プロセスなど）に渡すIPFIXメディエーターは、セクション4.1で説明されているように、変更されていないテンプレートを渡します。このセクションでは、一般的なケースでこれを機能させるために必要なテンプレートマッピング、および受信したIPFIXメッセージと生成されたIPFIXメッセージの引き出しの間の相関について説明します。
2. IPFIX Mediators that export Data Records that are substantially changed from the Data Records received from the Original Exporter follow the guidelines in Section 4.2 instead: in this case, the IPFIX Mediator generates new (Options) Template Records as a result of the Intermediate Process, and no Template Mapping is required.
2. 元のエクスポーターから受信したデータレコードから大幅に変更されたデータレコードをエクスポートするIPFIXメディエーターは、代わりにセクション4.2のガイドラインに従います。この場合、IPFIXメディエーターは、中間プロセスの結果として新しい（オプション）テンプレートレコードを生成します。テンプレートマッピングは必要ありません。
Subsequent subsections deal with specific issues in Template management that may occur at IPFIX Mediators.
後続のサブセクションでは、IPFIXメディエーターで発生する可能性があるテンプレート管理の特定の問題を扱います。
For some Intermediate Processes, the IPFIX Mediator doesn't modify the (Options) Template Record(s) content. A typical example is an Intermediate Flow Selection Process acting as distributor, which collects Flow Records from one or more Exporters, and based on the content of the Information Elements, redirects the Flow Records to the appropriate Collector. This example is a typical case of a single network operation center managing multiple universities: a unique IPFIX Collector collects all Flow Records for the common infrastructure, but might be re-exporting specific university Flow Records to the responsible system administrator.
一部の中間プロセスでは、IPFIXメディエーターは（オプション）テンプレートレコードのコンテンツを変更しません。典型的な例は、ディストリビューターとして機能する中間フロー選択プロセスであり、1つ以上のエクスポーターからフローレコードを収集し、情報要素のコンテンツに基づいて、フローレコードを適切なコレクターにリダイレクトします。この例は、複数の大学を管理する単一のネットワークオペレーションセンターの典型的なケースです。固有のIPFIXコレクターが共通インフラストラクチャのすべてのフローレコードを収集しますが、特定の大学フローレコードを責任のあるシステム管理者に再エクスポートする場合があります。
As specified in [RFC7011], the Template IDs are unique per Exporter, per Transport Session, and per Observation Domain. As there is no guarantee that, for similar Template Records, the Template IDs received on the incoming Transport Session and exported to the outgoing Transport Session would be same, the IPFIX Mediator MUST maintain a Template Mapping composed of related received and exported (Options) Template Records:
[RFC7011]で指定されているように、テンプレートIDは、エクスポーターごと、トランスポートセッションごと、および観測ドメインごとに一意です。同様のテンプレートレコードについて、着信トランスポートセッションで受信され、発信トランスポートセッションにエクスポートされるテンプレートIDが同じであるという保証はないため、IPFIXメディエーターは、関連する受信およびエクスポートされた（オプション）テンプレートで構成されるテンプレートマッピングを維持する必要があります。記録：
o for each received (Options) Template Record: Template Record Information Elements, Template ID, Observation Domain ID, and Transport Session information, metadata scoped to the Template (*)
o 受信した各（オプション）テンプレートレコード：テンプレートレコード情報要素、テンプレートID、監視ドメインID、およびトランスポートセッション情報、テンプレートにスコープされたメタデータ（*）
o for each exported (Options) Template Record: Template Record Information Elements, Template ID, Collector, Observation Domain ID, and Transport Session information metadata scoped to the Template (*)
o エクスポートされた各（オプション）テンプレートレコード：テンプレートレコード情報要素、テンプレートID、コレクター、観測ドメインID、およびテンプレートにスコープされたトランスポートセッション情報メタデータ（*）
(*) The "metadata scoped to the Template" encompasses the metadata, that are scoped to the Template, and that help to determine the semantics of the Template Record. Note that these metadata are typically sent in Data Records described by an Options Template. An example is the flowKeyIndicator. An IPFIX Mediator could potentially receive two different Template IDs, from the same Exporter, with the same Information Elements, but with a different set of Flow Keys (indicated by the flowKeyIndicator in an Options Template Record). Another example is the combination of anonymizationFlags and anonymizationTechnique [RFC6235]). This metadata information must be present in the Template Mapping, to stress that the two Template Record semantics are different.
（*）「テンプレートを範囲とするメタデータ」には、テンプレートを範囲とするメタデータが含まれ、テンプレートレコードのセマンティクスを決定するのに役立ちます。これらのメタデータは通常、オプションテンプレートによって記述されたデータレコードで送信されることに注意してください。例は、flowKeyIndicatorです。 IPFIXメディエーターは、同じエクスポーターから2つの異なるテンプレートIDを受け取る可能性がありますが、情報要素は同じですが、フローキーのセットが異なります（オプションテンプレートレコードのflowKeyIndicatorで示されます）。別の例は、anonymizationFlagsとanonymizationTechnique [RFC6235]の組み合わせです）。このメタデータ情報は、2つのテンプレートレコードのセマンティクスが異なることを強調するために、テンプレートマッピングに存在している必要があります。
If an IPFIX Mediator receives an IPFIX Withdrawal Message for a (Options) Template Record that is not used anymore in any other Template Mappings, the IPFIX Mediator SHOULD export the appropriate IPFIX Withdrawal Message(s) on the outgoing Transport Session and remove the corresponding entry in the Template Mapping.
IPFIXメディエーターが、他のテンプレートマッピングで使用されなくなった（オプション）テンプレートレコードのIPFIX取り消しメッセージを受信した場合、IPFIXメディエーターは、送信トランスポートセッションで適切なIPFIX取り消しメッセージをエクスポートし、対応するエントリを削除する必要があります（SHOULD）。テンプレートマッピングで。
If a (Options) Template Record is not used anymore in an outgoing Transport Session, it MUST be withdrawn with an IPFIX Template Withdrawal Message on that specific outgoing Transport Session, and its entry, MUST be removed from the Template Mapping.
（オプション）テンプレートレコードが発信トランスポートセッションで使用されなくなった場合は、その特定の発信トランスポートセッションでIPFIXテンプレート撤回メッセージを使用して撤回する必要があり、そのエントリはテンプレートマッピングから削除する必要があります。
If an incoming or outgoing Transport Session is gracefully shut down or reset, the (Options) Template Records corresponding to that Transport Session MUST be removed from the Template Mapping.
着信または発信トランスポートセッションが正常にシャットダウンまたはリセットされた場合、そのトランスポートセッションに対応する（オプション）テンプレートレコードをテンプレートマッピングから削除する必要があります。
For example, Figure 2 displays an example of an Intermediate Flow Selection Process, redistributing Data Records to Collectors on the basis of customer networks, i.e., the Route Distinguisher (RD). In this example, the Template Record received from the Exporter #1 is reused towards Collector #1, Collector #2, and Collector #3, for the customer #1, customer #2, and customer #3, respectively. In this example, the outgoing Template Records exported to the different Collectors are identical. As a reminder that the Template ID uniqueness is local to the Transport Session and Observation Domain that generated the Template ID, a mix of Template ID 256 and 257 has been used.
たとえば、図2は、中間フローの選択プロセスの例を示しており、顧客ネットワーク、つまりルート識別子（RD）に基づいてデータレコードをコレクターに再配布しています。この例では、エクスポーター＃1から受け取ったテンプレートレコードは、顧客＃1、顧客＃2、顧客＃3のそれぞれに対して、コレクタ＃1、コレクタ＃2、コレクタ＃3に向けて再利用されます。この例では、異なるコレクターにエクスポートされる送信テンプレートレコードは同一です。テンプレートIDの一意性は、テンプレートIDを生成したトランスポートセッションおよび監視ドメインに対してローカルであることを思い出させるため、テンプレートID 256と257の組み合わせが使用されています。
.---------.
Tmpl. | |
ID .---->|Collector|<==>Customer 1
256 | | #1 |
| | |
RD=100:1 '---------'
.--------. .--------. |
| | Tmpl. | |----'
| | Id | | .---------.
| | 258 | | RD=100:2 | |
| IPFIX |------->| IPFIX |--------->|Collector|<==>Customer 2
|Exporter| |Mediator| Tmpl. | #2 |
| #1 | | | ID 257 | |
| | | | '---------'
| | | |----.
'--------' '--------' |
RD=100:3
| .---------.
Tmpl. | | |
ID '---->|Collector|<==>Customer 3
257 | #3 |
| |
'---------'
Figure 2: Intermediate Flow Selection Process Example
図2：中間フロー選択プロセスの例
Figure 3 shows the Template Mapping for the system shown in Figure 2.
図3は、図2に示したシステムのテンプレートマッピングを示しています。
+-----------------------------------------------------------------+
| Template Entry A: |
| Incoming Transport Session information (from Exporter#1): |
| Source IP: <Exporter#1 export IP address> |
| Destination IP: <IPFIX Mediator IP address> |
| Protocol: SCTP |
| Source Port: <source port> |
| Destination Port: 4739 (IPFIX) |
| Observation Domain ID: <Observation Domain ID> |
| Template ID: 258 |
| Metadata scoped to the Template : <not applicable in this case> |
| |
| Template Entry B: |
| Outgoing Transport Session information (to Collector#1): |
| Source IP: <IPFIX Mediator IP address> |
| Destination IP: <IPFIX Collector#1 IP address> |
| Protocol: SCTP |
| Source Port: <source port> |
| Destination Port: 4739 (IPFIX) |
| Observation Domain ID: <Observation Domain ID> |
| Template ID: 256 |
| Metadata scoped to the Template : <not applicable in this case> |
| |
| Template Entry C: |
| Outgoing Transport Session information (to Collector#2): |
| Source IP: <IPFIX Mediator IP address> |
| Destination IP: <IPFIX Collector#2 IP address> |
| Protocol: SCTP |
| Source Port: <source port> |
| Destination Port: 4739 (IPFIX) |
| Observation Domain ID: <Observation Domain ID> |
| Template ID: 257 |
| Metadata scoped to the Template : <not applicable in this case> |
| |
| Template Entry D: |
| Outgoing Transport Session information (to Collector#3): |
| Source IP: <IPFIX Mediator IP address> |
| Destination IP: <IPFIX Collector#3 IP address> |
| Protocol: SCTP |
| Source Port: <source port> |
| Destination Port: 4739 (IPFIX) |
| Observation Domain ID: <Observation Domain ID> |
| Template ID: 257 |
| Metadata scoped to the Template : <not applicable in this case> |
+-----------------------------------------------------------------+
Figure 3: Template Mapping Example: Templates
図3：テンプレートマッピングの例：テンプレート
The Template Mapping corresponding to Figure 3 is displayed in Figure 4:
図3に対応するテンプレートマッピングを図4に示します。
Template Entry A <----> Template Entry B
Template Entry A <----> Template Entry C
Template Entry A <----> Template Entry D
Figure 4: Template Mapping Example: Mappings
図4：テンプレートマッピングの例：マッピング
Alternatively, the Template Mapping may be optimized as in Figure 5:
あるいは、図5のようにテンプレートマッピングを最適化することもできます。
+--> Template Entry B
|
Template Entry A <--+--> Template Entry C
|
+--> Template Entry D
Figure 5: Template Mapping Example 2: Mappings
図5：テンプレートマッピングの例2：マッピング
Note that all examples use Transport Sessions based on the SCTP, as simplified use cases. However, the transport protocol would be important in situations such as an Intermediate Conversion Process doing transport protocol conversion.
すべての例では、簡略化された使用例として、SCTPに基づくトランスポートセッションを使用していることに注意してください。ただし、トランスポートプロトコルは、トランスポートプロトコルの変換を行う中間変換プロセスなどの状況では重要です。
In the situation where Original Exporters each export an (Options) Template Record to a single IPFIX Mediator, and the (Options) Template Record contains the same Information Elements, but in different order, should the IPFIX Mediator maintain a Template Mapping with a single Export Template Record (see Figure 6) or should the IPFIX Mediator maintain multiple independent Template Records (see Figure 7) before re-exporting to the Collector?
オリジナルのエクスポーターがそれぞれ（オプション）テンプレートレコードを単一のIPFIXメディエーターにエクスポートし、（オプション）テンプレートレコードに同じ情報要素が含まれているが、IPFIXメディエーターが単一のエクスポートでテンプレートマッピングを維持する必要がある場合テンプレートレコード（図6を参照）またはIPFIXメディエーターは、コレクターに再エクスポートする前に、複数の独立したテンプレートレコード（図7を参照）を維持する必要がありますか？
Template Entry A <--+
|
Template Entry B <--+--> Template Entry D
|
Template Entry C <--+
Figure 6: Template Mapping and Ordering: A single Export Template Record
図6：テンプレートのマッピングと順序付け：単一のエクスポートテンプレートレコード
Template Entry A <--+--> Template Entry D
Template Entry B <--+--> Template Entry E
Template Entry C <--+--> Template Entry F
Figure 7: Template Mapping and Ordering: Multiple Export Template Records
図7：テンプレートのマッピングと順序付け：複数のエクスポートテンプレートレコード
The answer depends on whether the order of the Information Elements implies some specific semantic. One of the guiding principles in IPFIX protocol specifications is that the semantic meaning of one Information Element doesn't depend on the value of any other Information Element. However, there is one noticeable exception, as mentioned in [RFC7011]:
その答えは、情報要素の順序が特定のセマンティクスを意味するかどうかによって異なります。 IPFIXプロトコル仕様の基本原則の1つは、1つの情報要素の意味上の意味が他の情報要素の値に依存しないことです。ただし、[RFC7011]で述べられているように、1つの顕著な例外があります。
Multiple Scope Fields MAY be present in the Options Template Record, in which case the composite scope is the combination of the scopes. For example, if the two scopes are meteringProcessId and templateId, the combined scope is this Template for this Metering Process. If a different order of Scope Fields would result in a Record having a different semantic meaning, then the order of Scope Fields MUST be preserved by the Exporting Process. For example, in the context of PSAMP [RFC5476], if the first scope defines the filtering function, while the second scope defines the sampling function, the order of the scope is important. Applying the sampling function first, followed by the filtering function, would lead to potentially different Data Records than applying the filtering function first, followed by the sampling function.
オプションテンプレートレコードに複数のスコープフィールドが存在する場合があります。その場合、複合スコープはスコープの組み合わせになります。たとえば、2つのスコープがmeteringProcessIdとtemplateIdである場合、結合されたスコープはこのメータリングプロセスのこのテンプレートです。スコープフィールドの順序が異なると、レコードのセマンティックな意味が異なる場合は、エクスポートプロセスでスコープフィールドの順序を維持する必要があります。たとえば、PSAMP [RFC5476]のコンテキストでは、最初のスコープがフィルタリング関数を定義し、2番目のスコープがサンプリング関数を定義する場合、スコープの順序が重要です。最初にサンプリング関数を適用し、その後にフィルタリング関数を適用すると、最初にフィルタリング関数を適用し、その後にサンプリング関数を適用する場合とは、データレコードが異なる可能性があります。
If an IPFIX Mediator receives, from multiple Exporters, Template Records with identical Information Elements, but ordered differently, it SHOULD consider those Template Records as identical, subject to metadata information in the associated Options Template (for example, the Flow Key Options Template, see Section 10.2).
IPFIXメディエーターが、複数のエクスポーターから、同じ情報要素を持つテンプレートレコードを受け取ったが、順序が異なる場合、関連するオプションテンプレート（フローキーオプションテンプレートなど）のメタデータ情報に従って、それらのテンプレートレコードを同一と見なすべきです（SHOULD）。セクション10.2）。
If an IPFIX Mediator receives, from multiple Exporters, Options Template Records with identical and ordered Information Elements in the Scope fields, and with identical Information Elements, but ordered differently, in the non-Scope fields, it SHOULD consider those Template Records as identical.
IPFIXメディエーターが、複数のエクスポーターから、スコープフィールドに同一の順序付けられた情報要素を持ち、異なる情報要素を持ち、順序付けが異なるオプションテンプレートレコードを非スコープフィールドに受け取った場合、それらのテンプレートレコードは同一と見なす必要があります。
If an IPFIX Mediator receives, from multiple Exporters, Options Template Records with identical Information Elements in the Scope field, but ones that are ordered differently, it MUST consider those Template Records as semantically different.
IPFIXメディエーターが、複数のエクスポーターから、スコープフィールドに同じ情報要素を持つオプションテンプレートレコードを受け取ったが、順序が異なっている場合、それらのテンプレートレコードを意味的に異なるものと見なさなければなりません（MUST）。
For other Intermediate Processes, the IPFIX Mediator generates new (Options) Template Records as a result of the Intermediate Process.
他の中間プロセスの場合、IPFIXメディエーターは中間プロセスの結果として新しい（オプション）テンプレートレコードを生成します。
In these cases, the IPFIX Mediator doesn't need to maintain a Template Mapping, as it generates its own series of (Options) Template Records. However, some special cases might still require a Template Mapping. Consider a situation where the IPFIX Mediator generates new (Options) Template Records based on what it receives from the Exporter(s) based on the Intermediate Process function: for example, an Intermediate Anonymization process that performs black-marker anonymization [RFC6235] on certain Information Elements. In such cases, it's important to keep the correlation between the received (Options) Template Records and derived (Options) Template Records in the Template Mapping. These Template Mappings would be kept as in Section 4.1, except that the exported Template would not be identical to the received Template.
このような場合、IPFIXメディエーターは独自の一連の（オプション）テンプレートレコードを生成するため、テンプレートマッピングを維持する必要はありません。ただし、一部の特殊なケースでは、まだテンプレートマッピングが必要な場合があります。 IPFIXメディエーターが、中間プロセス機能に基づいてエクスポーターから受け取ったものに基づいて新しい（オプション）テンプレートレコードを生成する状況を考えます。たとえば、特定のブラックマーカー匿名化[RFC6235]を実行する中間匿名化プロセス情報要素。このような場合、テンプレートマッピングで、受信した（オプション）テンプレートレコードと派生した（オプション）テンプレートレコードの相関関係を維持することが重要です。これらのテンプレートマッピングは、エクスポートされたテンプレートが受信したテンプレートと同一ではないことを除いて、セクション4.1と同様に保持されます。
Similar to Exporting Processes in any Exporter, an IPFIX Mediator may use the technique for reducing redundancy in IPFIX described in [RFC5473].
任意のエクスポーターでのプロセスのエクスポートと同様に、IPFIXメディエーターは、[RFC5473]で説明されているIPFIXの冗長性を削減する手法を使用できます。
Depending on application requirements, Mediators that do not generate new Records SHOULD re-export values for unknown Information Elements, for which the Mediator does not have information about Information Element data type and semantics. However, as there may be presence or ordering dependencies among the unknown Information Elements, the Mediator MUST NOT omit fields from such re-exported Records or reorder any fields within the Records.
アプリケーションの要件に応じて、新しいレコードを生成しないメディエーターは、メディエーターが情報エレメントのデータ型とセマンティクスに関する情報を持っていない不明な情報エレメントの値を再エクスポートする必要があります（SHOULD）。ただし、不明な情報要素間に存在または順序の依存関係がある可能性があるため、メディエーターは、再エクスポートされたレコードからフィールドを省略したり、レコード内のフィールドを並べ替えたりしてはなりません。
Mediators that generate new Records, as in Section 4.2, MUST ignore values of Information Elements they do not understand. If a Mediator passes values of Information Elements it does not understand (for example, when re-exporting Flow Records), it MUST pass them in the order in which they were originally received.
セクション4.2のように、新しいレコードを生成するメディエーターは、理解できない情報要素の値を無視する必要があります。メディエーターが理解できない情報要素の値を渡す場合（たとえば、フローレコードを再エクスポートするとき）、メディエーターは、最初に受け取った順序でそれらを渡す必要があります。
In any case, Mediators handling unknown Information Elements SHOULD log this fact, as it is likely that mediation of records containing unknown values will have unintended consequences.
いずれの場合も、不明な情報要素を処理するメディエーターはこの事実をログに記録する必要があります。不明な値を含むレコードのメディエーションが意図しない結果になる可能性があるためです。
Depending on the use case, the Collector in an Exporter/IPFIX Mediator/Collector structure (for example, tiered Mediators) may need to receive information about the Original Observation Point(s);
ユースケースによっては、エクスポーター/ IPFIXメディエーター/コレクター構造のコレクター（たとえば、階層型メディエーター）が元の観測ポイントに関する情報を受け取る必要がある場合があります。
otherwise, it may wrongly conclude that the IPFIX Device exporting the Flow Records, i.e., the IPFIX Mediator, directly observed the packets that generated the Flow Records. Two new Information Elements are introduced to address this use case: originalExporterIPv4Address and originalExporterIPv6Address. Practically, the Original Exporters will not be exporting these Information Elements. Therefore, the Intermediate Process will report the Original Observation Point(s) to the best of its knowledge. Note that the Configuration Data Model for IPFIX and PSAMP [RFC6728] may report the Original Exporter information out of band.
そうしないと、フローレコードをエクスポートするIPFIXデバイス、つまりIPFIXメディエーターが、フローレコードを生成したパケットを直接観察したと誤って結論付けられる可能性があります。この使用例に対処するために、2つの新しい情報要素、originalExporterIPv4AddressとoriginalExporterIPv6Addressが導入されました。実際には、元のエクスポーターはこれらの情報要素をエクスポートしません。したがって、中間プロセスは、元の観測ポイントをその知識の範囲内で報告します。 IPFIXとPSAMPの構成データモデル[RFC6728]は、元のエクスポーター情報を帯域外で報告する場合があることに注意してください。
In the IPFIX Mediator, the Observation Point(s) may be represented by:
IPFIXメディエーターでは、観測ポイントは次のように表されます。
o A single Original Exporter (represented by the originalExporterIPv4Address or originalExporterIPv6Address Information Elements).
o 単一のオリジナルエクスポーター（originalExporterIPv4AddressまたはoriginalExporterIPv6Address情報要素で表される）。
o A list of Original Exporters (represented by a list of originalExporterIPv4Address or originalExporterIPv6Address Information Elements).
o オリジナルのエクスポーターのリスト（originalExporterIPv4AddressまたはoriginalExporterIPv6Address情報要素のリストによって表されます）。
o Any combination or list of Information Elements representing Observation Points. For example:
o 観測ポイントを表す情報要素の任意の組み合わせまたはリスト。例えば：
* A list of Original Exporter interfaces (represented by the originalExporterIPv4Address or originalExporterIPv6Address, the ingressInterface, and/or egressInterface Information Elements, respectively).
* Original Exporterインターフェースのリスト（originalExporterIPv4AddressまたはoriginalExporterIPv6Address、ingressInterface、egressInterface情報要素でそれぞれ表されます）。
* A list of Original Exporter line card (represented by the originalExporterIPv4Address, originalExporterIPv6Address, or lineCardId Information Elements, respectively).
* Original Exporterラインカードのリスト（それぞれ、originalExporterIPv4Address、originalExporterIPv6Address、またはlineCardId情報要素で表されます）。
Some Information Elements characterizing the Observation Point may be added. For example, the flowDirection Information Element specifies the direction of the observation, and, as such, characterizes the Observation Point.
観測ポイントを特徴付けるいくつかの情報要素が追加される場合があります。たとえば、flowDirection情報要素は観測の方向を指定し、観測ポイントを特徴付けます。
Any combination of the above representations is possible. An example of an Original Observation Point for an Intermediate Aggregation Process is displayed in Figure 8.
上記の表現の任意の組み合わせが可能です。中間集約プロセスの元の観測ポイントの例を図8に示します。
exporterIPv4Address 192.0.2.1 exporterIPv4Address 192.0.2.2, interface ethernet 0, direction ingress interface ethernet 1, direction ingress interface serial 1, direction egress interface serial 2, direction egress exporterIPv4Address 192.0.2.3, lineCardId 1, direction ingress
exporterIPv4Address 192.0.2.1 exporterIPv4Address 192.0.2.2、インターフェイスイーサネット0、方向入力インターフェイスイーサネット1、方向入力インターフェイスシリアル1、方向出力インターフェイスシリアル2、方向出力exporterIPv4Address 192.0.2.3、lineCardId 1、方向入力
Figure 8: Complex Observation Point Definition Example
図8：複雑な観測ポイント定義の例
A Mediator MAY export such complex Original Observation Point information, depending on application requirements. If such information is exported, the Mediator MUST use [RFC6313] to do so, as described below.
Mediatorは、アプリケーションの要件に応じて、このような複雑な元の観測ポイント情報をエクスポートできます（MAY）。そのような情報がエクスポートされる場合、メディエーターは、以下で説明するように、[RFC6313]を使用してエクスポートする必要があります。
The most generic way to export the Original Observation Point is to use a subTemplateMultiList, with the semantic "exactlyOneOf". Taking the previous example, the encoding in Figure 9 can be used.
元の観測ポイントをエクスポートする最も一般的な方法は、意味が「exactlyOneOf」のsubTemplateMultiListを使用することです。前の例では、図9のエンコードを使用できます。
Template Record 257: exporterIPv4Address Template Record 258: exporterIPv4Address, basicList of ingressInterface, flowDirection Template Record 259: exporterIPv4Address, lineCardId, flowDirection
テンプレートレコード257：exporterIPv4Addressテンプレートレコード258：exporterIPv4Address、ingressInterfaceのbasicList、flowDirectionテンプレートレコード259：exporterIPv4Address、lineCardId、flowDirection
Figure 9: Complex Observation Point Definition Example: Templates
図9：複雑な観測ポイント定義の例：テンプレート
The Original Observation Point is modeled with the Data Records corresponding to either Template Record 1, Template Record 2, or Template Record 3 but not more than one of these ("exactlyOneOf" semantic). This implies that the Flow was observed at exactly one of the Observation Points reported.
元の観測ポイントは、テンプレートレコード1、テンプレートレコード2、またはテンプレートレコード3のいずれかに対応するデータレコードでモデル化されますが、これらの1つだけです（ "exactlyOneOf"セマンティック）。これは、レポートされた観測ポイントの1つでフローが観測されたことを意味します。
When an IPFIX Mediator receives Flow Records containing the Original Observation Point Information Element, i.e., originalExporterIPv4Address or originalExporterIPv6Address, the IPFIX Mediator SHOULD NOT modify its value(s) when composing new Flow Records in the general case. Known exceptions include anonymization per Section 7.2.4 of [RFC6235] and an Intermediate Correlation Process rewriting addresses across NAT. In other words, the Original Observation Point should not be replaced with the IPFIX Mediator Observation Point. The daisy chain of (Exporter, Observation Point) representing the path the Flow Records took from the Exporter to the top Collector in the Exporter/IPFIX Mediator(s)/Collector structure model is out of the scope of this specification.
IPFIXメディエーターが元の観測ポイント情報要素（originalExporterIPv4AddressまたはoriginalExporterIPv6Address）を含むフローレコードを受信した場合、IPFIXメディエーターは、一般的なケースで新しいフローレコードを作成するときにその値を変更してはなりません（SHOULD NOT）。既知の例外には、[RFC6235]のセクション7.2.4による匿名化と、NAT全体でアドレスを書き換える中間相関プロセスが含まれます。つまり、元の観測ポイントをIPFIXメディエーター観測ポイントに置き換えないでください。フローレコードがエクスポーターからエクスポーター/ IPFIX Mediator（s）/ Collector構造モデルのトップコレクターにたどったパスを表す（Exporter、Observation Point）のデイジーチェーンは、この仕様の範囲外です。
The following subsections describe Information Elements for reporting Original Exporter addresses as seen by the Collecting Process; note they may be subject to network address translation upstream; see [NAT-LOGGING] for more on logging in this situation.
次のサブセクションでは、収集プロセスで表示される元のエクスポーターアドレスを報告するための情報要素について説明します。アップストリームのネットワークアドレス変換の対象となる場合があることに注意してください。この状況でのロギングの詳細については、[NAT-LOGGING]を参照してください。
Name: originalExporterIPv4Address
名前：originalExporterIPv4Address
Description: The IPv4 address used by the Exporting Process on an Original Exporter, as seen by the Collecting Process on an IPFIX Mediator. Used to provide information about the Original Observation Points to a downstream Collector.
説明：IPFIXメディエーターの収集プロセスから見た、元のエクスポーターのエクスポートプロセスで使用されるIPv4アドレス。元の観測ポイントに関する情報を下流のコレクターに提供するために使用されます。
Data Type: ipv4Address
データ型：ipv4Address
ElementId: 403
ElementId：403
Name: originalExporterIPv6Address
名前：originalExporterIPv6Address
Description: The IPv6 address used by the Exporting Process on an Original Exporter, as seen by the Collecting Process on an IPFIX Mediator. Used to provide information about the Original Observation Points to a downstream Collector.
説明：IPFIXメディエーターの収集プロセスから見た、元のエクスポーターのエクスポートプロセスで使用されるIPv6アドレス。元の観測ポイントに関する情報を下流のコレクターに提供するために使用されます。
Data Type: ipv6Address
データ型：ipv6Address
ElementId: 404
ElementId：404
The Observation Domain ID of any IPFIX Message containing Flow Records relevant to no particular Observation Domain, or to multiple Observation Domains, MUST have an Observation Domain ID of 0.
特定の観測ドメインに関連しない、または複数の観測ドメインに関連するフローレコードを含むIPFIXメッセージの観測ドメインIDは、0の観測ドメインIDを持つ必要があります。
IPFIX Mediators that do not change (Options) Template Records MUST maintain a Template Mapping, as detailed in Section 4.1, to ensure that the combination of Observation Domain IDs and Template IDs do not collide on export.
テンプレートレコードを変更しないIPFIXメディエーター（オプション）は、セクション4.1で詳細に説明されているように、観測ドメインIDとテンプレートIDの組み合わせがエクスポートで衝突しないように、テンプレートマッピングを維持する必要があります。
For IPFIX Mediators that export New (Options) Template Records, as in Section 4.2, there are two options for Observation Domain ID management. The first and simplest of these is to completely decouple exported Observation Domain IDs from received Observation Domain IDs; the IPFIX Mediator, in this case, comprises its own set of Observation Domain(s) independent of the Observation Domain(s) of the Original Exporters.
新しい（オプション）テンプレートレコードをエクスポートするIPFIXメディエーターの場合、セクション4.2のように、観測ドメインID管理には2つのオプションがあります。これらの最初で最も簡単な方法は、エクスポートされた観測ドメインIDを受信した観測ドメインIDから完全に分離することです。この場合、IPFIXメディエーターは、元のエクスポーターの観測ドメインとは独立した独自の一連の観測ドメインで構成されます。
The second option is to provide or maintain a Template Mapping for received (Options) Template Records and exported inferred (Options) Template Records, along with the appropriate Observation Domain IDs per Transport Session, which ensures that the combination of Observation Domain IDs and Template IDs do not collide on export.
2番目のオプションは、受信した（オプション）テンプレートレコードとエクスポートされた（オプション）テンプレートレコードのテンプレートマッピングを、トランスポートセッションごとの適切な観測ドメインIDとともに提供または維持することです。これにより、観測ドメインIDとテンプレートIDの組み合わせが保証されます。エクスポート時に衝突しないでください。
In some cases where the IPFIX Message Header can't contain a consistent Observation Domain for the entire IPFIX Message, but the Flow Records exported from the IPFIX Mediator should contain the Observation Domain of the Original Exporter anyway, the (Options) Template Record must contain the originalObservationDomainId Information Element, specified in Section 6.1. When an IPFIX Mediator receives Flow Records containing the originalObservationDomainId Information Element, the IPFIX Mediator MUST NOT modify its value(s) when composing new Flow Records with the originalObservationDomainId Information Element.
IPFIXメッセージヘッダーにIPFIXメッセージ全体の一貫した監視ドメインを含めることができない場合でも、IPFIXメディエーターからエクスポートされたフローレコードに元のエクスポーターの監視ドメインを含める必要がある場合は、（オプション）テンプレートレコードに含める必要があります。セクション6.1で指定された元のObservationDomainId情報要素。 IPFIXメディエーターがoriginalObservationDomainId情報要素を含むフローレコードを受信した場合、IPFIXメディエーターは、originalObservationDomainId情報要素を使用して新しいフローレコードを作成するときに、その値を変更してはなりません（MUST NOT）。
Name: originalObservationDomainId
名前：originalObservationDomainId
Description: The Observation Domain ID reported by the Exporting Process on an Original Exporter, as seen by the Collecting Process on an IPFIX Mediator. Used to provide information about the Original Observation Domain to a downstream Collector. When cascading through multiple Mediators, this identifies the initial Observation Domain in the cascade.
説明：IPFIXメディエーターの収集プロセスから見た、元のエクスポーターのエクスポートプロセスによって報告された監視ドメインID。元の観測ドメインに関する情報を下流のコレクターに提供するために使用されます。複数のメディエーターをカスケードする場合、カスケードの最初の観測ドメインを識別します。
Data Type: unsigned32
データ型：unsigned32
Data Type Semantics: identifier
データ型セマンティクス：識別子
ElementId: 405
ElementId：405
The IPFIX Message Header "Export Time" field is the time in seconds since 0000 UTC Jan 1, 1970, at which the IPFIX Message leaves the IPFIX Mediator. However, in the specific case of an IPFIX Mediator containing an Intermediate Conversion Process, the IPFIX Mediator MAY use the export time received from the incoming Transport Session.
IPFIXメッセージヘッダーの「エクスポート時間」フィールドは、1970年1月1日の0000 UTCからの秒数で、IPFIXメッセージがIPFIXメディエーターを離れる時間です。ただし、中間変換プロセスを含むIPFIXメディエーターの特定のケースでは、IPFIXメディエーターは、着信トランスポートセッションから受信したエクスポート時間を使用できます（MAY）。
It is RECOMMENDED that IPFIX Mediators handle time using absolute timestamps (e.g., flowStartSeconds, flowStartMilliseconds, or flowStartNanoseconds), which are specified relative to the UNIX epoch (00:00 UTC 1 Jan 1970) [POSIX.1], where possible rather than relative timestamps (e.g., flowStartSysUpTime or flowStartDeltaMicroseconds), which are specified relative to protocol structures such as system initialization or message export time.
IPFIXメディエーターが絶対タイムスタンプ（flowStartSeconds、flowStartMilliseconds、flowStartNanosecondsなど）を使用して時間を処理することをお勧めします。これは、UNIXエポック（00:00 UTC 1 Jan 1970）[POSIX.1]に関連して指定されます。システムの初期化やメッセージのエクスポート時間などのプロトコル構造に関連して指定されるタイムスタンプ（flowStartSysUpTimeやflowStartDeltaMicrosecondsなど）。
The latter are difficult to manage for two reasons. First, they require constant translation, as the system initialization time of an intermediate system and the export time of an intermediate message will change across mediation operations. Further, relative timestamps introduce range problems. For example, when using the flowStartDeltaMicroseconds and flowEndDeltaMicroseconds Information Elements [IANA-IPFIX], the Data Record must be exported within a maximum of 71 minutes after its creation. Otherwise, the 32-bit counter would not be sufficient to contain the flow start time offset. Those time constraints might be incompatible with some of the application requirements of some Intermediate Processes.
後者は、2つの理由で管理が困難です。第一に、中間システムのシステム初期化時間と中間メッセージのエクスポート時間は、メディエーション操作全体で変化するため、それらは一定の変換を必要とします。さらに、相対タイムスタンプは範囲の問題を引き起こします。たとえば、flowStartDeltaMicrosecondsおよびflowEndDeltaMicroseconds情報要素[IANA-IPFIX]を使用する場合、データレコードは作成後最大71分以内にエクスポートする必要があります。それ以外の場合、32ビットカウンターはフロー開始時間オフセットを含めるのに十分ではありません。これらの時間の制約は、一部の中間プロセスのアプリケーション要件の一部と互換性がない場合があります。
Intermediate Processes MUST NOT assume that received records appear in flowStartTime, flowEndTime, or observationTime order. An Intermediate Process processing timing information (e.g., an Intermediate Aggregation Process) MAY ignore records that are significantly out of order, in order to meet application-specific state and latency requirements, but SHOULD report that records were dropped.
中間プロセスは、受信したレコードがflowStartTime、flowEndTime、またはobservationTimeの順に現れると想定してはなりません。中間プロセス処理のタイミング情報（たとえば、中間集約プロセス）は、アプリケーション固有の状態とレイテンシの要件を満たすために、大幅に順序が乱れているレコードを無視してもかまいませんが、レコードが削除されたと報告する必要があります（SHOULD）。
When an Intermediate Process aggregates information from different Flow Records, the timestamps on exported records SHOULD be the minimum of the start times and the maximum of the end times in the general case. However, if the Flow Records do not overlap, i.e., if there is a time gap between the times in the Flow Records, then the report may be inaccurate. The IPFIX Mediator is only reporting what it knows, on the basis of the information made available to it, and there may not have been any data to observe during the gap. Then again, if there is an overlap in timestamps, there's the potential of double-accounting: different Observation Points may have observed the same traffic simultaneously. The specification of the precise rules for applying Flow Record timestamps at IPFIX Mediators for all the different situations is out of the scope of this document.
中間プロセスが異なるフローレコードから情報を集約する場合、エクスポートされたレコードのタイムスタンプは、一般的な場合の開始時間の最小値と終了時間の最大値である必要があります。ただし、フローレコードが重複しない場合、つまりフローレコードの時間の間に時間差がある場合、レポートは不正確になる可能性があります。 IPFIXメディエーターは、利用できるようになった情報に基づいて、知っていることだけを報告します。ギャップ中に観察するデータがなかった可能性があります。繰り返しになりますが、タイムスタンプが重複している場合は、二重アカウンティングの可能性があります。異なる観測ポイントが同じトラフィックを同時に観測した可能性があります。さまざまな状況すべてに対してIPFIXメディエーターでフローレコードのタイムスタンプを適用するための正確なルールの仕様は、このドキュメントの範囲外です。
Note that [RFC7015] provides additional specifications for handling of timestamps at an Intermediate Aggregation Process.
[RFC7015]は、中間集約プロセスでのタイムスタンプの処理に関する追加の仕様を提供することに注意してください。
SCTP [RFC4960] using the Partially Reliable SCTP (PR-SCTP) extension specified in [RFC3758] MUST be implemented by all compliant IPFIX Mediator implementations. TCP [RFC0793] MAY also be implemented by implementations compliant with the IPFIX Mediator. UDP [RFC0768] MAY also be implemented by compliant IPFIX Mediator implementations. Transport-specific considerations for IPFIX Exporters as specified in Sections 8.3, 8.4, 9.1, 9.2, and 10 of [RFC7011] apply to IPFIX Mediators as well.
[RFC3758]で指定されている部分的に信頼できるSCTP（PR-SCTP）拡張を使用するSCTP [RFC4960]は、準拠するすべてのIPFIX Mediator実装で実装する必要があります。 TCP [RFC0793]は、IPFIX Mediatorに準拠した実装によっても実装される場合があります。 UDP [RFC0768]は、準拠するIPFIX Mediator実装によっても実装される場合があります。 [RFC7011]のセクション8.3、8.4、9.1、9.2、および10で指定されているIPFIXエクスポーターのトランスポート固有の考慮事項は、IPFIXメディエーターにも適用されます。
SCTP SHOULD be used in deployments where IPFIX Mediators and Collectors are communicating over links that are susceptible to congestion. SCTP is capable of providing any required degree of reliability. TCP MAY be used in deployments where IPFIX Mediators and Collectors communicate over links that are susceptible to congestion, but SCTP is preferred due to its ability to limit back pressure on Exporters and its message versus stream orientation. UDP MAY be used, although it is not a congestion-aware protocol. However, in this case, the IPFIX traffic between IPFIX Mediator and Collector MUST run in an environment where IPFIX traffic has been provisioned for and/or separated from non-IPFIX traffic, whether physically or virtually.
SCTPは、IPFIXメディエーターとコレクターが、輻輳の影響を受けやすいリンクを介して通信している展開で使用する必要があります（SHOULD）。 SCTPは、必要な信頼性を提供できます。 TCPは、IPFIXメディエーターとコレクターが輻輳の影響を受けやすいリンクを介して通信するデプロイメントで使用できますが、エクスポーターへのバックプレッシャーとそのメッセージ対ストリームの方向を制限できるため、SCTPが推奨されます。 UDPは使用される場合がありますが、輻輳認識プロトコルではありません。ただし、この場合、IPFIX MediatorとCollectorの間のIPFIXトラフィックは、物理的または仮想的に、IPFIXトラフィックがプロビジョニングされているか、非IPFIXトラフィックから分離されている環境で実行する必要があります。
Any Collecting Process compliant with [RFC7011] can receive IPFIX Messages from an IPFIX Mediator. If the IPFIX Mediator uses IPFIX Structured Data [RFC6313] to export Original Exporter Information, as in Section 5, the Collecting Process MUST support [RFC6313].
[RFC7011]に準拠した収集プロセスは、IPFIX MediatorからIPFIXメッセージを受信できます。セクション5のように、IPFIXメディエーターがIPFIX構造化データ[RFC6313]を使用して元のエクスポーター情報をエクスポートする場合、収集プロセスは[RFC6313]をサポートする必要があります。
IPFIX provides Options Templates for the reporting the reliability of processes within the IPFIX Architecture. As each Mediator includes at least one IPFIX Exporting Process, they MAY use the Exporting Process Reliability Statistics Options Template, as specified in [RFC7011].
IPFIXは、IPFIXアーキテクチャ内のプロセスの信頼性を報告するためのオプションテンプレートを提供します。各メディエーターには少なくとも1つのIPFIXエクスポートプロセスが含まれているため、[RFC7011]で指定されているように、エクスポートプロセスの信頼性統計オプションテンプレートを使用できます（MAY）。
Analogous to the Metering Process Reliability Statistics Options Template, also specified in [RFC7011], Mediators MAY implement the Intermediate Process Reliability Statistics Options Template, specified in Sections 10.1, 10.3, and 10.4 define Information Elements used by this Options Template.
[RFC7011]でも指定されているメータリングプロセス信頼性統計オプションテンプレートと同様に、メディエーターは、セクション10.1、10.3、および10.4で指定されている中間プロセス信頼性統計オプションテンプレートを実装できます（MAY）。
The Flow Keys Options Template, as specified in [RFC7011], may require special handling at an IPFIX Mediator, as described in Section 10.2.
[RFC7011]で指定されているフローキーオプションテンプレートでは、セクション10.2で説明されているように、IPFIXメディエーターで特別な処理が必要になる場合があります。
In addition, each Intermediate Process may have its own specific reporting requirements (e.g., Anonymization Records as in [RFC6235], or the Aggregation Counter Distribution Options Template as in [RFC7015]); these SHOULD be implemented as necessary, as described in the specification for each Intermediate Process.
さらに、各中間プロセスには、独自の特定のレポート要件（[RFC6235]のような匿名化レコード、または[RFC7015]のような集計カウンター配布オプションテンプレート）がある場合があります）。これらは、各中間プロセスの仕様で説明されているように、必要に応じて実装する必要があります（SHOULD）。
The Intermediate Process Statistics Options Template specifies the structure of a Data Record for reporting Intermediate Process statistics. It SHOULD contain the following Information Elements; the intermediateProcessId Information Element is defined in Section 10.3 and the ignoredDataRecordTotalCount Information Element is defined in Section 10.4:
中間プロセス統計オプションテンプレートは、中間プロセス統計をレポートするためのデータレコードの構造を指定します。次の情報要素を含める必要があります。 IntermediateProcessId情報要素はセクション10.3で定義され、ignoredDataRecordTotalCount情報要素はセクション10.4で定義されます。
+-----------------------------+-------------------------------------+
| IE | Description |
+-----------------------------+-------------------------------------+
| observationDomainId [scope] | An identifier of the Observation |
| | Domain (of messages exported by |
| | this Mediator), locally unique to |
| | the Intermediate Process, to which |
| | this statistics record applies. |
| | ---------------------------------- |
| intermediateProcessId | An identifier for the Intermediate |
| [scope] | Process to which this statistics |
| | record applies. |
| | ---------------------------------- |
| ignoredDataRecordTotalCount | The total number of Data Records |
| | received but not processed by the |
| | Intermediate Process. |
| | ---------------------------------- |
| time first record ignored | The timestamp of the first record |
| | that was ignored by the |
| | Intermediate Process. For Data |
| | Records containing timestamp |
| | ranges, this SHOULD be taken from |
| | the start timestamp of the range; |
| | for data records containing no |
| | timing information, this SHOULD be |
| | taken from the Export Time in the |
| | message header of the IPFIX Message |
| | that contains it. For this |
| | timestamp, any of the following |
| | timestamp can be used: |
| | observationTimeSeconds, |
| | observationTimeMilliseconds, |
| | observationTimeMicroseconds, or |
| | observationTimeNanoseconds. |
+-----------------------------+-------------------------------------+
+-----------------------------+-------------------------------------+
| IE | Description |
+-----------------------------+-------------------------------------+
| time last record ignored | The timestamp of the last record |
| | that was ignored by the |
| | Intermediate Process. For Data |
| | Records containing timestamp |
| | ranges, this SHOULD be taken from |
| | the end timestamp of the range; for |
| | data records containing no timing |
| | information, this SHOULD be taken |
| | from the Export Time in the message |
| | header of the containing IPFIX |
| | Message. For this timestamp, any |
| | of the following timestamp can be |
| | used: observationTimeSeconds, |
| | observationTimeMilliseconds, |
| | observationTimeMicroseconds, or |
| | observationTimeNanoseconds. |
+-----------------------------+-------------------------------------+
The Flow Keys Options Template specifies the structure of a Data Record for reporting the Flow Keys of reported Flows. A Flow Keys Data Record extends a particular Template Record that is referenced by its templateId identifier. The Template Record is extended by specifying which of the Information Elements contained in the corresponding Data Records describe Flow properties that serve as Flow Keys of the reported Flow. This Options Template is defined in Section 4.4 of [RFC7011] and SHOULD be used by Mediators for export as defined there.
フローキーオプションテンプレートは、レポートされたフローのフローキーをレポートするためのデータレコードの構造を指定します。フローキーデータレコードは、templateId識別子によって参照される特定のテンプレートレコードを拡張します。テンプレートレコードは、対応するデータレコードに含まれる情報要素のうち、レポートされたフローのフローキーとして機能するフロープロパティを記述するものを指定することで拡張されます。このオプションテンプレートは[RFC7011]のセクション4.4で定義されており、メディエーターはそこで定義されているとおりにエクスポートに使用する必要があります（SHOULD）。
When an Intermediate Process exports Data Records containing different Flow Keys from those received from the Original Exporter, and the Original Exporter sent a Flow Keys Options record to the IPFIX Mediator, the IPFIX Mediator MUST export a Flow Keys Options record defining the new set of Flow Keys.
中間プロセスが元のエクスポーターから受け取ったものとは異なるフローキーを含むデータレコードをエクスポートし、元のエクスポーターがフローキーオプションレコードをIPFIXメディエーターに送信した場合、IPFIXメディエーターはフローの新しいセットを定義するフローキーオプションレコードをエクスポートする必要がありますキー。
Name: intermediateProcessId
名前：中間プロセスID
Description: An identifier of an Intermediate Process that is unique per IPFIX Device. Typically, this Information Element is used for limiting the scope of other Information Elements. Note that process identifiers may be assigned dynamically; that is, an Intermediate Process may be restarted with a different ID.
説明：IPFIXデバイスごとに一意である中間プロセスの識別子。通常、この情報要素は、他の情報要素の範囲を制限するために使用されます。プロセス識別子は動的に割り当てられることに注意してください。つまり、中間プロセスは別のIDで再起動される可能性があります。
Data Type: unsigned32
データ型：unsigned32
Data Type Semantics: identifier
データ型セマンティクス：識別子
ElementId: 406
ElementId：406
Name: ignoredDataRecordTotalCount
名前：ignoreDataRecordTotalCount
Description: The total number of received Data Records that the Intermediate Process did not process since the (re-)initialization of the Intermediate Process; includes only Data Records not examined or otherwise handled by the Intermediate Process due to resource constraints, not Data Records that were examined or otherwise handled by the Intermediate Process but those that merely do not contribute to any exported Data Record due to the operations performed by the Intermediate Process.
説明：中間プロセスの（再）初期化以降、中間プロセスが処理しなかった受信データレコードの総数。リソースの制約のために中間プロセスによって検査またはその他の方法で処理されなかったデータレコードのみが含まれます。中間プロセスによって検査またはその他の方法で処理されたデータレコードではなく、実行された操作が原因でエクスポートされたデータレコードに寄与しないデータレコードのみが含まれます中間プロセス。
Data Type: unsigned64
データ型：unsigned64
Data Type Semantics: totalCounter
データ型セマンティクス：totalCounter
ElementId: 407
ElementId：407
In general, using IPFIX Mediators to combine information from multiple Original Exporters requires a consistent configuration of the Metering Processes behind these Original Exporters. The details of this consistency are specific to each Intermediate Process. Consistency of configuration should be verified out of band, with the MIB modules ([RFC6615] and [RFC6727]) or with the Configuration Data Model for IPFIX and PSAMP [RFC6728].
一般に、IPFIXメディエーターを使用して複数の元のエクスポーターからの情報を組み合わせるには、これらの元のエクスポーターの背後にあるメータリングプロセスの一貫した構成が必要です。この一貫性の詳細は、各中間プロセスに固有です。構成の整合性は、MIBモジュール（[RFC6615]および[RFC6727]）またはIPFIXおよびPSAMPの構成データモデル[RFC6728]を使用して、帯域外で検証する必要があります。
From an operational perspective, this specification provides all the information required to set up IPFIX Mediators and Collectors behind IPFIX Mediators. While configuring the IPFIX Mediators, care must be taken to include all the relevant information so that the Collectors deduce the Data Records precise semantic. This is covered by the Template Mapping specifications in Section 4.1. Also, caution must be taken that if something is not carefully configured in the processing chain, this can lead to the wrong interpretation of collected IPFIX data, and the associated applications can produce results that are not operationally meaningful.
運用の観点から、この仕様はIPFIXメディエーターの背後にIPFIXメディエーターとコレクターをセットアップするために必要なすべての情報を提供します。 IPFIXメディエーターを構成するときは、コレクターがデータレコードを正確なセマンティクスで推定できるように、すべての関連情報を含めるように注意する必要があります。これは、セクション4.1のテンプレートマッピング仕様でカバーされています。また、処理チェーンで何かが注意深く構成されていない場合、収集されたIPFIXデータの誤った解釈につながり、関連するアプリケーションが操作上意味のない結果を生成する可能性があることに注意する必要があります。
As they act as both IPFIX Collecting Processes and Exporting Processes, the Security Considerations for the IPFIX Protocol [RFC7011] also apply to IPFIX Mediators. The Security Considerations for IPFIX Files [RFC5655] also apply to IPFIX Mediators that write IPFIX Files or use them for internal storage. However, there are a few specific considerations that IPFIX Mediator implementations must also take into account.
IPFIX収集プロセスとエクスポートプロセスの両方として機能するため、IPFIXプロトコルのセキュリティに関する考慮事項[RFC7011]もIPFIXメディエーターに適用されます。 IPFIXファイルのセキュリティに関する考慮事項[RFC5655]は、IPFIXファイルを書き込んだり、それらを内部ストレージに使用したりするIPFIXメディエーターにも適用されます。ただし、IPFIX Mediatorの実装でも考慮する必要があるいくつかの特定の考慮事項があります。
By design, IPFIX Mediators are "men in the middle": they intercede in the communication between an Original Exporter (or another upstream IPFIX Mediator) and a downstream Collecting Process. This has two important implications for the level of confidentiality provided across an IPFIX Mediator and the ability to protect data integrity and Original Exporter authenticity across an IPFIX Mediator. These are addressed in more detail in the Security Considerations for IPFIX Mediators in [RFC6183].
設計上、IPFIXメディエーターは「中間者」です。元のエクスポーター（または別のアップストリームIPFIXメディエーター）とダウンストリームの収集プロセスの間の通信に介入します。これは、IPFIXメディエーター全体で提供される機密性のレベル、およびIPFIXメディエーター全体でデータの整合性とオリジナルのエクスポーターの信頼性を保護する機能に2つの重要な影響があります。これらについては、[RFC6183]のIPFIXメディエーターのセキュリティに関する考慮事項で詳細に説明されています。
Note that while IPFIX Mediators can use the exporterCertificate and collectorCertificate Information Elements defined in [RFC5655] as described in Section 9.3 of [RFC6183] to export information about X.509 identities in upstream TLS-protected Transport Sessions, this mechanism cannot be used to provide true end-to-end assertions about a chain of IPFIX Mediators: any IPFIX Mediator in the chain can simply falsify the information about upstream Transport Sessions. In situations where information about the chain of mediation is important, it must be determined out of band. Note as well that an Exporting Process has no in-band way to determine whether or not a given Collecting Process will act as a Mediator. Trust placed in Collecting Processes is absolute, so care should be taken when exporting IPFIX Messages between Exporting Processes and Collecting Processes controlled by different entities.
IPFIXメディエーターは、[RFC6183]のセクション9.3で説明されているように、[RFC5655]で定義されているexporterCertificateおよびcollectorCertificate情報要素を使用して、上流のTLS保護トランスポートセッションでX.509 IDに関する情報をエクスポートできますが、このメカニズムを使用してIPFIXメディエーターのチェーンに関する真のエンドツーエンドアサーション：チェーン内のIPFIXメディエーターは、上流のトランスポートセッションに関する情報を改ざんするだけです。調停の連鎖に関する情報が重要な状況では、帯域外で決定する必要があります。また、エクスポートプロセスには、特定の収集プロセスがメディエーターとして機能するかどうかを判断するインバンドの方法がないことに注意してください。収集プロセスに置かれた信頼は絶対的なものなので、異なるエンティティによって制御されているエクスポートプロセスと収集プロセスの間でIPFIXメッセージをエクスポートするときは注意が必要です。
This document specifies new IPFIX Information Elements, originalExporterIPv4Address in Section 5.1, originalExporterIPv6Address in Section 5.2, originalObservationDomainId in Section 6.1, intermediateProcessId in Section 10.3, and ignoredDataRecordTotalCount in Section 10.4, which have been added to the IPFIX Information Element registry [IANA-IPFIX].
このドキュメントでは、IPFIX情報要素レジストリ[IANA-IPFIX]に追加された、新しいIPFIX情報要素、セクション5.1のoriginalExporterIPv4Address、セクション5.2のoriginalExporterIPv6Address、セクション6.1のoriginalObservationDomainId、セクション10.3の中間プロセスID、およびセクション10.4のignoreDataRecordTotalCountを指定しています。
We would like to thank the IPFIX contributors, specifically Paul Aitken (THE ultimate IPFIX document reviewer) and Andrew Feren for their thorough reviews; Nevil Brownlee and Juergen Quittek for shepherding this document and chairing the IPFIX Working Group; and to Rahul Patel, Meral Shirazipour, and Juergen Schoenwaelder for their feedback and comments. This work is materially supported by the European Union Seventh Framework Programme under grant agreements 257315 (DEMONS) and 318627 (mPlane).
IPFIXの寄稿者、特にPaul Aitken（究極のIPFIXドキュメントレビュー担当者）とAndrew Ferenの徹底したレビューに感謝します。この文書を提出し、IPFIXワーキンググループの議長を務めたNevil BrownleeとJuergen Quittek。フィードバックとコメントをいただいたRahul Patel、Meral Shirazipour、Juergen Schoenwaelderの各氏。この作業は、助成金契約257315（悪魔）と318627（mPlane）に基づく欧州連合第7フレームワークプログラムによって実質的にサポートされています。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768] Postel、J。、「User Datagram Protocol」、STD 6、RFC 768、1980年8月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、1981年9月。
[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月。
[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。、ラマーリョ、M。、シー、Q。、テューセン、M。、およびP.コンラッド、「ストリーム制御伝送プロトコル（SCTP）部分信頼性拡張」、RFC 3758、2004年5月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R。、「Stream Control Transmission Protocol」、RFC 4960、2007年9月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5655] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. Wagner, "Specification of the IP Flow Information Export (IPFIX) File Format", RFC 5655, October 2009.
[RFC5655] Trammell、B.、Boschi、E.、Mark、L.、Zseby、T。、およびA. Wagner、「Specification of the IP Flow Information Export（IPFIX）File Format」、RFC 5655、2009年10月。
[RFC6313] Claise, B., Dhandapani, G., Aitken, P., and S. Yates, "Export of Structured Data in IP Flow Information Export (IPFIX)", RFC 6313, July 2011.
[RFC6313] Claise、B.、Dhandapani、G.、Aitken、P。、およびS. Yates、「IP Flow Information Export（IPFIX）の構造化データのエクスポート」、RFC 6313、2011年7月。
[RFC6615] Dietz, T., Kobayashi, A., Claise, B., and G. Muenz, "Definitions of Managed Objects for IP Flow Information Export", RFC 6615, June 2012.
[RFC6615] Dietz、T。、小林、A.、Claise、B。、およびG. Muenz、「Defineions of Managed Objects for IP Flow Information Export」、RFC 6615、2012年6月。
[RFC6727] Dietz, T., Claise, B., and J. Quittek, "Definitions of Managed Objects for Packet Sampling", RFC 6727, October 2012.
[RFC6727] Dietz、T.、Claise、B。、およびJ. Quittek、「Definions of Managed Objects for Packet Sampling」、RFC 6727、2012年10月。
[RFC6728] Muenz, G., Claise, B., and P. Aitken, "Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols", RFC 6728, October 2012.
[RFC6728] Muenz、G.、Claise、B。、およびP. Aitken、「IPフロー情報エクスポート（IPFIX）およびパケットサンプリング（PSAMP）プロトコルの構成データモデル」、RFC 6728、2012年10月。
[RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, September 2013.
[RFC7011] Claise、B.、Trammell、B。、およびP. Aitken、「Specification of the IP Flow Information Export（IPFIX）Protocol for the Exchange of Flow Information of Exchange」、STD 77、RFC 7011、2013年9月。
[RFC7012] Claise, B. and B. Trammell, "Information Model for IP Flow Information Export (IPFIX)", RFC 7012, September 2013.
[RFC7012] Claise、B。およびB. Trammell、「IPフロー情報エクスポート（IPFIX）の情報モデル」、RFC 7012、2013年9月。
[RFC7013] Trammell, B. and B. Claise, "Guidelines for Authors and Reviewers of IP Flow Information Export (IPFIX) Information Elements", BCP 184, RFC 7013, September 2013.
[RFC7013] Trammell、B。およびB. Claise、「作成者とIPフロー情報エクスポート（IPFIX）情報要素のレビューアのためのガイドライン」、BCP 184、RFC 7013、2013年9月。
[RFC7014] D'Antonio, S., Zseby, T., Henke, C., and L. Peluso, "Flow Selection Techniques", RFC 7014, September 2013.
[RFC7014] D'Antonio、S.、Zseby、T.、Henke、C。、およびL. Peluso、「Flow Selection Techniques」、RFC 7014、2013年9月。
[RFC7015] Trammell, B., Wagner, A., and B. Claise, "Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol", RFC 7015, September 2013.
[RFC7015] Trammell、B.、Wagner、A。、およびB. Claise、「Flow Aggregation for the IP Flow Information Export（IPFIX）Protocol」、RFC 7015、2013年9月。
[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フロー情報エクスポート（IPFIX）の要件」、RFC 3917、2004年10月。
[RFC3954] Claise, B., "Cisco Systems NetFlow Services Export Version 9", RFC 3954, October 2004.
[RFC3954] Claise、B。、「Cisco Systems NetFlow Services Export Version 9」、RFC 3954、2004年10月。
[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、「Architecture for IP Flow Information Export」、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月。
[RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports", RFC 5473, March 2009.
[RFC5473] Boschi、E.、Mark、L。、およびB. Claise、「Reduce Redundancy in IP Flow Information Export（IPFIX）and Packet Sampling（PSAMP）Reports」、RFC 5473、2009年3月。
[RFC5476] Claise, B., Johnson, A., and J. Quittek, "Packet Sampling (PSAMP) Protocol Specifications", RFC 5476, March 2009.
[RFC5476] Claise、B.、Johnson、A。、およびJ. Quittek、「Packet Sampling（PSAMP）Protocol Specifications」、RFC 5476、2009年3月。
[RFC5610] Boschi, E., Trammell, B., Mark, L., and T. Zseby, "Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements", RFC 5610, July 2009.
[RFC5610] Boschi、E.、Trammell、B.、Mark、L。、およびT. Zseby、「Exporting Type Information for IP Flow Information Export（IPFIX）Information Elements」、RFC 5610、2009年7月。
[RFC5982] Kobayashi, A. and B. Claise, "IP Flow Information Export (IPFIX) Mediation: Problem Statement", RFC 5982, August 2010.
[RFC5982]小林、A。およびB. Claise、「IPフロー情報エクスポート（IPFIX）調停：問題の説明」、RFC 5982、2010年8月。
[RFC6183] Kobayashi, A., Claise, B., Muenz, G., and K. Ishibashi, "IP Flow Information Export (IPFIX) Mediation: Framework", RFC 6183, April 2011.
[RFC6183]小林明朗、クレイズB.、ムエンツG.、石橋健二、「IPフロー情報エクスポート（IPFIX）メディエーション：フレームワーク」、RFC 6183、2011年4月。
[RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization Support", RFC 6235, May 2011.
[RFC6235] Boschi、E。およびB. Trammell、「IP Flow Anonymization Support」、RFC 6235、2011年5月。
[NAT-LOGGING] Sivakumar, S. and R. Penno, "IPFIX Information Elements for logging NAT Events", Work in Progress, November 2013.
[NAT-LOGGING] Sivakumar、S。およびR. Penno、「NATイベントをログに記録するためのIPFIX情報要素」、作業中、2013年11月。
[IANA-IPFIX] IANA, "IP Flow Information Export (IPFIX) Entities", <http://www.iana.org/assignments/ipfix>.
[IANA-IPFIX] IANA、「IP Flow Information Export（IPFIX）Entities」、<http://www.iana.org/assignments/ipfix>。
[POSIX.1] IEEE, "IEEE Standard for Information Technology - Portable Operating System Interface", IEEE 1003.1-2008, 2008.
[POSIX.1] IEEE、「IEEE Standard for Information Technology-Portable Operating System Interface」、IEEE 1003.1-2008、2008。
Authors' Addresses
著者のアドレス
Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 1831 Diegem Belgium
Benoit Claise Cisco Systems、Inc. De Kleetlaan 6a b1 1831 Diegem Belgium
Phone: +32 2 704 5622
EMail: bclaise@cisco.com
Atsushi Kobayashi NTT Information Sharing Platform Laboratories 3-9-11 Midori-cho Musashino-shi, Tokyo 180-8585 Japan
あつし こばやし んっｔ いんふぉｒまちおん しゃりんｇ Ｐぁｔふぉｒｍ ぁぼらとりえｓ ３ー９ー１１ みどりーちょ むさしのーし、 ときょ １８０ー８５８５ じゃぱん
Phone: +81 422 59 3978
EMail: akoba@nttv6.net
Brian Trammell Swiss Federal Institute of Technology Zurich Gloriastrasse 35 8092 Zurich Switzerland
ブライアントラメルスイス連邦工科大学チューリッヒGloriastrasse 35 8092チューリッヒスイス
Phone: +41 44 632 70 13
EMail: trammell@tik.ee.ethz.ch