Network Working Group                                           T. Zseby
Request for Comments: 5472                              Fraunhofer FOKUS
Category: Informational                                        E. Boschi
                                                          Hitachi Europe
                                                             N. Brownlee
                                                               B. Claise
                                                     Cisco Systems, Inc.
                                                              March 2009
            IP Flow Information Export (IPFIX) Applicability

Status of This Memo


This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.


Copyright Notice


Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

著作権(C)2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document ( Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

この文書では、BCP 78と、この文書(の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.




In this document, we describe the applicability of the IP Flow Information eXport (IPFIX) protocol for a variety of applications. We show how applications can use IPFIX, describe the relevant Information Elements (IEs) for those applications, and present opportunities and limitations of the protocol. Furthermore, we describe relations of the IPFIX framework to other architectures and frameworks.


Table of Contents


   1. Introduction ....................................................4
      1.1. Terminology ................................................4
   2. Applications of IPFIX ...........................................4
      2.1. Accounting .................................................4
           2.1.1. Example .............................................5
      2.2. Traffic Profiling ..........................................7
      2.3. Traffic Engineering ........................................8
      2.4. Network Security ...........................................9
      2.5. QoS Monitoring ............................................11
           2.5.1. Correlating Events from Multiple
                  Observation Points .................................12
           2.5.2. Examples ...........................................12
      2.6. Inter-Domain Exchange of IPFIX Data .......................14
      2.7. Export of Derived Metrics .................................14
      2.8. Summary ...................................................15
   3. Relation of IPFIX to Other Frameworks and Protocols ............16
      3.1. IPFIX and IPv6 ............................................16
      3.2. IPFIX and PSAMP ...........................................16
      3.3. IPFIX and RMON ............................................16
      3.4. IPFIX and IPPM ............................................18
      3.5. IPFIX and AAA .............................................18
           3.5.1. Connecting via a AAA Client ........................20
           3.5.2. Connecting via an Application Specific
                  Module (ASM) .......................................21
      3.6. IPFIX and RTFM ............................................21
           3.6.1. Architecture .......................................21
           3.6.2. Flow Definition ....................................22
           3.6.3. Configuration and Management .......................22
           3.6.4. Data Collection ....................................22
           3.6.5. Data Model Details .................................23
           3.6.6. Transport Protocol .................................23
           3.6.7. Summary ............................................23
   4. Limitations ....................................................24
      4.1. Using IPFIX for Other Applications than Listed in
           RFC 3917 ..................................................24
      4.2. Using IPFIX for Billing (Reliability Limitations) .........24
      4.3. Using a Different Transport Protocol than SCTP ............25
      4.4. Push vs. Pull Mode ........................................25
      4.5. Template ID Number ........................................26
      4.6. Exporting Bidirectional Flow Information ..................26
      4.7. Remote Configuration ......................................27
   5. Security Considerations ........................................27
   6. Acknowledgements ...............................................28
   7. Normative References ...........................................28
   8. Informative References .........................................28
1. Introduction
1. はじめに

The IPFIX protocol defines how IP Flow information can be exported from routers, measurement probes, or other devices. IP Flow information provides important input data for a variety of applications. The IPFIX protocol is a general data transport protocol that is easily extensible to suit the needs of such applications. In this document, we describe how typical applications can use the IPFIX protocol and show opportunities and limitations of the protocol. Furthermore, we describe the relationship of IPFIX to other frameworks and architectures. Although examples in this document are shown for IPv4 only, the applicability statements apply to IPv4 and IPv6. IPFIX provides appropriate Information Elements for both IP versions.

IPFIXプロトコルは、IPフロー情報は、ルータ、計測プローブ、または他のデバイスからエクスポートすることができる方法を定義します。 IPフロー情報は、様々な用途に重要な入力データを提供します。 IPFIXプロトコルは、そのようなアプリケーションのニーズに合わせて容易に拡張可能であり、一般的なデータ転送プロトコルです。この文書では、我々は、IPFIXプロトコルを使用して、プロトコルの機会と限界を表示することができますどのように典型的なアプリケーションについて説明します。さらに、我々は他のフレームワークとアーキテクチャへのIPFIXの関係を説明します。このドキュメントの例は、IPv4のみのために示されているが、適用文は、IPv4とIPv6に適用されます。 IPFIXは、両方のIPバージョンのために適切な情報要素を提供します。

1.1. Terminology
1.1. 用語

IPFIX-specific terminology used in this document is defined in Section 2 of [RFC5101]. In this document, as in [RFC5101], the first letter of each IPFIX-specific term is capitalized.


2. Applications of IPFIX

IPFIX data enables several critical applications. The IPFIX target applications and the requirements that originate from those applications are described in [RFC3917]. Those requirements were used as basis for the design of the IPFIX protocol. This section describes how these target applications can use the IPFIX protocol. Considerations for using IPFIX for other applications than those described in [RFC3917] can be found in Section 4.1.

IPFIXデータは、いくつかの重要なアプリケーションを可能にします。 IPFIXターゲットアプリケーションとそれらのアプリケーションから発信要求は[RFC3917]に記載されています。これらの要件は、IPFIXプロトコルの設計のための基礎として使用されました。このセクションでは、これらのターゲットアプリケーションがIPFIXプロトコルを使用する方法について説明します。 [RFC3917]に記載されたもの以外の用途にIPFIXを使用するための考慮事項は、4.1節に見出すことができます。

2.1. Accounting
2.1. 経理

Usage-based accounting is one of the target applications for IPFIX as defined in [RFC3917]. IPFIX records provide fine-grained measurement results for highly flexible and detailed usage reporting. Such data is used to realize usage-based accounting. Nevertheless, IPFIX does not provide the reliability required by usage-based billing systems as defined in [RFC2975] (see Section 4.2). The accounting scenarios described in this document only provide limited reliability as explained in Section 4.2 and should not be used in environments where reliability as demanded by [RFC2975] is mandatory.

[RFC3917]で定義されるように従量課金は、IPFIXのためのターゲットアプリケーションの一つです。 IPFIXレコードは非常に柔軟で詳細な使用状況レポートのためのきめ細かな測定結果を提供します。このようなデータは、使用量ベースの会計を実現するために使用されます。それにもかかわらず、IPFIXは[RFC2975]で定義されるように従量課金システムによって必要とされる信頼性を提供しない(セクション4.2を参照)。 4.2節で説明した[RFC2975]によって要求としての信頼性は必須である環境で使用されるべきではないとして、この文書に記載された会計シナリオは限られた信頼性を提供します。

In order to realize usage-based accounting with IPFIX, the Flow definition has to be chosen in accordance to the accounting purpose, such as trend analysis, capacity planning, auditing, or billing and cost allocation where some loss of data can be tolerated (see Section 4.2).


Flows can be distinguished by various IEs (e.g., packet header fields) from [RFC5102]. Due to the flexible IPFIX Flow definition, arbitrary Flow-based accounting models can be realized without extensions to the IPFIX protocol.


Accounting can, for instance, be based on individual end-to-end Flows. In this case, it can be realized with a Flow definition determined by the quintuple consisting of source address (sourceIPv4Address), destination address (destinationIPv4Address), protocol (protocolIdentifier), and port numbers (udpSourcePort, udpDestinationPort). Another example is class-dependent accounting (e.g., in a Diffserv network). In this case, Flows could be distinguished just by the Diffserv codepoint (DSCP) (ipDiffServCodePoint) and IP addresses (sourceIPv4Address, destinationIPv4Address). The essential elements needed for accounting are the number of transferred packets and bytes per Flow, which can be represented by the per-flow counter IEs (e.g., packetTotalCount, octetTotalCount).


For accounting purposes, it would be advantageous to have the ability to use IPFIX Flow Records as accounting input in an Authentication, Authorization, and Accounting (AAA) infrastructure. AAA servers then could provide the mapping between user and Flow information. Again for such scenarios the limited reliability currently provided by IPFIX has to be taken into account.

会計目的のために、認証、許可、アカウンティング(AAA)インフラストラクチャの会計入力としてIPFIXフローレコードを使用する能力を有することが有利であろう。 AAAサーバは、ユーザとフロー情報との間のマッピングを提供することができます。再び、そのようなシナリオについて現在IPFIXによって提供される限られた信頼性を考慮に入れなければなりません。

2.1.1. Example
2.1.1. 例

Please note: As noted in [RFC3330], the address block may be used for example addresses. In the example below, we use two example networks. In order to be conformant to [RFC3330], we divide the given address block into two networks by subnetting with a 25-bit netmask ( as follows:

注意:[RFC3330]で述べたように、アドレスブロック192.0.2.0/24は、例えばアドレスのために使用することができます。以下の例では、我々は2つのサンプルネットワークを使用しています。 [RFC3330]に準拠するために、我々は次のように25ビットネットマスク(とサブネットことにより、2つのネットワークに与えられたアドレスブロックを分割します。

Network A: ... Network B: ...

ネットワークA: ...ネットワークB: ...

Let's suppose someone needs to monitor the individual Flows in a Diffserv network in order to compare traffic amount trend with the terms outlined in a Service Level Agreement (SLA). Flows are distinguished by source and destination address. The information to export in this case is:


- IPv4 source IP address: sourceIPv4Address in [RFC5102], with a length of 4 octets

- IPv4ソースIPアドレス:sourceIPv4Address [RFC5102]で、4つのオクテットの長さ

- IPv4 destination IP address: destinationIPv4Address in [RFC5102], with a length of 4 octets

- IPv4宛先IPアドレス:4つのオクテットの長さを有する、[RFC5102]でdestinationIPv4Address、

- DSCP: ipDiffServCodePoint in [RFC5102], with a length of 1 octet

- DSCP:[RFC5102]でipDiffServCodePoint、1つのオクテットの長さを有します

- Number of octets of the Flow: octetDeltaCount in [RFC5102], with a length of 4 octets

- フローのオクテットの数:[RFC5102]でoctetDeltaCount、4つのオクテットの長さ

The Template set will look as follows:


      |         Set ID = 2            |      Length = 24 octets       |
      |       Template ID 256         |       Field Count = 4         |
      |0|    sourceIPv4Address = 8    |       Field Length = 4        |
      |0| destinationIPv4Address = 12 |       Field Length = 4        |
      |0|  ipDiffServCodePoint = 195  |       Field Length = 1        |
      |0|     octetDeltaCount = 1     |       Field Length = 4        |

The information to be exported might be as listed in the following example table:


      Src. IP addr. | Dst. IP addr. |  DSCP  | Octets Number
      --------------+---------------+--------+--------------    |  |   46   |   120868    |  |   46   |   310364    |  |   46   |   241239

In the example we use Diffserv codepoint 46, recommended for the Expedited Forwarding Per Hop Behavior (EF PHB) in [RFC3246].

例では、Diffservのを使用し、46のコードポイント[RFC3246]で緊急転送毎のホップ行動(EF PHB)を推奨。

The Flow Records will then look as follows:


       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 = 256         |          Length = 43          |
      |                                           |
      |                                          |
      |      46       |               120868                          |
      |               |                           |
      |               |                          |
      |               |       46      |                 310364        |
      |                               |            |
      |                               |           |
      |                               |       46      |               |
      |                   241239                      |
2.2. Traffic Profiling
2.2. 交通プロファイリング

Measurement results reported in IPFIX records can provide useful input for traffic profiling. IPFIX records captured over a long period of time can be used to track and anticipate network growth and usage. Such information is valuable for trend analysis and network planning.


The parameters of interest are determined by the profiling objectives. Example parameters for traffic profiling are Flow duration, Flow volume, burstiness, the distribution of used services and protocols, the amount of packets of a specific type, etc. [RFC3917].


The distribution of services and protocols in use can be analyzed by configuring appropriate Flows Keys for Flow discrimination. Protocols can be distinguished by the protocolIdentifier IE. Portnumbers (e.g., udpDestinationPort) often provide information about services in use. Those Flow Keys are defined in [RFC5102]. If

使用中のサービスとプロトコルの分布は、フロー識別のための適切なフロー・キーを設定することによって分析することができます。プロトコルは、プロトコル識別子IEで区別することができます。 Portnumbers(例えば、udpDestinationPort)は、多くの場合、使用中のサービスに関する情報を提供しています。これらのフローキーは[RFC5102]で定義されています。もし

portnumbers are not sufficient for service discrimination, further parts of the packet may be needed. Header fields can be expressed by IEs from [RFC5102].

ポート番号は、パケットの更なる部品が必要になる場合があり、サービスの差別のために十分ではありません。ヘッダフィールドは、[RFC 5102]からのIEで表すことができます。

Packet payload can be reported by using the IE ipPayloadPacketSection in [RFC5477].

パケットペイロードは、[RFC5477]にIE ipPayloadPacketSectionを使用して報告することができます。

The Flow duration can be calculated from the Flow Timestamp IEs defined in [RFC5102] (e.g., flowEndMicroseconds - flowStartMicroseconds). The number of packets and number of bytes of a Flow are represented in the per-flow counter IEs (e.g., packetTotalCount, octetTotalCount). The burstiness of a Flow can be calculated from the Flow volume measured at different time intervals.

フロー時間は、[RFC5102]( - flowStartMicroseconds例えば、flowEndMicroseconds)で定義されたフローのタイムスタンプのIEから計算することができます。パケットおよびフローのバイト数の数は、フローごとのカウンタのIE(例えば、packetTotalCount、octetTotalCount)で表されます。フローのバーストは、異なる時間間隔で測定された流量から計算することができます。

2.3. Traffic Engineering
2.3. トラフィックエンジニアリング

Traffic engineering aims at the optimization of network resource utilization and traffic performance [RFC2702]. Typical parameters are link utilization, load between specific network, nodes, number, size and entry/exit points of active Flows, and routing information [RFC3917].


The size of Flows in packets and bytes can be reported by the IEs packetTotalCount and octetTotalCount. Utilization of a physical link can be reported by using a coarse-grained Flow definition (e.g., based on identifier IEs such as egressInterface or ingressInterface) and per-flow counter IEs (e.g., packetTotalCount, octetTotalCount) defined in [RFC5102].


The load between specific network nodes can be reported in the same way if one interface of a network node receives only traffic from exactly one neighbor node (as is usually the case). If the ingress interface is not sufficient for an unambiguous identification of the neighbor node, sub-IP header fields IEs (like sourceMacAddress) can be added as Flow Keys.


The IE observedFlowTotalCount provides the number of all Flows exported for the Observation Domain since the last initialization of the Metering Process [RFC5102]. If this IE is exported at subsequent points in time, one can derive the number of active Flows in a specific time interval from the difference of the reported counters. The configured Flow termination criteria have to be taken into account to interpret those numbers correctly.

IE observedFlowTotalCountは、計量プロセス[RFC5102]の最後の初期化以来観測ドメインのためにエクスポートされたすべてのフローの数を提供します。このIEは、時間的に後続の点でエクスポートされる場合、一方が報告カウンタの差から特定の時間間隔中にアクティブフローの数を導出することができます。構成されたフローの終了基準は正しくこれらの数字を解釈するために考慮しなければなりません。

Entry and exit points can be derived from Flow Records if Metering Processes are installed at all edges of the network and results are mapped in accordance to Flow Keys. For this and other analysis methods that require the mapping of records from different


Observation Points, the same Flow Keys should be used at all Observation Points. The path that packets take through a network can be investigated by using hash-based sampling techniques as described in [DuGr00] and [RFC5475]. For this, IEs from [RFC5477] are needed.


Neither [RFC5102] nor [RFC5477] defines IEs suitable for exporting routing information.


2.4. Network Security
2.4. ネットワークセキュリティー

Attack and intrusion detection are among the IPFIX target applications described in [RFC3917]. Due to the enormous amount of different network attack types, only general requirements could be addressed in [RFC3917].


The number of metrics useful for attack detection is as diverse as attack patterns themselves. Attackers adapt rapidly to circumvent detection methods and try to hide attack patterns using slow or stealth attacks. Furthermore, unusual traffic patterns are not always caused by malicious activities. A sudden traffic increase may be caused by legitimate users who seek access to a recently published web content. Strange traffic patterns may also be caused by misconfiguration.


IPFIX can export Flow information for arbitrary Flow definitions as defined in [RFC5101]. Packet information can be exported with IPFIX by using the additional Information Elements described in [RFC5477]. With this, theoretically all information about traffic in the network at the IP layer and above is accessible. This data either can be used directly to detect anomalies or can provide the basis for further post-processing to generate more complex attack detection metrics.


Depending on the attack type, different metrics are useful. A sudden increase of traffic load can be a hint that an attack has been launched. The overall traffic at an Observation Point can be monitored using per-flow counter IEs like packetTotalCount or octetTotalCount as described in Section 2.3. The number of active Flows can be monitored by regular reporting of the observedFlowTotalCount defined in [RFC5102].

攻撃の種類に応じて、異なるメトリックが便利です。トラフィック負荷の急激な増加は、攻撃が開始されたことをヒントすることができます。 2.3節で説明したようにObservation Pointの全体的なトラフィックがpacketTotalCountまたはoctetTotalCountのようなフローごとのカウンタのIEを使用して監視することができます。アクティブフローの数は、[RFC5102]で定義さobservedFlowTotalCountの定期的な報告によりモニターすることができます。

A sudden increase of Flows from different sources to one destination may be caused by an attack on a specific host or network node using spoofed addresses. The number of Flows from or to specific networks or hosts can be observed by using source and destination addresses as Flow Keys and observing the number of active Flows as explained above. Many Flows to the same machine, but on different ports, or many Flows to the same port and different machines may be an indicator for vertical or horizontal port scanning activities. The number of Flows to different ports can be reported by using the portnumber Information Elements (udpSourcePort, udpDestinationPort, tcpSourcePort, tcpDestinationPort) defined in [RFC5102] as Flow Keys.


An unusual ratio of TCP-SYN to TCP-FIN packets can refer to SYN-flooding. The number of SYN and FIN packets in a Flow can be reported with the IPFIX Information Elements tcpSynTotalCount and tcpFinTotalCount defined in [RFC5102].


Worms may leave signatures in traffic patterns. Detecting such events requires more detailed measurements and post-processing than detecting simple changes in traffic volumes.


A difficult task is the separation of good from bad packets to prepare and launch counteraction. This may require a deeper look into packet content by using further header field IEs from [RFC5102] and/or packet payloads from IE ipPayloadPacketSection in [RFC5477].

困難な作業は、反作用を準備し、起動する不良パケットから良いの分離です。これは、[RFC5477]にIE ipPayloadPacketSectionから[RFC5102]及び/又はパケットペイロードからさらにヘッダーフィールドIEを使用して、パケットの内容に深く外観を必要とするかもしれません。

Furthermore, the amount of resources needed for measurement and reporting increases with the level of granularity required to detect an attack. Multi-step analysis techniques may be useful, e.g., to launch an in-depth analysis (e.g., based on packet information) in case the Flow information shows suspicious patterns. In order to supervise traffic to a specific host or network node, it is useful to apply filtering methods such as those described in [RFC5475].


Mapping the two directions of communication is often useful for checking correct protocol behavior (see Section 4.6). A correlation of IPFIX data from multiple Observation Points (see Section 2.5.1) allows assessing the propagation of an attack and can help to locate its source.


The integration of previous measurement results helps to review traffic changes over time for detection of traffic anomalies and provides the basis for forensic analysis. A standardized storage format for IPFIX data would support the offline analysis of data from different operators.

前回の測定結果の統合は、トラフィック異常の検出のために時間をかけて、トラフィックの変化を確認するのに役立ち、法医学的分析のための基礎を提供します。 IPFIXデータの標準化された保存形式が異なるオペレータからのデータのオフライン分析をサポートします。

Nevertheless, capturing full packet traces at all Observation Points in the network is not viable due to resource limitations and privacy concerns. Therefore, metrics should be chosen wisely to allow a solid detection with minimal resource consumption. Resources can be saved, for instance, by using coarser-grained Flow definitions, reporting pre-processed metrics (e.g., with additional Information Elements), or deploying sampling methods.


In many cases, only derived metrics provide sufficient evidence about security incidents. For example, comparing the number of SYN and FIN packets for a specific time interval can reveal an ongoing SYN attack, which is not obvious from unprocessed packet and Flow data. Further metrics like the cumulated sum of various counters, distributions of packet attributes, or spectrum coefficients have been used to identify a variety of attacks.


In order to detect attacks early, it is useful to process the data as soon as possible in order to generate significant metrics for the detection. Pre-processing of raw packet and Flow data already at the measurement device can speed up the detection process and reduces the amount of data that need to be exported. Furthermore, it is possible to directly report derived metrics by defining appropriate Information Elements. Immediate data export in case of a potential incident is desired. IPFIX supports such source-triggered exporting of information due to the push model approach. Nevertheless, further exporting criteria have to be implemented to export IPFIX records upon incident detection events and not only upon flow-end or fixed-time intervals.

早期に攻撃を検出するためには、検出のための重要なメトリックを生成するためには、できるだけ早くデータを処理するのに便利です。既に測定装置において生のパケットおよびフローデータの前処理は、検出プロセスをスピードアップし、エクスポートする必要があるデータの量を減少させることができます。さらに、直接、適切な情報要素を定義することで派生メトリックを報告することが可能です。潜在的な事件の場合に即時のデータのエクスポートが望まれています。 IPFIXは、ソース・トリガによるプッシュモデルのアプローチに情報のエクスポートをサポートしています。それにもかかわらず、さらにエクスポート基準は、とだけでなく、フロー・エンドまたは固定の時間間隔に入射検出イベント時にIPFIXレコードをエクスポートするために実装する必要があります。

Intrusion detection would profit from the combination of IPFIX functions with AAA functions (see Section 3.5). Such an interoperation enables further means for attacker detection, advanced defense strategies, and secure inter-domain cooperation.


2.5. QoS Monitoring
2.5. QoSのモニタリング

Quality of service (QoS) monitoring is one target application of the IPFIX protocol [RFC3917]. QoS monitoring is the passive observation of the transmission quality for single Flows or traffic aggregates in the network. One example of its use is the validation of QoS guarantees in service level agreements (SLAs). Typical QoS parameters are loss [RFC2680], one-way [RFC2679] and round-trip delay [RFC2681], and delay variation [RFC3393]. Whenever applicable, the IP Performance Metrics (IPPM) definitions [RFC4148] should be used when reporting QoS metrics.

サービス(QoS)のモニタリングの質がIPFIXプロトコル[RFC3917]のいずれかのターゲットアプリケーションです。 QoSのモニタリングは、ネットワーク内の単一フローまたはトラフィック集合体のための伝送品質の受動的な観察です。その使用の一例は、サービスレベル契約(SLA)におけるQoS保証の検証です。典型的なQoSパラメータは、一方向[RFC2679]と往復遅延[RFC2681]、および遅延変動[RFC3393]損失[RFC2680]です。たび該当するQoSメトリックを報告するとき、IPパフォーマンス・メトリック(IPPM)の定義[RFC4148]は使用すべきです。

The calculation of those QoS metrics requires per-packet processing. Reporting packet information with IPFIX is possible by simply considering a single packet as Flow. [RFC5101] also allows the reporting of multiple identical Information Elements in one Flow Record. Using this feature for reporting information about multiple packets in one record would require additional agreement on semantics regarding the order of Information Elements (e.g., which timestamp belongs to which packet payload in a sequence of Information Elements). [RFC5477] defines useful additional Information Elements for exporting per-packet information with IPFIX.

これらのQoSメトリックの計算は、パケットあたりの処理が必要となります。 IPFIXでパケット情報を報告することは、単に流れとして単一のパケットを考慮することによって可能です。 [RFC5101]も1フローレコード内に複数の同一の情報要素の報告を可能にします。一つのレコードに複数のパケットに関する情報を報告するため、この機能を使用すると、情報要素(例えば、情報要素の順序でパケットペイロードどの属するタイムスタンプ)の順序に関するセマンティクスの追加契約が必要となります。 [RFC5477]はIPFIXとパケット単位の情報をエクスポートするために有用な追加の情報要素を定義します。

2.5.1. Correlating Events from Multiple Observation Points
2.5.1. 複数の観測点からの相関イベント

Some QoS metrics require the correlation of data from multiple Observation Points. For this, the clocks of the involved Metering Processes must be synchronized. Furthermore, it is necessary to recognize that the same packet was observed at different Observation Points.


This can be done by capturing parts of the packet content (packet header and/or parts of the payload) that do not change on the way to the destination. Based on the packet content, it can be recognized when the same packet arrived at another Observation Point. To reduce the amount of measurement data, a unique packet ID can be calculated from the packet content, e.g., by using a Cyclic Redundancy Check (CRC) or hash function instead of transferring and comparing the unprocessed content. Considerations on collision probability and efficiency of using such packet IDs are described in [GrDM98], [DuGr00], and [ZsZC01].


IPFIX allows the reporting of several IP and transport header fields (see Sections 5.3 and 5.4 in [RFC5102]). Using only those fields for packet recognition or ID generation can be sufficient in scenarios where those header fields vary a lot among subsequent packets, where a certain amount of packet ID collisions are tolerable, or where packet IDs need to be unique only for a small time interval.


For including packet payload information, the Information Element ipPayloadPacketSection defined in [RFC5477] can be used. The Information Element ipHeaderPacketSection can also be used. However, header fields that can change on the way from source to destination have to be excluded from the packet ID generation because they may differ at different Observation Points.


For reporting packet IDs generated by a CRC or hash function, the Information Element digestHashValue defined in [RFC5477] can be used.


2.5.2. Examples
2.5.2. 例

The following examples show which Information Elements need to be reported by IPFIX to generate specific QoS metrics. As an alternative, the metrics can be generated directly at the exporter and IPFIX can be used to export the metrics (see Section 2.7).

次の例では、情報要素は、特定のQoSメトリックを生成するために、IPFIXで報告する必要がある示しています。代替として、メトリックが輸出に直接生成することができ、IPFIXメトリック(セクション2.7を参照)をエクスポートするために使用することができます。 RTT Measurements with Packet Pair Matching (Single-Point)。パケットペアマッチングとRTTの測定(シングルポイント)

The passive measurement of round-trip time (RTT) can be performed by using packet pair matching techniques as described in [Brow00]. For the measurements, request/response packet pairs from protocols such as DNS, ICMP, SNMP or TCP (SYN/SYN_ACK, DATA/ACK) are utilized to passively observe the RTT [Brow00]. This technique requires the correlation of data from both directions.

【Brow00]で説明されるように、ラウンドトリップ時間(RTT)の受動的測定は、パケットペアマッチング技術を用いて行うことができます。測定のために、そのようなDNS、ICMP、SNMPまたはTCP(SYN / SYN_ACK、DATA / ACK)などのプロトコルからの要求/応答パケットペアは受動的に観察するために利用されるRTT [Brow00]。この技術は、両方向からのデータの相関を必要とします。

Required Information Elements per packet (DNS example): - Packet arrival time: observationTimeMicroseconds [RFC5477] - DNS header: ipPayloadPacketSection [RFC5477]

パケットごとに必要な情報要素(DNS例): - パケット到着時間:観測時間マイクロ秒[RFC 5477] - DNSヘッダー:ipPayloadPacketSection [RFC5477]

Required functions: - Recognition of request/response packet pairs

必要な機能: - 要求/応答パケットのペアの認識

Remarks: - Requires Information Elements from [RFC5477]. - observationTimeMicroseconds can be substituted by flowStartMicroseconds [RFC5102] because a single packet can be represented as a Flow. - If time values with a finer granularity are needed, observationTimeNanoseconds can be used.

備考: - [RFC5477]からの情報要素が必要です。 - 単一のパケットがフローとして表すことができるのでobservationTimeMicrosecondsはflowStartMicroseconds [RFC5102]で置換することができます。 - より細かい粒度で時間値が必要な場合は、observationTimeNanosecondsを使用することができます。 One-Way Delay Measurements (Multi-Point)。ワンウェイ遅延測定(マルチポイント)

Passive one-way delay measurements require the collection of data at two Observation Points. As mentioned above, synchronized clocks are needed to avoid time-differences at the involved Observation Points.


The recognition of packets at the second Observation Point can be based on parts of the packet content directly. A more efficient way is to use a packet ID (generated from packet content).


Required Information Elements per packet (with packet ID): - Packet arrival time: observationTimeMicroseconds [RFC5477] - Packet ID: digestHashValue [RFC5477]

(パケットIDを持つ)パケットごとに必要な情報要素: - パケット到着時間:observationTimeMicroseconds [RFC5477] - パケットID:digestHashValue [RFC5477]

Required functions: - Packet ID generation - Delay calculation (from arrival times at the two Observation Points)

必要な機能: - パケットIDの生成 - (2つの観測点での到着時間からの)遅延計算

Remarks: - Requires Information Elements from [RFC5477]. - observationTimeMicroseconds can be substituted by flowStartMicroseconds [RFC5102], because a single packet can be represented as a Flow. - If time values with a finer granularity are needed, observationTimeNanoseconds can be used.

備考: - [RFC5477]からの情報要素が必要です。 - 単一のパケットがフローとして表すことができるのでobservationTimeMicrosecondsは、flowStartMicroseconds [RFC5102]で置換することができます。 - より細かい粒度で時間値が必要な場合は、observationTimeNanosecondsを使用することができます。

- The amount of content used for ID generation influences the number of collisions (different packets that map to the same ID) that can occur. Investigations on this and other considerations on packet ID generation can be found in [GrDM98], [DuGr00], and [ZsZC01].

- IDの生成に使用されるコンテンツの量が発生する可能性が衝突(同じIDにマップ異なるパケット)の数に影響を与えます。このパケットID生成に関する他の考慮事項は、[GrDM98]に見出すことができ、[DuGr00]、および[ZsZC01]の検討。

2.6. Inter-Domain Exchange of IPFIX Data
2.6. IPFIXデータのドメイン間取引

IPFIX data can be used to share information with neighbor providers. A few recommendations should be considered if IPFIX records travel over the public Internet, compared to its usage within a single domain. First of all, security threat levels are higher if data travels over the public Internet. Protection against disclosure or manipulation of data is even more important than for intra-domain usage. Therefore, Transport Layer Security (TLS) or Datagram Transport Layer Security should be used as described in [RFC5101].

IPFIXデータは、隣接プロバイダと情報を共有するために使用することができます。 IPFIXレコードが公共のインターネット上で旅行する場合、いくつかの推奨事項は、単一のドメイン内でその使用法に比べて、考慮されるべきです。データは、公衆インターネット上を移動する場合はまず、セキュリティ上の脅威のレベルが高くなっています。データの漏洩や不正操作に対する保護がさらに重要ドメイン内の使用のために超えています。 [RFC5101]に記載されているように、したがって、トランスポート層セキュリティ(TLS)またはデータグラムトランスポート層セキュリティを使用すべきです。

Furthermore, data transfer should be congestion-aware in order to allow untroubled coexistence with other data Flows in public or foreign networks. That means transport over Stream Control Transmission Protocol (SCTP) or TCP is required.


Some ISPs are still reluctant to share information due to concerns that competing ISPs might exploit network information from neighbor providers to strengthen their own position in the market. Nevertheless, technical needs have already triggered the exchange of data in the past (e.g., exchange of routing information by BGP). The need to provide inter-domain guarantees is one big incentive to increase inter-domain cooperation. The necessity to defend networks against current and future threats (denial-of-service attacks, worm distributions, etc.) will hopefully increase the willingness to exchange measurement data between providers.


2.7. Export of Derived Metrics
2.7. 派生メトリックのエクスポート

The IPFIX protocol is used to transport Flow and packet information to provide the input for the calculation of a variety of metrics (e.g., for QoS validation or attack detection). IPFIX can also be used to transfer these metrics directly, e.g., if the metric calculation is co-located with the Metering and Exporting Processes.


It doesn't matter which measurement and post-processing functions are applied to generate a specific metric. IPFIX can be used to transport the results from passive and active measurements and from post-processing operations. For the reporting of derived metrics, additional Information Elements need to be defined.

計測および後処理機能は、特定のメトリックを生成するために適用されている問題ではありません。 IPFIXは、受動的および能動的測定から後処理操作からの結果を輸送するために使用することができます。派生メトリックの報告のために、追加の情報要素を定義する必要があります。

For most QoS metrics like loss, delay, delay variation, etc., standard IPPM definitions exist. In case such metrics are reported with IPFIX, the IPPM standard definition should be used.


2.8. Summary
2.8. 概要

The following table shows an overview of the Information Elements required for the target applications described in [RFC3917] (M-mandatory, R-recommended, O-optional).


      | Application |  [RFC5102] |   [RFC5477]  | additional IEs  |
      | Accounting  |     M      |      -       |       -         |
      | Traffic     |     M      |      O       |       -         |
      | Profiling   |            |              |                 |
      | Traffic     |     M      |      -       |       O         |
      | Engineering |            |              | (routing info)  |
      | Attack      |     M      |      R       |       R         |
      | Detection   |            |              |(derived metrics)|
      | QoS         |     M      |      M       |       O         |
      | Monitoring  |            |(most metrics)|(derived metrics)|

For accounting, the IEs in [RFC5102] are sufficient. As mentioned above, IPFIX does not conform to the reliability requirements demanded by [RFC2975] for usage-based billing systems (see Section 4.2). For traffic profiling, additional IEs from [RFC5477] can be useful to gain more insight into the traffic. For traffic engineering, Flow information from [RFC5102] is sufficient, but it would profit from routing information, which could be exported by IPFIX. Attack detection usually profits from further insight into the traffic. This can be achieved with IEs from [RFC5477]. Furthermore, the reporting of derived metrics in additional IEs would be useful. Most QoS metrics require the use of IEs from [RFC5477]. IEs from [RFC5477] are also useful for the mapping of results from different Observation Points as described in Section 2.5.1.


3. Relation of IPFIX to Other Frameworks and Protocols
3.1. IPFIX and IPv6
3.1. IPFIXとIPv6

From the beginning, IPFIX has been designed for IPv4 and IPv6. Therefore, IPFIX can be used in IPv4 and IPv6 networks without limitations. The usage of IPFIX in IPv6 networks has two aspects:

当初から、IPFIXは、IPv4とIPv6のために設計されています。したがって、IPFIXは、制限なく、IPv4とIPv6ネットワークで使用することができます。 IPv6ネットワークでのIPFIXの使用は、2つの側面があります。

- Generation and reporting of IPFIX records about IPv6 traffic - Exporting IPFIX records over IPv6

- 世代およびIPv6トラフィックに関するIPFIXレコードの報告 - IPv6の上IPFIXレコードのエクスポート

The generation and reporting of IPFIX records about IPv6 traffic is possible. Appropriate Information Elements for the reporting of IPv6 traffic are defined in [RFC5102]. Exporting IPFIX records over IPv6 is not explicitly addressed in [RFC5101]. Since IPFIX runs over a transport protocol (SCTP, PR-SCTP, UDP, or TCP) and all potential IPFIX transport protocols can run in IPv6 networks, one just needs to provide the chosen transport protocol in the IPv6 network to run IPFIX over IPv6.

IPv6トラフィックに関するIPFIXレコードの生成と報告が可能です。 IPv6トラフィックの報告のための適切な情報要素は[RFC5102]で定義されています。 IPv6の上IPFIXレコードをエクスポートするには、明示的に[RFC5101]で扱われていません。 IPFIXので、トランスポートプロトコル(SCTP、PR-SCTP、UDP、またはTCP)上で実行され、すべての潜在的なIPFIXのトランスポートプロトコルは、IPv6ネットワークで実行することができ、一つはただのIPv6上でIPFIXを実行するために、IPv6ネットワークで選択されたトランスポートプロトコルを提供する必要があります。

3.2. IPFIX and PSAMP

PSAMP defines packet selection methods, their configuration at routers and probes, and the reporting of packet information.


PSAMP uses IPFIX as a basis for exporting packet information [RFC5476]. [RFC5477] describes further Information Elements for exporting packet information and reporting configuration information.

PSAMPは、パケット情報[RFC5476]をエクスポートするための基礎としてIPFIXを使用します。 [RFC5477]はパケット情報をエクスポートし、設定情報を報告するために更なる情報要素について説明します。

The main difference between IPFIX and PSAMP is that IPFIX addresses the export of Flow Records, whereas PSAMP addresses the export of packet records. Furthermore, PSAMP explicitly addresses remote configuration. It defines a MIB for the configuration of packet selection processes. Remote configuration is not (yet) addressed in IPFIX, but one could consider extending the PSAMP MIB to also allow configuration of IPFIX processes.

IPFIXとPSAMPの主な違いは、PSAMPは、パケットレコードのエクスポートを扱うのに対し、IPFIXは、フローレコードの輸出を扱っていることです。さらに、PSAMPは、明示的にリモート設定に対応しています。これは、パケット選択プロセスの構成のためのMIBを定義します。リモート構成は(まだ)ないIPFIXで対処、しかし、1つはまた、IPFIXプロセスの設定を可能にPSAMP MIBを拡張考えることができます。

3.3. IPFIX and RMON

Remote Monitoring (RMON) [RFC3577] is a widely used monitoring system that gathers traffic data from RMON Agents in network devices. One major difference between RMON and IPFIX is that RMON uses SNMP for data export, whereas IPFIX defines its own push-oriented protocol. RMON defines MIBs that contain the information to be exported. In IPFIX, the data to be exported is defined as Information Elements.

リモートモニタリング(RMON)[RFC3577]は、ネットワークデバイスにRMONエージェントからのトラフィック・データを収集広く使用されている監視システムです。 RMONとIPFIXとの間の1つの大きな違いは、IPFIXは、独自のプッシュ指向のプロトコルを定義するのに対し、RMONは、データエクスポート用にSNMPを使用していることです。 RMONは、エクスポートされる情報が含まれているMIBを定義します。 IPFIXでは、エクスポートされるデータは、情報要素として定義されます。

The most relevant MIBs for comparison with IPFIX are the Application Performance Measurement MIB (APM-MIB) [RFC3729] and the Transport Performance Metrics MIB (TPM-MIB) [RFC4150]. The APM-MIB has a complex system for tracking user application performance, with reporting about transactions and SLA threshold notification-trigger configuration, and persistence across DHCP lease expirations. It requires a full RMON2-MIB protocolDirTable implementation.

IPFIXとの比較のために最も関連のMIBは、アプリケーションのパフォーマンス測定MIB(APM-MIB)[RFC3729]とトランスポート・パフォーマンス・メトリックMIB(TPM-MIB)[RFC4150]です。 APM-MIBは、DHCPリース満了横切ってトランザクションとSLAしきい値通知トリガ構成、および持続性について報告して、ユーザアプリケーションのパフォーマンスを追跡するための複雑なシステムを有します。これは、完全なRMON2-MIB protocolDirTableの実装が必要です。

The APM-MIB reports the performance of transactions. A transaction is a service-oriented term and describes the data exchange from the transaction start (when a user requests a service) until its completion. The performance parameters include response times, throughput, streaming responsiveness, and availability of services.


The RMON transaction concept differs from the IPFIX Flow concept. A Flow is a very generic term that allows one to group IP packets in accordance with common properties. In contrast to this, the term transaction is service-oriented and contains all data exchange required for service completion.


In order to report such data with IPFIX, one would probably need a specific combination of multiple Flows and the ability to map those to the transaction. Due to the service-oriented focus of APM, the required metrics also differ. For instance, the RMON APM requires a metric for the responsiveness of services. Such metrics are not addressed in IPFIX.

IPFIXと、このようなデータを報告するためには、おそらく、複数のフローの特定の組み合わせとの取引にそれらをマッピングする機能が必要になります。 APMのサービス指向焦点のため、必要な測定基準も異なります。たとえば、RMON APMは、サービスの応答性のメトリックが必要です。このようなメトリックは、IPFIXで対処されていません。

Furthermore, the APM-MIB allows the configuration of the transaction type to be monitored, which is currently not addressed in IPFIX.


The APM MIB could be considered as an extension of the IPFIX Metering Process where the application performance of a combination of multiple Flows is measured. If appropriate, IEs would be defined in the IPFIX information model and the IPFIX Device would support the APM MIB data collection, the solutions could be complementary. That means one could use IPFIX to export APM MIB transaction information.

APM MIBは、複数のフローの組み合わせのアプリケーションのパフォーマンスが測定されるIPFIX計量プロセスの拡張とみなすことができます。適切な場合、IEはIPFIX情報モデルで定義されることになると、APM MIBデータの収集をサポートするIPFIXデバイスは、ソリューションが補完的である可能性があります。それは1つがAPM MIBのトランザクション情報をエクスポートするIPFIXを使用することができますを意味します。

The TPM-MIB breaks out the APM-MIB transactions into sub-application level transactions. For instance, a web request is broken down into DNS, TCP, and HTTP sub-transactions. Such sub-transactions can be considered as bidirectional Flows. With an appropriate Flow definition and the ability to map both directions of a Flow (see Section 4.6), one could measure and report Flow characteristics of such sub-application level transaction with IPFIX.


The TPM-MIB requires APM-MIB and RMON2-MIB.


3.4. IPFIX and IPPM

The IPFIX protocol can be used to carry IPPM network performance metrics or information that can be used to calculate those metrics (see Sections 2.5 and 2.7 for details and references).


3.5. IPFIX and AAA

AAA defines a protocol and architecture for authentication, authorization, and accounting for service usage [RFC2903]. The DIAMETER protocol [RFC3588] is used for AAA communication, which is needed for network access services (Mobile IP, NASREQ, and ROAMOPS). The AAA architecture [RFC2903] provides a framework for extending AAA support to other services. DIAMETER defines the exchange of messages between AAA entities, e.g., between AAA clients at access devices and AAA servers, and among AAA servers. DIAMETER is used for the transfer of accounting records. In order to form accounting records for usage-based accounting measurement, data from the network is required. IPFIX defines a protocol to export such data from routers, measurement probes, and other devices. Therefore, it looks promising to connect those two architectures.

AAAは、サービス利用[RFC2903]のための認証、許可、およびアカウンティングのためのプロトコルおよびアーキテクチャを定義します。 DIAMETERプロトコル[RFC3588]は、ネットワーク・アクセス・サービス(モバイルIP、NASREQ、及びROAMOPS)のために必要とされるAAAの通信に使用されます。 AAAアーキテクチャ[RFC2903]は、他のサービスにAAAサポートを拡張するためのフレームワークを提供します。 DIAMETERは、例えば、アクセスデバイスでのAAAクライアントとAAAサーバの間、およびAAAサーバ間で、AAAエンティティ間のメッセージの交換を定義します。 DIAMETERは、会計記録の転送に使用されます。従量課金測定用アカウンティングレコードを形成するために、ネットワークからのデータが必要です。 IPFIXは、ルータ、測定プローブ、および他のデバイスからそのようなデータをエクスポートするためのプロトコルを定義します。したがって、これらの二つのアーキテクチャを接続するために有望に見えます。

For all scenarios described here, one has to keep in mind that IPFIX does not conform to the reliability requirements for usage-based billing described in [RFC2975] (see Section 4.2). Using IPFIX without reliability extensions together with AAA would result in accounting scenarios that do not conform to usage-based billing requirements described in [RFC2975].

ここに記載されているすべてのシナリオでは、1はIPFIXは、[RFC2975]で説明使用量ベースの課金のための信頼性要件に準拠していないことを心に留めておく必要があります(セクション4.2を参照してください)。 AAAと一緒に、信頼性の拡張子なしIPFIXを使用すると、[RFC2975]で説明使用量ベースの課金の要件に準拠していない会計のシナリオにつながります。

As shown in Section 2.1, accounting applications can directly incorporate an IPFIX Collecting Process to receive IPFIX records with information about the transmitted volume. Nevertheless, if a AAA infrastructure is in place, the cooperation between IPFIX and AAA provides many valuable synergistic benefits. IPFIX records can provide the input for AAA accounting functions and provide the basis for the generation of DIAMETER accounting records. However, as stated in Section 4.2, the use of IPFIX as described in [RFC5101] is currently limited to situations where the purpose of the accounting does not require reliability.

セクション2.1に示されているように、会計アプリケーションに直接送信容量に関する情報をIPFIXレコードを受信するようにIPFIX収集プロセスを組み込むことができます。 AAAインフラが整備されている場合にもかかわらず、IPFIXとAAAとの協力は、多くの貴重な相乗的な利点を提供します。 IPFIXレコードは、AAAアカウンティング機能のための入力を提供し、DIAMETERのアカウンティングレコードの生成のための基礎を提供することができます。セクション4.2で述べたようしかし、[RFC5101]に記載されているようにIPFIXの使用は、現在の会計の目的は、信頼性を必要としない状況に限定されています。

Further potential features include the mapping of a user ID to Flow information (by using authentication information) or using the secure authorized exchange of DIAMETER accounting records with neighbor domains. The last feature is especially useful in roaming scenarios where the user connects to a foreign network and the home provider generates the invoice.


Coupling an IPFIX Collecting Process with AAA functions also has high potential for intrusion and attack detection. AAA controls network access and maintains data about users and nodes. AAA functions can help to identify the source of malicious traffic. Authorization functions are able to deny access to suspicious users or nodes. Therefore, coupling those functions with an IPFIX Collecting Process can provide an efficient defense against network attacks.

AAA機能を収集処理IPFIXを結合することも侵入や攻撃検出のための高い可能性を有します。 AAAは、ネットワークアクセスを制御し、ユーザーやノードに関するデータを保持します。 AAA機能は、悪意のあるトラフィックの送信元を識別するのに役立ちます。認証機能は、不審なユーザーやノードへのアクセスを拒否することができます。したがって、IPFIX収集プロセスとそれらの機能を結合することは、ネットワーク攻撃に対する効率的な防御を提供することができます。

Sharing IPFIX records (either directly or encapsulated in DIAMETER) with neighbor providers allows an efficient inter-domain attack detection. For this, it would be useful to allow remote configuration of measurement and record generation in order to provide information in the required granularity and accuracy. Since remote configuration is currently not addressed in IPFIX, this would require additional work. The AAA infrastructure itself may be used to configure measurement functions in the network as proposed in [RFC3334].

隣人プロバイダーとIPFIXレコードを(直接またはDIAMETERにカプセル化)共有することで、効率的なドメイン間の攻撃を検出することができます。このため、必要な精度と正確さの情報を提供するために測定及び記録世代の遠隔構成を可能にするのに有用であろう。リモート設定が現在IPFIXで対処されていないので、これは追加の作業が必要になります。 [RFC3334]で提案されているようにAAAインフラストラクチャ自体は、ネットワーク内の測定機能を設定するために使用することができます。

Furthermore, the transport of IPFIX records with DIAMETER would require the translation of IPFIX Information Elements into DIAMETER attribute value pairs (AVPs) defined in [RFC3588]. Since the DIAMETER AVPs do not comprise all IPFIX Information Elements, it is necessary to define new AVPs to transport them over DIAMETER.

さらに、直径IPFIXレコードの輸送は、[RFC3588]で定義されたDIAMETER属性値ペア(AVPの)にIPFIX情報要素の翻訳を必要とします。 DIAMETERのAVPのは、すべてのIPFIX情報要素を含んでいないので、DIAMETERの上にそれらを輸送するために新しいAVPを定義する必要があります。

Two possibilities exist to connect IPFIX and AAA:


- Connecting via a AAA Client - Connecting via an Application Specific Module (ASM)

- AAAクライアントを介して接続 - アプリケーション固有モジュール(ASM)を介して接続

Both are explained in the following sections. The approaches only require a few additional functions. They do not require any changes to IPFIX or DIAMETER.


3.5.1. Connecting via a AAA Client
3.5.1. AAAクライアントを経由して接続します

One possibility of connecting IPFIX and AAA is to run a AAA client on the IPFIX Collector. This client can generate DIAMETER accounting messages and send them to a AAA server. The mapping of the Flow information to a user ID can be done in the AAA server by using data from the authentication process. DIAMETER accounting messages can be sent to the accounting application or to other AAA servers (e.g., in roaming scenarios).

IPFIXとAAAを接続する一つの可能​​性はIPFIXコレクターにAAAクライアントを実行することです。このクライアントは、DIAMETERアカウンティングメッセージを生成し、AAAサーバに送信することができます。ユーザーIDにフロー情報のマッピングは、認証プロセスからのデータを使用して、AAAサーバで行うことができます。 DIAMETERアカウンティングメッセージは、会計アプリケーション、または他のAAAサーバ(例えば、ローミングのシナリオで)に送信することができます。

                    +---------+  DIAMETER    +---------+
                    |  AAA-S  |------------->|  AAA-S  |
                    +---------+              +---------+
                         | DIAMETER
                  |  |  AAA-C |  |
                  +  +--------+  |
                  |              |
                  |  Collector   |
                         | IPFIX
                   |  Exporter  |

Figure 1: IPFIX Collector connects to AAA server via AAA client


3.5.2. Connecting via an Application Specific Module (ASM)
3.5.2. アプリケーション固有モジュール(ASM)を介して接続

Another possibility is to directly connect the IPFIX Collector with the AAA server via an application specific module (ASM). Application specific modules have been proposed by the IRTF AAA architecture research group (AAARCH) in [RFC2903]. They act as an interface between AAA server and service equipment. In this case, the IPFIX Collector is part of the ASM. The ASM acts as an interface between the IPFIX protocol and the input interface of the AAA server. The ASM translates the received IPFIX data into an appropriate format for the AAA server. The AAA server then can add information about the user ID and generate a DIAMETER accounting record. This accounting record can be sent to an accounting application or to other AAA servers.

別の可能性は、直接アプリケーション固有モジュール(ASM)を介してAAAサーバとIPFIXコレクタを接続することです。特定用途向けモジュールは、[RFC2903]にIRTFのAAAアーキテクチャ研究グループ(AAARCH)によって提案されています。彼らは、AAAサーバとサービス機器間のインタフェースとして機能します。この場合、IPFIXコレクターは、ASMの一部です。 ASMは、IPFIXプロトコルとAAAサーバの入力インタフェースとの間のインタフェースとして機能します。 ASMは、AAAサーバに適したフォーマットに受け入れIPFIXデータを変換します。 AAAサーバは、ユーザIDに関する情報を追加して、DIAMETERアカウンティングレコードを生成することができます。このアカウンティングレコードは、会計アプリケーションや他のAAAサーバに送信することができます。

                       +---------+  DIAMETER    +---------+
                       |  AAA-S  |------------->|  AAA-S  |
                       +---------+              +---------+
                    |     ASM          |
                    |  +------------+  |
                    |  |  Collector |  |
                            | IPFIX
                      |  Exporter  |

Figure 2: IPFIX connects to AAA server via ASM


3.6. IPFIX and RTFM

The Realtime Traffic Flow Measurement (RTFM) working group defined an architecture for Flow measurement [RFC2722]. This section compares the RTFM framework with the IPFIX framework.


3.6.1. Architecture
3.6.1. 建築

The RTFM architecture [RFC2722] is very similar to the IPFIX architecture. It defines meter, meter reader, and a manager as building blocks of the measurement architecture. The manager configures the meter, and the meter reader collects data from the meter. In RTFM, the building blocks communicate via SNMP.

RTFMアーキテクチャ[RFC2722]はIPFIXアーキテクチャに非常に類似しています。これは、測定アーキテクチャのビルディングブロックとして計、メータリーダ、およびマネージャを定義します。マネージャは、計器を構成し、メーター読者は、メータからデータを収集します。 RTFMでは、ビルディングブロックは、SNMPを介して通信します。

The IPFIX architecture [RFC5470] defines Metering, Exporting, and Collecting Processes. IPFIX speaks about processes instead of devices to clarify that multiple of those processes may be co-located on the same machine.

IPFIXアーキテクチャ[RFC5470]は測光、エクスポート、および収集プロセスを定義します。 IPFIXは、プロセスの代わりに、それらのプロセスの複数が同じマシン上で同じ場所に配置することができることを明確にする装置について話します。

These definitions do not contradict each other. One could see the Metering Process as part of the meter, and the Collecting Process as part of the meter reader.


One difference is that IPFIX currently does not define a managing process because remote configuration was (at least initially) out of scope for the working group.


3.6.2. Flow Definition
3.6.2. フロー定義

RTFM and IPFIX both consider Flows as a group of packets that share a common set of properties. A Flow is completely specified by that set of values, together with a termination criterion (like inactivity timeout).


A difference is that RTFM defines Flows as bidirectional. An RTFM meter matches packets from B to A and A to B as separate parts of a single Flow, and it maintains two sets of packet and byte counters, one for each direction.

違いはRTFMが双方向としてフローを定義することです。 RTFMメーターは単一のフローの別個の部品としてBにAをBとAからのパケットと一致し、それは、パケットおよびバイトカウンタを、各方向に1つの二組を維持します。

IPFIX does not explicitly state whether Flows are uni- or bidirectional. Nevertheless, Information Elements for describing Flow properties were defined for only one direction in [RFC5102]. There are several solutions for reporting bidirectional Flow information (see Section 4.6).


3.6.3. Configuration and Management
3.6.3. 設定と管理

In RTFM, remote configuration is the only way to configure a meter. This is done by using SNMP and a specific Meter MIB [RFC2720]. The IPFIX group currently does not address IPFIX remote configuration.

RTFMでは、リモート設定はメーターを設定するための唯一の方法です。これは、SNMPおよび特定のメーターMIB [RFC2720]を使用して行われます。 IPFIXグループは、現在、IPFIXリモート設定に対応していません。

IPFIX Metering Processes export the layout of data within their Templates, from time to time. IPFIX Collecting Processes use that Template information to determine how they should interpret the IPFIX Flow data they receive.


3.6.4. Data Collection
3.6.4. データ収集

One major difference between IPFIX and RTFM is the data collection model. RTFM retrieves data in pull mode, whereas IPFIX uses a push mode model to send data to Collecting Processes.

IPFIXとRTFMとの間の1つの大きな違いは、データ収集モデルです。 IPFIXは収集プロセスにデータを送信するためにプッシュ・モード・モデルを使用し、一方RTFMは、プルモードでデータを取得します。

An RTFM meter reader pulls data from a meter by using SNMP. SNMP security on the meter determines whether a reader is allowed to pull data from it. An IPFIX Exporting Process is configured to export records to a specified list of IPFIX Collecting Processes. The condition of when to send IPFIX records (e.g., Flow termination) has to be configured in the Exporting or Metering Process.

RTFMメーターリーダーは、SNMPを使って計からデータを取得します。メーターのSNMPセキュリティは、リーダーがそれからデータを取得することが許可されているかどうかを決定します。 IPFIXエクスポートプロセスは、プロセスを収集IPFIXの指定されたリストにレコードをエクスポートするよう構成されています。 IPFIXレコード(例えば、フローターミネーション)を送信する場合の条件は、エクスポートまたは計量プロセスで構成されなければなりません。

3.6.5. Data Model Details
3.6.5. データモデル詳細

RTFM defines all its attributes in the RTFM Meter MIB [RFC2720]. IPFIX Information Elements are defined in [RFC5102].

RTFMはRTFMメーターMIB [RFC2720]ですべての属性を定義します。 IPFIX情報要素は[RFC5102]で定義されています。

RTFM uses continuously-incrementing 64-bit counters for the storage of the number of packets of a Flow. The counters are never reset and just wrap back to zero if the maximum value is exceeded. Flows can be read at any time. The difference between counter readings gives the counts for activity in the interval between readings.


IPFIX allows absolute (totalCounter) and relative counters (deltaCounter) [RFC5102]. The totalCounter is never reset and just wraps to zero if values are too large, exactly as the counters used in RTFM. The deltaCounter is reset to zero when the associated Flow Record is exported.

IPFIXは、絶対(totalCounter)及び相対カウンタ(deltaCounter)[RFC5102]を可能にします。 totalCounterは正確にRTFMに使用されるカウンタとして、リセットされず、ただ値が大きすぎる場合は、ゼロにラップありません。 deltaCounterは、関連するフローレコードがエクスポートされたときにゼロにリセットされます。

3.6.6. Transport Protocol
3.6.6. トランスポートプロトコル

RTFM has a Standards-Track Meter MIB [RFC2720], which is used both to configure a meter and to store metering results. The MIB provides a way to read lists of attributes with a single Object Identifier (called a 'package'), which reduces the SNMP overhead for Flow data collection. SNMP, of course, normally uses UDP as its transport protocol. Since RTFM requires a reliable Flow data transport system, an RTFM meter reader must time out and resend unanswered SNMP requests. Apart from being clumsy, this can limit the maximum data transfer rate from meter to meter reader.

RTFMメーターを設定し、計量結果を格納するための両方に使用される標準トラックメーターMIB [RFC2720]を有します。 MIBは、フローデータ収集のためのSNMPのオーバーヘッドを削減(「パッケージ」と呼ばれる)、単一のオブジェクト識別子と属性のリストを読み込むための方法を提供します。 SNMPは、当然のことながら、通常、そのトランスポートプロトコルとしてUDPを使用しています。 RTFMは、信頼性の高いフローデータ転送システムを必要とするので、RTFMメーターリーダーはタイムアウトして未解決のSNMP要求を再送信する必要があります。離れ不器用であるから、これはメーターからメーター読者に最大データ転送速度を制限することができます。

IPFIX is designed to work over a variety of different transport protocols. SCTP [RFC4960] and PR-SCTP [RFC3758] are mandatory. UDP and TCP are optional. In addition, the IPFIX protocol encodes data much more efficiently than SNMP does, hence IPFIX has lower data transport overheads than RTFM.

IPFIXは、異なるトランスポートプロトコルのさまざまなオーバー動作するように設計されています。 SCTP [RFC4960]とPR-SCTP [RFC3758]は必須です。 UDPとTCPはオプションです。また、IPFIXプロトコルは、はるかに効率的にSNMPをよりもデータを符号化し、それゆえIPFIXはRTFMより低いデータ転送オーバーヘッドを有しています。

3.6.7. Summary
3.6.7. 概要

IPFIX exports Flow information in a push model by using SCTP, TCP, or UDP. It currently does not address remote configuration. RTFM data collection is using the pull model and runs over SNMP. RTFM addresses remote configuration, which also runs over SNMP. Both frameworks allow a very flexible Flow definition, although RTFM is based on a bidirectional Flow definition.

IPFIXはSCTP、TCP、またはUDPを使用して、プッシュモデルでフロー情報をエクスポートします。これは、現在のリモート設定に対応していません。 RTFMデータ収集は、SNMP経由プルモデルと実行を使用しています。 RTFMはまた、SNMP上で実行するリモートコンフィギュレーションを、対応しています。 RTFMが双方向フロー定義に基づいているが、両方のフレームワークは、非常に柔軟なフロー定義を可能にします。

4. Limitations

The goal of this section is to show the limitations of IPFIX and to give advice where not to use IPFIX or in which cases additional considerations are required.


4.1. Using IPFIX for Other Applications than Listed in
4.1. に記載されている以外の用途にIPFIXを使用します

IPFIX provides a generic export mechanism. Due to its Template-based structure, it is a quite flexible protocol. Network operators and users may want to use it for other applications than those described in [RFC3917].

IPFIXは、一般的な輸出メカニズムを提供します。 、そのテンプレートベース構造に、それは非常に柔軟なプロトコルです。ネットワークオペレータおよびユーザーは、[RFC3917]に記載されているもの以外の用途のためにそれを使用することをお勧めします。

Apart from sending raw Flow information, it can be used to send per-packet data, aggregated or post-processed data. For this, new Templates and Information Elements can be defined if needed. Due to its push mode operation, IPFIX is also suited to send network initiated events like alarms and other notifications. It can be used for exchanging information among network nodes to autonomously improve network operation.


Nevertheless, the IPFIX design is based on the requirements that originate only from the target applications stated in [RFC3917]. Using IPFIX for other purposes requires a careful checking of IPFIX capabilities against application requirements. Only with this, one can decide whether IPFIX is a suitable protocol to meet the needs of a specific application.


4.2. Using IPFIX for Billing (Reliability Limitations)
4.2. 課金のためのIPFIXを使用する(信頼限界)

The reliability requirements defined in [RFC3917] are not sufficient to guarantee the level of reliability that is needed for usage-based billing systems as described in [RFC2975]. In particular, IPFIX does not support the following features required by [RFC2975]:


- Record loss: IPFIX allows the usage of different transport protocols for the transfer of data records. Resilience against the loss of IPFIX data records can be only provided if TCP or SCTP is used for the transfer of data records.

- レコード損失:IPFIXは、データレコードの転送のためのさまざまなトランスポートプロトコルの使用を可能にします。 TCPまたはSCTPは、データレコードの転送に使用されている場合IPFIXデータレコードの損失に対する弾力性にのみ提供することができます。

- Network or device failures: IPFIX does allow the usage of multiple Collectors for one Exporter, but it neither specifies nor demands the use of multiple Collectors for the provisioning of fault tolerance.

- ネットワークやデバイスの故障:IPFIXは1つの輸出業者のために複数のコレクターの使用を許可しませんが、それは指定しないでもフォールトトレランスのプロビジョニングのために複数のコレクターの使用を要求し、どちらも。

- Detection and elimination of duplicate records: This is currently not supported by IPFIX.

- 重複レコードの検出と除去:これは、現在IPFIXによってサポートされていません。

- Application layer acknowledgements: IPFIX does not support the control of measurement and Exporting Processes by higher-level applications. Application layer acknowledgements are necessary, e.g., to inform the Exporter in case the application is not able to process the data exported with IPFIX. Such acknowledgements are not supported in IPFIX.

- アプリケーション層肯定応答:IPFIXは、より高いレベルのアプリケーションによる測定の制御およびエクスポートプロセスをサポートしません。アプリケーション層肯定応答は、アプリケーションがIPFIXとエクスポートされたデータを処理することができない場合に輸出を通知するために、例えば、必要です。このような確認応答は、IPFIXではサポートされていません。

Further features like archival accounting and pre-authorization are out of scope of the IPFIX specification but need to be realized in billing system architectures as described in [RFC2975].


4.3. Using a Different Transport Protocol than SCTP
4.3. SCTPとは異なるトランスポートプロトコルを使用して

SCTP is the preferred protocol for IPFIX, i.e., a conforming implementation must work over SCTP. Although IPFIX can also work over TCP or UDP, both protocols have drawbacks [RFC5101]. Users should make sure they have good reasons before using protocols other than SCTP in a specific environment.

SCTPは、IPFIXのための好ましいプロトコルである、すなわち、適合実装は、SCTP上に働かなければなりません。 IPFIXはまた、TCPやUDP上で動作することができますが、両方のプロトコルには欠点[RFC5101]を持っています。ユーザーは、特定の環境でSCTP以外のプロトコルを使用する前に十分な理由を持っていることを確認しなければなりません。

4.4. Push vs. Pull Mode
4.4. プルモード対プッシュ

IPFIX works in push mode. That means IPFIX records are automatically exported without the need to wait for a request. The responsibility for initiating a data export lies with the Exporting Process.


Criteria for exporting data need to be configured at the Exporting Process. Therefore, push mode has more benefits if the trigger for data export is related to events at the Exporting Process (e.g., Flow termination, memory shortage due to large amount of Flows, etc.). If the protocol used pull mode, the Exporting Process would need to wait for a request to send the data. With push mode, it can send data immediately, e.g., before memory shortage would require a discarding of data.


With push mode, one can prevent the overloading of resources at the Exporting Process by simply exporting the information as soon as certain thresholds are about to be exceeded. Therefore, exporting criteria are often related to traffic characteristics (e.g., Flow timeout) or resource limitations (e.g., size of Flow cache). However, traffic characteristics are usually quite dynamic and often impossible to predict. If they are used to trigger Flow export, the exporting rate and the resource consumption for Flow export becomes variable and unpredictable.


Pull mode has advantages if the trigger for data export is related to events at the Collecting Process (e.g., a specific application requests immediate input).


In a pull mode, a request could simply be forwarded to the Exporting Process. In a push mode, the exporting configuration must be changed to trigger the export of the requested data. Furthermore, with pull mode, one can prevent the overloading of the Collecting Process by the arrival of more records than it can process.


Whether this is a relevant drawback depends on the flexibility of the IPFIX configuration and how IPFIX configuration rules are implemented.


4.5. Template ID Number
4.5. テンプレートのID番号

The IPFIX specification limits the different Template ID numbers that can be assigned to the newly generated Template records in an Observation Domain. In particular, Template IDs up to 255 are reserved for Template or option sets (or other sets to be created) and Template IDs from 256 to 65535 are assigned to data sets. In the case of many exports requiring many different Templates, the set of Template IDs could be exhausted.


4.6. Exporting Bidirectional Flow Information
4.6. 双方向フロー情報のエクスポート

Although IPFIX does not explicitly state that Flows are unidirectional, Information Elements that describe Flow characteristics are defined only for one direction in [RFC5102]. [RFC5101] allows the reporting of multiple identical Information Elements in one Flow Record. With this, Information Elements for forward and reverse directions can be reported in one Flow Record.

IPFIXは、明示的にフローが単方向であることを述べる、情報要素流量特性を記述しているものではないが唯一[RFC5102]で一つの方向のために定義されています。 [RFC5101]は1フローレコード内に複数の同一の情報要素の報告を可能にします。これにより、前進方向と逆方向のための情報要素は、1フローレコードで報告することができます。

However, this is not sufficient. Using this feature for reporting bidirectional Flow information would require an agreement on the semantics of Information Elements (e.g., first counter is the counter for the forward direction, the second counter for the reverse direction).


Another option is to use two adjacent Flow Records to report both directions of a bidirectional Flow separately. This approach requires additional means for mapping those records and is quite inefficient due to the redundant reporting of Flow Keys.


4.7. Remote Configuration
4.7. リモート設定

Remote configuration was initially out of scope of the IPFIX working group in order to concentrate on the protocol specification. Therefore, there is currently no standardized way to configure IPFIX processes remotely. Nevertheless, due to the broad need for this feature, it is quite likely that solutions for this will be standardized soon.


5. Security Considerations

This document describes the usage of IPFIX in various scenarios. Security requirements for IPFIX target applications and security considerations for IPFIX are addressed in [RFC3917] and [RFC5101]. Those requirements have to be met for the usage of IPFIX for all scenarios described in this document. To our current knowledge, the usage scenarios proposed in Section 2 do not induce further security hazards.

この文書では、さまざまなシナリオにIPFIXの使用方法について説明します。 IPFIXのためのIPFIXターゲットアプリケーションとセキュリティ上の配慮のためのセキュリティ要件は[RFC3917]と[RFC5101]で扱われています。これらの要件は、本書に記載されているすべてのシナリオのIPFIXの使用のために満たされなければなりません。私たちの現在の知識に、第2節で提案されている使用シナリオは、さらにセキュリティ上の危険を誘発しません。

The threat level to IPIFX itself may depend on the usage scenario of IPFIX. The usage of IPFIX for accounting or attack detection may increase the incentive to attack IPFIX itself. Nevertheless, security considerations have to be taken into account in all described scenarios.


As described in the security considerations in [RFC5101], security incidents can become a threat to IPFIX processes themselves, even if IPIFX is not the target of the attack. If an attack generates a large amount of Flows (e.g., by sending packets with spoofed addresses or simulating Flow termination), Exporting and Collecting Processes may get overloaded by the immense amount of records that are exported. A flexible deployment of packet or Flow sampling methods can be useful to prevent the exhaustion of resources.


Section 3 of this document describes how IPFIX can be used in combination with other technologies. New security hazards can arise when two individually secure technologies or architectures are combined. For the combination of AAA with IPFIX, an application specific module (ASM) or an IPFIX Collector can function as a transit point for the messages. One has to ensure that at this point the applied security mechanisms (e.g., encryption of messages) are maintained.

このドキュメントのセクション3は、IPFIXは、他の技術と組み合わせて使用​​することができる方法を説明します。 2人の個別に安全な技術やアーキテクチャを組み合わせた場合、新たなセキュリティ上の危険が発生する可能性があります。 IPFIXとAAAとの組み合わせのために、アプリケーション固有のモジュール(ASM)またはIPFIXコレクタはメッセージの中継点として機能することができます。一つは、適用されるセキュリティメカニズムが(例えば、メッセージの暗号化)が維持され、この時点でそれを確実にしなければなりません。

6. Acknowledgements

We would like to thank the following people for their contributions, discussions on the mailing list, and valuable comments:


Sebastian Zander Robert Loewe Reinaldo Penno Lutz Mark Andy Biermann


Part of the work has been developed in the research project 6QM, co-funded with support from the European Commission.


7. Normative References

[RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics Registry", BCP 108, RFC 4148, August 2005.

[RFC4148]ステファン、E.、 "IPパフォーマンス・メトリック(IPPM)メトリクスレジストリ"、BCP 108、RFC 4148、2005年8月。

[RFC5101] Claise, B., Ed., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008.

[RFC5101] Claise、B.、エド。、RFC 5101、2008年1月 "IPトラフィックフロー情報を交換するためのIPフロー情報のエクスポート(IPFIX)プロトコルの仕様"。

[RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, January 2008.

[RFC5102] Quittek、J.、ブライアント、S.、Claise、B.、エイトケン、P.、およびJ.マイヤー、 "IPフロー情報のエクスポートのための情報モデル"、RFC 5102、2008年1月。

[RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. Carle, "Information Model for Packet Sampling Exports", RFC 5477, March 2009.

[RFC5477]ディーツ、T.、Claise、B.、エイトケン、P.、ドレスラー、F.、およびG.カール、RFC 5477 "情報モデルパケットサンプリングの輸出について"、2009年3月。

8. Informative References

[Brow00] Brownlee, N., "Packet Matching for NeTraMet Distributions", < netramet/packetmatching/>.

"パケットマッチング毛皮netramet分布"、オン[BR 00] braunli。<HTTP:vvvsaidaargtulsmessurment netramet / paketamatacing />。

[DuGr00] Duffield, N. and M. Grossglauser, "Trajectory Sampling for Direct Traffic Observation", Proceedings of ACM SIGCOMM 2000, Stockholm, Sweden, August 28 - September 1, 2000.

[DuGr00]ダッフィールド、N.およびM. Grossglauser、 "ノーリファラー観察のための軌道サンプリング"、ACMのSIGCOMM 2000の議事録、ストックホルム、スウェーデン、2000年8月28日から9月1日まで。

[GrDM98] Graham, I., Donnelly, S., Martin, S., Martens, J., and J. Cleary, "Nonintrusive and Accurate Measurement of Unidirectional Delay and Delay Variation on the Internet", INET'98, Geneva, Switzerland, 21-24 July, 1998.

【GrDM98]グラハム、I.、ドネリー、S.、マーティン、S.、マルテンス、J.、およびJ.クリアリー、「一方向遅延と遅延変動の非侵入と正確な測定インターネット上」、INET'98、ジュネーブスイス、21-24 1998年7月。

[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999.

[RFC2679] Almes、G.、Kalidindi、S.、およびM. Zekauskas、 "一方向IPPMの遅延メトリック"、RFC 2679、1999年9月。

[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999.

[RFC2680] Almes、G.、Kalidindi、S.、およびM. Zekauskas、 "IPPMための一方向パケット損失メトリック"、RFC 2680、1999年9月。

[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999.

[RFC2681] Almes、G.、Kalidindi、S.、およびM. Zekauskas、 "IPPMのラウンドトリップ遅延メトリック"、RFC 2681、1999年9月。

[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.

[RFC2702] Awduche、D.、マルコム、J.、Agogbua、J.、オデル、M.、およびJ.マクマナス、 "トラフィックエンジニアリングオーバーMPLSのための要件"、RFC 2702、1999年9月。

[RFC2720] Brownlee, N., "Traffic Flow Measurement: Meter MIB", RFC 2720, October 1999.

[RFC2720]ブラウンリー、N.、 "トラフィックフロー測定:メーターMIB"、RFC 2720、1999年10月。

[RFC2722] Brownlee, N., Mills, C., and G. Ruth, "Traffic Flow Measurement: Architecture", RFC 2722, October 1999.

[RFC2722]ブラウンリー、N.、ミルズ、C.、およびG.ルース、 "トラフィックフロー測定:アーキテクチャ"、RFC 2722、1999年10月。

[RFC2903] de Laat, C., Gross, G., Gommans, L., Vollbrecht, J., and D. Spence, "Generic AAA Architecture", RFC 2903, August 2000.

[RFC2903]デLAAT、C.、グロス、G.、Gommans、L.、Vollbrecht、J.、およびD.スペンス、 "汎用AAAアーキテクチャ"、RFC 2903、2000年8月。

[RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to Accounting Management", RFC 2975, October 2000.

[RFC2975] Aboba、B.、Arkko、J.、およびD.ハリントン、 "会計管理の概要"、RFC 2975、2000年10月。

[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.

[RFC3246]デイビー、B.、Charny、A.、ベネット、J.、ベンソン、K.、ルBoudec、J.、コートニー、W.、Davari、S.、Firoiu、V.、およびD. Stiliadis、 "緊急転送PHB(ホップ単位動作)」、RFC 3246、2002年3月。

[RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002.

[RFC3330] IANA、 "特殊用途IPv4アドレス"、RFC 3330、2002年9月。

[RFC3334] Zseby, T., Zander, S., and C. Carle, "Policy-Based Accounting", RFC 3334, October 2002.

[RFC3334] Zseby、T.、ザンダー、S.、およびC.カール、 "ポリシーベースの会計"、RFC 3334、2002年10月。

[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002.

[RFC3393]デミチェリス、C.およびP. Chimento、 "IPパフォーマンス・メトリックのためのIPパケット遅延変動メトリック(IPPM)"、RFC 3393、2002年11月。

[RFC3577] Waldbusser, S., Cole, R., Kalbfleisch, C., and D. Romascanu, "Introduction to the Remote Monitoring (RMON) Family of MIB Modules", RFC 3577, August 2003.

[RFC3577] Waldbusser、S.、コール、R.、Kalbfleisch、C.、およびD. Romascanu、 "MIBモジュールのリモートモニタリング(RMON)ファミリーの紹介"、RFC 3577、2003年8月。

[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

[RFC3588]カルフーン、P.、Loughney、J.、ガットマン、E.、ゾルン、G.、およびJ. Arkko、 "直径ベースプロトコル"、RFC 3588、2003年9月。

[RFC3729] Waldbusser, S., "Application Performance Measurement MIB", RFC 3729, March 2004.

[RFC3729] Waldbusser、S.、 "アプリケーションのパフォーマンス測定MIB"、RFC 3729、2004年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.、Ramalho、M.、謝、Q.、Tuexen、M.、およびP.コンラッド、 "ストリーム制御伝送プロトコル(SCTP)部分的な信頼性拡張"、RFC 3758、2004年5月。

[RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export (IPFIX)", RFC 3917, October 2004.

[RFC3917] Quittek、J.、Zseby、T.、Claise、B.、およびS.ザンダー、 "IPフロー情報エクスポート(IPFIX)のための要件"、RFC 3917、2004年10月。

[RFC4150] Dietz, R. and R. Cole, "Transport Performance Metrics MIB", RFC 4150, August 2005.

[RFC4150]ディーツ、R.とR.コール、 "交通パフォーマンス・メトリックMIB"、RFC 4150、2005年8月。

[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.

[RFC4960]スチュワート、R.、エド。、 "ストリーム制御伝送プロトコル"、RFC 4960、2007年9月。

[RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture for IP Flow Information Export", RFC 5470, March 2009.

[RFC5470] Sadasivan、G.、ブラウンリー、N.、Claise、B.、およびJ. Quittek、RFC 5470、2009年3月 "IPフロー情報のエクスポートのためのアーキテクチャ"。

[RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. Raspall, "Sampling and Filtering Techniques for IP Packet Selection", RFC 5475, March 2009.

[RFC5475] Zseby、T.、モリーナ、M.、ダッフィールド、N.、ニッコリーニ、S.、およびF. Raspall、 "IPパケットの選択のためのサンプリングとフィルタリング技術"、RFC 5475、2009年3月。

[RFC5476] Claise, B., Ed., "Packet Sampling (PSAMP) Protocol Specifications", RFC 5476, March 2009.

[RFC5476] Claise、B.、エド。、 "パケットサンプリング(PSAMP)プロトコル仕様"、RFC 5476、2009年3月。

[ZsZC01] Zseby, T., Zander, S., and G. Carle, "Evaluation of Building Blocks for Passive One-way-delay Measurements", Proceedings of Passive and Active Measurement Workshop (PAM 2001), Amsterdam, The Netherlands, April 23-24, 2001

【ZsZC01] Zseby、T.、ザンダー、S.、およびG.カール、「受動的一方向遅延測定のためのビルディング・ブロックの評価」、受動的および能動的測定ワークショップの議事録(2001 PAM)、アムステルダム、オランダ、 4月23-24、2001

Authors' Addresses


Tanja Zseby Fraunhofer Institute for Open Communication Systems (FOKUS) Kaiserin-Augusta-Allee 31 10589 Berlin, Germany Phone: +49 30 3463 7153 EMail:

オープン通信システムのためのターニャZsebyフラウンホーファー研究所(FOKUS)カイザリンオーガスタダレ31 10589ベルリン、ドイツ電話:+49 30 3463 7153 Eメール

Elisa Boschi Hitachi Europe c/o ETH Zurich Gloriastrasse 35 8092 Zurich Switzerland Phone: +41 44 6327057 EMail:

エリサボスキ日立ヨーロッパのC / O ETHチューリッヒGloriastrasse 35 8092チューリッヒスイス電話:+41 44 6327057電子メール

Nevil Brownlee CAIDA (UCSD/SDSC) 9500 Gilman Drive La Jolla, CA 92093-0505 Phone: +1 858 534 8338 EMail:

NevilブラウンリーCAIDA(UCSD / SDSC)9500ギルマンドライブラ・ホーヤ、カリフォルニア州92093から0505電話:+1 858 534 8338 Eメール

Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 1831 Diegem Belgium Phone: +32 2 704 5622 EMail:

ブノワClaiseシスコシステムズ、株式会社デKleetlaan 6aはB1 1831ディーゲムベルギー電話:+32 2 704 5622 Eメール