[要約] RFC 6526は、IPFIXを使用してSCTPストリームごとのIPフロー情報をエクスポートするためのプロトコルです。その目的は、ネットワークトラフィックのモニタリングと分析を容易にすることです。
Internet Engineering Task Force (IETF) B. Claise
Request for Comments: 6526 P. Aitken
Category: Standards Track A. Johnson
ISSN: 2070-1721 Cisco Systems, Inc.
G. Muenz
TU Muenchen
March 2012
IP Flow Information Export (IPFIX) Per Stream Control Transmission Protocol (SCTP) Stream
ストリーム制御伝送プロトコル（SCTP）ストリームあたりのIPフロー情報エクスポート（IPFIX）
Abstract
概要
This document specifies an extension to the specifications in RFC 5101, IP Flow Information Export (IPFIX), when using the Partial Reliability extension of SCTP (PR-SCTP, Partial Reliability Stream Control Transmission Protocol).
このドキュメントは、SCTP（PR-SCTP、部分信頼性ストリーム制御伝送プロトコル）の部分信頼性拡張を使用する場合、RFC 5101の仕様、IPフロー情報エクスポート（IPFIX）の仕様の拡張を指定します。
When implemented at both the Exporting Process and Collecting Process, this method offers several advantages, such as the ability to calculate Data Record losses for PR-SCTP per Template, immediate export of Template Withdrawal Messages, immediate reuse of Template IDs within an SCTP stream, reduced likelihood of Data Record loss, and reduced demands on the Collecting Process. When implemented in only the Collecting Process or Exporting Process, then normal IPFIX behavior will be seen without all of the additional benefits.
エクスポートプロセスと収集プロセスの両方で実装される場合、この方法は、テンプレートあたりのPR-SCTPのデータ記録損失を計算する機能、テンプレート引き出しメッセージの即時エクスポート、SCTPストリーム内のテンプレートIDの即時再利用など、いくつかの利点を提供します。データの記録損失の可能性の低下、および収集プロセスに対する需要の減少。収集プロセスまたはエクスポートプロセスのみに実装されると、追加の利点はすべてなくても通常のIPFIX動作が見られます。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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）の製品です。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/rfc6526.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6526で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Relationship with IPFIX and PSAMP ..........................4
1.2. Applicability ..............................................5
1.3. Limitations ................................................5
2. Terminology .....................................................6
2.1. Conventions Used in This Document ..........................6
2.2. IPFIX Documents Overview ...................................6
2.3. PSAMP Documents Overview ...................................7
3. IPFIX Protocol Specifications: Limitations and Improvements .....7
3.1. Data Record Loss Calculated Per Template ...................7
3.1.1. IPFIX Protocol Specifications: Limitation ...........7
3.1.2. IPFIX Export Per SCTP Stream: Advantage .............8
3.2. Immediate Template Withdrawal and Reuse ....................8
3.2.1. IPFIX Protocol Specifications: Limitation ...........8
3.2.2. IPFIX Export Per SCTP Stream: Advantages ............9
3.3. Requirement for Data Set Buffering .........................9
3.3.1. IPFIX Protocol Specifications: Limitation ...........9
3.3.2. IPFIX Export Per SCTP Stream: Advantages ...........10
4. Specifications .................................................10
4.1. New Information Element ...................................10
4.2. Template Management .......................................11
4.3. SCTP ......................................................12
4.4. Template Withdrawal Message ...............................13
4.5. The Collecting Process's Side .............................14
4.5.1. SCTP ...............................................14
4.5.2. Enabling the Per-SCTP-Stream Extension .............14
4.5.3. Disabling the Per-SCTP-Stream Extension ............15
4.5.4. Calculating Data Record Loss Per Template ..........16
5. Resource Impact ................................................16
6. Examples .......................................................17
7. IANA Considerations ............................................20
8. Security Considerations ........................................21
9. References .....................................................21
9.1. Normative References ......................................21
9.2. Informative References ....................................21
10. Acknowledgments ...............................................22
The IPFIX protocol [RFC5101] has the goal of exporting 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.). However, thanks to its Template mechanism, the IPFIX protocol can export any type of
IPFIXプロトコル[RFC5101]には、フロー情報をエクスポートするという目標があります。このプロトコルは、IPトラフィックフローと関連測定データに関する情報をエクスポートするように設計されています。ここで、フローは一連のキー属性（ソースおよび宛先IPアドレス、ソースおよび宛先ポートなど）によって定義されます。ただし、そのテンプレートメカニズムのおかげで、IPFIXプロトコルはあらゆるタイプのエクスポートできます
information, as long as the relevant Information Element is specified in the IPFIX information model [RFC5102], registered with IANA [IANA], or specified as an enterprise-specific Information Element.
情報は、関連する情報要素がIPFIX情報モデル[RFC5102]で指定されている限り、IANA [IANA]に登録されている、またはエンタープライズ固有の情報要素として指定されている限り。
The IPFIX protocol [RFC5101] specifies that traffic measurements for Flows are exported using a TLV (Type, Length, Value) format. The information is exported using a Template Record, which is sent once to export the {Type, Length} pairs that define the data format for the Information Elements in a Flow. The Data Records specify values for each Flow.
IPFIXプロトコル[RFC5101]は、フローのトラフィック測定がTLV（タイプ、長さ、値）形式を使用してエクスポートされることを指定します。情報は、フロー内の情報要素のデータ形式を定義する{type、length}ペアをエクスポートするために1回送信されるテンプレートレコードを使用してエクスポートされます。データレコードは、各フローの値を指定します。
The IPFIX protocol [RFC5101] is flexible: It foresees the usage of multiple SCTP streams per association; it allows the transmission of Data Sets, Template Sets, and/or Options Template Sets on any SCTP stream; it offers full and partially reliable export of Data Sets; it specifies both ordered and out-of-order delivery of Data Sets. However, due to bandwidth restrictions and packet losses in the network as well as resource constraints on the Exporter and Collector (e.g., limited buffer sizes), it is not always possible to export all Data Sets in a reliable way.
IPFIXプロトコル[RFC5101]は柔軟性があります。これは、関連性あたりの複数のSCTPストリームの使用を予見しています。SCTPストリームにデータセット、テンプレートセット、および/またはオプションテンプレートセットを送信できます。データセットの完全かつ部分的に信頼できるエクスポートを提供します。データセットの順序と注文不足の両方の配信の両方を指定します。ただし、ネットワーク内の帯域幅の制限とパケット損失、および輸出業者とコレクターのリソースの制約（例：限られたバッファサイズ）により、信頼できる方法ですべてのデータセットをエクスポートすることは常に可能ではありません。
This document specifies a method for exporting a Template Record and its associated Data Sets in a single SCTP stream, limiting each Template ID to a single SCTP stream if possible, and imposing in-order transmission.
このドキュメントは、テンプレートレコードとその関連するデータセットを単一のSCTPストリームでエクスポートする方法を指定し、各テンプレートIDを可能であれば単一のSCTPストリームに制限し、次数の送信を課します。
This method offers several advantages over IPFIX export as specified in [RFC5101], such as the ability to calculate Data Record losses for PR-SCTP per Template, immediate export of Template Withdrawal Messages, immediate reuse of Template IDs within an SCTP stream, reduced likelihood of Data Record loss, and reduced demands on the Collecting Process.
この方法は、[RFC5101]で指定されているIPFIXエクスポートよりもいくつかの利点を提供します。たとえば、テンプレートあたりのPR-SCTPのデータ記録損失を計算する機能、テンプレート引き出しメッセージの即時エクスポート、SCTPストリーム内のテンプレートIDの即時再利用、尤度の減少データの記録の損失、および収集プロセスに対する需要の減少。
The specifications in this document apply to the IPFIX protocol specifications [RFC5101]. However, they only apply to the SCTP transport protocol [RFC4960] option of the IPFIX protocol specifications (see Section 10 of [RFC5101]), specifically if the Partial Reliability extension [RFC3758] is used. All specifications from [RFC5101] apply, unless specified otherwise in this document.
このドキュメントの仕様は、IPFIXプロトコル仕様[RFC5101]に適用されます。ただし、特に部分的信頼性拡張[RFC3758]が使用されている場合は、IPFIXプロトコル仕様のSCTPトランスポートプロトコル[RFC4960]オプション（[RFC5101]のセクション10を参照）にのみ適用されます。[RFC5101]のすべての仕様は、このドキュメントで別段の指定がない限り、適用されます。
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.
パケットサンプリング（PSAMP）プロトコル仕様[RFC5476]はIPFIXプロトコル仕様に基づいているため、このドキュメントの仕様はPSAMPプロトコルにも有効です。
The specifications contained in this document are applicable to cases where application requirements include knowing how many Data Records of a certain type (i.e., from a certain Template) were lost. A typical example is a router exporting billing records, where the Exporting Process cannot afford to export all the Flow Records reliably, due to limited resources to buffer a large number of Flow Records. Such a situation may occur if Data Sets are generated at a higher rate at the Exporter than can be transferred to the Collector because of bandwidth limitations in the network or slow reception at the Collector.
このドキュメントに含まれる仕様は、特定のタイプのデータレコードの数（つまり、特定のテンプレートから）が失われたことを知ることが含まれる場合に適用されます。典型的な例は、多数のフローレコードをバッファリングするためのリソースが限られているため、エクスポートプロセスがすべてのフローレコードを確実にエクスポートする余裕がないルーターエクスポート請求レコードです。このような状況は、ネットワークの帯域幅の制限またはコレクターでのゆっくりした受信のために、コレクターに転送できるよりも、輸出業者のデータセットをより高いレートで生成する場合に発生する可能性があります。
To be more precise, the specification applicability is the case where multiple Templates are simultaneously active within a single SCTP Transport Session and the calculation of the Data Record loss for a particular Template is required. Indeed, with the current IPFIX specifications [RFC5101], if an IPFIX Message is lost (UDP or SCTP partially reliable), it is not possible to determine to which Template(s) the lost Data Records belong.
より正確には、仕様の適用性は、単一のSCTPトランスポートセッション内で複数のテンプレートが同時にアクティブになっている場合であり、特定のテンプレートのデータレコード損失の計算が必要です。実際、現在のIPFIX仕様[RFC5101]では、IPFIXメッセージが紛失した場合（UDPまたはSCTPが部分的に信頼性が高い）、失われたデータレコードがどのテンプレートに属するかを判断することはできません。
Exporting Processes following the specifications in this document will interoperate with existing Collecting Processes that comply with [RFC5101]; no changes are required at the Collecting Process to receive data from an Exporting Process compliant with this method. However, Collecting Processes may implement additional support for per-stream export specified in this document in order to realize all the benefits of the approach specified herein. Since the specifications in this document mandate in-order transmission of (Options) Templates and associated Data Records, late arrival of (Options) Templates at the Collecting Process is avoided, which means that there are no Data Records that need to be dropped or buffered.
このドキュメントの仕様に従ってプロセスのエクスポートは、[RFC5101]に準拠する既存の収集プロセスと相互操作します。収集プロセスでは、この方法に準拠したエクスポートプロセスからデータを受信するために変更は必要ありません。ただし、収集プロセスは、本書で指定されたアプローチのすべての利点を実現するために、このドキュメントで指定されたストリームごとのエクスポートの追加サポートを実装する場合があります。このドキュメントの仕様は（オプション）テンプレートと関連するデータレコードの注文の送信を義務付けているため、収集プロセスでの（オプション）テンプレートの遅れて到着することは回避されています。。
When multiple Templates are required, this method requires multiple SCTP streams in the association between the Exporting Process and Collecting Process, ideally one stream per Template. To properly handle the transmission of additional Templates during the Transport Session, additional SCTP streams are sometimes required. These SCTP streams can only be added within the existing SCTP association if the specifications in [RFC6525] are supported.
複数のテンプレートが必要な場合、この方法では、エクスポートプロセスと収集プロセス、理想的にはテンプレートごとに1つのストリームとの関連性に複数のSCTPストリームが必要です。トランスポートセッション中に追加のテンプレートの送信を適切に処理するには、追加のSCTPストリームが必要な場合があります。これらのSCTPストリームは、[RFC6525]の仕様がサポートされている場合にのみ、既存のSCTPアソシエーション内に追加できます。
IPFIX-specific terminology used in this document is defined in Section 2 of [RFC5101]. As in [RFC5101], these IPFIX-specific terms have the first letter of a word capitalized when used in this document.
このドキュメントで使用されるIPFIX固有の用語は、[RFC5101]のセクション2で定義されています。[RFC5101]のように、これらのIPFIX固有の用語には、このドキュメントで使用されたときに最初の単語の文字が大文字になります。
Note that, in this document, "(Options) Template" is used to refer to Templates and Options Templates. Unless otherwise specified, "Template" alone refers to Templates exclusive of Options Templates.
このドキュメントでは、「（オプション）テンプレート」がテンプレートとオプションテンプレートを参照するために使用されることに注意してください。特に指定されていない限り、「テンプレート」だけでは、オプションテンプレートを除くテンプレートを指します。
Template Reuse Delay
テンプレートの再利用遅延
The time the Exporting Process needs to wait after sending the last Data Set described by a given Template before sending a Template Withdrawal Message for the Template. A suitable default value is 5 seconds, as specified in [RFC5101].
テンプレートにテンプレートの引き出しメッセージを送信する前に、特定のテンプレートで記述された最後のデータセットを送信した後、エクスポートプロセスが待機する必要があります。[RFC5101]で指定されているように、適切なデフォルト値は5秒です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
The IPFIX protocol [RFC5101] provides network administrators with access to Flow information.
IPFIXプロトコル[RFC5101]は、ネットワーク管理者にフロー情報へのアクセスを提供します。
The architecture for the export of measured Flow information out of an IPFIX Exporting Process to a Collecting Process is defined in the IPFIX architecture [RFC5470], per the requirements defined in [RFC3917].
[RFC3917]で定義されている要件に従って、IPFIXエクスポートプロセスから収集プロセスへの測定フロー情報のエクスポートのアーキテクチャが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, their types, and additional semantic information, as specified in the IPFIX information model [RFC5102].
IPFIXには、IPFIX情報モデル[RFC5102]で指定されているように、IPFIX情報要素、名前、タイプ、および追加のセマンティック情報の正式な説明があります。
Finally, the IPFIX applicability statement [RFC5472] describes what types of applications can use the IPFIX protocol and how they can use the information provided. Furthermore, it shows how the IPFIX framework relates to other architectures and frameworks.
最後に、IPFIXアプリケーションステートメント[RFC5472]は、IPFIXプロトコルを使用できるアプリケーションの種類と、提供された情報の使用方法を説明します。さらに、IPFIXフレームワークが他のアーキテクチャとフレームワークとどのように関連するかを示しています。
The document "A Framework for Packet Selection and Reporting" [RFC5474] describes the Packet Sampling (PSAMP) framework for network elements to select subsets of packets by statistical and other methods, and to export a stream of reports on the selected packets to a Collector.
ドキュメント「パケット選択とレポートのフレームワーク」[RFC5474]は、ネットワーク要素のパケットサンプリング（PSAMP）フレームワークを説明して、統計およびその他の方法でパケットのサブセットを選択し、選択したパケットのレポートのストリームをコレクターにエクスポートします。。
The set of packet selection techniques (sampling, filtering, and hashing) supported by PSAMP are described in "Sampling and Filtering Techniques for IP Packet Selection" [RFC5475].
PSAMPでサポートされているパケット選択手法（サンプリング、フィルタリング、およびハッシュ）のセットは、「IPパケット選択のためのサンプリングとフィルタリング技術」[RFC5475]で説明されています。
The PSAMP protocol [RFC5476] specifies the export of packet information from a PSAMP Exporting Process to a PSAMP Collecting Process. Like IPFIX, PSAMP has a formal description of its Information Elements, their names, their types, and additional semantic information. The PSAMP information model is defined in [RFC5477].
PSAMPプロトコル[RFC5476]は、PSAMPエクスポートプロセスからPSAMP収集プロセスへのパケット情報のエクスポートを指定します。IPFIXと同様に、PSAMPには、情報要素、名前、種類、および追加のセマンティック情報の正式な説明があります。PSAMP情報モデルは[RFC5477]で定義されています。
For three specific topics ("Data Record Loss Calculated Per Template", "Immediate Template Withdrawal and Reuse", and "Requirement for Data Set Buffering"), this section explains the limitations of the IPFIX protocol specifications on the one hand, and the advantages of the method specified in this document on the other.
3つの特定のトピック（「テンプレートごとに計算されたデータレコードの損失」、「即時テンプレートの引き出しと再利用」、および「データセットバッファリングの要件」）について、このセクションでは、片手のIPFIXプロトコル仕様の制限と利点について説明します。このドキュメントで指定された方法の他方に指定されています。
Section 6.3.2 of [RFC3917], "Requirements for IP Flow Information Export" discusses the data transfer reliability issues:
[RFC3917]のセクション6.3.2、「IPフロー情報エクスポートの要件」では、データ転送の信頼性の問題について説明します。
Loss of flow records during the data transfer from the Exporting Process to the Collecting Process must be indicated at the Collecting Process.
エクスポートプロセスから収集プロセスへのデータ転送中のフロー記録の損失は、収集プロセスで示されなければなりません。
However, in some cases, it may be important to know how many Data Records of a certain type were lost (e.g., in the case of billing), and IPFIX does not conventionally provide this information.
ただし、場合によっては、特定のタイプのデータレコードの数が失われたものを知ることが重要かもしれません（例：請求の場合）、IPFIXは従来この情報を提供していません。
A Collecting Process can detect out-of-sequence, dropped, or duplicate IPFIX Messages by tracking the Sequence Number [RFC5101]. Note that the Sequence Number field in the IPFIX Message header increases with the number of IPFIX Data Records within the SCTP stream, so loss will be detected per stream.
収集プロセスは、シーケンス番号[RFC5101]を追跡することにより、IPFIXメッセージをドロップする、または重複するアウトシーケンスを検出できます。IPFIXメッセージヘッダーのシーケンス番号フィールドは、SCTPストリーム内のIPFIXデータレコードの数とともに増加するため、ストリームごとに損失が検出されることに注意してください。
The IPFIX protocol specifications [RFC5101] specify that Data Records defined by any Template may be sent on any SCTP stream. As such, if there is more than one Template defined within the whole SCTP association, then there is no way of knowing with which Template any lost Data Record is associated. This is true, no matter what convention the Exporting Process uses to send Data Records on different SCTP streams, as the protocol makes no guarantees.
IPFIXプロトコル仕様[RFC5101]は、任意のテンプレートによって定義されたデータレコードが任意のSCTPストリームで送信される可能性があることを指定します。そのため、SCTPアソシエーション全体で複数のテンプレートが定義されている場合、失われたデータレコードが関連付けられているテンプレートを知る方法はありません。これは、プロトコルが保証しないため、エクスポートプロセスがさまざまなSCTPストリームでデータレコードを送信するために使用する慣習に関係なく、これは真実です。
Note that a workaround allowed by the IPFIX specifications in [RFC5101] is to use only one Template Record per SCTP Transport Session, at the cost of multiplying the number of SCTP Transport Sessions when multiple Template Records are required.
[RFC5101]のIPFIX仕様で許可されている回避策は、複数のテンプレートレコードが必要な場合にSCTPトランスポートセッションの数を掛けるコストで、SCTPトランスポートセッションごとに1つのテンプレートレコードのみを使用することであることに注意してください。
Using the specifications in this document, it is guaranteed that any lost Data Records will be associated only with the Templates that are defined on that SCTP stream. By defining only one Template per SCTP stream, it is ensured that any loss is associated with that single Template. So, by exporting each Template and its corresponding Data Records in a separate SCTP stream from other Templates and Data Records, the loss pertaining to each specific Template can be deduced from the Sequence Number field in the IPFIX Message headers.
このドキュメントの仕様を使用すると、失われたデータレコードは、そのSCTPストリームで定義されているテンプレートのみに関連付けられることが保証されています。SCTPストリームごとに1つのテンプレートのみを定義することにより、損失がその単一のテンプレートに関連付けられていることが保証されます。したがって、他のテンプレートおよびデータレコードから個別のSCTPストリームで各テンプレートとその対応するデータレコードをエクスポートすることにより、各特定のテンプレートに関連する損失は、IPFIXメッセージヘッダーのシーケンス番号フィールドから推定できます。
A Collecting Process must have received the Template Record associated with the Data Records to be able to decode the information in the Data Records. [RFC5101] specifies the following:
収集プロセスは、データレコードの情報をデコードできるように、データレコードに関連付けられたテンプレートレコードを受信している必要があります。[RFC5101]次のことを指定します。
The Exporting Process SHOULD transmit the Template Set and Options Template Set in advance of any Data Sets that use that (Options) Template ID, to help ensure that the Collecting Process has the Template Record before receiving the first Data Record.
エクスポートプロセスでは、テンプレートセットとオプションテンプレートを送信して、その（オプション）テンプレートIDを使用するデータセットの前に設定され、最初のデータレコードを受信する前に収集プロセスにテンプレートレコードがあることを確認する必要があります。
The fact that the Collecting Process cannot decode the Data Records without the corresponding Template Record may result in Data Records being discarded by the Collecting Process, as specified in [RFC5101]:
[RFC5101]で指定されているように、収集プロセスが対応するテンプレートレコードなしでデータレコードをデコードできないという事実により、データレコードが収集プロセスによって破棄される可能性があります。
The Collecting Process normally receives Template Records from the Exporting Process before receiving Data Records. The Data Records are then decoded and stored by the Collector. If the Template Records have not been received at the time Data Records are received, the Collecting Process MAY store the Data Records for a short period of time and decode them after the Template Records are received.
収集プロセスは通常、データレコードを受信する前にエクスポートプロセスからテンプレートレコードを受信します。データレコードは、コレクターによってデコードされ、保存されます。データレコードが受信された時点でテンプレートレコードを受信していない場合、収集プロセスはデータレコードを短時間保存し、テンプレートレコードを受信した後にそれらをデコードする場合があります。
By exporting each Template Record and the corresponding Data Records within a single SCTP stream and imposing in-order transmission, the Template Record will always arrive before the associated Data Records. Therefore, there is no risk that the Collecting Process discards Data Records while waiting for the Template Record to arrive.
各テンプレートレコードと単一のSCTPストリーム内の対応するデータレコードをエクスポートし、順序内送信を課すことにより、テンプレートレコードは常に関連するデータレコードの前に到着します。したがって、テンプレートレコードが到着するのを待っている間に、収集プロセスがデータレコードを破棄するリスクはありません。
Furthermore, when reusing a Template ID within an SCTP stream, the Template Withdrawal Message will be guaranteed to arrive before the new definition of the Template, and therefore the Template Record may be sent directly after the Template Withdrawal Message. In other words, the Template Reuse Delay restriction (5 seconds by default, as specified in [RFC5101]) does not need to be applied to Template ID reuse within the same SCTP stream.
さらに、SCTPストリーム内でテンプレートIDを再利用すると、テンプレートの新しい定義の前にテンプレートの引き出しメッセージが到着することが保証され、したがってテンプレートレコードはテンプレートの引き出しメッセージの直後に送信されます。言い換えれば、テンプレートの再利用遅延制限（[RFC5101]で指定されているように、デフォルトで5秒）は、同じSCTPストリーム内のテンプレートIDの再利用に適用する必要はありません。
Another advantage of the new specifications in this document is a reduced load on the Collecting Process. Indeed, the Collecting Process doesn't have to store the Data Records while waiting for the Template Record, as the transmission order is always guaranteed. This way, extra reliability of the Data Records is achieved without extra burden on the Collecting Process.
このドキュメントの新しい仕様のもう1つの利点は、収集プロセスの負荷が削減されることです。実際、送信順序が常に保証されているため、テンプレートレコードを待っている間にデータレコードを保存する必要はありません。これにより、データレコードの追加の信頼性は、収集プロセスに余分な負担をかけずに達成されます。
The fact that the protocol specifications in [RFC5101] are flexible in terms of SCTP stream(s) on which the Template Set, Options Template Set, and corresponding Data Sets are exported implies that the (Options) Template Record might be exported on a different SCTP stream than the corresponding Data Records. This might cause Data Record loss in the Collecting Process, as ordered transmission across SCTP streams is not guaranteed.
[RFC5101]のプロトコル仕様は、テンプレートセット、オプションテンプレートセット、および対応するデータセットがエクスポートされるSCTPストリームの観点から柔軟であるという事実は、（オプション）テンプレートレコードが異なるものでエクスポートされる可能性があることを意味します。対応するデータレコードよりもSCTPストリーム。これにより、SCTPストリーム全体の順序付けられた送信が保証されていないため、収集プロセスのデータ記録の損失を引き起こす可能性があります。
For example, a Template Record may be blocked pending reliable transmission on one SCTP stream while the corresponding Data Records may be transmitted immediately in another SCTP stream. Also, due to different levels of SCTP stream congestion, it is possible that even if the Template Record and corresponding Data Records are sent reliably, Data Records sent on a different SCTP stream than the Template Record might still arrive before the Template Record.
たとえば、テンプレートレコードは、1つのSCTPストリームで信頼できる送信が保留されてブロックされる場合がありますが、対応するデータレコードは別のSCTPストリームで直ちに送信できます。また、SCTPストリームの混雑のレベルが異なるため、テンプレートレコードと対応するデータレコードが確実に送信されたとしても、テンプレートレコードとは異なるSCTPストリームで送信されるデータレコードがテンプレートレコードの前に到着する可能性があります。
By exporting each Template Record and all corresponding Data Records within a single SCTP stream, and imposing in-order transmission, the issue of ordered transmission across multiple SCTP streams is avoided.
各テンプレートレコードと単一のSCTPストリーム内のすべての対応するデータレコードをエクスポートし、順序の送信を課すことにより、複数のSCTPストリームにわたる順序付けられた伝送の問題は回避されます。
By exporting all corresponding Data Records within the same ordered SCTP stream as the Template Record, each SCTP stream is independent and self-contained, and the interaction between SCTP streams is limited to that of the Options Template and associated Data Records sent in different streams. This has several advantageous consequences, including order preservation that does not result in the blocking of unrelated data, and load reduction on the Collecting Process (as the Template Records are guaranteed to be delivered before the associated Data Records, there is no need for the buffering of Data Sets that correspond with Templates that are missing).
テンプレートレコードと同じ順序付けられたSCTPストリーム内のすべての対応するデータレコードをエクスポートすることにより、各SCTPストリームは独立して自己完結型であり、SCTPストリーム間の相互作用は、オプションテンプレートと異なるストリームで送信される関連データレコードの相互作用に限定されます。これには、無関係なデータがブロックされない注文保存や収集プロセスの負荷削減など、いくつかの有利な結果があります（関連データレコードの前にテンプレートレコードが配信されることが保証されているため、バッファリングの必要はありません。欠落しているテンプレートに対応するデータセットの）。
This section specifies Exporting Process and Collecting Process behavior different from that in [RFC5101] in order to realize the benefits of per-stream export. Note that Exporting Processes following these specifications will interoperate with [RFC5101]- compliant Collecting Processes, but that Collecting Processes will have to follow additional non-interoperable specifications to realize the full benefits of the technique. These new specifications, which add to those in [RFC5101], are described with the key words defined in [RFC2119].
このセクションでは、ストリームあたりの輸出の利点を実現するために、プロセスとプロセスの動作とは異なるプロセス動作とは異なるプロセスの動作とは異なります。これらの仕様に続くプロセスのエクスポートは、[RFC5101] - 準拠の収集プロセスと相互運用するが、収集プロセスは、技術の完全な利点を実現するために追加の非操作不可能な仕様に従う必要があることに注意してください。[RFC5101]のものに追加するこれらの新しい仕様は、[RFC2119]で定義されたキーワードで説明されています。
dataRecordsReliability
DatareCordsReliability
Description: The export reliability of Data Records, within this SCTP stream, for the element(s) in the Options Template scope. A typical example of an element for which the export reliability will be reported is the Template ID, as specified in the Data Records Reliability Options Template. A value of 'True' means that the Exporting Process MUST send any Data Records associated with the element(s) reliably within this SCTP stream. A value of 'False' means that the Exporting Process MAY send any Data Records associated with the element(s) unreliably within this SCTP stream.
説明：オプションテンプレートスコープの要素のための、このSCTPストリーム内のデータレコードのエクスポート信頼性。データレコードの信頼性オプションテンプレートで指定されているように、エクスポートの信頼性が報告される要素の典型的な例は、テンプレートIDです。「true」の値とは、エクスポートプロセスがこのSCTPストリーム内で要素に関連するデータレコードを確実に送信する必要があることを意味します。「false」の値とは、エクスポートプロセスが、このSCTPストリーム内で必ず不定期に関連するデータレコードを送信できることを意味します。
Abstract Data Type: boolean Data Type Semantics: identifier ElementId: 276 Status: current
抽象データ型：ブールデータ型セマンティクス：識別子ElementID：276ステータス：現在
Per Section 6.1.5 of [RFC5101], the boolean data type is encoded as a single octet, with the value of 1 for True and the value of 2 for False.
[RFC5101]のセクション6.1.5に従って、ブールデータ型は単一のオクテットとしてエンコードされ、値は1の値、falsは2の値が2の値です。
To take advantage of per-stream export, Exporting Processes MUST follow the specification in this section in addition to Section 8, "Template Management", of [RFC5101].
ストリームごとのエクスポートを活用するには、[RFC5101]のセクション8「テンプレート管理」に加えて、このセクションの仕様に従う必要があります。
As specified in [RFC5101], Template Sets and Options Template Sets MUST be sent reliably.
[RFC5101]で指定されているように、テンプレートセットとオプションテンプレートセットを確実に送信する必要があります。
Any Data Sets associated with a Template Record MUST be sent on the same SCTP stream on which the Template Record was sent.
テンプレートレコードに関連付けられたデータセットは、テンプレートレコードが送信された同じSCTPストリームで送信する必要があります。
The Data Records Reliability Options Template is used to explicitly inform the Collecting Process which Templates will be used in each SCTP stream and whether each set of associated Data Records will be sent reliably or unreliably. After defining a Template ID and before sending any associated Data Records on an SCTP stream, the Exporting Process MUST notify the Collecting Process of its intention to send those Data Records reliably or unreliably within that SCTP stream. It does this by sending a Data Record defined by the Data Records Reliability Options Template for the Template associated with the Data Records to be sent. If it does not, then the Collecting Process MUST disable this extension for the SCTP association. The one exception to this rule is that the Data Records associated with the Data Records Reliability Options Template don't require an explicit notification, as these MUST always be sent reliably.
データレコードの信頼性オプションテンプレートは、各SCTPストリームで使用されるテンプレートと、関連するデータレコードの各セットが確実にまたは不正に送信されるかどうかを収集プロセスに明示的に通知するために使用されます。テンプレートIDを定義し、SCTPストリームで関連するデータレコードを送信する前に、エクスポートプロセスは、そのSCTPストリーム内でこれらのデータレコードを確実にまたは不当に送信する意図を収集プロセスに通知する必要があります。これは、送信されるデータレコードに関連付けられたテンプレートのデータレコード信頼性オプションテンプレートで定義されたデータレコードを送信することにより行います。そうでない場合、収集プロセスはSCTP協会のこの拡張機能を無効にする必要があります。このルールの1つの例外は、データレコードの信頼性オプションテンプレートに関連付けられたデータレコードは、常に確実に送信する必要があるため、明示的な通知を必要としないことです。
The Data Records Reliability Options Template MUST contain the following Information Elements:
データレコードの信頼性オプションテンプレートには、次の情報要素が含まれている必要があります。
Scope: Template ID Non-scope: dataRecordsReliability
スコープ：テンプレートID Non-Scope：DataRecordsReliability
After sending a value of 'True' for the dataRecordsReliability Element, the Exporting Process MUST send any Data Records associated with the currently defined Template ID reliably within this SCTP stream. After sending a value of 'False' for the
DataRecordSreliability要素に対して「True」の値を送信した後、エクスポートプロセスは、このSCTPストリーム内で現在定義されているテンプレートIDに関連付けられているデータレコードを送信する必要があります。のために「false」の値を送信した後
dataRecordsReliability Element, the Exporting Process MAY send any Data Records associated with the Template ID unreliably within this SCTP stream.
DatareCordsReliability要素、エクスポートプロセスは、このsctpストリーム内で必ず不当にテンプレートIDに関連付けられたデータレコードを送信する場合があります。
If the Exporting Process wants to change the Data Records Reliability value (from reliable to unreliable, or vice versa) for Data Records on an SCTP stream, the Template MUST be withdrawn, and a new Template MUST be used.
エクスポートプロセスが、SCTPストリームのデータレコードのデータレコードの信頼性値（信頼性から信頼性から信頼性から信頼性、またはその逆に）を変更したい場合は、テンプレートを撤回する必要があり、新しいテンプレートを使用する必要があります。
The Data Records Reliability Options Template MAY contain other non-scope Information Elements associated with the (Options) Template.
データレコードの信頼性オプションテンプレートには、（オプション）テンプレートに関連付けられた他の非スコープ情報要素が含まれる場合があります。
When an Options Template (including the Data Records Reliability Options Template) and associated Data Records are sent in the same SCTP stream, the first associated Data Record can follow the Options Template immediately. When the Options Template and associated Data Records are sent in different SCTP streams, the Exporting Process SHOULD transmit the Options Template in advance of any Data Sets that use it, to help ensure that the Collector has received the Options Template Record before receiving the first associated Data Record.
オプションテンプレート（データレコードの信頼性オプションテンプレートを含む）と関連するデータレコードが同じSCTPストリームで送信されると、最初の関連データレコードはすぐにオプションテンプレートに従うことができます。オプションテンプレートと関連するデータレコードが異なるSCTPストリームで送信される場合、エクスポートプロセスは、コレクターが最初の関連する関連を受信する前にオプションテンプレートレコードを受信することを保証するために、それを使用するデータセットの前にオプションテンプレートを送信する必要がありますデータレコード。
It is RECOMMENDED that the Exporting Process only sends a single Template and corresponding Data Sets within a single SCTP stream in order to enable calculation of the potential Data Record loss for this Template. The Exporting Process MAY group related (Options) Templates and their associated Data Records within a single SCTP stream so that loss statistics are calculated for the group of Templates that are being sent unreliably within the SCTP stream. This is suitable in cases where there are only slight variations among the Templates in a group (e.g., the omission of unavailable fields for export efficiency) and may be necessary if the SCTP association does not support enough SCTP streams to export each Template in its own SCTP stream.
エクスポートプロセスは、このテンプレートの潜在的なデータレコードの損失を計算できるように、単一のSCTPストリーム内で単一のテンプレートと対応するデータセットのみを送信することをお勧めします。エクスポートプロセスは、単一のSCTPストリーム内で関連する（オプション）テンプレートとそれに関連するデータレコードをグループ化する場合があり、SCTPストリーム内で不可能に送信されているテンプレートのグループについて損失統計が計算されます。これは、グループ内のテンプレート間にわずかなバリエーションしかない場合（たとえば、エクスポート効率のために利用できないフィールドの省略）、SCTP協会が独自のテンプレートを独自のテンプレートでエクスポートするのに十分なSCTPストリームをサポートしていない場合に必要になる場合があります。SCTPストリーム。
If an SCTP stream contains a mixture of Data Records defined by Template Records and by Options Template Records, the Data Records defined by the Options Template Records SHOULD be sent reliably so that the Collecting Process does not consider any loss to be associated with the Options Data Records.
SCTPストリームにテンプレートレコードとオプションテンプレートレコードで定義されたデータレコードの混合が含まれている場合、オプションテンプレートレコードで定義されたデータレコードを確実に送信する必要があります。記録。
To take advantage of per-stream export, Exporting Processes MUST manage SCTP streams according to the specification in this section, in addition to Section 10.2.4.3, "Stream", of [RFC5101].
ストリームあたりのエクスポートを活用するには、[RFC5101]のセクション10.2.4.3、「ストリーム」に加えて、このセクションの仕様に従ってSCTPストリームを輸出する必要があります。
PR-SCTP [RFC3758] MUST be implemented by all compliant implementations.
PR-SCTP [RFC3758]は、すべての準拠の実装によって実装する必要があります。
All IPFIX Messages in an SCTP stream MUST be sent in order.
SCTPストリーム内のすべてのIPFIXメッセージは、順番に送信する必要があります。
As specified in [RFC5101], depending on the requirements of the application, the Exporting Process may send Data Sets with full or partial reliability.
[RFC5101]で指定されているように、アプリケーションの要件に応じて、エクスポートプロセスは完全または部分的な信頼性を持つデータセットを送信する場合があります。
If the Exporting Process is required to export a new Template Record but there are no more free SCTP streams available, it SHOULD attempt to increase the number of outbound SCTP streams to which it is able to send, per [RFC6525]. Alternatively, the Exporting Process MAY add the Template Set and Data Records to an existing SCTP stream at the cost of diluting the granularity of any Data Record loss attribution. An alternative that may result in the loss of Flow Records (for example, due to lack of buffering on the Exporter) is to restart the SCTP association with an increased number of SCTP streams.
新しいテンプレートレコードをエクスポートするためにエクスポートプロセスが必要であるが、利用可能な無料のSCTPストリームはもうない場合、[RFC6525]ごとに送信できるアウトバウンドSCTPストリームの数を増やそうとする必要があります。あるいは、エクスポートプロセスでは、データ記録の損失の属性の粒度を希釈するコストで、テンプレートセットとデータレコードを既存のSCTPストリームに追加する場合があります。フロー記録の損失をもたらす可能性のある代替手段（たとえば、輸出業者のバッファリングの不足による）は、SCTPストリームの数を増やしてSCTP関連を再開することです。
To take advantage of per-stream export, Exporting Processes MUST send Template Withdrawal Messages according to the specification in this section, in addition to Section 8, "Template Management", of [RFC5101].
ストリームあたりのエクスポートを活用するには、エクスポートプロセスは、[RFC5101]のセクション8「テンプレート管理」に加えて、このセクションの仕様に従ってテンプレートの引き出しメッセージを送信する必要があります。
As specified in [RFC5101], Templates that are no longer in use SHOULD be deleted. Before reusing a Template ID, the Template MUST be deleted. In order to delete an allocated Template, the Template is withdrawn through the use of a Template Withdrawal Message.
[RFC5101]で指定されているように、使用されなくなったテンプレートは削除する必要があります。テンプレートIDを再利用する前に、テンプレートを削除する必要があります。割り当てられたテンプレートを削除するために、テンプレートはテンプレートの引き出しメッセージを使用して撤回されます。
The Template Withdrawal Message MUST be sent on the same SCTP stream as the associated Template Record.
テンプレートの引き出しメッセージは、関連するテンプレートレコードと同じSCTPストリームで送信する必要があります。
The Template Withdrawal Message MUST be sent reliably, using SCTP-ordered delivery per [RFC5101]. As all IPFIX Messages are sent in order within an SCTP stream (per the specifications in this document), the IPFIX Message containing the Template Withdrawal Message will not arrive at the Collecting Process before any associated and previously sent Data Record. As a consequence, no Data Records will be lost due to delayed arrival at the Collecting Process.
[RFC5101]ごとにSCTP順序の配信を使用して、テンプレートの引き出しメッセージを確実に送信する必要があります。すべてのIPFIXメッセージはSCTPストリーム内で順番に送信されるため（このドキュメントの仕様ごと）、テンプレートの引き出しメッセージを含むIPFIXメッセージは、関連するデータレコードの前に収集プロセスに到達しません。結果として、収集プロセスへの到着が遅れたため、データレコードは失われません。
The Template ID from a withdrawn Template MAY be reused on the same SCTP stream immediately after the Template Withdrawal Message is sent. This case is equivalent to the use of a Template Reuse Delay value of 0.
撤回されたテンプレートからのテンプレートIDは、テンプレートの引き出しメッセージが送信された直後に同じSCTPストリームで再利用できます。このケースは、テンプレートの再利用遅延値0の使用に相当します。
After reusing the Template ID, the Exporting Process MUST send a Data Record associated with the Data Records Reliability Options Template to specify the reliability level of the Data Records associated with the new Template.
テンプレートIDを再利用した後、エクスポートプロセスは、データレコードの信頼性オプションテンプレートに関連付けられたデータレコードを送信して、新しいテンプレートに関連付けられたデータレコードの信頼性レベルを指定する必要があります。
If the Template ID is to be reused on a different SCTP stream, the new Template Record MUST NOT be sent before the Template Reuse Delay interval.
テンプレートIDを別のSCTPストリームで再利用する場合、テンプレートの再利用遅延間隔の前に新しいテンプレートレコードを送信してはなりません。
A Template Withdrawal Message to withdraw all Templates for the Observation Domain ID specified in the IPFIX Message header MUST NOT be used.
IPFIXメッセージヘッダーで指定された観測ドメインIDのすべてのテンプレートを撤回するためのテンプレート引き出しメッセージを使用してはなりません。
Multiple Template IDs MAY be withdrawn with a single Template Withdrawal Message under the condition that all the Template IDs in the Template Withdrawal Message are used on the same SCTP stream as the Template Withdrawal Message.
複数のテンプレートIDは、テンプレート引き出しメッセージ内のすべてのテンプレートIDがテンプレート引き出しメッセージと同じSCTPストリームで使用されるという条件の下で、単一のテンプレート引き出しメッセージで撤回される場合があります。
Collecting Processes must operate in a fashion slightly contrary to [RFC5101] in order to realize the full benefits of per-stream export. However, the specification in this section contains a mechanism that allows per-stream-capable Collecting Processes to selectively enable per-stream export, in order to ensure interoperability of per-stream-capable Collecting Processes with Exporting Processes that do not implement per-stream export.
収集プロセスは、ストリームあたりの輸出の完全な利点を実現するために、[RFC5101]に少し反してファッションで動作する必要があります。ただし、このセクションの仕様には、ストリームごとの収集プロセスがストリームごとのエクスポートを選択できるようにするメカニズムが含まれています。書き出す。
As specified in [RFC5101], the Collecting Process SHOULD listen for a new association request from the Exporting Process. The Exporting Process will request a number of SCTP streams to use for export.
[RFC5101]で指定されているように、収集プロセスは、エクスポートプロセスからの新しい関連リクエストを聞く必要があります。エクスポートプロセスは、エクスポートに使用するために多くのSCTPストリームを要求します。
A Collecting Process SHOULD support the procedure for the addition of an SCTP stream specified in [RFC6525].
収集プロセスは、[RFC6525]で指定されたSCTPストリームの追加手順をサポートする必要があります。
In IPFIX, there is no explicit notification of the Exporting Process's capabilities. There is also no return channel for the Collecting Process to communicate its capabilities.
IPFIXでは、エクスポートプロセスの機能の明示的な通知はありません。また、収集プロセスがその機能を通信するためのリターンチャネルはありません。
When the Exporting Process is sending according to the per-SCTP-stream extension, the first Data Record received by the Collecting Process will be associated with the Data Records Reliability Options
エクスポートプロセスがSCTPストリームごとに送信されている場合、収集プロセスで受信された最初のデータレコードは、データレコードの信頼性オプションに関連付けられます
Template. In this case, the Collecting Process enables the extension for this Transport Session. Otherwise, the Collecting Process MUST NOT enable the extension for this Transport Session.
テンプレート。この場合、収集プロセスにより、この輸送セッションの拡張機能が可能になります。それ以外の場合、収集プロセスは、このトランスポートセッションの拡張機能を有効にしてはなりません。
The Collecting Process MUST accept other non-scope Information Elements in the Data Records Reliability Options Template.
収集プロセスは、データレコードの信頼性オプションテンプレートの他の非スコープ情報要素を受け入れる必要があります。
Nothing prevents an implementation that does not meet the specification of the per-SCTP-stream extension from sending a Template that looks like a dataRecordsReliability Options Template. Therefore, a Collecting Process MUST detect if the Exporting Process fails to meet the specification fully. If any of the conditions below is met, the Exporting Process does not properly use the per-SCTP-stream extension, and the Collecting Process MUST log an error message and disable this extension for the SCTP association.
DataRecordSreliabilityオプションテンプレートのように見えるテンプレートを送信することから、SCTPストリームあたりの拡張機能の仕様を満たさない実装を防ぐものはありません。したがって、収集プロセスは、エクスポートプロセスが仕様を完全に満たしていないかどうかを検出する必要があります。以下の条件のいずれかが満たされている場合、エクスポートプロセスではSCTP通信ごとの拡張機能を適切に使用しておらず、収集プロセスはエラーメッセージを記録し、SCTPアソシエーションのこの拡張機能を無効にする必要があります。
1. A Data Record is received before the appropriate Data Record associated with the Data Records Reliability Options Template has been received on the same SCTP stream (see Section 4.2). Note: Data Records associated with the Data Records Reliability Options Template are an exception to this rule.
1. データレコードの信頼性オプションテンプレートに関連する適切なデータレコードが同じSCTPストリームで受信される前に、データレコードが受信されます（セクション4.2を参照）。注：データレコードに関連するデータレコード信頼性オプションテンプレートは、このルールの例外です。
2. A Data Record associated with a Data Records Reliability Options Template is received on an SCTP stream for a (non-Options) Template that was defined on a different SCTP stream.
2. データレコードの信頼性オプションテンプレートに関連付けられたデータレコードは、異なるSCTPストリームで定義された（非オプション）テンプレートのSCTPストリームで受信されます。
3. A second Data Record associated with the Data Records Reliability Options Template is received for the same (Options) Template.
3. データレコードの信頼性オプションテンプレートに関連付けられた2番目のデータレコードは、同じ（オプション）テンプレートに対して受信されます。
4. A Data Record or a Template Withdrawal Message is associated with a Template that was defined on a different SCTP stream.
4. データレコードまたはテンプレートの引き出しメッセージは、異なるSCTPストリームで定義されたテンプレートに関連付けられています。
5. Loss of Data Records is detected within a stream where a Data Record associated with the Data Records Reliability Options Template indicating unreliable transmission for any Template has not been received.
5. データレコードの損失は、データレコードの信頼性オプションテンプレートに関連付けられたデータレコードが、テンプレートの信頼できない送信が受信されていないことを示すストリーム内で検出されます。
6. A message is received with the SCTP U(nordered) flag set to 1 (i.e., the message was sent unordered), even if it is processed in order.
6. sctp u（nordered）フラグが1に設定されている場合（つまり、メッセージが順序付けられていない場合）メッセージが受信されます。
As specified in [RFC5101], the IPFIX protocol has a Sequence Number field in the IPFIX Message header that increases with the number of IPFIX Data Records in the IPFIX Message. A Collecting Process may detect out-of-sequence, dropped, or duplicate IPFIX Messages by tracking the Sequence Number.
[RFC5101]で指定されているように、IPFIXプロトコルにはIPFIXメッセージヘッダーにシーケンス番号フィールドがあり、IPFIXメッセージのIPFIXデータレコードの数とともに増加します。収集プロセスでは、シーケンス番号を追跡して、IPFIXメッセージをドロップしたり、複製したりすることができます。
When one or more sequential IPFIX Messages are considered lost, the number of lost Data Records is equal to the Sequence Number of the first IPFIX Message Header following the lost packets (S2) minus the Sequence Number of the first lost IPFIX Message (S1). The Sequence Number of the first lost IPFIX Message can be calculated as the Sequence Number of the last IPFIX Message before the sequence of lost IPFIX Messages (S0) plus the number of Data Records in that IPFIX Message (N0).
1つ以上のシーケンシャルIPFIXメッセージが失われたと見なされると、失われたデータレコードの数は、失われたパケット（S2）に続く最初のIPFIXメッセージヘッダーのシーケンス番号に等しくなります。最初の失われたIPFIXメッセージのシーケンス番号は、失われたIPFIXメッセージ（S0）のシーケンスの前に、最後のIPFIXメッセージのシーケンス番号として計算できます。
S1 = S0 + N0
loss = (S2 - S1) (mod(2^32))
= (S2 - (S0 + N0)) (mod(2^32))
Note that modulo 2^32 arithmetic is required, since the Sequence Number may wrap within the series of lost IPFIX Messages. If less than 2^32 Data Records are lost in a sequence (which can be assumed in practice), the above equation returns the exact number of lost Data Records.
シーケンス番号が一連の失われたIPFIXメッセージ内でラップする可能性があるため、Modulo 2^32算術が必要であることに注意してください。2^32未満のデータレコードがシーケンスで失われた場合（実際には想定できます）、上記の方程式は失われたデータレコードの正確な数を返します。
Note that using an unsigned32 type for the loss would automatically take care of the mod(2^32) operation.
損失にunsigned32タイプを使用すると、MOD（2^32）操作が自動的に処理されることに注意してください。
As this Sequence Number is incremented per SCTP stream, the loss of Data Records sent in that SCTP stream can be calculated in the case of partially reliable export. This loss can be attributed to the Data Records sent for the (Options) Template(s) whose records are being sent unreliably within that SCTP stream.
このシーケンス数はSCTPストリームごとに増加するため、そのSCTPストリームで送信されたデータレコードの損失は、部分的に信頼できるエクスポートの場合に計算できます。この損失は、そのsctpストリーム内でレコードが間違いなく送信されている（オプション）テンプレートに送信されたデータレコードに起因する可能性があります。
Although adding the new SCTP streams requires a message exchange, it is more lightweight to set up additional SCTP streams than to set up a new SCTP association, since the only overhead of adding SCTP stream(s) to an existing SCTP association is the addition of 16-24 more bytes (allocated in the SCTP association, a single time), whereas setting up a new SCTP association requires more overhead.
新しいSCTPストリームを追加するにはメッセージ交換が必要ですが、既存のSCTPストリームを追加する唯一のオーバーヘッドは、既存のSCTPアソシエーションに追加する唯一のオーバーヘッドは追加であるため、新しいSCTPアソシエーションをセットアップするよりも追加のSCTPストリームをセットアップする方がより軽量です。16-24バイト（SCTP協会で1回割り当てられます）が、新しいSCTP協会を設定するには、より多くのオーバーヘッドが必要です。
In terms of throughput impact, the fact that these specifications discourage multiplexing Templates and Data Records of different Template IDs may lead to a slightly larger IPFIX Message overhead.
スループットの影響に関しては、これらの仕様が異なるテンプレートIDの多重化テンプレートとデータレコードを阻止するという事実は、わずかに大きいIPFIXメッセージのオーバーヘッドにつながる可能性があります。
If the Data Record rate is low for a specific Template (and hence a specific SCTP stream), the Exporting Process might not be able to fill the IPFIX Messages with Data Records associated with other Templates. In such a situation, there is a potential overhead due to additional IPFIX Message headers and SCTP chunk headers.
特定のテンプレート（したがって特定のSCTPストリーム）のデータレコードレートが低い場合、エクスポートプロセスでは、IPFIXメッセージに他のテンプレートに関連付けられたデータレコードを入力できない場合があります。このような状況では、追加のIPFIXメッセージヘッダーとSCTPチャンクヘッダーのために、潜在的なオーバーヘッドがあります。
Finally, with respect to the processing overhead on the Exporter, a lot of state information must be stored when a large number of SCTP streams are used within an SCTP association. However, no comparison of the performance impact of multiple streams within an SCTP association versus opening the same number of independent SCTP associations is available.
最後に、輸出業者の処理オーバーヘッドに関しては、SCTP協会内で多数のSCTPストリームを使用している場合、多くの州情報を保存する必要があります。ただし、同じ数の独立したSCTPアソシエーションを開くのと、SCTPアソシエーション内の複数のストリームのパフォーマンスへの影響の比較は利用できません。
Figure 1 shows an example where SCTP stream 10 carries a Template Record with Template ID 257 transmitted with full reliability (FR), together with associated Data Records transmitted with partial reliability (PR). The Data Records Reliability Options Template with Template ID 256 is transmitted with full reliability. Its corresponding Data Set contains one Data Record.
図1は、SCTPストリーム10が、部分的信頼性（PR）を送信した関連データレコードとともに、完全な信頼性（FR）を送信したテンプレートID 257を備えたテンプレートレコードを運ぶ例を示しています。テンプレートID 256を備えたデータレコード信頼性オプションテンプレートには、完全な信頼性が送信されます。対応するデータセットには、1つのデータレコードが含まれています。
Record 1:
レコード1：
o Scope: Template ID = 257 o Non-scope: dataRecordsReliability = False
o 範囲：テンプレートID = 257 o非スコープ：DataRecordsReliability = false
+--------+ +---------+ +--------+
| | | | | |
stream 10 ----| Data | . . . | Data |---| Data |---...
| 257 | | 257 | | 256 |
| PR| | PR| | FR|
+--------+ +---------+ +--------+
+----------+ +-------------+
| | | Reliability |
| | | Options |
...---| Template |-------| Template |------>
| 257 | | 256 |
| FR| | FR|
+----------+ +-------------+
Figure 1
図1
Note that Template 257 will always be processed before the Data Records by the Collecting Process, because all IPFIX Messages are sent in order within an SCTP stream. Therefore, the job of the Collecting Process is simplified. Furthermore, the Data Record loss for Template 257 can easily be calculated by the Collecting Process.
すべてのIPFIXメッセージはSCTPストリーム内で順番に送信されるため、テンプレート257は収集プロセスによってデータレコードの前に常に処理されることに注意してください。したがって、収集プロセスの仕事は簡素化されます。さらに、テンプレート257のデータ記録損失は、収集プロセスによって簡単に計算できます。
If an Options Template is necessary to understand the content of a Data Record (i.e., the scope in the Options Template Record is an Information Element contained in the Data Record or associated with the Data Record), the Options Template Record should be sent in the same SCTP stream, as displayed in Figure 2.
データレコードの内容を理解するためにオプションテンプレートが必要な場合（つまり、オプションテンプレートレコードのスコープはデータレコードに含まれる情報要素であるか、データレコードに関連付けられています）、オプションテンプレートレコードは図2に表示されているのと同じSCTPストリーム。
+--------+ +--------+ +--------+
| | | | | |
stream 20 ----| Data |...| Data |-----| Data |--- ...
| 260 | | 260 | | 259 |
| PR| | PR| | FR|
+--------+ +--------+ +--------+
+--------+ +----------+
| | | |
...---| Data |-------| Template |---...
| 258 | | 260 |
| FR| | FR|
+--------+ +----------+
+----------+ +-------------+
| Options | | Reliability |
| Template | | Options |
...---| |-------| Template |------>
| 259 | | 258 |
| FR| | FR|
+----------+ +-------------+
Figure 2
図2
Figure 2 shows an example where SCTP stream 20 carries the following:
図2は、SCTPストリーム20に次のような例を示しています。
- a Data Records Reliability Options Template with Template ID 258, transmitted with full reliability.
- 完全な信頼性で送信されたテンプレートID 258を備えたデータの信頼性オプションテンプレートを記録します。
- an Options Template Record with Template ID 259, transmitted with full reliability. This Options Template Record contains additional information related to the subsequent Data Records based on Template ID 260. Typical examples are the Common Properties information [RFC5473] or the Selector Report Interpretation [RFC5476].
- 完全な信頼性で送信されたテンプレートID 259を備えたオプションテンプレートレコード。このオプションテンプレートレコードには、テンプレートID 260に基づいた後続のデータレコードに関連する追加情報が含まれています。典型的な例は、一般的なプロパティ情報[RFC5473]またはセレクターレポートの解釈[RFC5476]です。
- a Template Record with Template ID 260, transmitted with full reliability.
- 完全な信頼性で送信されたテンプレートID 260を備えたテンプレートレコード。
- a Data Set specified by the Reliability Options Template with Template ID 258, transmitted with full reliability.
- テンプレートID 258を備えた信頼性オプションテンプレートで指定されたデータセットは、完全な信頼性で送信されます。
The Data Set contains three Data Records:
データセットには3つのデータレコードが含まれています。
Record 1:
o Scope: Template ID = 258
o Non-scope: dataRecordsReliability = True
Record 2:
o Scope: Template ID = 259
o Non-scope: dataRecordsReliability = True
Record 3:
o Scope: Template ID = 260
o Non-scope: dataRecordsReliability = False
These Data Records inform the Collecting Process that the Data Records for Template IDs 258 and 259 are sent reliably, while the Data Records for Template ID 260 are not. Note that the first Data Record associated with the Data Record Reliability Options Template (Template ID 258) is not required and can be omitted.
これらのデータレコードは、テンプレートID 258および259のデータレコードが確実に送信され、テンプレートID 260のデータレコードはそうではないことを収集プロセスに通知します。データレコードの信頼性オプションテンプレート（テンプレートID 258）に関連付けられた最初のデータレコードは不要であり、省略できます。
- a Data Record specified by Template ID 259, transmitted with full reliability.
- テンプレートID 259で指定されたデータレコードは、完全な信頼性で送信されます。
- a Data Record specified by Template ID 260, transmitted with partial reliability.
- テンプレートID 260で指定されたデータレコードは、部分的な信頼性を備えています。
If the Collecting Process observes some Data Record loss using the Sequence Number, the loss can only stem from the Data Records associated with Template ID 260, as these are the only Data Records not exported reliably. Therefore, the calculation of loss per Template ID 260 is possible.
収集プロセスがシーケンス番号を使用してデータレコードの損失を観察する場合、損失はテンプレートID 260に関連付けられたデータレコードからのみ生じることができます。これらは確実にエクスポートされていない唯一のデータレコードです。したがって、テンプレートID 260あたりの損失の計算が可能です。
Note that Options Templates 258, 259, and 260 will always arrive before their associated Data Records, respectively, because all IPFIX Messages must be sent in order within an SCTP stream.
すべてのIPFIXメッセージをSCTPストリーム内で順番に送信する必要があるため、オプションテンプレート258、259、および260はそれぞれ関連するデータレコードの前に常に到着することに注意してください。
Figure 3 shows an example where SCTP stream 30 carries a Template Record with Template ID 262 transmitted with full reliability, an associated Data Record transmitted with full reliability, and a Template Withdrawal Message, followed by a redefinition of Template ID 262, and finally the Data Record associated with the new Template transmitted with partial reliability. The Template Withdrawal Message and the new definition of Template ID 262 are sent immediately, without waiting for the Template Reuse Delay interval.
図3は、SCTPストリーム30が、完全な信頼性を備えたテンプレートID 262を備えたテンプレートレコード、完全な信頼性を送信する関連データレコード、およびテンプレート引き出しメッセージ、その後、テンプレートID 262の再定義、最後にデータの再定義を伴う例を示しています。部分的な信頼性を備えた新しいテンプレートに関連付けられたレコード。テンプレートの再利用遅延間隔を待つことなく、テンプレートの引き出しメッセージとテンプレートID 262の新しい定義はすぐに送信されます。
+--------+ +----------+ +----------+
| | |Data | | |
stream 30 ... ---| Data |...| 261 |-----| Template |---
| 262 | |tmpID: 262| | 262 |
| PR| |dRR: False| | FR|
+--------+ +----------+ +----------+
+----------+ +--------+ +----------+
| Template | | | | Data |
...| Withdraw |-----| Data |-------| 261 |---...
| 262 | | 262 | |tmpID: 262|
| FR| | FR| |dRR: True|
+----------+ +--------+ +----------+
+----------+ +-------------+
| | | Reliability |
| Template | | Options |
...---| |-------| Template |------>
| 262 | | 261 |
| FR| | FR|
+----------+ +-------------+
dRR: Data Records Reliability
DRR：データレコードの信頼性
Figure 3
図3
The second Data Record associated with the Data Records Reliability Options Template shows that the Data Records associated with the newly specified Template ID 262 will be sent unreliably.
データレコードの信頼性オプションテンプレートに関連付けられている2番目のデータレコードは、新しく指定されたテンプレートID 262に関連付けられているデータレコードが必ず送信されることを示しています。
According to the process defined in [RFC5102], IANA has allocated the dataRecordsReliability Information Element (defined in Section 4.1) in the "IPFIX Information Elements" registry [IANA].
[RFC5102]で定義されているプロセスによれば、IANAは「IPFIX情報要素」レジストリ[IANA]のDatareCordsReliability情報要素（セクション4.1で定義）を割り当てました。
The same security considerations as for the IPFIX protocol [RFC5101] apply.
IPFIXプロトコル[RFC5101]と同じセキュリティ上の考慮事項が適用されます。
[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] Stewart、R.、Ramalho、M.、Xie、Q.、Tuexen、M。、およびP. Conrad、「Stream Control Transmission Protocol（SCTP）部分信頼性拡張」、RFC 3758、2004年5月。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R.、ed。、「Stream Control Transmission Protocol」、RFC 4960、2007年9月。
[RFC5101] Claise, B., Ed., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008.
[RFC5101] Claise、B.、ed。、「IPトラフィックフロー情報の交換のためのIPフロー情報エクスポート（IPFIX）プロトコルの仕様」、RFC 5101、2008年1月。
[RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, January 2008.
[RFC5102] Quittek、J.、Bryant、S.、Claise、B.、Aitken、P。、およびJ. Meyer、「IPフロー情報エクスポートの情報モデル」、RFC 5102、2008年1月。
[RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. Raspall, "Sampling and Filtering Techniques for IP Packet Selection", RFC 5475, March 2009.
[RFC5475] Zseby、T.、Molina、M.、Duffield、N.、Niccolini、S。、およびF. Raspall、「IPパケット選択のためのサンプリングとフィルタリング技術」、RFC 5475、2009年3月。
[RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control Transmission Protocol (SCTP) Stream Reconfiguration", RFC 6525, February 2012.
[RFC6525] Stewart、R.、Tuexen、M。、およびP. Lei、「ストリーム制御伝送プロトコル（SCTP）ストリーム再構成」、RFC 6525、2012年2月。
[IANA] IPFIX Information Elements Registry, <http://www.iana.org/assignments/ipfix>.
[IANA] IPFIX情報要素レジストリ、<http://www.iana.org/assignments/ipfix>。
[RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export (IPFIX)", RFC 3917, October 2004.
[RFC3917] Quittek、J.、Zseby、T.、Claise、B。、およびS. Zander、「IP Flow Information Export（IPFIX）の要件」、RFC 3917、2004年10月。
[RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture for IP Flow Information Export", RFC 5470, March 2009.
[RFC5470] Sadasivan、G.、Brownlee、N.、Claise、B。、およびJ. Quittek、「IPフロー情報エクスポートのアーキテクチャ」、RFC 5470、2009年3月。
[RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP Flow Information Export (IPFIX) Applicability", RFC 5472, March 2009.
[RFC5472] Zseby、T.、Boschi、E.、Brownlee、N。、およびB. Claise、「IP Flow Information Export（IPFIX）Applicability」、RFC 5472、2009年3月。
[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、「IPフロー情報エクスポート（IPFIX）およびパケットサンプリング（PSAMP）レポートの冗長性の削減」、RFC 5473、2009年3月。
[RFC5474] Duffield, N., Ed., Chiou, D., Claise, B., Greenberg, A., Grossglauser, M., and J. Rexford, "A Framework for Packet Selection and Reporting", RFC 5474, March 2009.
[RFC5474] Duffield、N.、Ed。、Chiou、D.、Claise、B.、Greenberg、A.、Grossglauser、M。、およびJ. Rexford、「パケット選択とレポートのフレームワーク」、RFC 5474、3月2009年。
[RFC5476] Claise, B., Ed., Johnson, A., and J. Quittek, "Packet Sampling (PSAMP) Protocol Specifications", RFC 5476, March 2009.
[RFC5476] Claise、B.、ed。、Johnson、A。、およびJ. Quittek、「パケットサンプリング（PSAMP）プロトコル仕様」、RFC 5476、2009年3月。
[RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. Carle, "Information Model for Packet Sampling Exports", RFC 5477, March 2009.
[RFC5477] Dietz、T.、Claise、B.、Aitken、P.、Dressler、F.、およびG. Carle、「パケットサンプリングエクスポートの情報モデル」、RFC 5477、2009年3月。
The authors would like to thank Brian Trammell for his expert feedback and continuous effort to improve the specifications; Elisa Boschi for her thorough reading; Randall Stewart, Peter Lei, and Michael Tuexen for their SCTP-related feedback and expertise; and Tobias Limmer.
著者は、ブライアン・トラメルの専門的なフィードバックと仕様を改善するための継続的な努力について感謝したいと思います。彼女の徹底的な読書のためにエリサ・ボスキ。Randall Stewart、Peter Lei、およびMichael TuexenのSCTP関連のフィードバックと専門知識について。そしてトビアスのリマー。
Authors' Addresses
著者のアドレス
Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 Diegem 1813 Belgium
Benoit Claise Cisco Systems、Inc。de Kleetlaan 6a B1 Diegem 1813ベルギー
Phone: +32 2 704 5622
EMail: bclaise@cisco.com
Paul Aitken Cisco Systems, Inc. 96 Commercial Quay Commercial Street Edinburgh, EH6 6LX, United Kingdom
Paul Aitken Cisco Systems、Inc。96コマーシャルキーコマーシャルストリートエディンバラ、EH6 6LX、イギリス
Phone: +44 131 561 3616
EMail: paitken@cisco.com
Andrew Johnson Cisco Systems, Inc. 96 Commercial Quay Commercial Street Edinburgh, EH6 6LX, United Kingdom
Andrew Johnson Cisco Systems、Inc。96コマーシャルキーコマーシャルストリートエディンバラ、EH6 6LX、イギリス
Phone: +44 131 561 3641
EMail: andrjohn@cisco.com
Gerhard Muenz Technische Universitaet Muenchen Department of Informatics - I8 Boltzmannstr. 3 Garching D-85748 DE
Gerhard Muenz Technische Universitaet Muenchen Informatics Department -I8 Boltzmannstr。3 Garching D-85748 de
EMail: muenz@net.in.tum.de
URI: http://www.net.in.tum.de/~muenz