[要約] RFC 5102は、IPフロー情報のエクスポートのための情報モデルを定義しています。このRFCの目的は、ネットワークデバイスから収集されたIPフロー情報を効果的にエクスポートするための標準化を提供することです。
Network Working Group J. Quittek
Request for Comments: 5102 NEC
Category: Standards Track S. Bryant
B. Claise
P. Aitken
Cisco Systems, Inc.
J. Meyer
PayPal
January 2008
Information Model for IP Flow Information Export
IPフロー情報エクスポートの情報モデル
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Abstract
概要
This memo defines an information model for the IP Flow Information eXport (IPFIX) protocol. It is used by the IPFIX protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic Metering Process, and the Exporting Process. Although developed for the IPFIX protocol, the model is defined in an open way that easily allows using it in other protocols, interfaces, and applications.
このメモは、IPフロー情報エクスポート（IPFIX）プロトコルの情報モデルを定義します。IPFIXプロトコルでは、測定されたトラフィック情報とトラフィック観測点、トラフィックメータープロセス、およびエクスポートプロセスに関連する情報をエンコードするために使用されます。IPFIXプロトコル用に開発されましたが、モデルはオープンな方法で定義されており、他のプロトコル、インターフェイス、アプリケーションで簡単に使用できます。
Table of Contents
目次
1. Introduction ....................................................6
2. Properties of IPFIX Protocol Information Elements ...............7
2.1. Information Elements Specification Template ................7
2.2. Scope of Information Elements ..............................9
2.3. Naming Conventions for Information Elements ................9
3. Type Space .....................................................10
3.1. Abstract Data Types .......................................10
3.1.1. unsigned8 ..........................................10
3.1.2. unsigned16 .........................................11
3.1.3. unsigned32 .........................................11
3.1.4. unsigned64 .........................................11
3.1.5. signed8 ............................................11
3.1.6. signed16 ...........................................11
3.1.7. signed32 ...........................................11
3.1.8. signed64 ...........................................11
3.1.9. float32 ............................................11
3.1.10. float64 ...........................................11
3.1.11. boolean ...........................................12
3.1.12. macAddress ........................................12
3.1.13. octetArray ........................................12
3.1.14. string ............................................12
3.1.15. dateTimeSeconds ...................................12
3.1.16. dateTimeMilliseconds ..............................12
3.1.17. dateTimeMicroseconds ..............................12
3.1.18. dateTimeNanoseconds ...............................13
3.1.19. ipv4Address .......................................13
3.1.20. ipv6Address .......................................13
3.2. Data Type Semantics .......................................13
3.2.1. quantity ...........................................13
3.2.2. totalCounter .......................................13
3.2.3. deltaCounter .......................................14
3.2.4. identifier .........................................14
3.2.5. flags ..............................................14
4. Information Element Identifiers ................................14
5. Information Elements ...........................................18
5.1. Identifiers ...............................................19
5.1.1. lineCardId .........................................20
5.1.2. portId .............................................20
5.1.3. ingressInterface ...................................20
5.1.4. egressInterface ....................................21
5.1.5. meteringProcessId ..................................21
5.1.6. exportingProcessId .................................21
5.1.7. flowId .............................................22
5.1.8. templateId .........................................22
5.1.9. observationDomainId ................................22
5.1.10. observationPointId ................................23
5.1.11. commonPropertiesId ................................23
5.2. Metering and Exporting Process Configuration ..............23
5.2.1. exporterIPv4Address ................................24
5.2.2. exporterIPv6Address ................................24
5.2.3. exporterTransportPort ..............................24
5.2.4. collectorIPv4Address ...............................25
5.2.5. collectorIPv6Address ...............................25
5.2.6. exportInterface ....................................25
5.2.7. exportProtocolVersion ..............................26
5.2.8. exportTransportProtocol ............................26
5.2.9. collectorTransportPort .............................27
5.2.10. flowKeyIndicator ..................................27
5.3. Metering and Exporting Process Statistics .................28
5.3.1. exportedMessageTotalCount ..........................28
5.3.2. exportedOctetTotalCount ............................28
5.3.3. exportedFlowRecordTotalCount .......................29
5.3.4. observedFlowTotalCount .............................29
5.3.5. ignoredPacketTotalCount ............................29
5.3.6. ignoredOctetTotalCount .............................30
5.3.7. notSentFlowTotalCount ..............................30
5.3.8. notSentPacketTotalCount ............................30
5.3.9. notSentOctetTotalCount .............................31
5.4. IP Header Fields ..........................................31
5.4.1. ipVersion ..........................................31
5.4.2. sourceIPv4Address ..................................32
5.4.3. sourceIPv6Address ..................................32
5.4.4. sourceIPv4PrefixLength .............................32
5.4.5. sourceIPv6PrefixLength .............................33
5.4.6. sourceIPv4Prefix ...................................33
5.4.7. sourceIPv6Prefix ...................................33
5.4.8. destinationIPv4Address .............................33
5.4.9. destinationIPv6Address .............................34
5.4.10. destinationIPv4PrefixLength .......................34
5.4.11. destinationIPv6PrefixLength .......................34
5.4.12. destinationIPv4Prefix .............................34
5.4.13. destinationIPv6Prefix .............................35
5.4.14. ipTTL .............................................35
5.4.15. protocolIdentifier ................................35
5.4.16. nextHeaderIPv6 ....................................36
5.4.17. ipDiffServCodePoint ...............................36
5.4.18. ipPrecedence ......................................36
5.4.19. ipClassOfService ..................................37
5.4.20. postIpClassOfService ..............................37
5.4.21. flowLabelIPv6 .....................................38
5.4.22. isMulticast .......................................38
5.4.23. fragmentIdentification ............................39
5.4.24. fragmentOffset ....................................39
5.4.25. fragmentFlags .....................................39
5.4.26. ipHeaderLength ....................................40
5.4.27. ipv4IHL ...........................................40
5.4.28. totalLengthIPv4 ...................................41
5.4.29. ipTotalLength .....................................41
5.4.30. payloadLengthIPv6 .................................41
5.5. Transport Header Fields ...................................42
5.5.1. sourceTransportPort ................................42
5.5.2. destinationTransportPort ...........................42
5.5.3. udpSourcePort ......................................43
5.5.4. udpDestinationPort .................................43
5.5.5. udpMessageLength ...................................43
5.5.6. tcpSourcePort ......................................44
5.5.7. tcpDestinationPort .................................44
5.5.8. tcpSequenceNumber ..................................44
5.5.9. tcpAcknowledgementNumber ...........................44
5.5.10. tcpWindowSize .....................................45
5.5.11. tcpWindowScale ....................................45
5.5.12. tcpUrgentPointer ..................................45
5.5.13. tcpHeaderLength ...................................45
5.5.14. icmpTypeCodeIPv4 ..................................46
5.5.15. icmpTypeIPv4 ......................................46
5.5.16. icmpCodeIPv4 ......................................46
5.5.17. icmpTypeCodeIPv6 ..................................46
5.5.18. icmpTypeIPv6 ......................................47
5.5.19. icmpCodeIPv6 ......................................47
5.5.20. igmpType ..........................................47
5.6. Sub-IP Header Fields ......................................48
5.6.1. sourceMacAddress ...................................48
5.6.2. postSourceMacAddress ...............................48
5.6.3. vlanId .............................................49
5.6.4. postVlanId .........................................49
5.6.5. destinationMacAddress ..............................49
5.6.6. postDestinationMacAddress ..........................49
5.6.7. wlanChannelId ......................................50
5.6.8. wlanSSID ...........................................50
5.6.9. mplsTopLabelTTL ....................................50
5.6.10. mplsTopLabelExp ...................................51
5.6.11. postMplsTopLabelExp ...............................51
5.6.12. mplsLabelStackDepth ...............................51
5.6.13. mplsLabelStackLength ..............................52
5.6.14. mplsPayloadLength .................................52
5.6.15. mplsTopLabelStackSection ..........................52
5.6.16. mplsLabelStackSection2 ............................53
5.6.17. mplsLabelStackSection3 ............................53
5.6.18. mplsLabelStackSection4 ............................53
5.6.19. mplsLabelStackSection5 ............................54
5.6.20. mplsLabelStackSection6 ............................54
5.6.21. mplsLabelStackSection7 ............................54
5.6.22. mplsLabelStackSection8 ............................55
5.6.23. mplsLabelStackSection9 ............................55
5.6.24. mplsLabelStackSection10 ...........................55
5.7. Derived Packet Properties .................................56
5.7.1. ipPayloadLength ....................................56
5.7.2. ipNextHopIPv4Address ...............................56
5.7.3. ipNextHopIPv6Address ...............................57
5.7.4. bgpSourceAsNumber ..................................57
5.7.5. bgpDestinationAsNumber .............................57
5.7.6. bgpNextAdjacentAsNumber ............................57
5.7.7. bgpPrevAdjacentAsNumber ............................58
5.7.8. bgpNextHopIPv4Address ..............................58
5.7.9. bgpNextHopIPv6Address ..............................58
5.7.10. mplsTopLabelType ..................................59
5.7.11. mplsTopLabelIPv4Address ...........................59
5.7.12. mplsTopLabelIPv6Address ...........................60
5.7.13. mplsVpnRouteDistinguisher .........................60
5.8. Min/Max Flow Properties ...................................61
5.8.1. minimumIpTotalLength ...............................61
5.8.2. maximumIpTotalLength ...............................61
5.8.3. minimumTTL .........................................61
5.8.4. maximumTTL .........................................62
5.8.5. ipv4Options ........................................62
5.8.6. ipv6ExtensionHeaders ...............................64
5.8.7. tcpControlBits .....................................65
5.8.8. tcpOptions .........................................66
5.9. Flow Timestamps ...........................................67
5.9.1. flowStartSeconds ...................................67
5.9.2. flowEndSeconds .....................................68
5.9.3. flowStartMilliseconds ..............................68
5.9.4. flowEndMilliseconds ................................68
5.9.5. flowStartMicroseconds ..............................68
5.9.6. flowEndMicroseconds ................................68
5.9.7. flowStartNanoseconds ...............................69
5.9.8. flowEndNanoseconds .................................69
5.9.9. flowStartDeltaMicroseconds .........................69
5.9.10. flowEndDeltaMicroseconds ..........................69
5.9.11. systemInitTimeMilliseconds ........................70
5.9.12. flowStartSysUpTime ................................70
5.9.13. flowEndSysUpTime ..................................70
5.10. Per-Flow Counters ........................................70
5.10.1. octetDeltaCount ...................................71
5.10.2. postOctetDeltaCount ...............................71
5.10.3. octetDeltaSumOfSquares ............................72
5.10.4. octetTotalCount ...................................72
5.10.5. postOctetTotalCount ...............................72
5.10.6. octetTotalSumOfSquares ............................72
5.10.7. packetDeltaCount ..................................73
5.10.8. postPacketDeltaCount ..............................73
5.10.9. packetTotalCount ..................................73
5.10.10. postPacketTotalCount .............................74
5.10.11. droppedOctetDeltaCount ...........................74
5.10.12. droppedPacketDeltaCount ..........................74
5.10.13. droppedOctetTotalCount ...........................74
5.10.14. droppedPacketTotalCount ..........................75
5.10.15. postMCastPacketDeltaCount ........................75
5.10.16. postMCastOctetDeltaCount .........................75
5.10.17. postMCastPacketTotalCount ........................76
5.10.18. postMCastOctetTotalCount .........................76
5.10.19. tcpSynTotalCount .................................76
5.10.20. tcpFinTotalCount .................................77
5.10.21. tcpRstTotalCount .................................77
5.10.22. tcpPshTotalCount .................................77
5.10.23. tcpAckTotalCount .................................78
5.10.24. tcpUrgTotalCount .................................78
5.11. Miscellaneous Flow Properties ............................78
5.11.1. flowActiveTimeout .................................79
5.11.2. flowIdleTimeout ...................................79
5.11.3. flowEndReason .....................................79
5.11.4. flowDurationMilliseconds ..........................80
5.11.5. flowDurationMicroseconds ..........................80
5.11.6. flowDirection .....................................80
5.12. Padding ..................................................80
5.12.1. paddingOctets .....................................81
6. Extending the Information Model ................................81
7. IANA Considerations ............................................82
7.1. IPFIX Information Elements ................................82
7.2. MPLS Label Type Identifier ................................82
7.3. XML Namespace and Schema ..................................83
8. Security Considerations ........................................83
9. Acknowledgements ...............................................84
10. References ....................................................84
10.1. Normative References .....................................84
10.2. Informative References ...................................84
Appendix A. XML Specification of IPFIX Information Elements .......88
Appendix B. XML Specification of Abstract Data Types .............157
The IP Flow Information eXport (IPFIX) protocol serves for transmitting information related to measured IP traffic over the Internet. The protocol specification in [RFC5101] defines how Information Elements are transmitted. For Information Elements, it specifies the encoding of a set of basic data types. However, the list of Information Elements that can be transmitted by the protocol, such as Flow attributes (source IP address, number of packets, etc.) and information about the Metering and Exporting Process (packet Observation Point, sampling rate, Flow timeout interval, etc.), is not specified in [RFC5101].
IPフロー情報エクスポート（IPFIX）プロトコルは、インターネット上の測定されたIPトラフィックに関連する情報を送信するのに役立ちます。[RFC5101]のプロトコル仕様は、情報要素の送信方法を定義します。情報要素については、一連の基本データ型のエンコードを指定します。ただし、フロー属性（ソースIPアドレス、パケット数など）など、プロトコルで送信できる情報要素のリスト、および計量およびエクスポートプロセスに関する情報（パケット観測ポイント、サンプリングレート、フロータイムアウト間隔、など）、[RFC5101]で指定されていません。
This document complements the IPFIX protocol specification by providing the IPFIX information model. 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情報モデルを提供することにより、IPFIXプロトコルの仕様を補完します。このドキュメントで使用されるIPFIX固有の用語は、[RFC5101]のセクション2で定義されています。[RFC5101]のように、これらのIPFIX固有の用語には、このドキュメントで使用されたときに最初の単語の文字が大文字になります。
The use of the term 'information model' is not fully in line with the definition of this term in [RFC3444]. The IPFIX information model does not specify relationships between Information Elements, but also it does not specify a concrete encoding of Information Elements. Besides the encoding used by the IPFIX protocol, other encodings of IPFIX Information Elements can be applied, for example, XML-based encodings.
「情報モデル」という用語の使用は、[RFC3444]のこの用語の定義と完全に一致していません。IPFIX情報モデルは、情報要素間の関係を指定するのではなく、情報要素の具体的なエンコードも指定しません。IPFIXプロトコルで使用されるエンコーディングに加えて、IPFIX情報要素の他のエンコーディングを適用できます。たとえば、XMLベースのエンコーディングなどです。
The main part of this document is Section 5, which defines the (extensible) list of Information Elements to be transmitted by the IPFIX protocol. Section 2 defines a template for specifying IPFIX Information Elements in Section 5. Section 3 defines the set of abstract data types that are available for IPFIX Information Elements. Section 6 discusses extensibility of the IPFIX information model.
このドキュメントの主な部分はセクション5で、IPFIXプロトコルによって送信される情報要素の（拡張可能な）リストを定義します。セクション2では、セクション5でIPFIX情報要素を指定するためのテンプレートを定義します。セクション3では、IPFIX情報要素で使用できる抽象データ型のセットを定義します。セクション6では、IPFIX情報モデルの拡張性について説明します。
The main bodies of Sections 2, 3, and 5 were generated from XML documents. The XML-based specification of template, abstract data types, and IPFIX Information Elements can be used for automatically checking syntactical correctness of the specification of IPFIX Information Elements. It can further be used for generating IPFIX protocol implementation code that deals with processing IPFIX Information Elements. Also, code for applications that further process traffic information transmitted via the IPFIX protocol can be generated with the XML specification of IPFIX Information Elements.
セクション2、3、および5の主な本体は、XMLドキュメントから生成されました。テンプレート、抽象データ型、およびIPFIX情報要素のXMLベースの仕様を使用して、IPFIX情報要素の仕様の構文的な正しさを自動的に確認できます。さらに、IPFIX情報要素の処理を扱うIPFIXプロトコル実装コードの生成に使用できます。また、IPFIXプロトコルを介して送信されるトラフィック情報をさらに処理するアプリケーションのコードは、IPFIX情報要素のXML仕様で生成できます。
For that reason, the XML document that served as a source for Section 5 and the XML schema that served as source for Sections 2 and 3 are attached to this document in Appendices A and B.
そのため、セクション5のソースとして機能したXMLドキュメントと、セクション2および3のソースとして機能するXMLスキーマは、付録AおよびBのこのドキュメントに添付されています。
Note that although partially generated from the attached XML documents, the main body of this document is normative while the appendices are informational.
添付されたXMLドキュメントから部分的に生成されますが、このドキュメントの本体は規範的であり、付録は情報に基づいていることに注意してください。
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 [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
Information in messages of the IPFIX protocol is modeled in terms of Information Elements of the IPFIX information model. IPFIX Information Elements are specified in Section 5. For specifying these Information Elements, a template is used that is described below.
All Information Elements specified for the IPFIX protocol either in this document or by any future extension MUST have the following properties defined:
このドキュメントまたは将来の拡張機能のいずれかでIPFIXプロトコルに指定されたすべての情報要素は、次のプロパティを定義する必要があります。
name - A unique and meaningful name for the Information Element.
名前 - 情報要素のユニークで意味のある名前。
elementId - A numeric identifier of the Information Element. If this identifier is used without an enterprise identifier (see [RFC5101] and enterpriseId below), then it is globally unique and the list of allowed values is administered by IANA. It is used for compact identification of an Information Element when encoding Templates in the protocol.
ElementID-情報要素の数値識別子。この識別子がエンタープライズ識別子（[RFC5101]と以下のEnterpriseidを参照）なしで使用されている場合、それはグローバルに一意であり、許可された値のリストはIANAによって管理されます。プロトコル内のテンプレートをエンコードするときに、情報要素のコンパクトな識別に使用されます。
description - The semantics of this Information Element. Describes how this Information Element is derived from the Flow or other information available to the observer.
説明 - この情報要素のセマンティクス。この情報要素が、オブザーバーが利用できるフローまたはその他の情報からどのように導き出されるかについて説明します。
dataType - One of the types listed in Section 3.1 of this document or in a future extension of the information model. The type space for attributes is constrained to facilitate implementation. The existing type space does however encompass most basic types used in modern programming languages, as well as some derived types (such as ipv4Address) that are common to this domain and useful to distinguish.
データタイプ - このドキュメントのセクション3.1にリストされているタイプの1つまたは情報モデルの将来の拡張。属性のタイプスペースは、実装を容易にするために制約されています。ただし、既存のタイプスペースには、最新のプログラミング言語で使用されるほとんどの基本的なタイプと、このドメインに共通し、区別するのに役立ついくつかの派生タイプ（IPv4Addressなど）が含まれます。
status - The status of the specification of this Information Element. Allowed values are 'current', 'deprecated', and 'obsolete'.
ステータス - この情報要素の仕様のステータス。許可された値は、「現在」、「非推奨」、および「時代遅れ」です。
Enterprise-specific Information Elements MUST have the following property defined:
エンタープライズ固有の情報要素は、次のプロパティを定義する必要があります。
enterpriseId - Enterprises may wish to define Information Elements without registering them with IANA, for example, for enterprise-internal purposes. For such Information Elements, the Information Element identifier described above is not sufficient when the Information Element is used outside the enterprise. If specifications of enterprise-specific Information Elements are made public and/or if enterprise-specific identifiers are used by the IPFIX protocol outside the enterprise, then the enterprise-specific identifier MUST be made globally unique by combining it with an enterprise identifier. Valid values for the enterpriseId are defined by IANA as Structure of Management Information (SMI) network management private enterprise codes. They are defined at http://www.iana.org/assignments/enterprise-numbers.
EnterpriseID-エンタープライズは、たとえばエンタープライズ内目的のために、IANAに登録せずに情報要素を定義したい場合があります。このような情報要素については、上記の情報要素識別子は、情報要素がエンタープライズの外で使用されている場合、十分ではありません。エンタープライズ固有の情報要素の仕様が公開されている場合、および/またはエンタープライズ固有の識別子がエンタープライズ外のIPFIXプロトコルで使用されている場合、エンタープライズ固有の識別子をエンタープライズ識別子と組み合わせることによりグローバルに一意にする必要があります。EnterpriseIDの有効な値は、IANAによって管理情報の構造（SMI）ネットワーク管理のプライベートエンタープライズコードとして定義されています。それらはhttp://www.iana.org/assignments/enterprise-numbersで定義されています。
All Information Elements specified for the IPFIX protocol either in this document or by any future extension MAY have the following properties defined:
このドキュメントまたは将来の拡張機能でIPFIXプロトコルに指定されたすべての情報要素は、次のプロパティを定義する場合があります。
dataTypeSemantics - The integral types may be qualified by additional semantic details. Valid values for the data type semantics are specified in Section 3.2 of this document or in a future extension of the information model.
DataTypESEMANTICS-積分タイプは、追加のセマンティックの詳細によって適格になる場合があります。データ型セマンティクスの有効な値は、このドキュメントのセクション3.2または情報モデルの将来の拡張で指定されています。
units - If the Information Element is a measure of some kind, the units identify what the measure is.
ユニット - 情報要素が何らかの尺度である場合、ユニットは尺度が何であるかを識別します。
range - Some Information Elements may only be able to take on a restricted set of values that can be expressed as a range (e.g., 0 through 511 inclusive). If this is the case, the valid inclusive range should be specified.
範囲 - 一部の情報要素は、範囲として表すことができる制限された値のセットのみを引き受けることができる場合があります（たとえば、0〜511包括的）。この場合、有効な包括的範囲を指定する必要があります。
reference - Identifies additional specifications that more precisely define this item or provide additional context for its use.
参照 - このアイテムをより正確に定義するか、使用するための追加のコンテキストを提供する追加の仕様を識別します。
By default, most Information Elements have a scope specified in their definitions.
デフォルトでは、ほとんどの情報要素には、定義で指定されたスコープがあります。
o The Information Elements defined in Sections 5.2 and 5.3 have a default of "a specific Metering Process" or of "a specific Exporting Process", respectively.
o セクション5.2および5.3で定義されている情報要素には、それぞれ「特定のメータープロセス」または「特定のエクスポートプロセス」のデフォルトがあります。
o The Information Elements defined in Sections 5.4-5.11 have a scope of "a specific Flow".
o セクション5.4-5.11で定義されている情報要素には、「特定のフロー」の範囲があります。
Within Data Records defined by Option Templates, the IPFIX protocol allows further limiting of the Information Element scope. The new scope is specified by one or more scope fields and defined as the combination of all specified scope values; see Section 3.4.2.1 on IPFIX scopes in [RFC5101].
オプションテンプレートで定義されたデータレコード内で、IPFIXプロトコルにより、情報要素の範囲をさらに制限できます。新しいスコープは、1つ以上のスコープフィールドで指定され、指定されたすべてのスコープ値の組み合わせとして定義されます。[RFC5101]のIPFIXスコープのセクション3.4.2.1を参照してください。
The following naming conventions were used for naming Information Elements in this document. It is recommended that extensions of the model use the same conventions.
このドキュメントの情報要素の命名には、次の命名規則が使用されました。モデルの拡張は同じ規則を使用することをお勧めします。
o Names of Information Elements should be descriptive.
o 情報要素の名前は説明的でなければなりません。
o Names of Information Elements that are not enterprise-specific MUST be unique within the IPFIX information model. Enterprise-specific Information Elements SHOULD be prefixed with a vendor name.
o エンタープライズ固有ではない情報要素の名前は、IPFIX情報モデル内で一意でなければなりません。エンタープライズ固有の情報要素には、ベンダー名が付いている必要があります。
o Names of Information Elements start with non-capitalized letters.
o 情報要素の名前は、資本化されていない文字から始まります。
o Composed names use capital letters for the first letter of each component (except for the first one). All other letters are non-capitalized, even for acronyms. Exceptions are made for acronyms containing non-capitalized letter, such as 'IPv4' and 'IPv6'. Examples are sourceMacAddress and destinationIPv4Address.
o 構成名は、各コンポーネントの最初の文字の大文字を使用します（最初のコンポーネントを除く）。他のすべての文字は、頭字語であっても資本化されていません。「IPv4」や「IPv6」などの非資本文字を含む頭字語の例外が行われます。例は、sourcemacaddressとdestinationipv4Addressです。
o Middleboxes [RFC3234] may change Flow properties, such as the Differentiated Service Code Point (DSCP) value or the source IP address. If an IPFIX Observation Point is located in the path of a Flow before one or more middleboxes that potentially modify packets of the Flow, then it may be desirable to also report Flow properties after the modification performed by the middleboxes. An example is an Observation Point before a packet marker changing a packet's IPv4 Type of Service (TOS) field that is encoded in Information Element classOfServiceIPv4. Then the value observed and reported by Information Element classOfServiceIPv4 is valid at the Observation Point, but not after the packet passed the packet marker. For reporting the change value of the TOS field, the IPFIX information model uses Information Elements that have a name prefix "post", for example, "postClassOfServiceIPv4". Information Elements with prefix "post" report on Flow properties that are not necessarily observed at the Observation Point, but which are obtained within the Flow's Observation Domain by other means considered to be sufficiently reliable, for example, by analyzing the packet marker's marking tables.
o ミドルボックス[RFC3234]は、差別化されたサービスコードポイント（DSCP）値やソースIPアドレスなどのフロープロパティを変更する場合があります。IPFIXの観測点が、フローのパケットを潜在的に変更する潜在的な1つ以上のミドルボックスの前にフローのパスにある場合、ミドルボックスによって実行された変更後にフロープロパティを報告することも望ましい場合があります。例は、パケットマーカーがPacketのIPv4タイプのサービス（TOS）フィールドを変更する前の観測点です。次に、情報要素classofserviceIPv4によって観察および報告された値は、パケットがパケットマーカーを通過した後ではありませんが、観測点で有効です。TOSフィールドの変更値を報告するために、IPFIX情報モデルは、たとえば「PostClassofServiceIPv4」などの名前の接頭辞「POST」を持つ情報要素を使用します。フロープロパティに関するプレフィックス「POST」レポートを使用した情報要素は、観測点で必ずしも観察されるわけではありませんが、フローの観測ドメイン内で、たとえばパケットマーカーのマーキングテーブルを分析することにより、十分に信頼できると考えられる他の手段によって得られます。
This section describes the abstract data types that can be used for the specification of IPFIX Information Elements in Section 4. Section 3.1 describes the set of abstract data types.
このセクションでは、セクション4のIPFIX情報要素の指定に使用できる抽象データ型について説明します。セクション3.1では、抽象データ型のセットについて説明します。
Abstract data types unsigned8, unsigned16, unsigned32, unsigned64, signed8, signed16, signed32, and signed64 are integral data types. As described in Section 3.2, their data type semantics can be further specified, for example, by 'totalCounter', 'deltaCounter', 'identifier', or 'flags'.
抽象データ型Unsigned8、unsigned16、unsigned32、unsigned64、Signed8、Signed16、Signed32、およびSigned64は積分データ型です。セクション3.2で説明されているように、データ型セマンティクスは、たとえば「TotalCounter」、「Deltacounter」、「Identifier」、または「Flags」など、さらに指定できます。
This section describes the set of valid abstract data types of the IPFIX information model. Note that further abstract data types may be specified by future extensions of the IPFIX information model.
このセクションでは、IPFIX情報モデルの有効な抽象データ型のセットについて説明します。IPFIX情報モデルの将来の拡張により、さらなる抽象データ型が指定される可能性があることに注意してください。
The type "unsigned8" represents a non-negative integer value in the range of 0 to 255.
タイプ「unsigned8」は、0〜255の範囲の非陰性整数値を表します。
The type "unsigned16" represents a non-negative integer value in the range of 0 to 65535.
タイプ「unsigned16」は、0〜65535の範囲の非陰性整数値を表します。
The type "unsigned32" represents a non-negative integer value in the range of 0 to 4294967295.
The type "unsigned64" represents a non-negative integer value in the range of 0 to 18446744073709551615.
タイプ「unsigned64」は、0〜1844674073709551615の範囲の非陰性整数値を表します。
The type "signed8" represents an integer value in the range of -128 to 127.
タイプ「Signed8」は、-128〜127の範囲の整数値を表します。
The type "signed16" represents an integer value in the range of -32768 to 32767.
タイプ「Signed16」は、-32768〜32767の範囲の整数値を表します。
The type "signed32" represents an integer value in the range of -2147483648 to 2147483647.
タイプ「Signed32」は、-2147483648〜2147483647の範囲の整数値を表します。
The type "signed64" represents an integer value in the range of -9223372036854775808 to 9223372036854775807.
タイプ「Signed64」は、-9223372036854775808〜9223372036854775807の範囲の整数値を表します。
The type "float32" corresponds to an IEEE single-precision 32-bit floating point type as defined in [IEEE.754.1985].
[float32]という型は、[IEEE.754.1985]で定義されているIEEEシングルプレシジョン32ビットフローティングポイントタイプに対応します。
The type "float64" corresponds to an IEEE double-precision 64-bit floating point type as defined in [IEEE.754.1985].
[float64]という型は、[IEEE.754.1985]で定義されているIEEEダブルエシジョン64ビットフローティングポイントタイプに対応します。
The type "boolean" represents a binary value. The only allowed values are "true" and "false".
タイプ「ブール」はバイナリ値を表します。許可されている唯一の値は、「真」と「false」です。
The type "macAddress" represents a string of 6 octets.
タイプ「MacAddress」は、6オクテットの文字列を表します。
The type "octetArray" represents a finite-length string of octets.
タイプ「OctetArray」は、オクテットの有限長い文字列を表します。
The type "string" represents a finite-length string of valid characters from the Unicode character encoding set [ISO.10646- 1.1993]. Unicode allows for ASCII [ISO.646.1991] and many other international character sets to be used.
タイプ「文字列」は、Unicode文字エンコードセット[ISO.10646- 1.1993]からの有限長の有効な文字の文字列を表します。Unicodeでは、ASCII [ISO.646.1991]および他の多くの国際的なキャラクターセットを使用できます。
The type "dateTimeSeconds" represents a time value in units of seconds based on coordinated universal time (UTC). The choice of an epoch, for example, 00:00 UTC, January 1, 1970, is left to corresponding encoding specifications for this type, for example, the IPFIX protocol specification. Leap seconds are excluded. Note that transformation of values might be required between different encodings if different epoch values are used.
タイプ「DateTimeseConds」は、調整されたユニバーサル時間（UTC）に基づいて、秒単位の時間値を表します。たとえば、1970年1月1日、00:00 UTCなどのエポックの選択は、このタイプの対応するエンコード仕様、たとえばIPFIXプロトコル仕様に任されています。跳躍秒は除外されます。異なるエポック値が使用される場合、異なるエンコーディング間で値の変換が必要になる場合があることに注意してください。
The type "dateTimeMilliseconds" represents a time value in units of milliseconds based on coordinated universal time (UTC). The choice of an epoch, for example, 00:00 UTC, January 1, 1970, is left to corresponding encoding specifications for this type, for example, the IPFIX protocol specification. Leap seconds are excluded. Note that transformation of values might be required between different encodings if different epoch values are used.
「DateTimemilliseConds」というタイプは、調整されたユニバーサル時間（UTC）に基づいて、ミリ秒単位の時間値を表します。たとえば、1970年1月1日、00:00 UTCなどのエポックの選択は、このタイプの対応するエンコード仕様、たとえばIPFIXプロトコル仕様に任されています。跳躍秒は除外されます。異なるエポック値が使用される場合、異なるエンコーディング間で値の変換が必要になる場合があることに注意してください。
The type "dateTimeMicroseconds" represents a time value in units of microseconds based on coordinated universal time (UTC). The choice of an epoch, for example, 00:00 UTC, January 1, 1970, is left to corresponding encoding specifications for this type, for example, the IPFIX protocol specification. Leap seconds are excluded. Note that transformation of values might be required between different encodings if different epoch values are used.
「DateTimemicRoseconds」というタイプは、調整されたユニバーサル時間（UTC）に基づいて、マイクロ秒単位の時間値を表します。たとえば、1970年1月1日、00:00 UTCなどのエポックの選択は、このタイプの対応するエンコード仕様、たとえばIPFIXプロトコル仕様に任されています。跳躍秒は除外されます。異なるエポック値が使用される場合、異なるエンコーディング間で値の変換が必要になる場合があることに注意してください。
The type "dateTimeNanoseconds" represents a time value in units of nanoseconds based on coordinated universal time (UTC). The choice of an epoch, for example, 00:00 UTC, January 1, 1970, is left to corresponding encoding specifications for this type, for example, the IPFIX protocol specification. Leap seconds are excluded. Note that transformation of values might be required between different encodings if different epoch values are used.
「DateTimenanAnoSeconds」というタイプは、調整されたユニバーサル時間（UTC）に基づいて、ナノ秒単位の時間値を表します。たとえば、1970年1月1日、00:00 UTCなどのエポックの選択は、このタイプの対応するエンコード仕様、たとえばIPFIXプロトコル仕様に任されています。跳躍秒は除外されます。異なるエポック値が使用される場合、異なるエンコーディング間で値の変換が必要になる場合があることに注意してください。
The type "ipv4Address" represents a value of an IPv4 address.
タイプ「IPv4Address」は、IPv4アドレスの値を表します。
The type "ipv6Address" represents a value of an IPv6 address.
タイプ「IPv6Address」は、IPv6アドレスの値を表します。
This section describes the set of valid data type semantics of the IPFIX information model. Note that further data type semantics may be specified by future extensions of the IPFIX information model.
このセクションでは、IPFIX情報モデルの有効なデータ型セマンティクスのセットについて説明します。IPFIX情報モデルの将来の拡張により、さらなるデータ型セマンティクスが指定される可能性があることに注意してください。
A quantity value represents a discrete measured value pertaining to the record. This is distinguished from counters that represent an ongoing measured value whose "odometer" reading is captured as part of a given record. If no semantic qualifier is given, the Information Elements that have an integral data type should behave as a quantity.
数量値は、レコードに関連する離散測定値を表します。これは、「走行距離」の読み取り値が特定のレコードの一部としてキャプチャされる継続的な測定値を表すカウンターとは区別されます。セマンティック予選が与えられていない場合、積分データ型を持つ情報要素は数量として動作する必要があります。
An integral value reporting the value of a counter. Counters are unsigned and wrap back to zero after reaching the limit of the type. For example, an unsigned64 with counter semantics will continue to increment until reaching the value of 2**64 - 1. At this point, the next increment will wrap its value to zero and continue counting from zero. The semantics of a total counter is similar to the semantics of counters used in SNMP, such as Counter32 defined in RFC 2578 [RFC2578]. The only difference between total counters and counters used in SNMP is that the total counters have an initial value of 0. A total counter counts independently of the export of its value.
カウンターの値を報告する積分値。カウンターは署名されておらず、タイプの限界に達した後、ゼロに戻ります。たとえば、カウンターセマンティクスを備えたunsigned64は、2 ** 64-1の値に達するまで増加し続けます。総カウンターのセマンティクスは、RFC 2578 [RFC2578]で定義されているカウンター32など、SNMPで使用されるカウンターのセマンティクスに似ています。SNMPで使用される総カウンターとカウンターの唯一の違いは、合計カウンターの初期値が0であることです。合計カウンターは、その値のエクスポートとは無関係です。
An integral value reporting the value of a counter. Counters are unsigned and wrap back to zero after reaching the limit of the type. For example, an unsigned64 with counter semantics will continue to increment until reaching the value of 2**64 - 1. At this point, the next increment will wrap its value to zero and continue counting from zero. The semantics of a delta counter is similar to the semantics of counters used in SNMP, such as Counter32 defined in RFC 2578 [RFC2578]. The only difference between delta counters and counters used in SNMP is that the delta counters have an initial value of 0. A delta counter is reset to 0 each time its value is exported.
カウンターの値を報告する積分値。カウンターは署名されておらず、タイプの限界に達した後、ゼロに戻ります。たとえば、カウンターセマンティクスを備えたunsigned64は、2 ** 64-1の値に達するまで増加し続けます。デルタカウンターのセマンティクスは、RFC 2578 [RFC2578]で定義されているカウンター32など、SNMPで使用されるカウンターのセマンティクスに似ています。SNMPで使用されているデルタカウンターとカウンターの唯一の違いは、デルタカウンターの初期値が0にあることです。デルタカウンターは、値がエクスポートされるたびに0にリセットされます。
An integral value that serves as an identifier. Specifically, mathematical operations on two identifiers (aside from the equality operation) are meaningless. For example, Autonomous System ID 1 * Autonomous System ID 2 is meaningless.
識別子として機能する積分値。具体的には、2つの識別子（平等操作を除く）での数学的操作は無意味です。たとえば、自律システムID 1 *自律システムID 2は無意味です。
An integral value that actually represents a set of bit fields. Logical operations are appropriate on such values, but not other mathematical operations. Flags should always be of an unsigned type.
実際に一連のビットフィールドを表す積分値。論理操作はそのような値に適していますが、他の数学操作ではありません。フラグは常に署名されていないタイプでなければなりません。
All Information Elements defined in Section 5 of this document or in future extensions of the IPFIX information model have their identifiers assigned by IANA. Their identifiers can be retrieved at http://www.iana.org/assignments/ipfix.
このドキュメントのセクション5で定義されているすべての情報要素またはIPFIX情報モデルの将来の拡張機能には、IANAによって割り当てられた識別子があります。それらの識別子は、http：//www.iana.org/assignments/ipfixで取得できます。
The value of these identifiers is in the range of 1-32767. Within this range, Information Element identifier values in the sub-range of 1-127 are compatible with field types used by NetFlow version 9 [RFC3954].
これらの識別子の値は、1-32767の範囲です。この範囲内で、1-127のサブレンジの情報要素識別子値は、Netflowバージョン9 [RFC3954]が使用するフィールドタイプと互換性があります。
+---------------------------------+---------------------------------+
| Range of IANA-assigned | Description |
| Information Element identifiers | |
+---------------------------------+---------------------------------+
| 0 | Reserved. |
| 1-127 | Information Element identifiers |
| | compatible with NetFlow version |
| | 9 field types [RFC3954]. |
| 128-32767 | Further Information Element |
| | identifiers. |
+---------------------------------+---------------------------------+
Enterprise-specific Information Element identifiers have the same range of 1-32767, but they are coupled with an additional enterprise identifier. For enterprise-specific Information Elements, Information Element identifier 0 is also reserved.
エンタープライズ固有の情報要素識別子の範囲は1〜32767ですが、追加のエンタープライズ識別子と結合されています。エンタープライズ固有の情報要素の場合、情報要素識別子0も予約されています。
Enterprise-specific Information Element identifiers can be chosen by an enterprise arbitrarily within the range of 1-32767. The same identifier may be assigned by other enterprises for different purposes.
エンタープライズ固有の情報要素識別子は、1-32767の範囲内で企業によって任意に選択できます。同じ識別子が、異なる目的で他の企業によって割り当てられる場合があります。
Still, Collecting Processes can distinguish these Information Elements because the Information Element identifier is coupled with an enterprise identifier.
それでも、情報要素識別子がエンタープライズ識別子と結合されているため、プロセスを収集すると、これらの情報要素を区別できます。
Enterprise identifiers MUST be registered as SMI network management private enterprise code numbers with IANA. The registry can be found at http://www.iana.org/assignments/enterprise-numbers.
エンタープライズ識別子は、IANAを使用したSMIネットワーク管理プライベートエンタープライズコード番号として登録する必要があります。レジストリはhttp://www.iana.org/assignments/enterprise-numbersにあります。
The following list gives an overview of the Information Element identifiers that are specified in Section 5 and are compatible with field types used by NetFlow version 9 [RFC3954].
次のリストは、セクション5で指定され、Netflowバージョン9 [RFC3954]で使用されているフィールドタイプと互換性のある情報要素識別子の概要を示しています。
+----+----------------------------+-------+-------------------------+
| ID | Name | ID | Name |
+----+----------------------------+-------+-------------------------+
| 1 | octetDeltaCount | 43 | RESERVED |
| 2 | packetDeltaCount | 44 | sourceIPv4Prefix |
| 3 | RESERVED | 45 | destinationIPv4Prefix |
| 4 | protocolIdentifier | 46 | mplsTopLabelType |
| 5 | ipClassOfService | 47 | mplsTopLabelIPv4Address |
| 6 | tcpControlBits | 48-51 | RESERVED |
| 7 | sourceTransportPort | 52 | minimumTTL |
| 8 | sourceIPv4Address | 53 | maximumTTL |
| 9 | sourceIPv4PrefixLength | 54 | fragmentIdentification |
| 10 | ingressInterface | 55 | postIpClassOfService |
| 11 | destinationTransportPort | 56 | sourceMacAddress |
| 12 | destinationIPv4Address | 57 |postDestinationMacAddress|
| 13 | destinationIPv4PrefixLength| 58 | vlanId |
| 14 | egressInterface | 59 | postVlanId |
| 15 | ipNextHopIPv4Address | 60 | ipVersion |
| 16 | bgpSourceAsNumber | 61 | flowDirection |
| 17 | bgpDestinationAsNumber | 62 | ipNextHopIPv6Address |
| 18 | bgpNexthopIPv4Address | 63 | bgpNexthopIPv6Address |
| 19 | postMCastPacketDeltaCount | 64 | ipv6ExtensionHeaders |
| 20 | postMCastOctetDeltaCount | 65-69 | RESERVED |
| 21 | flowEndSysUpTime | 70 | mplsTopLabelStackSection|
| 22 | flowStartSysUpTime | 71 | mplsLabelStackSection2 |
| 23 | postOctetDeltaCount | 72 | mplsLabelStackSection3 |
| 24 | postPacketDeltaCount | 73 | mplsLabelStackSection4 |
| 25 | minimumIpTotalLength | 74 | mplsLabelStackSection5 |
| 26 | maximumIpTotalLength | 75 | mplsLabelStackSection6 |
| 27 | sourceIPv6Address | 76 | mplsLabelStackSection7 |
| 28 | destinationIPv6Address | 77 | mplsLabelStackSection8 |
| 29 | sourceIPv6PrefixLength | 78 | mplsLabelStackSection9 |
| 30 | destinationIPv6PrefixLength| 79 | mplsLabelStackSection10 |
| 31 | flowLabelIPv6 | 80 | destinationMacAddress |
| 32 | icmpTypeCodeIPv4 | 81 | postSourceMacAddress |
| 33 | igmpType | 82-84 | RESERVED |
| 34 | RESERVED | 85 | octetTotalCount |
| 35 | RESERVED | 86 | packetTotalCount |
| 36 | flowActiveTimeout | 87 | RESERVED |
| 37 | flowIdleTimeout | 88 | fragmentOffset |
| 38 | RESERVED | 89 | RESERVED |
| 39 | RESERVED | 90 |mplsVpnRouteDistinguisher|
| 40 | exportedOctetTotalCount |91-127 | RESERVED |
| 41 | exportedMessageTotalCount | | |
| 42 |exportedFlowRecordTotalCount| | |
+----+----------------------------+-------+-------------------------+
The following list gives an overview of the Information Element
identifiers that are specified in Section 5 and extends the list of
Information Element identifiers specified already in [RFC3954].
+-----+---------------------------+-----+---------------------------+
| ID | Name | ID | Name |
+-----+---------------------------+-----+---------------------------+
| 128 | bgpNextAdjacentAsNumber | 169 | destinationIPv6Prefix |
| 129 | bgpPrevAdjacentAsNumber | 170 | sourceIPv6Prefix |
| 130 | exporterIPv4Address | 171 | postOctetTotalCount |
| 131 | exporterIPv6Address | 172 | postPacketTotalCount |
| 132 | droppedOctetDeltaCount | 173 | flowKeyIndicator |
| 133 | droppedPacketDeltaCount | 174 | postMCastPacketTotalCount |
| 134 | droppedOctetTotalCount | 175 | postMCastOctetTotalCount |
| 135 | droppedPacketTotalCount | 176 | icmpTypeIPv4 |
| 136 | flowEndReason | 177 | icmpCodeIPv4 |
| 137 | commonPropertiesId | 178 | icmpTypeIPv6 |
| 138 | observationPointId | 179 | icmpCodeIPv6 |
| 139 | icmpTypeCodeIPv6 | 180 | udpSourcePort |
| 140 | mplsTopLabelIPv6Address | 181 | udpDestinationPort |
| 141 | lineCardId | 182 | tcpSourcePort |
| 142 | portId | 183 | tcpDestinationPort |
| 143 | meteringProcessId | 184 | tcpSequenceNumber |
| 144 | exportingProcessId | 185 | tcpAcknowledgementNumber |
| 145 | templateId | 186 | tcpWindowSize |
| 146 | wlanChannelId | 187 | tcpUrgentPointer |
| 147 | wlanSSID | 188 | tcpHeaderLength |
| 148 | flowId | 189 | ipHeaderLength |
| 149 | observationDomainId | 190 | totalLengthIPv4 |
| 150 | flowStartSeconds | 191 | payloadLengthIPv6 |
| 151 | flowEndSeconds | 192 | ipTTL |
| 152 | flowStartMilliseconds | 193 | nextHeaderIPv6 |
| 153 | flowEndMilliseconds | 194 | mplsPayloadLength |
| 154 | flowStartMicroseconds | 195 | ipDiffServCodePoint |
| 155 | flowEndMicroseconds | 196 | ipPrecedence |
| 156 | flowStartNanoseconds | 197 | fragmentFlags |
| 157 | flowEndNanoseconds | 198 | octetDeltaSumOfSquares |
| 158 | flowStartDeltaMicroseconds| 199 | octetTotalSumOfSquares |
| 159 | flowEndDeltaMicroseconds | 200 | mplsTopLabelTTL |
| 160 | systemInitTimeMilliseconds| 201 | mplsLabelStackLength |
| 161 | flowDurationMilliseconds | 202 | mplsLabelStackDepth |
| 162 | flowDurationMicroseconds | 203 | mplsTopLabelExp |
| 163 | observedFlowTotalCount | 204 | ipPayloadLength |
| 164 | ignoredPacketTotalCount | 205 | udpMessageLength |
| 165 | ignoredOctetTotalCount | 206 | isMulticast |
| 166 | notSentFlowTotalCount | 207 | ipv4IHL |
| 167 | notSentPacketTotalCount | 208 | ipv4Options |
| 168 | notSentOctetTotalCount | 209 | tcpOptions |
+-----+---------------------------+-----+---------------------------+
| ID | Name | ID | Name |
+-----+---------------------------+-----+---------------------------+
| 210 | paddingOctets | 218 | tcpSynTotalCount |
| 211 | collectorIPv4Address | 219 | tcpFinTotalCount |
| 212 | collectorIPv6Address | 220 | tcpRstTotalCount |
| 213 | exportInterface | 221 | tcpPshTotalCount |
| 214 | exportProtocolVersion | 222 | tcpAckTotalCount |
| 215 | exportTransportProtocol | 223 | tcpUrgTotalCount |
| 216 | collectorTransportPort | 224 | ipTotalLength |
| 217 | exporterTransportPort | 237 | postMplsTopLabelExp |
| | | 238 | tcpWindowScale |
+-----+---------------------------+-----+---------------------------+
This section describes the Information Elements of the IPFIX information model. The elements are grouped into 12 groups according to their semantics and their applicability:
このセクションでは、IPFIX情報モデルの情報要素について説明します。要素は、セマンティクスと適用性に従って12のグループにグループ化されます。
1. Identifiers 2. Metering and Exporting Process Configuration 3. Metering and Exporting Process Statistics 4. IP Header Fields 5. Transport Header Fields 6. Sub-IP Header Fields 7. Derived Packet Properties 8. Min/Max Flow Properties 9. Flow Timestamps 10. Per-Flow Counters 11. Miscellaneous Flow Properties 12. Padding
1. 識別子2.メーターおよびエクスポートプロセス構成3.メータリングとエクスポートプロセス統計4. IPヘッダーフィールド5.輸送ヘッダーフィールド6.サブIPヘッダーフィールド7.派生パケットプロパティ8. Min/Max Flowプロパティ9.フロータイムスタンプ10。流量パーカウンター11.その他の流れの特性12.パディング
The Information Elements that are derived from fields of packets or from packet treatment, such as the Information Elements in groups 4-7, can typically serve as Flow Keys used for mapping packets to Flows.
グループ4〜7の情報要素など、パケットのフィールドやパケット処理から派生した情報要素は、通常、パケットを流れるためにパケットをマッピングするために使用されるフローキーとして機能します。
If they do not serve as Flow Keys, their value may change from packet to packet within a single Flow. For Information Elements with values that are derived from fields of packets or from packet treatment and for which the value may change from packet to packet within a single Flow, the IPFIX information model defines that their value is determined by the first packet observed for the corresponding Flow, unless the description of the Information Element explicitly specifies a different semantics. This simple rule allows writing all Information Elements related to header fields once when the first packet of the Flow is observed. For further observed packets of the same Flow, only Flow properties that depend on more than one packet, such as the Information Elements in groups 8-11, need to be updated.
それらがフローキーとして機能しない場合、それらの値はパケットから単一のフロー内でパケットに変わる可能性があります。パケットのフィールドまたはパケット処理から派生した値を持つ情報要素の場合、および単一のフロー内で値がパケットからパケットに変化する可能性がある場合、IPFIX情報モデルは、その値が対応する最初のパケットによって決定されることを定義します。情報要素の説明が異なるセマンティクスを明示的に指定しない限り。この単純なルールにより、フローの最初のパケットが観察されたときに、ヘッダーフィールドに関連するすべての情報要素を1回記述できます。同じフローのさらに観察されたパケットのために、グループ8〜11の情報要素など、複数のパケットに依存するフロープロパティのみを更新する必要があります。
Information Elements with a name having the "post" prefix, for example, "postClassOfServiceIPv4", do not report properties that were actually observed at the Observation Point, but retrieved by other means within the Observation Domain. These Information Elements can be used if there are middlebox functions within the Observation Domain changing Flow properties after packets passed the Observation Point.
「Post」プレフィックスを持つ名前の情報要素、たとえば「PostClassofServiceIPv4」など、観測点で実際に観察されたプロパティを報告しませんが、観測領域内の他の手段によって取得されます。これらの情報要素は、パケットが観測ポイントを通過した後にフロープロパティを変更する観測ドメイン内にミドルボックス機能がある場合に使用できます。
Information Elements in this section use the reference property to reference [RFC0768], [RFC0791], [RFC0792], [RFC0793], [RFC1108], [RFC1112], [RFC1191], [RFC1323], [RFC1385], [RFC1812], [RFC1930], [RFC2113], [RFC2119], [RFC2460], [RFC2675], [RFC2863], [RFC3031], [RFC3032], [RFC3193], [RFC3234], [RFC3260], [RFC3270], [RFC3376], [RFC3954], [RFC4271], [RFC4291], [RFC4302], [RFC4303], [RFC4364], [RFC4382], [RFC4443], [RFC4960], [RFC5036], [IEEE.802-11.1999], [IEEE.802-1Q.2003], and [IEEE.802-3.2002].
このセクションの情報要素は、参照プロパティを使用して、[RFC0768]、[RFC0791]、[RFC0792]、[RFC0793]、[RFC1108]、[RFC1112]、[RFC1191]、[RFC1323]、[RFC1323]、[RFC1385]、[RFC1812]、[RFC1108]、[RFC1112]、[RFC1191]、[RFC1191]、、[RFC1930]、[RFC2113]、[RFC2119]、[RFC2460]、[RFC2675]、[RFC2863]、[RFC3031]、[RFC3032]、[RFC3193]、[RFC3234]、[RFC3260]、RFC3376]、[RFC3954]、[RFC4271]、[RFC4291]、[RFC4302]、[RFC4303]、[RFC4364]、[RFC4382]、[RFC4443]、[RFC4443]、[RFC4960]、[RFC5036]、[RFC5036]、[RFC5036]、[IEEE.802-1Q.2003]、および[IEEE.802-3.2002]。
Information Elements grouped in the table below are identifying components of the IPFIX architecture, of an IPFIX Device, or of the IPFIX protocol. All of them have an integral abstract data type and data type semantics "identifier" as described in Section 3.2.4.
以下の表にグループ化された情報要素は、IPFIXアーキテクチャ、IPFIXデバイス、またはIPFIXプロトコルのコンポーネントを識別しています。それらはすべて、セクション3.2.4で説明されているように、積分抽象データ型とデータ型セマンティクス「識別子」を持っています。
Typically, some of them are used for limiting scopes of other Information Elements. However, other Information Elements MAY be used for limiting scopes. Note also that all Information Elements listed below MAY be used for other purposes than limiting scopes.
通常、それらのいくつかは、他の情報要素のスコープを制限するために使用されます。ただし、他の情報要素は、スコープの制限に使用される場合があります。また、以下にリストされているすべての情報要素は、スコープを制限する以外の目的に使用できることに注意してください。
+-----+---------------------------+-----+---------------------------+
| ID | Name | ID | Name |
+-----+---------------------------+-----+---------------------------+
| 141 | lineCardId | 148 | flowId |
| 142 | portId | 145 | templateId |
| 10 | ingressInterface | 149 | observationDomainId |
| 14 | egressInterface | 138 | observationPointId |
| 143 | meteringProcessId | 137 | commonPropertiesId |
| 144 | exportingProcessId | | |
+-----+---------------------------+-----+---------------------------+
Description: An identifier of a line card that is unique per IPFIX Device hosting an Observation Point. Typically, this Information Element is used for limiting the scope of other Information Elements. Abstract Data Type: unsigned32 Data Type Semantics: identifier ElementId: 141 Status: current
説明：観測ポイントをホストするIPFIXデバイスごとに一意のラインカードの識別子。通常、この情報要素は、他の情報要素の範囲を制限するために使用されます。要約データ型：unsigned32データ型セマンティクス：識別子ElementID：141ステータス：現在
Description: An identifier of a line port that is unique per IPFIX Device hosting an Observation Point. Typically, this Information Element is used for limiting the scope of other Information Elements. Abstract Data Type: unsigned32 Data Type Semantics: identifier ElementId: 142 Status: current
説明：観測ポイントをホストするIPFIXデバイスごとに一意のラインポートの識別子。通常、この情報要素は、他の情報要素の範囲を制限するために使用されます。要約データ型：unsigned32データ型セマンティクス：識別子ElementID：142ステータス：現在
Description: The index of the IP interface where packets of this Flow are being received. The value matches the value of managed object 'ifIndex' as defined in RFC 2863. Note that ifIndex values are not assigned statically to an interface and that the interfaces may be renumbered every time the device's management system is re-initialized, as specified in RFC 2863. Abstract Data Type: unsigned32 Data Type Semantics: identifier ElementId: 10 Status: current Reference: See RFC 2863 for the definition of the ifIndex object.
説明：このフローのパケットが受信されているIPインターフェイスのインデックス。値は、RFC 2863で定義されている管理されたオブジェクト「ifindex」の値と一致します。Ifindex値はインターフェイスに静的に割り当てられておらず、RFCで指定されているように、デバイスの管理システムが再目的化されるたびにインターフェイスを変更することができることに注意してください。2863.要約データ型：unsigned32データ型セマンティクス：識別子ElementID：10ステータス：現在の参照：Ifindexオブジェクトの定義についてはRFC 2863を参照してください。
Description: The index of the IP interface where packets of this Flow are being sent. The value matches the value of managed object 'ifIndex' as defined in RFC 2863. Note that ifIndex values are not assigned statically to an interface and that the interfaces may be renumbered every time the device's management system is re-initialized, as specified in RFC 2863. Abstract Data Type: unsigned32 Data Type Semantics: identifier ElementId: 14 Status: current Reference: See RFC 2863 for the definition of the ifIndex object.
説明：このフローのパケットが送信されているIPインターフェイスのインデックス。値は、RFC 2863で定義されている管理されたオブジェクト「ifindex」の値と一致します。Ifindex値はインターフェイスに静的に割り当てられておらず、RFCで指定されているように、デバイスの管理システムが再目的化されるたびにインターフェイスを変更することができることに注意してください。2863.要約データ型：unsigned32データ型セマンティクス：識別子ElementID：14ステータス：現在の参照：Ifindexオブジェクトの定義についてはRFC 2863を参照してください。
Description: An identifier of a Metering Process that is unique per IPFIX Device. Typically, this Information Element is used for limiting the scope of other Information Elements. Note that process identifiers are typically assigned dynamically. The Metering Process may be re-started with a different ID. Abstract Data Type: unsigned32 Data Type Semantics: identifier ElementId: 143 Status: current
説明：IPFIXデバイスごとに一意の計量プロセスの識別子。通常、この情報要素は、他の情報要素の範囲を制限するために使用されます。通常、プロセス識別子は動的に割り当てられていることに注意してください。計量プロセスは、別のIDで再起動する場合があります。抽象データ型：unsigned32データ型セマンティクス：識別子ElementID：143ステータス：現在
Description: An identifier of an Exporting Process that is unique per IPFIX Device. Typically, this Information Element is used for limiting the scope of other Information Elements. Note that process identifiers are typically assigned dynamically. The Exporting Process may be re-started with a different ID. Abstract Data Type: unsigned32 Data Type Semantics: identifier ElementId: 144 Status: current
説明：IPFIXデバイスごとに一意のエクスポートプロセスの識別子。通常、この情報要素は、他の情報要素の範囲を制限するために使用されます。通常、プロセス識別子は動的に割り当てられていることに注意してください。エクスポートプロセスは、別のIDで再起動する場合があります。抽象データ型：unsigned32データ型セマンティクス：識別子ElementID：144ステータス：現在
Description: An identifier of a Flow that is unique within an Observation Domain. This Information Element can be used to distinguish between different Flows if Flow Keys such as IP addresses and port numbers are not reported or are reported in separate records. Abstract Data Type: unsigned64 Data Type Semantics: identifier ElementId: 148 Status: current
説明：観測ドメイン内で一意のフローの識別子。この情報要素は、IPアドレスやポート番号などのフローキーが報告されていないか、別のレコードで報告されていない場合、異なるフローを区別するために使用できます。要約データ型：unsigned64データ型セマンティクス：識別子ElementID：148ステータス：現在
Description: An identifier of a Template that is locally unique within a combination of a Transport session and an Observation Domain. Template IDs 0-255 are reserved for Template Sets, Options Template Sets, and other reserved Sets yet to be created. Template IDs of Data Sets are numbered from 256 to 65535. Typically, this Information Element is used for limiting the scope of other Information Elements. Note that after a re-start of the Exporting Process Template identifiers may be re-assigned. Abstract Data Type: unsigned16 Data Type Semantics: identifier ElementId: 145 Status: current
説明：トランスポートセッションと観測ドメインの組み合わせ内でローカルにユニークなテンプレートの識別子。テンプレートID 0-255は、テンプレートセット、オプションテンプレートセット、およびまだ作成されていないその他の予約セット用に予約されています。データセットのテンプレートIDは、256〜65535です。通常、この情報要素は、他の情報要素の範囲を制限するために使用されます。エクスポートプロセステンプレート識別子の再起動後、再割り当てされる可能性があることに注意してください。要約データ型：unsigned16データ型セマンティクス：識別子ElementID：145ステータス：現在
Description: An identifier of an Observation Domain that is locally unique to an Exporting Process. The Exporting Process uses the Observation Domain ID to uniquely identify to the Collecting Process the Observation Domain where Flows were metered. It is RECOMMENDED that this identifier is also unique per IPFIX Device. A value of 0 indicates that no specific Observation Domain is identified by this Information Element. Typically, this Information Element is used for limiting the scope of other Information Elements. Abstract Data Type: unsigned32 Data Type Semantics: identifier ElementId: 149 Status: current
説明：エクスポートプロセスに局所的にユニークな観測ドメインの識別子。エクスポートプロセスは、観測ドメインIDを使用して、フローが計算された観測ドメインを収集プロセスに一意に識別します。この識別子は、IPFixデバイスごとに一意であることをお勧めします。0の値は、この情報要素によって特定の観察ドメインが識別されないことを示します。通常、この情報要素は、他の情報要素の範囲を制限するために使用されます。抽象データ型：unsigned32データ型セマンティクス：識別子ElementID：149ステータス：現在
Description: An identifier of an Observation Point that is unique per Observation Domain. It is RECOMMENDED that this identifier is also unique per IPFIX Device. Typically, this Information Element is used for limiting the scope of other Information Elements. Abstract Data Type: unsigned32 Data Type Semantics: identifier ElementId: 138 Status: current
説明：観察ドメインごとに一意の観測点の識別子。この識別子は、IPFixデバイスごとに一意であることをお勧めします。通常、この情報要素は、他の情報要素の範囲を制限するために使用されます。抽象データ型：unsigned32データ型セマンティクス：識別子ElementID：138ステータス：現在
Description: An identifier of a set of common properties that is unique per Observation Domain and Transport Session. Typically, this Information Element is used to link to information reported in separate Data Records. Abstract Data Type: unsigned64 Data Type Semantics: identifier ElementId: 137 Status: current
説明：観測ドメインと輸送セッションごとに一意の共通プロパティのセットの識別子。通常、この情報要素は、個別のデータレコードで報告された情報にリンクするために使用されます。抽象データ型：unsigned64データ型セマンティクス：識別子ElementID：137ステータス：現在
Information Elements in this section describe the configuration of the Metering Process or the Exporting Process. The set of these Information Elements is listed in the table below.
このセクションの情報要素は、計量プロセスの構成またはエクスポートプロセスについて説明します。これらの情報要素のセットは、以下の表にリストされています。
+-----+--------------------------+-----+----------------------------+
| ID | Name | ID | Name |
+-----+--------------------------+-----+----------------------------+
| 130 | exporterIPv4Address | 213 | exportInterface |
| 131 | exporterIPv6Address | 214 | exportProtocolVersion |
| 217 | exporterTransportPort | 215 | exportTransportProtocol |
| 211 | collectorIPv4Address | 216 | collectorTransportPort |
| 212 | collectorIPv6Address | 173 | flowKeyIndicator |
+-----+--------------------------+-----+----------------------------+
Description: The IPv4 address used by the Exporting Process. This is used by the Collector to identify the Exporter in cases where the identity of the Exporter may have been obscured by the use of a proxy. Abstract Data Type: ipv4Address Data Type Semantics: identifier ElementId: 130 Status: current
説明：エクスポートプロセスで使用されるIPv4アドレス。これは、輸出業者の身元がプロキシの使用によって不明瞭になった場合に輸出国を識別するためにコレクターによって使用されます。抽象データ型：IPv4Addressデータ型セマンティクス：識別子ElementID：130ステータス：現在
Description: The IPv6 address used by the Exporting Process. This is used by the Collector to identify the Exporter in cases where the identity of the Exporter may have been obscured by the use of a proxy. Abstract Data Type: ipv6Address Data Type Semantics: identifier ElementId: 131 Status: current
説明：エクスポートプロセスで使用されるIPv6アドレス。これは、輸出業者の身元がプロキシの使用によって不明瞭になった場合に輸出国を識別するためにコレクターによって使用されます。要約データ型：IPv6Addressデータ型セマンティクス：識別子ElementID：131ステータス：現在
Description: The source port identifier from which the Exporting Process sends Flow information. For the transport protocols UDP, TCP, and SCTP, this is the source port number. This field MAY also be used for future transport protocols that have 16-bit source port identifiers. This field may be useful for distinguishing multiple Exporting Processes that use the same IP address. Abstract Data Type: unsigned16 Data Type Semantics: identifier ElementId: 217 Status: current Reference: See RFC 768 for the definition of the UDP source port field. See RFC 793 for the definition of the TCP source port field. See RFC 4960 for the definition of SCTP. Additional information on defined UDP and TCP port numbers can be found at http://www.iana.org/assignments/port-numbers.
説明：エクスポートプロセスがフロー情報を送信するソースポート識別子。輸送プロトコルUDP、TCP、およびSCTPの場合、これはソースポート番号です。このフィールドは、16ビットのソースポート識別子を持つ将来の輸送プロトコルにも使用できます。このフィールドは、同じIPアドレスを使用する複数のエクスポートプロセスを区別するのに役立つ場合があります。抽象データ型：unsigned16データ型セマンティクス：識別子ElementID：217ステータス：現在の参照：UDPソースポートフィールドの定義については、RFC 768を参照してください。TCPソースポートフィールドの定義については、RFC 793を参照してください。SCTPの定義については、RFC 4960を参照してください。定義されたUDPおよびTCPポート番号の追加情報は、http：//www.iana.org/assignments/port-numbersをご覧ください。
Description: An IPv4 address to which the Exporting Process sends Flow information. Abstract Data Type: ipv4Address Data Type Semantics: identifier ElementId: 211 Status: current
説明：エクスポートプロセスがフロー情報を送信するIPv4アドレス。抽象データ型：IPv4Addressデータ型セマンティクス：識別子ElementID：211ステータス：現在
Description: An IPv6 address to which the Exporting Process sends Flow information. Abstract Data Type: ipv6Address Data Type Semantics: identifier ElementId: 212 Status: current
説明：エクスポートプロセスがフロー情報を送信するIPv6アドレス。抽象データ型：IPv6Addressデータ型セマンティクス：識別子ElementID：212ステータス：現在
Description: The index of the interface from which IPFIX Messages sent by the Exporting Process to a Collector leave the IPFIX Device. The value matches the value of managed object 'ifIndex' as defined in RFC 2863. Note that ifIndex values are not assigned statically to an interface and that the interfaces may be renumbered every time the device's management system is re-initialized, as specified in RFC 2863. Abstract Data Type: unsigned32 Data Type Semantics: identifier ElementId: 213 Status: current Reference: See RFC 2863 for the definition of the ifIndex object.
説明：コレクターにエクスポートプロセスによって送信されたIPFIXメッセージのインデックスは、IPFIXデバイスを離れます。値は、RFC 2863で定義されている管理されたオブジェクト「ifindex」の値と一致します。Ifindex値はインターフェイスに静的に割り当てられておらず、RFCで指定されているように、デバイスの管理システムが再目的化されるたびにインターフェイスを変更することができることに注意してください。2863.要約データ型：unsigned32データ型セマンティクス：識別子ElementID：213ステータス：現在の参照：Ifindexオブジェクトの定義についてはRFC 2863を参照してください。
Description: The protocol version used by the Exporting Process for sending Flow information. The protocol version is given by the value of the Version Number field in the Message Header. The protocol version is 10 for IPFIX and 9 for NetFlow version 9. A value of 0 indicates that no export protocol is in use. Abstract Data Type: unsigned8 Data Type Semantics: identifier ElementId: 214 Status: current Reference: See the IPFIX protocol specification [RFC5101] for the definition of the IPFIX Message Header. See RFC 3954 for the definition of the NetFlow version 9 message header.
説明：フロー情報を送信するためにエクスポートプロセスで使用されるプロトコルバージョン。プロトコルバージョンは、メッセージヘッダーのバージョン番号フィールドの値によって指定されます。プロトコルバージョンはIPFIXで10、Netflowバージョン9の場合は9です。5の値は、エクスポートプロトコルが使用されていないことを示します。抽象データ型：Unsigned8データ型セマンティクス：識別子ElementID：214ステータス：現在の参照：IPFIXメッセージヘッダーの定義については、IPFIXプロトコル仕様[RFC5101]を参照してください。Netflowバージョン9メッセージヘッダーの定義については、RFC 3954を参照してください。
Description: The value of the protocol number used by the Exporting Process for sending Flow information. The protocol number identifies the IP packet payload type. Protocol numbers are defined in the IANA Protocol Numbers registry. In Internet Protocol version 4 (IPv4), this is carried in the Protocol field. In Internet Protocol version 6 (IPv6), this is carried in the Next Header field in the last extension header of the packet. Abstract Data Type: unsigned8 Data Type Semantics: identifier ElementId: 215 Status: current Reference: See RFC 791 for the specification of the IPv4 protocol field. See RFC 2460 for the specification of the IPv6 protocol field. See the list of protocol numbers assigned by IANA at http://www.iana.org/assignments/protocol-numbers.
説明：フロー情報を送信するためにエクスポートプロセスで使用されるプロトコル番号の値。プロトコル番号は、IPパケットペイロードタイプを識別します。プロトコル番号は、IANAプロトコル番号レジストリで定義されています。インターネットプロトコルバージョン4（IPv4）では、これはプロトコルフィールドに配信されます。インターネットプロトコルバージョン6（IPv6）では、これはパケットの最後の拡張ヘッダーの次のヘッダーフィールドに掲載されています。抽象データ型：Unsigned8データ型セマンティクス：識別子ElementID：215ステータス：現在の参照：IPv4プロトコルフィールドの仕様については、RFC 791を参照してください。IPv6プロトコルフィールドの仕様については、RFC 2460を参照してください。http://www.iana.org/assignments/protocol-numbersでIANAが割り当てたプロトコル番号のリストを参照してください。
Description: The destination port identifier to which the Exporting Process sends Flow information. For the transport protocols UDP, TCP, and SCTP, this is the destination port number. This field MAY also be used for future transport protocols that have 16-bit source port identifiers. Abstract Data Type: unsigned16 Data Type Semantics: identifier ElementId: 216 Status: current Reference: See RFC 768 for the definition of the UDP destination port field. See RFC 793 for the definition of the TCP destination port field. See RFC 4960 for the definition of SCTP. Additional information on defined UDP and TCP port numbers can be found at http://www.iana.org/assignments/port-numbers.
説明：エクスポートプロセスがフロー情報を送信する宛先ポート識別子。輸送プロトコルUDP、TCP、およびSCTPの場合、これは宛先ポート番号です。このフィールドは、16ビットのソースポート識別子を持つ将来の輸送プロトコルにも使用できます。抽象データ型：unsigned16データ型セマンティクス：識別子ElementID：216ステータス：現在の参照：UDP宛先ポートフィールドの定義については、RFC 768を参照してください。TCP宛先ポートフィールドの定義については、RFC 793を参照してください。SCTPの定義については、RFC 4960を参照してください。定義されたUDPおよびTCPポート番号の追加情報は、http：//www.iana.org/assignments/port-numbersをご覧ください。
Description: This set of bit fields is used for marking the Information Elements of a Data Record that serve as Flow Key. Each bit represents an Information Element in the Data Record with the n-th bit representing the n-th Information Element. A bit set to value 1 indicates that the corresponding Information Element is a Flow Key of the reported Flow. A bit set to value 0 indicates that this is not the case. If the Data Record contains more than 64 Information Elements, the corresponding Template SHOULD be designed such that all Flow Keys are among the first 64 Information Elements, because the flowKeyIndicator only contains 64 bits. If the Data Record contains less than 64 Information Elements, then the bits in the flowKeyIndicator for which no corresponding Information Element exists MUST have the value 0. Abstract Data Type: unsigned64 Data Type Semantics: flags ElementId: 173 Status: current
説明：このビットフィールドのセットは、フローキーとして機能するデータレコードの情報要素をマークするために使用されます。各ビットは、データレコードの情報要素を表し、n番目のビットはn番目の情報要素を表します。値1に少し設定すると、対応する情報要素が報告されたフローのフローキーであることを示します。値0に少し設定されていると、これが当てはまらないことがわかります。データレコードに64を超える情報要素が含まれている場合、FlowKeyIndicatorには64ビットのみが含まれているため、すべてのフローキーが最初の64の情報要素になるように対応するテンプレートを設計する必要があります。データレコードに64未満の情報要素が含まれている場合、対応する情報要素が存在しないFlowKeyindicatorのビットには値が必要です。
Information Elements in this section describe statistics of the Metering Process and/or the Exporting Process. The set of these Information Elements is listed in the table below.
このセクションの情報要素は、計量プロセスおよび/またはエクスポートプロセスの統計について説明します。これらの情報要素のセットは、以下の表にリストされています。
+-----+-----------------------------+-----+-------------------------+
| ID | Name | ID | Name |
+-----+-----------------------------+-----+-------------------------+
| 41 | exportedMessageTotalCount | 165 | ignoredOctetTotalCount |
| 40 | exportedOctetTotalCount | 166 | notSentFlowTotalCount |
| 42 | exportedFlowRecordTotalCount| 167 | notSentPacketTotalCount |
| 163 | observedFlowTotalCount | 168 | notSentOctetTotalCount |
| 164 | ignoredPacketTotalCount | | |
+-----+-----------------------------+-----+-------------------------+
Description: The total number of IPFIX Messages that the Exporting Process has sent since the Exporting Process (re-)initialization to a particular Collecting Process. The reported number excludes the IPFIX Message that carries the counter value. If this Information Element is sent to a particular Collecting Process, then by default it specifies the number of IPFIX Messages sent to this Collecting Process. Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: 41 Status: current Units: messages
説明：エクスポートプロセスから送信されたIPFIXメッセージの総数（特定の収集プロセスへの初期化（再）初期化。報告された番号は、カウンター値を伝えるIPFIXメッセージを除外します。この情報要素が特定の収集プロセスに送信された場合、デフォルトでは、この収集プロセスに送信されたIPFIXメッセージの数を指定します。抽象データ型：unsigned64データ型セマンティクス：TotalCounter ElementID：41ステータス：現在の単位：メッセージ
Description: The total number of octets that the Exporting Process has sent since the Exporting Process (re-)initialization to a particular Collecting Process. The value of this Information Element is calculated by summing up the IPFIX Message Header length values of all IPFIX Messages that were successfully sent to the Collecting Process. The reported number excludes octets in the IPFIX Message that carries the counter value. If this Information Element is sent to a particular Collecting Process, then by default it specifies the number of octets sent to this Collecting Process. Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: 40 Status: current Units: octets
説明：エクスポートプロセスが特定の収集プロセスへの初期化（再）以降に送信されたオクテットの総数。この情報要素の値は、収集プロセスに正常に送信されたすべてのIPFIXメッセージのIPFIXメッセージヘッダー長値を合計することによって計算されます。報告された番号は、カウンター値を運ぶIPFIXメッセージにオクテットを除外します。この情報要素が特定の収集プロセスに送信される場合、デフォルトでは、この収集プロセスに送信されたオクテットの数を指定します。抽象データ型：unsigned64データ型セマンティクス：TotalCounter ElementID：40ステータス：現在の単位：オクテット
Description: The total number of Flow Records that the Exporting Process has sent as Data Records since the Exporting Process (re-)initialization to a particular Collecting Process. The reported number excludes Flow Records in the IPFIX Message that carries the counter value. If this Information Element is sent to a particular Collecting Process, then by default it specifies the number of Flow Records sent to this process. Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: 42 Status: current Units: flows
説明：エクスポートプロセスが特定の収集プロセスへの初期化以来、エクスポートプロセスがデータレコードとして送信したフローレコードの総数。報告された番号は、カウンター値を運ぶIPFIXメッセージのフローレコードを除外します。この情報要素が特定の収集プロセスに送信される場合、デフォルトでは、このプロセスに送信されたフローレコードの数を指定します。抽象データ型：unsigned64データ型セマンティクス：TotalCounter ElementID：42ステータス：現在の単位：フロー
Description: The total number of Flows observed in the Observation Domain since the Metering Process (re-)initialization for this Observation Point. Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: 163 Status: current Units: flows
説明：この観測点の計量プロセス（再）初期化以降、観測ドメインで観察されたフローの総数。抽象データ型：unsigned64データ型セマンティクス：TotalCounter ElementID：163ステータス：現在の単位：フロー
Description: The total number of observed IP packets that the Metering Process did not process since the (re-)initialization of the Metering Process. Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: 164 Status: current Units: packets
説明：計量プロセスの（再）初期化以来、計量プロセスが処理されなかった観測されたIPパケットの総数。抽象データ型：unsigned64データ型セマンティクス：TotalCounter ElementID：164ステータス：現在の単位：パケット
Description: The total number of octets in observed IP packets (including the IP header) that the Metering Process did not process since the (re-)initialization of the Metering Process. Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: 165 Status: current Units: octets
説明：計測プロセスの（再）初期化以来、計量プロセスが処理されなかった観測されたIPパケット（IPヘッダーを含む）のオクテットの総数。抽象データ型：unsigned64データ型セマンティクス：TotalCounter ElementID：165ステータス：現在の単位：オクテット
Description: The total number of Flow Records that were generated by the Metering Process and dropped by the Metering Process or by the Exporting Process instead of being sent to the Collecting Process. There are several potential reasons for this including resource shortage and special Flow export policies. Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: 166 Status: current Units: flows
説明：計量プロセスによって生成され、計量プロセスまたは輸出プロセスによって削除されたフローレコードの総数は、収集プロセスに送信される代わりに。これには、リソース不足や特別なフローエクスポートポリシーなど、いくつかの潜在的な理由があります。抽象データ型：unsigned64データ型セマンティクス：TotalCounter ElementID：166ステータス：現在の単位：フロー
Description: The total number of packets in Flow Records that were generated by the Metering Process and dropped by the Metering Process or by the Exporting Process instead of being sent to the Collecting Process. There are several potential reasons for this including resource shortage and special Flow export policies. Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: 167 Status: current Units: packets
説明：メータープロセスによって生成され、計量プロセスまたはエクスポートプロセスによって削除されたフローレコードのパケットの総数は、収集プロセスに送信される代わりに。これには、リソース不足や特別なフローエクスポートポリシーなど、いくつかの潜在的な理由があります。抽象データ型：unsigned64データ型セマンティクス：TotalCounter ElementID：167ステータス：現在の単位：パケット
Description: The total number of octets in packets in Flow Records that were generated by the Metering Process and dropped by the Metering Process or by the Exporting Process instead of being sent to the Collecting Process. There are several potential reasons for this including resource shortage and special Flow export policies. Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: 168 Status: current Units: octets
説明：メータープロセスによって生成され、計量プロセスまたは輸出プロセスによって削除されたフローレコードのパケットのオクテットの総数。これには、リソース不足や特別なフローエクスポートポリシーなど、いくつかの潜在的な理由があります。抽象データ型：unsigned64データ型セマンティクス：TotalCounter ElementID：168ステータス：現在の単位：オクテット
Information Elements in this section indicate values of IP header fields or are derived from IP header field values in combination with further information.
このセクションの情報要素は、IPヘッダーフィールドの値を示しているか、さらに情報と組み合わせたIPヘッダーフィールド値から派生しています。
+-----+----------------------------+-----+--------------------------+
| ID | Name | ID | Name |
+-----+----------------------------+-----+--------------------------+
| 60 | ipVersion | 193 | nextHeaderIPv6 |
| 8 | sourceIPv4Address | 195 | ipDiffServCodePoint |
| 27 | sourceIPv6Address | 196 | ipPrecedence |
| 9 | sourceIPv4PrefixLength | 5 | ipClassOfService |
| 29 | sourceIPv6PrefixLength | 55 | postIpClassOfService |
| 44 | sourceIPv4Prefix | 31 | flowLabelIPv6 |
| 170 | sourceIPv6Prefix | 206 | isMulticast |
| 12 | destinationIPv4Address | 54 | fragmentIdentification |
| 28 | destinationIPv6Address | 88 | fragmentOffset |
| 13 | destinationIPv4PrefixLength| 197 | fragmentFlags |
| 30 | destinationIPv6PrefixLength| 189 | ipHeaderLength |
| 45 | destinationIPv4Prefix | 207 | ipv4IHL |
| 169 | destinationIPv6Prefix | 190 | totalLengthIPv4 |
| 192 | ipTTL | 224 | ipTotalLength |
| 4 | protocolIdentifier | 191 | payloadLengthIPv6 |
+-----+----------------------------+-----+--------------------------+
Description: The IP version field in the IP packet header. Abstract Data Type: unsigned8 Data Type Semantics: identifier ElementId: 60 Status: current Reference: See RFC 791 for the definition of the version field in the IPv4 packet header. See RFC 2460 for the definition of the version field in the IPv6 packet header. Additional information on defined version numbers can be found at http://www.iana.org/assignments/version-numbers.
説明：IPパケットヘッダーのIPバージョンフィールド。抽象データ型：Unsigned8データ型セマンティクス：識別子ElementID：60ステータス：現在の参照：IPv4パケットヘッダーのバージョンフィールドの定義については、RFC 791を参照してください。IPv6パケットヘッダーのバージョンフィールドの定義については、RFC 2460を参照してください。定義されたバージョン番号に関する追加情報は、http：//www.iana.org/assignments/version-numbersをご覧ください。
Description: The IPv4 source address in the IP packet header. Abstract Data Type: ipv4Address Data Type Semantics: identifier ElementId: 8 Status: current Reference: See RFC 791 for the definition of the IPv4 source address field.
説明：IPパケットヘッダーのIPv4ソースアドレス。抽象データ型：IPv4Addressデータ型セマンティクス：識別子ElementID：8ステータス：現在の参照：IPv4ソースアドレスフィールドの定義については、RFC 791を参照してください。
Description: The IPv6 source address in the IP packet header. Abstract Data Type: ipv6Address Data Type Semantics: identifier ElementId: 27 Status: current Reference: See RFC 2460 for the definition of the Source Address field in the IPv6 header.
説明：IPパケットヘッダーのIPv6ソースアドレス。抽象データ型：IPv6Addressデータ型セマンティクス：識別子ElementID：27ステータス：現在の参照：IPv6ヘッダーのソースアドレスフィールドの定義については、RFC 2460を参照してください。
Description: The number of contiguous bits that are relevant in the sourceIPv4Prefix Information Element. Abstract Data Type: unsigned8 ElementId: 9 Status: current Units: bits Range: The valid range is 0-32.
説明：soulityipv4prefix情報要素に関連する隣接するビットの数。抽象データ型：Unsigned8 ElementID：9ステータス：現在の単位：ビット範囲：有効な範囲は0-32です。
Description: The number of contiguous bits that are relevant in the sourceIPv6Prefix Information Element. Abstract Data Type: unsigned8 ElementId: 29 Status: current Units: bits Range: The valid range is 0-128.
説明：soulityipv6prefix情報要素に関連する隣接するビットの数。抽象データ型：unsigned8 ElementID：29ステータス：現在の単位：ビット範囲：有効な範囲は0-128です。
Description: IPv4 source address prefix. Abstract Data Type: ipv4Address ElementId: 44 Status: current
説明：IPv4ソースアドレスプレフィックス。抽象データ型：IPv4Address ElementID：44ステータス：現在
Description: IPv6 source address prefix. Abstract Data Type: ipv6Address ElementId: 170 Status: current
説明：IPv6ソースアドレスプレフィックス。要約データ型：IPv6Address ElementID：170ステータス：現在
Description: The IPv4 destination address in the IP packet header. Abstract Data Type: ipv4Address Data Type Semantics: identifier ElementId: 12 Status: current Reference: See RFC 791 for the definition of the IPv4 destination address field.
説明：IPパケットヘッダーのIPv4宛先アドレス。抽象データ型：IPv4Addressデータ型セマンティクス：識別子ElementID：12ステータス：現在の参照：IPv4宛先アドレスフィールドの定義については、RFC 791を参照してください。
Description: The IPv6 destination address in the IP packet header. Abstract Data Type: ipv6Address Data Type Semantics: identifier ElementId: 28 Status: current Reference: See RFC 2460 for the definition of the Destination Address field in the IPv6 header.
説明：IPパケットヘッダーのIPv6宛先アドレス。要約データ型：IPv6Addressデータ型セマンティクス：識別子ElementID：28ステータス：現在の参照：IPv6ヘッダーの宛先アドレスフィールドの定義については、RFC 2460を参照してください。
Description: The number of contiguous bits that are relevant in the destinationIPv4Prefix Information Element. Abstract Data Type: unsigned8 ElementId: 13 Status: current Units: bits Range: The valid range is 0-32.
説明：DestinationIPv4Prefix情報要素に関連する隣接するビットの数。抽象データ型：Unsigned8 ElementID：13ステータス：現在の単位：ビット範囲：有効な範囲は0-32です。
Description: The number of contiguous bits that are relevant in the destinationIPv6Prefix Information Element. Abstract Data Type: unsigned8 ElementId: 30 Status: current Units: bits Range: The valid range is 0-128.
Description: IPv4 destination address prefix. Abstract Data Type: ipv4Address ElementId: 45 Status: current
説明：IPv4宛先アドレスプレフィックス。抽象データ型：IPv4Address ElementID：45ステータス：現在
Description: IPv6 destination address prefix. Abstract Data Type: ipv6Address ElementId: 169 Status: current
説明：IPv6宛先アドレスプレフィックス。要約データ型：IPv6Address ElementID：169ステータス：現在
Description: For IPv4, the value of the Information Element matches the value of the Time to Live (TTL) field in the IPv4 packet header. For IPv6, the value of the Information Element matches the value of the Hop Limit field in the IPv6 packet header. Abstract Data Type: unsigned8 ElementId: 192 Status: current Units: hops Reference: See RFC 791 for the definition of the IPv4 Time to Live field. See RFC 2460 for the definition of the IPv6 Hop Limit field.
Description: The value of the protocol number in the IP packet header. The protocol number identifies the IP packet payload type. Protocol numbers are defined in the IANA Protocol Numbers registry. In Internet Protocol version 4 (IPv4), this is carried in the Protocol field. In Internet Protocol version 6 (IPv6), this is carried in the Next Header field in the last extension header of the packet. Abstract Data Type: unsigned8 Data Type Semantics: identifier ElementId: 4 Status: current Reference: See RFC 791 for the specification of the IPv4 protocol field. See RFC 2460 for the specification of the IPv6 protocol field. See the list of protocol numbers assigned by IANA at http://www.iana.org/assignments/protocol-numbers.
説明：IPパケットヘッダーのプロトコル番号の値。プロトコル番号は、IPパケットペイロードタイプを識別します。プロトコル番号は、IANAプロトコル番号レジストリで定義されています。インターネットプロトコルバージョン4（IPv4）では、これはプロトコルフィールドに配信されます。インターネットプロトコルバージョン6（IPv6）では、これはパケットの最後の拡張ヘッダーの次のヘッダーフィールドに掲載されています。抽象データ型：Unsigned8データ型セマンティクス：識別子ElementID：4ステータス：現在の参照：IPv4プロトコルフィールドの仕様については、RFC 791を参照してください。IPv6プロトコルフィールドの仕様については、RFC 2460を参照してください。http://www.iana.org/assignments/protocol-numbersでIANAが割り当てたプロトコル番号のリストを参照してください。
Description: The value of the Next Header field of the IPv6 header. The value identifies the type of the following IPv6 extension header or of the following IP payload. Valid values are defined in the IANA Protocol Numbers registry. Abstract Data Type: unsigned8 ElementId: 193 Status: current Reference: See RFC 2460 for the definition of the IPv6 Next Header field. See the list of protocol numbers assigned by IANA at http://www.iana.org/assignments/protocol-numbers.
説明：IPv6ヘッダーの次のヘッダーフィールドの値。値は、次のIPv6拡張ヘッダーまたは次のIPペイロードのタイプを識別します。有効な値は、IANAプロトコル番号レジストリで定義されています。抽象データ型：Unsigned8 ElementID：193ステータス：現在の参照：IPv6次のヘッダーフィールドの定義については、RFC 2460を参照してください。http://www.iana.org/assignments/protocol-numbersでIANAが割り当てたプロトコル番号のリストを参照してください。
Description: The value of a Differentiated Services Code Point (DSCP) encoded in the Differentiated Services field. The Differentiated Services field spans the most significant 6 bits of the IPv4 TOS field or the IPv6 Traffic Class field, respectively. This Information Element encodes only the 6 bits of the Differentiated Services field. Therefore, its value may range from 0 to 63. Abstract Data Type: unsigned8 Data Type Semantics: identifier ElementId: 195 Status: current Range: The valid range is 0-63. Reference: See RFC 3260 for the definition of the Differentiated Services field. See RFC 1812 (Section 5.3.2) and RFC 791 for the definition of the IPv4 TOS field. See RFC 2460 for the definition of the IPv6 Traffic Class field.
説明：差別化されたサービスフィールドでエンコードされた差別化されたサービスコードポイント（DSCP）の値。差別化されたサービスフィールドは、それぞれIPv4 TOSフィールドまたはIPv6トラフィッククラスフィールドの最も重要な6ビットに及びます。この情報要素は、差別化されたサービスフィールドの6ビットのみをエンコードします。したがって、その値は0〜63の範囲です。抽象データ型：unsigned8データ型セマンティクス：識別子ElementID：195ステータス：現在の範囲：有効な範囲は0-63です。参照：差別化されたサービスフィールドの定義については、RFC 3260を参照してください。IPv4 TOSフィールドの定義については、RFC 1812（セクション5.3.2）およびRFC 791を参照してください。IPv6トラフィッククラスフィールドの定義については、RFC 2460を参照してください。
Description: The value of the IP Precedence. The IP Precedence value is encoded in the first 3 bits of the IPv4 TOS field or the IPv6 Traffic Class field, respectively. This Information Element encodes only these 3 bits. Therefore, its value may range from 0 to 7. Abstract Data Type: unsigned8 Data Type Semantics: identifier ElementId: 196 Status: current Range: The valid range is 0-7. Reference: See RFC 1812 (Section 5.3.3) and RFC 791 for the definition of the IP Precedence. See RFC 1812 (Section 5.3.2) and RFC 791 for the definition of the IPv4 TOS field. See RFC 2460 for the definition of the IPv6 Traffic Class field.
説明：IPの優先順位の値。IPの優先順位値は、それぞれIPv4 TOSフィールドまたはIPv6トラフィッククラスフィールドの最初の3ビットでエンコードされます。この情報要素は、これらの3ビットのみをエンコードします。したがって、その値は0〜7の範囲です。抽象データ型：unsigned8データ型セマンティクス：識別子要素：196ステータス：現在の範囲：有効な範囲は0-7です。参照：IPの優先順位の定義については、RFC 1812（セクション5.3.3）およびRFC 791を参照してください。IPv4 TOSフィールドの定義については、RFC 1812（セクション5.3.2）およびRFC 791を参照してください。IPv6トラフィッククラスフィールドの定義については、RFC 2460を参照してください。
Description: For IPv4 packets, this is the value of the TOS field in the IPv4 packet header. For IPv6 packets, this is the value of the Traffic Class field in the IPv6 packet header. Abstract Data Type: unsigned8 Data Type Semantics: identifier ElementId: 5 Status: current Reference: See RFC 1812 (Section 5.3.2) and RFC 791 for the definition of the IPv4 TOS field. See RFC 2460 for the definition of the IPv6 Traffic Class field.
説明：IPv4パケットの場合、これはIPv4パケットヘッダーのTOSフィールドの値です。IPv6パケットの場合、これはIPv6パケットヘッダーのトラフィッククラスフィールドの値です。要約データ型：Unsisised8データ型セマンティクス：識別子ElementID：5ステータス：現在の参照：RFC 1812（セクション5.3.2）およびRFC 791を参照IPv4 TOSフィールドの定義について。IPv6トラフィッククラスフィールドの定義については、RFC 2460を参照してください。
Description: The definition of this Information Element is identical to the definition of Information Element 'ipClassOfService', except that it reports a potentially modified value caused by a middlebox function after the packet passed the Observation Point. Abstract Data Type: unsigned8 Data Type Semantics: identifier ElementId: 55 Status: current Reference: See RFC 791 for the definition of the IPv4 TOS field. See RFC 2460 for the definition of the IPv6 Traffic Class field. See RFC 3234 for the definition of middleboxes.
説明：この情報要素の定義は、パケットが観測ポイントを通過した後にミドルボックス関数によって引き起こされる潜在的に変更された値を報告することを除いて、情報要素「ipclassofservice」の定義と同一です。抽象データ型：Unsigned8データ型セマンティクス：識別子ElementID：55ステータス：現在の参照：IPv4 TOSフィールドの定義については、RFC 791を参照してください。IPv6トラフィッククラスフィールドの定義については、RFC 2460を参照してください。ミドルボックスの定義については、RFC 3234を参照してください。
Description: The value of the IPv6 Flow Label field in the IP packet header. Abstract Data Type: unsigned32 Data Type Semantics: identifier ElementId: 31 Status: current Reference: See RFC 2460 for the definition of the Flow Label field in the IPv6 packet header.
説明：IPパケットヘッダーのIPv6フローラベルフィールドの値。要約データ型：unsigned32データ型セマンティクス：識別子ElementID：31ステータス：現在の参照：IPv6パケットヘッダーのフローラベルフィールドの定義については、RFC 2460を参照してください。
Description: If the IP destination address is not a reserved multicast address, then the value of all bits of the octet (including the reserved ones) is zero. The first bit of this octet is set to 1 if the Version field of the IP header has the value 4 and if the Destination Address field contains a reserved multicast address in the range from 224.0.0.0 to 239.255.255.255. Otherwise, this bit is set to 0. The second and third bits of this octet are reserved for future use. The remaining bits of the octet are only set to values other than zero if the IP Destination Address is a reserved IPv6 multicast address. Then the fourth bit of the octet is set to the value of the T flag in the IPv6 multicast address and the remaining four bits are set to the value of the scope field in the IPv6 multicast address.
説明：IP宛先アドレスが予約済みのマルチキャストアドレスでない場合、オクテットのすべてのビット（予約済みのアドレスを含む）の値はゼロです。このオクテットの最初のビットは、IPヘッダーのバージョンフィールドに値4があり、宛先アドレスフィールドに224.0.0.0から239.255.255.255までの範囲の予約済みマルチキャストアドレスが含まれている場合、1に設定されます。それ以外の場合、このビットは0に設定されています。このオクテットの2番目と3番目のビットは、将来の使用のために予約されています。Octetの残りのビットは、IP宛先アドレスが予約済みのIPv6マルチキャストアドレスである場合、ゼロ以外の値にのみ設定されます。次に、Octetの4番目のビットはIPv6マルチキャストアドレスのTフラグの値に設定され、残りの4つのビットはIPv6マルチキャストアドレスのスコープフィールドの値に設定されます。
0 1 2 3 4 5 6 7
+------+------+------+------+------+------+------+------+
| MCv4 | RES. | RES. | T | IPv6 multicast scope |
+------+------+------+------+------+------+------+------+
Bit 0: set to 1 if IPv4 multicast Bits 1-2: reserved for future use Bit 4: set to value of T flag, if IPv6 multicast Bits 4-7: set to value of multicast scope if IPv6 multicast
ビット0：IPv4マルチキャストビットの場合1に設定1-2：将来の使用のために予約ビット4：Tフラグの値に設定します。
Abstract Data Type: unsigned8 Data Type Semantics: flags ElementId: 206 Status: current Reference: See RFC 1112 for the specification of reserved IPv4 multicast addresses. See RFC 4291 for the specification of reserved IPv6 multicast addresses and the definition of the T flag and the IPv6 multicast scope.
抽象データ型：Unsigned8データ型セマンティクス：Flags ElementID：206ステータス：現在の参照：予約されたIPv4マルチキャストアドレスの仕様については、RFC 1112を参照してください。予約されたIPv6マルチキャストアドレスの仕様とTフラグとIPv6マルチキャストスコープの定義については、RFC 4291を参照してください。
Description: The value of the Identification field in the IPv4 packet header or in the IPv6 Fragment header, respectively. The value is 0 for IPv6 if there is no fragment header. Abstract Data Type: unsigned32 Data Type Semantics: identifier ElementId: 54 Status: current Reference: See RFC 791 for the definition of the IPv4 Identification field. See RFC 2460 for the definition of the Identification field in the IPv6 Fragment header.
説明：IPv4パケットヘッダーまたはIPv6フラグメントヘッダーの識別フィールドの値。フラグメントヘッダーがない場合、IPv6の値は0です。抽象データ型：unsigned32データ型セマンティクス：識別子ElementID：54ステータス：現在の参照：IPv4識別フィールドの定義については、RFC 791を参照してください。IPv6フラグメントヘッダーの識別フィールドの定義については、RFC 2460を参照してください。
Description: The value of the IP fragment offset field in the IPv4 packet header or the IPv6 Fragment header, respectively. The value is 0 for IPv6 if there is no fragment header. Abstract Data Type: unsigned16 Data Type Semantics: identifier ElementId: 88 Status: current Reference: See RFC 791 for the specification of the fragment offset in the IPv4 header. See RFC 2460 for the specification of the fragment offset in the IPv6 Fragment header.
Description: Fragmentation properties indicated by flags in the IPv4 packet header or the IPv6 Fragment header, respectively.
説明：IPv4パケットヘッダーまたはIPv6フラグメントヘッダーのフラグによって示されるフラグメンテーションプロパティ。
Bit 0: (RS) Reserved. The value of this bit MUST be 0 until specified otherwise.
Bit 1: (DF) 0 = May Fragment, 1 = Don't Fragment. Corresponds to the value of the DF flag in the IPv4 header. Will always be 0 for IPv6 unless a "don't fragment" feature is introduced to IPv6.
ビット1：（df）0 =メイフラグメント、1 =フラグメントしないでください。IPv4ヘッダーのDFフラグの値に対応します。「断片化しない」機能がIPv6に導入されない限り、IPv6の場合は常に0になります。
Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments. Corresponds to the MF flag in the IPv4 header or to the M flag in the IPv6 Fragment header, respectively. The value is 0 for IPv6 if there is no fragment header.
ビット2：（MF）0 =最後のフラグメント、1 =より多くのフラグメント。IPv4ヘッダーのMFフラグまたはIPv6フラグメントヘッダーのMフラグにそれぞれ対応します。フラグメントヘッダーがない場合、IPv6の値は0です。
Bits 3-7: (DC) Don't Care. The values of these bits are irrelevant.
ビット3-7：（DC）気にしないでください。これらのビットの値は無関係です。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| R | D | M | D | D | D | D | D |
| S | F | F | C | C | C | C | C |
+---+---+---+---+---+---+---+---+
Abstract Data Type: unsigned8 Data Type Semantics: flags ElementId: 197 Status: current Reference: See RFC 791 for the specification of the IPv4 fragment flags. See RFC 2460 for the specification of the IPv6 Fragment header.
要約データ型：Unsigned8データ型セマンティクス：Flags ElementID：197ステータス：現在の参照：IPv4フラグメントフラグの仕様については、RFC 791を参照してください。IPv6フラグメントヘッダーの仕様については、RFC 2460を参照してください。
Description: The length of the IP header. For IPv6, the value of this Information Element is 40. Abstract Data Type: unsigned8 ElementId: 189 Status: current Units: octets Reference: See RFC 791 for the specification of the IPv4 header. See RFC 2460 for the specification of the IPv6 header.
説明：IPヘッダーの長さ。IPv6の場合、この情報要素の値は40です。抽象データ型：Unsigned8 ElementID：189ステータス：現在の単位：Octetsリファレンス：IPv4ヘッダーの仕様についてはRFC 791を参照してください。IPv6ヘッダーの仕様については、RFC 2460を参照してください。
Description: The value of the Internet Header Length (IHL) field in the IPv4 header. It specifies the length of the header in units of 4 octets. Please note that its unit is different from most of the other Information Elements reporting length values.
説明：IPv4ヘッダーのインターネットヘッダー長（IHL）フィールドの値。ヘッダーの長さを4オクテットのユニットの長さを指定します。そのユニットは、長さの値を報告する他のほとんどの情報要素とは異なることに注意してください。
Abstract Data Type: unsigned8 ElementId: 207 Status: current Units: 4 octets Reference: See RFC 791 for the specification of the IPv4 header.
抽象データ型：Unsigned8 ElementID：207ステータス：現在の単位：4オクテットリファレンス：IPv4ヘッダーの仕様については、RFC 791を参照してください。
Description: The total length of the IPv4 packet. Abstract Data Type: unsigned16 ElementId: 190 Status: current Units: octets Reference: See RFC 791 for the specification of the IPv4 total length.
説明：IPv4パケットの全長。抽象データ型：unsigned16 ElementID：190ステータス：現在の単位：オクテットリファレンス：IPv4の合計長の仕様については、RFC 791を参照してください。
Description: The total length of the IP packet. Abstract Data Type: unsigned64 ElementId: 224 Status: current Units: octets Reference: See RFC 791 for the specification of the IPv4 total length. See RFC 2460 for the specification of the IPv6 payload length. See RFC 2675 for the specification of the IPv6 jumbo payload length.
説明：IPパケットの全長。抽象データ型：unsigned64 ElementID：224ステータス：現在の単位：Octetsリファレンス：IPv4の合計長の仕様については、RFC 791を参照してください。IPv6ペイロード長の仕様については、RFC 2460を参照してください。IPv6ジャンボペイロード長の仕様については、RFC 2675を参照してください。
Description: This Information Element reports the value of the Payload Length field in the IPv6 header. Note that IPv6 extension headers belong to the payload. Also note that in case of a jumbo payload option the value of the Payload Length field in the IPv6 header is zero and so will be the value reported by this Information Element. Abstract Data Type: unsigned16 ElementId: 191 Status: current Units: octets Reference: See RFC 2460 for the specification of the IPv6 payload length. See RFC 2675 for the specification of the IPv6 jumbo payload option.
説明：この情報要素は、IPv6ヘッダーのペイロード長フィールドの値を報告します。IPv6拡張ヘッダーはペイロードに属していることに注意してください。また、ジャンボペイロードオプションの場合、IPv6ヘッダーのペイロード長さフィールドの値はゼロであり、この情報要素によって報告される値になることに注意してください。抽象データ型：unsigned16 ElementID：191ステータス：現在の単位：Octetsリファレンス：IPv6ペイロード長の仕様については、RFC 2460を参照してください。IPv6ジャンボペイロードオプションの仕様については、RFC 2675を参照してください。
The set of Information Elements related to transport header fields and length includes the Information Elements listed in the table below.
輸送ヘッダーフィールドと長さに関連する情報要素のセットには、以下の表にリストされている情報要素が含まれています。
+-----+---------------------------+-----+---------------------------+
| ID | Name | ID | Name |
+-----+---------------------------+-----+---------------------------+
| 7 | sourceTransportPort | 238 | tcpWindowScale |
| 11 | destinationTransportPort | 187 | tcpUrgentPointer |
| 180 | udpSourcePort | 188 | tcpHeaderLength |
| 181 | udpDestinationPort | 32 | icmpTypeCodeIPv4 |
| 205 | udpMessageLength | 176 | icmpTypeIPv4 |
| 182 | tcpSourcePort | 177 | icmpCodeIPv4 |
| 183 | tcpDestinationPort | 139 | icmpTypeCodeIPv6 |
| 184 | tcpSequenceNumber | 178 | icmpTypeIPv6 |
| 185 | tcpAcknowledgementNumber | 179 | icmpCodeIPv6 |
| 186 | tcpWindowSize | 33 | igmpType |
+-----+---------------------------+-----+---------------------------+
Description: The source port identifier in the transport header. For the transport protocols UDP, TCP, and SCTP, this is the source port number given in the respective header. This field MAY also be used for future transport protocols that have 16-bit source port identifiers. Abstract Data Type: unsigned16 Data Type Semantics: identifier ElementId: 7 Status: current Reference: See RFC 768 for the definition of the UDP source port field. See RFC 793 for the definition of the TCP source port field. See RFC 4960 for the definition of SCTP. Additional information on defined UDP and TCP port numbers can be found at http://www.iana.org/assignments/port-numbers.
説明：トランスポートヘッダーのソースポート識別子。輸送プロトコルUDP、TCP、およびSCTPの場合、これはそれぞれのヘッダーに与えられたソースポート番号です。このフィールドは、16ビットのソースポート識別子を持つ将来の輸送プロトコルにも使用できます。抽象データ型：unsigned16データ型セマンティクス：識別子ElementID：7ステータス：現在の参照：UDPソースポートフィールドの定義については、RFC 768を参照してください。TCPソースポートフィールドの定義については、RFC 793を参照してください。SCTPの定義については、RFC 4960を参照してください。定義されたUDPおよびTCPポート番号の追加情報は、http：//www.iana.org/assignments/port-numbersをご覧ください。
Description: The destination port identifier in the transport header. For the transport protocols UDP, TCP, and SCTP, this is the destination port number given in the respective header. This field MAY also be used for future transport protocols that have 16-bit destination port identifiers.
Abstract Data Type: unsigned16 Data Type Semantics: identifier ElementId: 11 Status: current Reference: See RFC 768 for the definition of the UDP destination port field. See RFC 793 for the definition of the TCP destination port field. See RFC 4960 for the definition of SCTP. Additional information on defined UDP and TCP port numbers can be found at http://www.iana.org/assignments/port-numbers.
抽象データ型：unsigned16データ型セマンティクス：識別子ElementID：11ステータス：現在の参照：UDP宛先ポートフィールドの定義については、RFC 768を参照してください。TCP宛先ポートフィールドの定義については、RFC 793を参照してください。SCTPの定義については、RFC 4960を参照してください。定義されたUDPおよびTCPポート番号の追加情報は、http：//www.iana.org/assignments/port-numbersをご覧ください。
Description: The source port identifier in the UDP header. Abstract Data Type: unsigned16 Data Type Semantics: identifier ElementId: 180 Status: current Reference: See RFC 768 for the definition of the UDP source port field. Additional information on defined UDP port numbers can be found at http://www.iana.org/assignments/port-numbers.
説明：UDPヘッダーのソースポート識別子。抽象データ型：unsigned16データ型セマンティクス：識別子ElementID：180ステータス：現在の参照：UDPソースポートフィールドの定義については、RFC 768を参照してください。定義されたUDPポート番号に関する追加情報は、http：//www.iana.org/assignments/port-numbersをご覧ください。
Description: The destination port identifier in the UDP header. Abstract Data Type: unsigned16 Data Type Semantics: identifier ElementId: 181 Status: current Reference: See RFC 768 for the definition of the UDP destination port field. Additional information on defined UDP port numbers can be found at http://www.iana.org/assignments/port-numbers.
説明：UDPヘッダーの宛先ポート識別子。抽象データ型：unsigned16データ型セマンティクス：識別子ElementID：181ステータス：現在の参照：UDP宛先ポートフィールドの定義については、RFC 768を参照してください。定義されたUDPポート番号に関する追加情報は、http：//www.iana.org/assignments/port-numbersをご覧ください。
Description: The value of the Length field in the UDP header. Abstract Data Type: unsigned16 ElementId: 205 Status: current Units: octets Reference: See RFC 768 for the specification of the UDP header.
説明：UDPヘッダーの長さフィールドの値。抽象データ型：unsigned16 ElementID：205ステータス：現在の単位：Octetsリファレンス：UDPヘッダーの仕様については、RFC 768を参照してください。
Description: The source port identifier in the TCP header. Abstract Data Type: unsigned16 Data Type Semantics: identifier ElementId: 182 Status: current Reference: See RFC 793 for the definition of the TCP source port field. Additional information on defined TCP port numbers can be found at http://www.iana.org/assignments/port-numbers.
説明：TCPヘッダーのソースポート識別子。抽象データ型：unsigned16データ型セマンティクス：識別子ElementID：182ステータス：現在の参照：TCPソースポートフィールドの定義については、RFC 793を参照してください。定義されたTCPポート番号に関する追加情報は、http：//www.iana.org/assignments/port-numbersをご覧ください。
Description: The destination port identifier in the TCP header. Abstract Data Type: unsigned16 Data Type Semantics: identifier ElementId: 183 Status: current Reference: See RFC 793 for the definition of the TCP source port field. Additional information on defined TCP port numbers can be found at http://www.iana.org/assignments/port-numbers.
説明：TCPヘッダーの宛先ポート識別子。抽象データ型：unsigned16データ型セマンティクス：識別子ElementID：183ステータス：現在の参照：TCPソースポートフィールドの定義については、RFC 793を参照してください。定義されたTCPポート番号に関する追加情報は、http：//www.iana.org/assignments/port-numbersをご覧ください。
Description: The sequence number in the TCP header. Abstract Data Type: unsigned32 ElementId: 184 Status: current Reference: See RFC 793 for the definition of the TCP sequence number.
説明：TCPヘッダーのシーケンス番号。抽象データ型：unsigned32 ElementID：184ステータス：現在の参照：TCPシーケンス番号の定義については、RFC 793を参照してください。
Description: The acknowledgement number in the TCP header. Abstract Data Type: unsigned32 ElementId: 185 Status: current Reference: See RFC 793 for the definition of the TCP acknowledgement number.
説明：TCPヘッダーの確認番号。抽象データ型：unsigned32 ElementID：185ステータス：現在の参照：TCP確認番号の定義については、RFC 793を参照してください。
Description: The window field in the TCP header. If the TCP window scale is supported, then TCP window scale must be known to fully interpret the value of this information. Abstract Data Type: unsigned16 ElementId: 186 Status: current Reference: See RFC 793 for the definition of the TCP window field. See RFC 1323 for the definition of the TCP window scale.
説明：TCPヘッダーのウィンドウフィールド。TCPウィンドウスケールがサポートされている場合、この情報の値を完全に解釈するには、TCPウィンドウスケールが知られている必要があります。抽象データ型：unsigned16 ElementID：186ステータス：現在の参照：TCPウィンドウフィールドの定義については、RFC 793を参照してください。TCPウィンドウスケールの定義については、RFC 1323を参照してください。
Description: The scale of the window field in the TCP header. Abstract Data Type: unsigned16 ElementId: 238 Status: current Reference: See RFC 1323 for the definition of the TCP window scale.
Description: The urgent pointer in the TCP header. Abstract Data Type: unsigned16 ElementId: 187 Status: current Reference: See RFC 793 for the definition of the TCP urgent pointer.
説明：TCPヘッダーの緊急ポインター。抽象データ型：unsigned16 ElementID：187ステータス：現在の参照：TCP緊急ポインターの定義については、RFC 793を参照してください。
Description: The length of the TCP header. Note that the value of this Information Element is different from the value of the Data Offset field in the TCP header. The Data Offset field indicates the length of the TCP header in units of 4 octets. This Information Elements specifies the length of the TCP header in units of octets. Abstract Data Type: unsigned8 ElementId: 188 Status: current Units: octets Reference: See RFC 793 for the definition of the TCP header.
説明：TCPヘッダーの長さ。この情報要素の値は、TCPヘッダーのデータオフセットフィールドの値とは異なることに注意してください。データオフセットフィールドは、4オクテットの単位でのTCPヘッダーの長さを示します。この情報要素は、オクテットの単位でTCPヘッダーの長さを指定します。抽象データ型：Unsigned8 ElementID：188ステータス：現在の単位：Octetsリファレンス：TCPヘッダーの定義については、RFC 793を参照してください。
Description: Type and Code of the IPv4 ICMP message. The combination of both values is reported as (ICMP type * 256) + ICMP code. Abstract Data Type: unsigned16 Data Type Semantics: identifier ElementId: 32 Status: current Reference: See RFC 792 for the definition of the IPv4 ICMP type and code fields.
説明：IPv4 ICMPメッセージのタイプとコード。両方の値の組み合わせは、（ICMPタイプ * 256）ICMPコードとして報告されます。抽象データ型：unsigned16データ型セマンティクス：識別子ElementID：32ステータス：現在の参照：IPv4 ICMPタイプとコードフィールドの定義については、RFC 792を参照してください。
Description: Type of the IPv4 ICMP message. Abstract Data Type: unsigned8 Data Type Semantics: identifier ElementId: 176 Status: current Reference: See RFC 792 for the definition of the IPv4 ICMP type field.
説明：IPv4 ICMPメッセージのタイプ。抽象データ型：unsigned8データ型セマンティクス：識別子ElementID：176ステータス：現在の参照：IPv4 ICMPタイプフィールドの定義については、RFC 792を参照してください。
Description: Code of the IPv4 ICMP message. Abstract Data Type: unsigned8 Data Type Semantics: identifier ElementId: 177 Status: current Reference: See RFC 792 for the definition of the IPv4 ICMP code field.
説明：IPv4 ICMPメッセージのコード。抽象データ型：Unsigned8データ型セマンティクス：識別子ElementID：177ステータス：現在の参照：IPv4 ICMPコードフィールドの定義については、RFC 792を参照してください。
Description: Type and Code of the IPv6 ICMP message. The combination of both values is reported as (ICMP type * 256) + ICMP code. Abstract Data Type: unsigned16 Data Type Semantics: identifier ElementId: 139 Status: current Reference: See RFC 4443 for the definition of the IPv6 ICMP type and code fields.
説明：IPv6 ICMPメッセージのタイプとコード。両方の値の組み合わせは、（ICMPタイプ * 256）ICMPコードとして報告されます。抽象データ型：unsigned16データ型セマンティクス：識別子ElementID：139ステータス：現在の参照：IPv6 ICMPタイプとコードフィールドの定義については、RFC 4443を参照してください。
Description: Type of the IPv6 ICMP message. Abstract Data Type: unsigned8 Data Type Semantics: identifier ElementId: 178 Status: current Reference: See RFC 4443 for the definition of the IPv6 ICMP type field.
説明：IPv6 ICMPメッセージのタイプ。抽象データ型：Unsigned8データ型セマンティクス：識別子ElementID：178ステータス：現在の参照：IPv6 ICMPタイプフィールドの定義については、RFC 4443を参照してください。
Description: Code of the IPv6 ICMP message. Abstract Data Type: unsigned8 Data Type Semantics: identifier ElementId: 179 Status: current Reference: See RFC 4443 for the definition of the IPv6 ICMP code field.
説明：IPv6 ICMPメッセージのコード。抽象データ型：Unsigned8データ型セマンティクス：識別子ElementID：179ステータス：現在の参照：IPv6 ICMPコードフィールドの定義については、RFC 4443を参照してください。
Description: The type field of the IGMP message. Abstract Data Type: unsigned8 Data Type Semantics: identifier ElementId: 33 Status: current Reference: See RFC 3376 for the definition of the IGMP type field.
説明：IGMPメッセージのタイプフィールド。抽象データ型：Unsigned8データ型セマンティクス：識別子ElementID：33ステータス：現在の参照：IGMP型フィールドの定義については、RFC 3376を参照してください。
The set of Information Elements related to Sub-IP header fields includes the Information Elements listed in the table below.
サブIPヘッダーフィールドに関連する情報要素のセットには、以下の表にリストされている情報要素が含まれています。
+-----+---------------------------+-----+---------------------------+
| ID | Name | ID | Name |
+-----+---------------------------+-----+---------------------------+
| 56 | sourceMacAddress | 201 | mplsLabelStackLength |
| 81 | postSourceMacAddress | 194 | mplsPayloadLength |
| 58 | vlanId | 70 | mplsTopLabelStackSection |
| 59 | postVlanId | 71 | mplsLabelStackSection2 |
| 80 | destinationMacAddress | 72 | mplsLabelStackSection3 |
| 57 | postDestinationMacAddress | 73 | mplsLabelStackSection4 |
| 146 | wlanChannelId | 74 | mplsLabelStackSection5 |
| 147 | wlanSSID | 75 | mplsLabelStackSection6 |
| 200 | mplsTopLabelTTL | 76 | mplsLabelStackSection7 |
| 203 | mplsTopLabelExp | 77 | mplsLabelStackSection8 |
| 237 | postMplsTopLabelExp | 78 | mplsLabelStackSection9 |
| 202 | mplsLabelStackDepth | 79 | mplsLabelStackSection10 |
+-----+---------------------------+-----+---------------------------+
Description: The IEEE 802 source MAC address field. Abstract Data Type: macAddress Data Type Semantics: identifier ElementId: 56 Status: current Reference: See IEEE.802-3.2002.
説明：IEEE 802ソースMacアドレスフィールド。抽象データ型：MacAddressデータ型セマンティクス：識別子ElementID：56ステータス：現在の参照：IEEE.802-3.2002を参照。
Description: The definition of this Information Element is identical to the definition of Information Element 'sourceMacAddress', except that it reports a potentially modified value caused by a middlebox function after the packet passed the Observation Point. Abstract Data Type: macAddress Data Type Semantics: identifier ElementId: 81 Status: current Reference: See IEEE.802-3.2002.
説明：この情報要素の定義は、パケットが観測ポイントを通過した後にミドルボックス関数によって引き起こされる潜在的に変更された値を報告することを除いて、情報要素「sourcemacaddress」の定義と同一です。抽象データ型：MacAddressデータ型セマンティクス：識別子ElementID：81ステータス：現在の参照：IEEE.802-3.2002を参照。
Description: The IEEE 802.1Q VLAN identifier (VID) extracted from the Tag Control Information field that was attached to the IP packet. Abstract Data Type: unsigned16 Data Type Semantics: identifier ElementId: 58 Status: current Reference: See IEEE.802-1Q.2003.
説明：IPパケットに取り付けられたタグ制御情報フィールドから抽出されたIEEE 802.1Q VLAN識別子（VID）。抽象データ型：unsigned16データ型セマンティクス：識別子ElementID：58ステータス：現在の参照：IEEE.802-1Q.2003を参照。
Description: The definition of this Information Element is identical to the definition of Information Element 'vlanId', except that it reports a potentially modified value caused by a middlebox function after the packet passed the Observation Point. Abstract Data Type: unsigned16 Data Type Semantics: identifier ElementId: 59 Status: current Reference: See IEEE.802-1Q.2003.
説明：この情報要素の定義は、パケットが観測点を通過した後にミドルボックス関数によって引き起こされる潜在的に変更された値を報告することを除いて、情報要素「Vlanid」の定義と同一です。抽象データ型：unsigned16データ型セマンティクス：識別子ElementID：59ステータス：現在の参照：IEEE.802-1Q.2003を参照。
Description: The IEEE 802 destination MAC address field. Abstract Data Type: macAddress Data Type Semantics: identifier ElementId: 80 Status: current Reference: See IEEE.802-3.2002.
説明：IEEE 802宛先Macアドレスフィールド。抽象データ型：MacAddressデータ型セマンティクス：識別子ElementID：80ステータス：現在の参照：IEEE.802-3.2002を参照。
Description: The definition of this Information Element is identical to the definition of Information Element 'destinationMacAddress', except that it reports a potentially modified value caused by a middlebox function after the packet passed the Observation Point. Abstract Data Type: macAddress Data Type Semantics: identifier ElementId: 57 Status: current Reference: See IEEE.802-3.2002.
説明：この情報要素の定義は、パケットが観測ポイントを通過した後にミドルボックス関数によって引き起こされる潜在的に変更された値を報告することを除いて、情報要素「DestinationMacAddress」の定義と同一です。抽象データ型：MacAddressデータ型セマンティクス：識別子ElementID：57ステータス：現在の参照：IEEE.802-3.2002を参照。
Description: The identifier of the 802.11 (Wi-Fi) channel used. Abstract Data Type: unsigned8 Data Type Semantics: identifier ElementId: 146 Status: current Reference: See IEEE.802-11.1999.
説明：使用される802.11（Wi-Fi）チャネルの識別子。抽象データ型：unsigned8データ型セマンティクス：識別子ElementID：146ステータス：現在の参照：IEEE.802-11.1999を参照。
Description: The Service Set IDentifier (SSID) identifying an 802.11 (Wi-Fi) network used. According to IEEE.802-11.1999, the SSID is encoded into a string of up to 32 characters. Abstract Data Type: string ElementId: 147 Status: current Reference: See IEEE.802-11.1999.
説明：使用される802.11（Wi-Fi）ネットワークを識別するサービスセット識別子（SSID）。IEEE.802-11.1999によると、SSIDは最大32文字の文字列にエンコードされています。要約データ型：文字列ElementID：147ステータス：現在の参照：IEEE.802-11.1999を参照。
Description: The TTL field from the top MPLS label stack entry, i.e., the last label that was pushed. Abstract Data Type: unsigned8 ElementId: 200 Status: current Units: hops Reference: See RFC 3032 for the specification of the TTL field.
説明：上部MPLSラベルスタックエントリからのTTLフィールド、つまりプッシュされた最後のラベル。抽象データ型：Unsigned8 ElementID：200ステータス：現在の単位：ホップリファレンス：TTLフィールドの仕様についてはRFC 3032を参照してください。
Description: The Exp field from the top MPLS label stack entry, i.e., the last label that was pushed.
説明：上部のMPLSラベルスタックエントリからのEXPフィールド、つまりプッシュされた最後のラベル。
Bits 0-4: Don't Care, value is irrelevant. Bits 5-7: MPLS Exp field.
ビット0-4：気にしないでください、価値は無関係です。ビット5-7：MPLS EXPフィールド。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| don't care | Exp |
+---+---+---+---+---+---+---+---+
Abstract Data Type: unsigned8 Data Type Semantics: flags ElementId: 203 Status: current Reference: See RFC 3032 for the specification of the Exp field. See RFC 3270 for usage of the Exp field.
抽象データ型：Unsigned8データ型セマンティクス：Flags ElementID：203ステータス：現在の参照：EXPフィールドの仕様についてはRFC 3032を参照してください。EXPフィールドの使用については、RFC 3270を参照してください。
Description: The definition of this Information Element is identical to the definition of Information Element 'mplsTopLabelExp', except that it reports a potentially modified value caused by a middlebox function after the packet passed the Observation Point. Abstract Data Type: unsigned8 Data Type Semantics: flags ElementId: 237 Status: current Reference: See RFC 3032 for the specification of the Exp field. See RFC 3270 for usage of the Exp field.
説明：この情報要素の定義は、パケットが観測ポイントを通過した後にミドルボックス関数によって引き起こされる潜在的に変更された値を報告することを除いて、情報要素「mplstoplabelexp」の定義と同一です。抽象データ型：Unsigned8データ型セマンティクス：Flags ElementID：237ステータス：現在の参照：EXPフィールドの仕様についてはRFC 3032を参照してください。EXPフィールドの使用については、RFC 3270を参照してください。
Description: The number of labels in the MPLS label stack. Abstract Data Type: unsigned32 ElementId: 202 Status: current Units: label stack entries Reference: See RFC 3032 for the specification of the MPLS label stack.
説明：MPLSラベルスタックのラベルの数。抽象データ型：unsigned32 ElementID：202ステータス：現在の単位：ラベルスタックエントリリファレンス：MPLSラベルスタックの仕様については、RFC 3032を参照してください。
Description: The length of the MPLS label stack in units of octets. Abstract Data Type: unsigned32 ElementId: 201 Status: current Units: octets Reference: See RFC 3032 for the specification of the MPLS label stack.
説明：オクテットの単位でのMPLSラベルスタックの長さ。抽象データ型：unsigned32 ElementID：201ステータス：現在の単位：オクテットリファレンス：MPLSラベルスタックの仕様については、RFC 3032を参照してください。
Description: The size of the MPLS packet without the label stack. Abstract Data Type: unsigned32 ElementId: 194 Status: current Units: octets Reference: See RFC 3031 for the specification of MPLS packets. See RFC 3032 for the specification of the MPLS label stack.
説明：ラベルスタックなしのMPLSパケットのサイズ。抽象データ型：unsigned32 ElementID：194ステータス：現在の単位：Octetsリファレンス：MPLSパケットの仕様についてはRFC 3031を参照してください。MPLSラベルスタックの仕様については、RFC 3032を参照してください。
Description: The Label, Exp, and S fields from the top MPLS label stack entry, i.e., from the last label that was pushed. The size of this Information Element is 3 octets.
説明：上部MPLSラベルスタックエントリ、つまり、プッシュされた最後のラベルからのラベル、EXP、およびSフィールド。この情報要素のサイズは3オクテットです。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | Exp |S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label: Label Value, 20 bits Exp: Experimental Use, 3 bits S: Bottom of Stack, 1 bit
ラベル：ラベル値、20ビットExp：実験用使用、3ビットS：スタックの下部、1ビット
Abstract Data Type: octetArray Data Type Semantics: identifier ElementId: 70 Status: current Reference: See RFC 3032.
抽象データ型：OctetArrayデータ型セマンティクス：識別子ElementID：70ステータス：現在の参照：RFC 3032を参照。
Description: The Label, Exp, and S fields from the label stack entry that was pushed immediately before the label stack entry that would be reported by mplsTopLabelStackSection. See the definition of mplsTopLabelStackSection for further details. The size of this Information Element is 3 octets. Abstract Data Type: octetArray Data Type Semantics: identifier ElementId: 71 Status: current Reference: See RFC 3032.
説明：MplStoplabelStackSectionによって報告されるラベルスタックエントリの直前にプッシュされたラベルスタックエントリからのラベル、EXP、およびSフィールド。詳細については、mplstoplabelstacksectionの定義を参照してください。この情報要素のサイズは3オクテットです。抽象データ型：OctetArrayデータ型セマンティクス：識別子ElementID：71ステータス：現在の参照：RFC 3032を参照。
Description: The Label, Exp, and S fields from the label stack entry that was pushed immediately before the label stack entry that would be reported by mplsLabelStackSection2. See the definition of mplsTopLabelStackSection for further details. The size of this Information Element is 3 octets. Abstract Data Type: octetArray Data Type Semantics: identifier ElementId: 72 Status: current Reference: See RFC 3032.
説明：MPLSLabelStackSection2によって報告されるラベルスタックエントリの直前にプッシュされたラベルスタックエントリからのラベル、EXP、およびSフィールド。詳細については、mplstoplabelstacksectionの定義を参照してください。この情報要素のサイズは3オクテットです。抽象データ型：OctetArrayデータ型セマンティクス：識別子ElementID：72ステータス：現在の参照：RFC 3032を参照。
Description: The Label, Exp, and S fields from the label stack entry that was pushed immediately before the label stack entry that would be reported by mplsLabelStackSection3. See the definition of mplsTopLabelStackSection for further details. The size of this Information Element is 3 octets. Abstract Data Type: octetArray Data Type Semantics: identifier ElementId: 73 Status: current Reference: See RFC 3032.
説明：MPLSLABELSTACKSECTION3によって報告されるラベルスタックエントリの直前にプッシュされたラベルスタックエントリからのラベル、EXP、およびSフィールド。詳細については、mplstoplabelstacksectionの定義を参照してください。この情報要素のサイズは3オクテットです。抽象データ型：OctetArrayデータ型セマンティクス：識別子ElementID：73ステータス：現在の参照：RFC 3032を参照。
Description: The Label, Exp, and S fields from the label stack entry that was pushed immediately before the label stack entry that would be reported by mplsLabelStackSection4. See the definition of mplsTopLabelStackSection for further details. The size of this Information Element is 3 octets. Abstract Data Type: octetArray Data Type Semantics: identifier ElementId: 74 Status: current Reference: See RFC 3032.
説明：MPLSLABELSTACKSECTION4によって報告されるラベルスタックエントリの直前にプッシュされたラベルスタックエントリからのラベル、EXP、およびSフィールド。詳細については、mplstoplabelstacksectionの定義を参照してください。この情報要素のサイズは3オクテットです。抽象データ型：OctetArrayデータ型セマンティクス：識別子ElementID：74ステータス：現在の参照：RFC 3032を参照。
Description: The Label, Exp, and S fields from the label stack entry that was pushed immediately before the label stack entry that would be reported by mplsLabelStackSection5. See the definition of mplsTopLabelStackSection for further details. The size of this Information Element is 3 octets. Abstract Data Type: octetArray Data Type Semantics: identifier ElementId: 75 Status: current Reference: See RFC 3032.
説明：MPLSLABELSTACKSECTION5によって報告されるラベルスタックエントリの直前にプッシュされたラベルスタックエントリからのラベル、EXP、およびSフィールド。詳細については、mplstoplabelstacksectionの定義を参照してください。この情報要素のサイズは3オクテットです。抽象データ型：OctetArrayデータ型セマンティクス：識別子ElementID：75ステータス：現在の参照：RFC 3032を参照。
Description: The Label, Exp, and S fields from the label stack entry that was pushed immediately before the label stack entry that would be reported by mplsLabelStackSection6. See the definition of mplsTopLabelStackSection for further details. The size of this Information Element is 3 octets. Abstract Data Type: octetArray Data Type Semantics: identifier ElementId: 76 Status: current Reference: See RFC 3032.
説明：MPLSLABELSTACKSECTION6によって報告されるラベルスタックエントリの直前にプッシュされたラベルスタックエントリからのラベル、EXP、およびSフィールド。詳細については、mplstoplabelstacksectionの定義を参照してください。この情報要素のサイズは3オクテットです。抽象データ型：OctetArrayデータ型セマンティクス：識別子ElementID：76ステータス：現在の参照：RFC 3032を参照してください。
Description: The Label, Exp, and S fields from the label stack entry that was pushed immediately before the label stack entry that would be reported by mplsLabelStackSection7. See the definition of mplsTopLabelStackSection for further details. The size of this Information Element is 3 octets. Abstract Data Type: octetArray Data Type Semantics: identifier ElementId: 77 Status: current Reference: See RFC 3032.
説明：MPLSLABELSTACKSECTION7によって報告されるラベルスタックエントリの直前にプッシュされたラベルスタックエントリからのラベル、EXP、およびSフィールド。詳細については、mplstoplabelstacksectionの定義を参照してください。この情報要素のサイズは3オクテットです。抽象データ型：OctetArrayデータ型セマンティクス：識別子ElementID：77ステータス：現在の参照：RFC 3032を参照。
Description: The Label, Exp, and S fields from the label stack entry that was pushed immediately before the label stack entry that would be reported by mplsLabelStackSection8. See the definition of mplsTopLabelStackSection for further details. The size of this Information Element is 3 octets. Abstract Data Type: octetArray Data Type Semantics: identifier ElementId: 78 Status: current Reference: See RFC 3032.
説明：MPLSLabelStackSection8によって報告されるラベルスタックエントリの直前にプッシュされたラベルスタックエントリからのラベル、EXP、およびSフィールド。詳細については、mplstoplabelstacksectionの定義を参照してください。この情報要素のサイズは3オクテットです。抽象データ型：OctetArrayデータ型セマンティクス：識別子ElementID：78ステータス：現在の参照：RFC 3032を参照。
Description: The Label, Exp, and S fields from the label stack entry that was pushed immediately before the label stack entry that would be reported by mplsLabelStackSection9. See the definition of mplsTopLabelStackSection for further details. The size of this Information Element is 3 octets. Abstract Data Type: octetArray Data Type Semantics: identifier ElementId: 79 Status: current Reference: See RFC 3032.
説明：MPLSLabelStackSection9によって報告されるラベルスタックエントリの直前にプッシュされたラベルスタックエントリからのラベル、EXP、およびSフィールド。詳細については、mplstoplabelstacksectionの定義を参照してください。この情報要素のサイズは3オクテットです。抽象データ型：OctetArrayデータ型セマンティクス：識別子ElementID：79ステータス：現在の参照：RFC 3032を参照。
The set of Information Elements derived from packet properties (for example, values of header fields) includes the Information Elements listed in the table below.
パケットプロパティ（たとえば、ヘッダーフィールドの値など）から派生した情報要素のセットには、以下の表にリストされている情報要素が含まれています。
+-----+---------------------------+-----+---------------------------+
| ID | Name | ID | Name |
+-----+---------------------------+-----+---------------------------+
| 204 | ipPayloadLength | 18 | bgpNextHopIPv4Address |
| 15 | ipNextHopIPv4Address | 63 | bgpNextHopIPv6Address |
| 62 | ipNextHopIPv6Address | 46 | mplsTopLabelType |
| 16 | bgpSourceAsNumber | 47 | mplsTopLabelIPv4Address |
| 17 | bgpDestinationAsNumber | 140 | mplsTopLabelIPv6Address |
| 128 | bgpNextAdjacentAsNumber | 90 | mplsVpnRouteDistinguisher |
| 129 | bgpPrevAdjacentAsNumber | | |
+-----+---------------------------+-----+---------------------------+
Description: The effective length of the IP payload. For IPv4 packets, the value of this Information Element is the difference between the total length of the IPv4 packet (as reported by Information Element totalLengthIPv4) and the length of the IPv4 header (as reported by Information Element headerLengthIPv4). For IPv6, the value of the Payload Length field in the IPv6 header is reported except in the case that the value of this field is zero and that there is a valid jumbo payload option. In this case, the value of the Jumbo Payload Length field in the jumbo payload option is reported. Abstract Data Type: unsigned32 ElementId: 204 Status: current Units: octets Reference: See RFC 791 for the specification of IPv4 packets. See RFC 2460 for the specification of the IPv6 payload length. See RFC 2675 for the specification of the IPv6 jumbo payload length.
説明：IPペイロードの有効長。IPv4パケットの場合、この情報要素の値は、IPv4パケットの総長さ（情報要素totallengthipv4によって報告されている）とIPv4ヘッダーの長さ（情報要素headerlengthipv4で報告）の差です。IPv6の場合、このフィールドの値がゼロであり、有効なジャンボペイロードオプションがある場合を除き、IPv6ヘッダーのペイロード長フィールドの値が報告されます。この場合、ジャンボペイロードオプションのジャンボペイロード長さフィールドの値が報告されています。抽象データ型：unsigned32 ElementID：204ステータス：現在の単位：Octetsリファレンス：IPv4パケットの仕様については、RFC 791を参照してください。IPv6ペイロード長の仕様については、RFC 2460を参照してください。IPv6ジャンボペイロード長の仕様については、RFC 2675を参照してください。
Description: The IPv4 address of the next IPv4 hop. Abstract Data Type: ipv4Address Data Type Semantics: identifier ElementId: 15 Status: current
説明：次のIPv4ホップのIPv4アドレス。抽象データ型：IPv4Addressデータ型セマンティクス：識別子ElementID：15ステータス：現在
Description: The IPv6 address of the next IPv6 hop. Abstract Data Type: ipv6Address Data Type Semantics: identifier ElementId: 62 Status: current
説明：次のIPv6ホップのIPv6アドレス。抽象データ型：IPv6Addressデータ型セマンティクス：識別子ElementID：62ステータス：現在
Description: The autonomous system (AS) number of the source IP address. If AS path information for this Flow is only available as an unordered AS set (and not as an ordered AS sequence), then the value of this Information Element is 0. Abstract Data Type: unsigned32 Data Type Semantics: identifier ElementId: 16 Status: current Reference: See RFC 4271 for a description of BGP-4, and see RFC 1930 for the definition of the AS number.
説明：ソースIPアドレスの自律システム（AS）番号。このフローのパス情報が、セットとして順序付けされていない（シーケンスとして順序付けされていない）としてのみ利用可能である場合、この情報要素の値は0です。現在の参照：BGP-4の説明については、RFC 4271を参照してください。AS番号の定義については、RFC 1930を参照してください。
Description: The autonomous system (AS) number of the destination IP address. If AS path information for this Flow is only available as an unordered AS set (and not as an ordered AS sequence), then the value of this Information Element is 0. Abstract Data Type: unsigned32 Data Type Semantics: identifier ElementId: 17 Status: current Reference: See RFC 4271 for a description of BGP-4, and see RFC 1930 for the definition of the AS number.
説明：宛先IPアドレスの自律システム（AS）番号。このフローのパス情報が、セットとして順序付けられていない（シーケンスとして順序付けされていない）としてのみ利用可能である場合、この情報要素の値は0です。現在の参照：BGP-4の説明については、RFC 4271を参照してください。AS番号の定義については、RFC 1930を参照してください。
Description: The autonomous system (AS) number of the first AS in the AS path to the destination IP address. The path is deduced by looking up the destination IP address of the Flow in the BGP routing information base. If AS path information for this Flow is only available as an unordered AS set (and not as an ordered AS sequence), then the value of this Information Element is 0.
説明：宛先IPアドレスへのASパスのように、最初のシステム（AS）の自律システム（AS）数。パスは、BGPルーティング情報ベースのフローの宛先IPアドレスを調べることによって推定されます。このフローのパス情報が、セットとして順序付けされていない（シーケンスとして順序付けされていない）としてのみ利用可能である場合、この情報要素の値は0です。
Abstract Data Type: unsigned32 Data Type Semantics: identifier ElementId: 128 Status: current Reference: See RFC 4271 for a description of BGP-4, and see RFC 1930 for the definition of the AS number.
要約データ型：unsigned32データ型セマンティクス：識別子ElementID：128ステータス：現在の参照：BGP-4の説明については、RFC 4271を参照し、AS番号の定義についてはRFC 1930を参照してください。
Description: The autonomous system (AS) number of the last AS in the AS path from the source IP address. The path is deduced by looking up the source IP address of the Flow in the BGP routing information base. If AS path information for this Flow is only available as an unordered AS set (and not as an ordered AS sequence), then the value of this Information Element is 0. In case of BGP asymmetry, the bgpPrevAdjacentAsNumber might not be able to report the correct value. Abstract Data Type: unsigned32 Data Type Semantics: identifier ElementId: 129 Status: current Reference: See RFC 4271 for a description of BGP-4, and see RFC 1930 for the definition of the AS number.
説明：ソースIPアドレスからのASパスのように、最後の[AS）の自律システム（AS）数。パスは、BGPルーティング情報ベースのフローのソースIPアドレスを調べることによって推定されます。このフローのパス情報が、セットとして順序付けされていない（シーケンスとして順序付けされていない）としてのみ利用可能である場合、この情報要素の値は0です。BGP非対称性の場合、BGPPREVADJACENTASNUMBERは正しい値。要約データ型：unsigned32データ型セマンティクス：識別子ElementID：129ステータス：現在の参照：BGP-4の説明については、RFC 4271を参照し、AS番号の定義についてはRFC 1930を参照してください。
Description: The IPv4 address of the next (adjacent) BGP hop. Abstract Data Type: ipv4Address Data Type Semantics: identifier ElementId: 18 Status: current Reference: See RFC 4271 for a description of BGP-4.
説明：次の（隣接）BGPホップのIPv4アドレス。抽象データ型：IPv4Addressデータ型セマンティクス：識別子ElementID：18ステータス：現在の参照：BGP-4の説明については、RFC 4271を参照してください。
Description: The IPv6 address of the next (adjacent) BGP hop. Abstract Data Type: ipv6Address Data Type Semantics: identifier ElementId: 63 Status: current Reference: See RFC 4271 for a description of BGP-4.
説明：次の（隣接）BGPホップのIPv6アドレス。抽象データ型：IPv6Addressデータ型セマンティクス：識別子ElementID：63ステータス：現在の参照：BGP-4の説明については、RFC 4271を参照してください。
Description: This field identifies the control protocol that allocated the top-of-stack label. Initial values for this field are listed below. Further values may be assigned by IANA in the MPLS label type registry.
説明：このフィールドは、トップオブスタックラベルを割り当てた制御プロトコルを識別します。このフィールドの初期値を以下に示します。MPLSラベルタイプレジストリのIANAによって、さらなる値が割り当てられる場合があります。
- 0x01 TE-MIDPT: Any TE tunnel mid-point or tail label - 0x02 Pseudowire: Any PWE3 or Cisco AToM based label - 0x03 VPN: Any label associated with VPN - 0x04 BGP: Any label associated with BGP or BGP routing - 0x05 LDP: Any label associated with dynamically assigned labels using LDP
- 0x01 TE -MIDPT：任意のTEトンネルミッドポイントまたはテールラベル-0X02 PSEUDOWIRE：任意のPWE3またはCisco Atomベースのラベル-0x03 VPN：VPN -0x04 BGP：BGPまたはBGPルーティングに関連付けられたラベル-0x05LDP：LDPを使用して動的に割り当てられたラベルに関連付けられたラベル
Abstract Data Type: unsigned8 Data Type Semantics: identifier ElementId: 46 Status: current Reference: See RFC 3031 for the MPLS label structure. See RFC 4364 for the association of MPLS labels with Virtual Private Networks (VPNs). See RFC 4271 for BGP and BGP routing. See RFC 5036 for Label Distribution Protocol (LDP). See the list of MPLS label types assigned by IANA at http://www.iana.org/assignments/mpls-label-values.
抽象データ型：unsigned8データ型セマンティクス：識別子ElementID：46ステータス：現在の参照：MPLSラベル構造についてはRFC 3031を参照してください。MPLSラベルと仮想プライベートネットワーク（VPNS）の関連付けについては、RFC 4364を参照してください。BGPおよびBGPルーティングについては、RFC 4271を参照してください。ラベル分布プロトコル（LDP）については、RFC 5036を参照してください。http://www.iana.org/assignments/mpls-label-valuesでIANAが割り当てたMPLSラベルタイプのリストを参照してください。
Description: The IPv4 address of the system that the MPLS top label will cause this Flow to be forwarded to. Abstract Data Type: ipv4Address Data Type Semantics: identifier ElementId: 47 Status: current Reference: See RFC 3031 for the association between MPLS labels and IP addresses.
説明：MPLSトップラベルがこのフローを転送するシステムのIPv4アドレス。抽象データ型：IPv4Addressデータ型セマンティクス：識別子ElementID：47ステータス：現在の参照：MPLSラベルとIPアドレスの関連付けについては、RFC 3031を参照してください。
Description: The IPv6 address of the system that the MPLS top label will cause this Flow to be forwarded to. Abstract Data Type: ipv6Address Data Type Semantics: identifier ElementId: 140 Status: current Reference: See RFC 3031 for the association between MPLS labels and IP addresses.
説明：MPLSトップラベルがこのフローを転送するシステムのIPv6アドレス。抽象データ型：IPv6Addressデータ型セマンティクス：識別子ElementID：140ステータス：現在の参照：MPLSラベルとIPアドレスの関連付けについては、RFC 3031を参照してください。
Description: The value of the VPN route distinguisher of a corresponding entry in a VPN routing and forwarding table. Route distinguisher ensures that the same address can be used in several different MPLS VPNs and that it is possible for BGP to carry several completely different routes to that address, one for each VPN. According to RFC 4364, the size of mplsVpnRouteDistinguisher is 8 octets. However, in RFC 4382 an octet string with flexible length was chosen for representing a VPN route distinguisher by object MplsL3VpnRouteDistinguisher. This choice was made in order to be open to future changes of the size. This idea was adopted when choosing octetArray as abstract data type for this Information Element. The maximum length of this Information Element is 256 octets. Abstract Data Type: octetArray Data Type Semantics: identifier ElementId: 90 Status: current Reference: See RFC 4364 for the specification of the route distinguisher. See RFC 4382 for the specification of the MPLS/BGP Layer 3 Virtual Private Network (VPN) Management Information Base.
説明：VPNルートの値は、VPNルーティングと転送テーブルの対応するエントリを区別します。Route Distinguisherは、いくつかの異なるMPLS VPNで同じアドレスを使用できることを保証し、BGPがそのアドレスにいくつかの完全に異なるルートを運ぶことができることを保証します。RFC 4364によると、MPLSVPNROUTEDISTISTISTISIOMERのサイズは8オクテットです。ただし、RFC 4382では、オブジェクトMPLSL3VPNROUTEDISTINGISIOMERでVPNルートの区別器を表すために、柔軟な長さのOctet Stringが選択されました。この選択は、サイズの将来の変化に開かれるために行われました。このアイデアは、この情報要素の抽象データ型としてOctetArrayを選択する際に採用されました。この情報要素の最大長は256オクテットです。抽象データ型：OctetArrayデータ型セマンティクス：識別子ElementID：90ステータス：現在の参照：ルート違いの仕様については、RFC 4364を参照してください。MPLS/BGPレイヤー3仮想プライベートネットワーク（VPN）管理情報ベースの仕様については、RFC 4382を参照してください。
Information Elements in this section are results of minimum or maximum operations over all packets of a Flow.
このセクションの情報要素は、フローのすべてのパケットにおける最小または最大操作の結果です。
+-----+---------------------------+-----+---------------------------+
| ID | Name | ID | Name |
+-----+---------------------------+-----+---------------------------+
| 25 | minimumIpTotalLength | 208 | ipv4Options |
| 26 | maximumIpTotalLength | 64 | ipv6ExtensionHeaders |
| 52 | minimumTTL | 6 | tcpControlBits |
| 53 | maximumTTL | 209 | tcpOptions |
+-----+---------------------------+-----+---------------------------+
Description: Length of the smallest packet observed for this Flow. The packet length includes the IP header(s) length and the IP payload length. Abstract Data Type: unsigned64 ElementId: 25 Status: current Units: octets Reference: See RFC 791 for the specification of the IPv4 total length. See RFC 2460 for the specification of the IPv6 payload length. See RFC 2675 for the specification of the IPv6 jumbo payload length.
説明：このフローで観察された最小のパケットの長さ。パケットの長さには、IPヘッダーの長さとIPペイロード長が含まれます。抽象データ型：unsigned64 ElementID：25ステータス：現在の単位：オクテットリファレンス：IPv4の合計長の仕様については、RFC 791を参照してください。IPv6ペイロード長の仕様については、RFC 2460を参照してください。IPv6ジャンボペイロード長の仕様については、RFC 2675を参照してください。
Description: Length of the largest packet observed for this Flow. The packet length includes the IP header(s) length and the IP payload length. Abstract Data Type: unsigned64 ElementId: 26 Status: current Units: octets Reference: See RFC 791 for the specification of the IPv4 total length. See RFC 2460 for the specification of the IPv6 payload length. See RFC 2675 for the specification of the IPv6 jumbo payload length.
説明：このフローで観察された最大のパケットの長さ。パケットの長さには、IPヘッダーの長さとIPペイロード長が含まれます。抽象データ型：unsigned64 ElementID：26ステータス：現在の単位：オクテットリファレンス：IPv4の合計長の仕様については、RFC 791を参照してください。IPv6ペイロード長の仕様については、RFC 2460を参照してください。IPv6ジャンボペイロード長の仕様については、RFC 2675を参照してください。
Description: Minimum TTL value observed for any packet in this Flow.
説明：このフローのパケットで観察される最小TTL値。
Abstract Data Type: unsigned8 ElementId: 52 Status: current Units: hops Reference: See RFC 791 for the definition of the IPv4 Time to Live field. See RFC 2460 for the definition of the IPv6 Hop Limit field.
抽象データ型：Unsigned8 ElementID：52ステータス：現在の単位：ホップリファレンス：LiveフィールドへのIPv4時間の定義については、RFC 791を参照してください。IPv6ホップリミットフィールドの定義については、RFC 2460を参照してください。
Description: Maximum TTL value observed for any packet in this Flow. Abstract Data Type: unsigned8 ElementId: 53 Status: current Units: hops Reference: See RFC 791 for the definition of the IPv4 Time to Live field. See RFC 2460 for the definition of the IPv6 Hop Limit field.
説明：このフローのパケットで観察される最大TTL値。抽象データ型：Unsigned8 ElementID：53ステータス：現在の単位：ホップリファレンス：LiveフィールドへのIPv4時間の定義については、RFC 791を参照してください。IPv6ホップリミットフィールドの定義については、RFC 2460を参照してください。
Description: IPv4 options in packets of this Flow. The information is encoded in a set of bit fields. For each valid IPv4 option type, there is a bit in this set. The bit is set to 1 if any observed packet of this Flow contains the corresponding IPv4 option type. Otherwise, if no observed packet of this Flow contained the respective IPv4 option type, the value of the corresponding bit is 0. The list of valid IPv4 options is maintained by IANA. Note that for identifying an option not just the 5-bit Option Number, but all 8 bits of the Option Type need to match one of the IPv4 options specified at http://www.iana.org/assignments/ip-parameters. Options are mapped to bits according to their option numbers. Option number X is mapped to bit X. The mapping is illustrated by the figure below.
説明：このフローのパケット内のIPv4オプション。情報は、ビットフィールドのセットでエンコードされています。有効なIPv4オプションタイプごとに、このセットには少しあります。このフローの観察されたパケットに対応するIPv4オプションタイプが含まれている場合、ビットは1に設定されます。それ以外の場合、このフローの観察されたパケットにそれぞれのIPv4オプションタイプが含まれていない場合、対応するビットの値は0です。有効なIPv4オプションのリストはIANAによって維持されます。5ビットオプション番号だけでなく、オプションタイプの8ビットすべてがhttp://www.iana.org/assignments/ip-parametersで指定されたIPv4オプションのいずれかを一致させる必要があることに注意してください。オプションは、オプション番号に従ってビットにマッピングされます。オプション番号xはビットxにマッピングされます。マッピングは、下の図に示されています。
0 1 2 3 4 5 6 7
+------+------+------+------+------+------+------+------+
| EOOL | NOP | SEC | LSR | TS |E-SEC |CIPSO | RR | ...
+------+------+------+------+------+------+------+------+
8 9 10 11 12 13 14 15
+------+------+------+------+------+------+------+------+
... | SID | SSR | ZSU | MTUP | MTUR | FINN | VISA |ENCODE| ...
+------+------+------+------+------+------+------+------+
16 17 18 19 20 21 22 23
16 17 18 19 20 21 22 23
+------+------+------+------+------+------+------+------+
... |IMITD | EIP | TR |ADDEXT|RTRALT| SDB |NSAPA | DPS | ...
+------+------+------+------+------+------+------+------+
24 25 26 27 28 29 30 31
+------+------+------+------+------+------+------+------+
... | UMP | QS | to be assigned by IANA | EXP | |
+------+------+------+------+------+------+------+------+
Type Option
Bit Value Name Reference
---+-----+-------+------------------------------------
0 0 EOOL End of Options List, RFC 791
1 1 NOP No Operation, RFC 791
2 130 SEC Security, RFC 1108
3 131 LSR Loose Source Route, RFC 791
4 68 TS Time Stamp, RFC 791
5 133 E-SEC Extended Security, RFC 1108
6 134 CIPSO Commercial Security
7 7 RR Record Route, RFC 791
8 136 SID Stream ID, RFC 791
9 137 SSR Strict Source Route, RFC 791
10 10 ZSU Experimental Measurement
11 11 MTUP (obsoleted) MTU Probe, RFC 1191
12 12 MTUR (obsoleted) MTU Reply, RFC 1191
13 205 FINN Experimental Flow Control
14 142 VISA Experimental Access Control
15 15 ENCODE
16 144 IMITD IMI Traffic Descriptor
17 145 EIP Extended Internet Protocol, RFC 1385
18 82 TR Traceroute, RFC 3193
19 147 ADDEXT Address Extension
20 148 RTRALT Router Alert, RFC 2113
21 149 SDB Selective Directed Broadcast
22 150 NSAPA NSAP Address
23 151 DPS Dynamic Packet State
24 152 UMP Upstream Multicast Pkt.
25 25 QS Quick-Start
30 30 EXP RFC3692-style Experiment
30 94 EXP RFC3692-style Experiment
30 158 EXP RFC3692-style Experiment
30 222 EXP RFC3692-style Experiment
... ... ... Further options numbers
may be assigned by IANA
Abstract Data Type: unsigned32 Data Type Semantics: flags ElementId: 208 Status: current Reference: See RFC 791 for the definition of IPv4 options. See the list of IPv4 option numbers assigned by IANA at http://www.iana.org/assignments/ip-parameters.
抽象データ型：unsigned32データ型セマンティクス：Flags ElementID：208ステータス：現在の参照：IPv4オプションの定義については、RFC 791を参照してください。http://www.iana.org/assignments/ip-parametersでIANAが割り当てたIPv4オプション番号のリストを参照してください。
Description: IPv6 extension headers observed in packets of this Flow. The information is encoded in a set of bit fields. For each IPv6 option header, there is a bit in this set. The bit is set to 1 if any observed packet of this Flow contains the corresponding IPv6 extension header. Otherwise, if no observed packet of this Flow contained the respective IPv6 extension header, the value of the corresponding bit is 0.
説明：このフローのパケットで観察されたIPv6拡張ヘッダー。情報は、ビットフィールドのセットでエンコードされています。各IPv6オプションヘッダーについて、このセットには少しあります。このフローの観察されたパケットに対応するIPv6拡張ヘッダーが含まれている場合、ビットは1に設定されます。それ以外の場合、このフローの観察されたパケットにそれぞれのIPv6拡張ヘッダーが含まれていない場合、対応するビットの値は0です。
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| Res | FRA1| RH | FRA0| UNK | Res | HOP | DST | ...
+-----+-----+-----+-----+-----+-----+-----+-----+
8 9 10 11 12 13 14 15
+-----+-----+-----+-----+-----+-----+-----+-----+
... | PAY | AH | ESP | Reserved | ...
+-----+-----+-----+-----+-----+-----+-----+-----+
16 17 18 19 20 21 22 23
+-----+-----+-----+-----+-----+-----+-----+-----+
... | Reserved | ...
+-----+-----+-----+-----+-----+-----+-----+-----+
24 25 26 27 28 29 30 31
+-----+-----+-----+-----+-----+-----+-----+-----+
... | Reserved |
+-----+-----+-----+-----+-----+-----+-----+-----+
Bit IPv6 Option Description
ビットIPv6オプション説明
0, Res Reserved
1, FRA1 44 Fragmentation header - not first fragment
2, RH 43 Routing header
3, FRA0 44 Fragment header - first fragment
4, UNK Unknown Layer 4 header
(compressed, encrypted, not supported)
5, Res Reserved
6, HOP 0 Hop-by-hop option header
7, DST 60 Destination option header
8, PAY 108 Payload compression header
9, AH 51 Authentication Header
10, ESP 50 Encrypted security payload
11 to 31 Reserved
Abstract Data Type: unsigned32 Data Type Semantics: flags ElementId: 64 Status: current Reference: See RFC 2460 for the general definition of IPv6 extension headers and for the specification of the hop-by-hop options header, the routing header, the fragment header, and the destination options header. See RFC 4302 for the specification of the authentication header. See RFC 4303 for the specification of the encapsulating security payload.
抽象データ型：unsigned32データ型セマンティクス：Flags ElementID：64ステータス：現在の参照：IPv6拡張ヘッダーの一般的な定義、およびホップバイホップオプションヘッダー、ルーティングヘッダー、フラグメントヘッダーの仕様については、RFC 2460を参照してください、および宛先オプションヘッダー。認証ヘッダーの仕様については、RFC 4302を参照してください。カプセル化セキュリティペイロードの仕様については、RFC 4303を参照してください。
Description: TCP control bits observed for packets of this Flow. The information is encoded in a set of bit fields. For each TCP control bit, there is a bit in this set. A bit is set to 1 if any observed packet of this Flow has the corresponding TCP control bit set to 1. A value of 0 for a bit indicates that the corresponding bit was not set in any of the observed packets of this Flow.
説明：このフローのパケットに対して観察されたTCP制御ビット。情報は、ビットフィールドのセットでエンコードされています。TCPコントロールビットごとに、このセットには少しあります。このフローの観測されたパケットが対応するTCPコントロールビットが1に設定されている場合、ビットは1に設定されます。少しの値は、このフローの観測されたパケットのいずれにも対応するビットが設定されていないことを示します。
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| Reserved | URG | ACK | PSH | RST | SYN | FIN |
+-----+-----+-----+-----+-----+-----+-----+-----+
Reserved: Reserved for future use by TCP. Must be zero. URG: Urgent Pointer field significant ACK: Acknowledgment field significant PSH: Push Function RST: Reset the connection SYN: Synchronize sequence numbers FIN: No more data from sender
予約済み：TCPによる将来の使用のために予約されています。ゼロでなければなりません。URG：緊急ポインターフィールド重要なACK：謝辞フィールド重要なPSH：プッシュ関数RST：接続のリセットSyn：シーケンス番号の同期FIN：送信者からのデータはありません
Abstract Data Type: unsigned8 Data Type Semantics: flags ElementId: 6 Status: current Reference: See RFC 793 for the definition of the TCP control bits in the TCP header.
抽象データ型：Unsigned8データ型セマンティクス：Flags ElementID：6ステータス：現在の参照：TCPヘッダーのTCPコントロールビットの定義については、RFC 793を参照してください。
Description: TCP options in packets of this Flow. The information is encoded in a set of bit fields. For each TCP option, there is a bit in this set. The bit is set to 1 if any observed packet of this Flow contains the corresponding TCP option. Otherwise, if no observed packet of this Flow contained the respective TCP option, the value of the corresponding bit is 0. Options are mapped to bits according to their option numbers. Option number X is mapped to bit X. TCP option numbers are maintained by IANA.
説明：このフローのパケット内のTCPオプション。情報は、ビットフィールドのセットでエンコードされています。各TCPオプションについて、このセットには少しあります。このフローの観察されたパケットに対応するTCPオプションが含まれている場合、ビットは1に設定されます。それ以外の場合、このフローの観察されたパケットにそれぞれのTCPオプションが含まれていない場合、対応するビットの値は0です。オプションは、オプション番号に従ってビットにマッピングされます。オプション番号XはビットXにマッピングされます。TCPオプション番号はIANAによって維持されます。
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+
8 9 10 11 12 13 14 15
+-----+-----+-----+-----+-----+-----+-----+-----+
... | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 |...
+-----+-----+-----+-----+-----+-----+-----+-----+
16 17 18 19 20 21 22 23
+-----+-----+-----+-----+-----+-----+-----+-----+
... | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 |...
+-----+-----+-----+-----+-----+-----+-----+-----+
. . .
。。。
56 57 58 59 60 61 62 63
+-----+-----+-----+-----+-----+-----+-----+-----+
... | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 |
+-----+-----+-----+-----+-----+-----+-----+-----+
Abstract Data Type: unsigned64 Data Type Semantics: flags ElementId: 209 Status: current Reference: See RFC 793 for the definition of TCP options. See the list of TCP option numbers assigned by IANA at http://www.iana.org/assignments/tcp-parameters.
抽象データ型：unsigned64データ型セマンティクス：Flags ElementID：209ステータス：現在の参照：TCPオプションの定義についてはRFC 793を参照してください。http://www.iana.org/assignments/tcp-parametersでIANAが割り当てたTCPオプション番号のリストを参照してください。
Information Elements in this section are timestamps of events.
このセクションの情報要素は、イベントのタイムスタンプです。
Timestamps flowStartSeconds, flowEndSeconds, flowStartMilliseconds, flowEndMilliseconds, flowStartMicroseconds, flowEndMicroseconds, flowStartNanoseconds, flowEndNanoseconds, and systemInitTimeMilliseconds are absolute and have a well-defined fixed time base, such as, for example, the number of seconds since 0000 UTC Jan 1st 1970.
タイムスタンプフロースタートセカンド、FlowEndSeconds、Flow-StartMilliseConds、FlowEndMilliseConds、FlowStartMicroSeconds、FlowEndMicroSeconds、FlowStartNanOSeconds、FlowEndnanAnoSoconds、およびSystemInitItimemillisecondsは、絶対に定義された時間を設定しています。
Timestamps flowStartDeltaMicroseconds and flowEndDeltaMicroseconds are relative timestamps only valid within the scope of a single IPFIX Message. They contain the negative time offsets relative to the export time specified in the IPFIX Message Header. The maximum time offset that can be encoded by these delta counters is 1 hour, 11 minutes, and 34.967295 seconds.
タイムスタンプFlowStartDeltamicroSecondsおよびFlowEndDeltamicroSecondsは、単一のIPFIXメッセージの範囲内でのみ有効な相対的なタイムスタンプです。IPFIXメッセージヘッダーで指定されたエクスポート時間に対する負のタイムオフセットが含まれています。これらのデルタカウンターによってエンコードできる最大タイムオフセットは、1時間11分、34.967295秒です。
Timestamps flowStartSysUpTime and flowEndSysUpTime are relative timestamps indicating the time relative to the last (re-)initialization of the IPFIX Device. For reporting the time of the last (re-)initialization, systemInitTimeMilliseconds can be reported, for example, in Data Records defined by Option Templates.
タイムスタンプFlow-StartSysuptimeとFlowEndSuptimeは、IPFIXデバイスの最後（再）の初期化に関連する時間を示す相対的なタイムスタンプです。最後の（再）初期化の時間を報告するために、たとえば、オプションテンプレートで定義されたデータレコードでSystemInittimemillisecondsを報告できます。
+-----+---------------------------+-----+---------------------------+
| ID | Name | ID | Name |
+-----+---------------------------+-----+---------------------------+
| 150 | flowStartSeconds | 156 | flowStartNanoseconds |
| 151 | flowEndSeconds | 157 | flowEndNanoseconds |
| 152 | flowStartMilliseconds | 158 | flowStartDeltaMicroseconds|
| 153 | flowEndMilliseconds | 159 | flowEndDeltaMicroseconds |
| 154 | flowStartMicroseconds | 160 | systemInitTimeMilliseconds|
| 155 | flowEndMicroseconds | 22 | flowStartSysUpTime |
| | | 21 | flowEndSysUpTime |
+-----+---------------------------+-----+---------------------------+
Description: The absolute timestamp of the first packet of this Flow. Abstract Data Type: dateTimeSeconds ElementId: 150 Status: current Units: seconds
説明：このフローの最初のパケットの絶対的なタイムスタンプ。抽象データ型：DateTimeseConds ElementID：150ステータス：現在の単位：秒
Description: The absolute timestamp of the last packet of this Flow. Abstract Data Type: dateTimeSeconds ElementId: 151 Status: current Units: seconds
説明：このフローの最後のパケットの絶対的なタイムスタンプ。抽象データ型：DateTimeseConds ElementID：151ステータス：現在の単位：秒
Description: The absolute timestamp of the first packet of this Flow. Abstract Data Type: dateTimeMilliseconds ElementId: 152 Status: current Units: milliseconds
説明：このフローの最初のパケットの絶対的なタイムスタンプ。抽象データ型：DateTimeMilliseConds ElementID：152ステータス：現在の単位：ミリ秒
Description: The absolute timestamp of the last packet of this Flow. Abstract Data Type: dateTimeMilliseconds ElementId: 153 Status: current Units: milliseconds
説明：このフローの最後のパケットの絶対的なタイムスタンプ。抽象データ型：DateTimeMilliseConds ElementID：153ステータス：現在の単位：ミリ秒
Description: The absolute timestamp of the first packet of this Flow. Abstract Data Type: dateTimeMicroseconds ElementId: 154 Status: current Units: microseconds
説明：このフローの最初のパケットの絶対的なタイムスタンプ。抽象データ型：DateTimemicRoseconds ElementID：154ステータス：現在の単位：マイクロ秒
Description: The absolute timestamp of the last packet of this Flow. Abstract Data Type: dateTimeMicroseconds ElementId: 155 Status: current Units: microseconds
説明：このフローの最後のパケットの絶対的なタイムスタンプ。抽象データ型：DateTimemicRoseconds ElementID：155ステータス：現在の単位：マイクロ秒
Description: The absolute timestamp of the first packet of this Flow. Abstract Data Type: dateTimeNanoseconds ElementId: 156 Status: current Units: nanoseconds
Description: The absolute timestamp of the last packet of this Flow. Abstract Data Type: dateTimeNanoseconds ElementId: 157 Status: current Units: nanoseconds
説明：このフローの最後のパケットの絶対的なタイムスタンプ。抽象データ型：DateTimenanAneconds ElementID：157ステータス：現在の単位：NanSoconds
Description: This is a relative timestamp only valid within the scope of a single IPFIX Message. It contains the negative time offset of the first observed packet of this Flow relative to the export time specified in the IPFIX Message Header. Abstract Data Type: unsigned32 ElementId: 158 Status: current Units: microseconds Reference: See the IPFIX protocol specification [RFC5101] for the definition of the IPFIX Message Header.
説明：これは、単一のIPFIXメッセージの範囲内でのみ有効な相対的なタイムスタンプです。IPFIXメッセージヘッダーで指定されたエクスポート時間と比較して、このフローの最初に観測されたパケットの負のタイムオフセットが含まれています。要約データ型：unsigned32 elementID：158ステータス：現在の単位：マイクロ秒秒参照：IPFIXメッセージヘッダーの定義については、IPFIXプロトコル仕様[RFC5101]を参照してください。
Description: This is a relative timestamp only valid within the scope of a single IPFIX Message. It contains the negative time offset of the last observed packet of this Flow relative to the export time specified in the IPFIX Message Header. Abstract Data Type: unsigned32 ElementId: 159 Status: current Units: microseconds Reference: See the IPFIX protocol specification [RFC5101] for the definition of the IPFIX Message Header.
説明：これは、単一のIPFIXメッセージの範囲内でのみ有効な相対的なタイムスタンプです。IPFIXメッセージヘッダーで指定されたエクスポート時間と比較して、このフローの最後に観察されたパケットの負のタイムオフセットが含まれています。要約データ型：unsigned32 elementID：159ステータス：現在の単位：マイクロ秒秒参照：IPFIXメッセージヘッダーの定義については、IPFIXプロトコル仕様[RFC5101]を参照してください。
Description: The absolute timestamp of the last (re-)initialization of the IPFIX Device. Abstract Data Type: dateTimeMilliseconds ElementId: 160 Status: current Units: milliseconds
説明：IPFIXデバイスの最後（再）初期化の絶対タイムスタンプ。抽象データタイプ：DateTimeMilliseConds ElementID：160ステータス：現在の単位：ミリ秒
Description: The relative timestamp of the first packet of this Flow. It indicates the number of milliseconds since the last (re-)initialization of the IPFIX Device (sysUpTime). Abstract Data Type: unsigned32 ElementId: 22 Status: current Units: milliseconds
説明：このフローの最初のパケットの相対的なタイムスタンプ。IPFIXデバイス（sysuptime）の最後（再）初期化以降のミリ秒数を示します。要約データ型：unsigned32 elementID：22ステータス：現在の単位：ミリ秒
Description: The relative timestamp of the last packet of this Flow. It indicates the number of milliseconds since the last (re-)initialization of the IPFIX Device (sysUpTime). Abstract Data Type: unsigned32 ElementId: 21 Status: current Units: milliseconds
説明：このフローの最後のパケットの相対的なタイムスタンプ。IPFIXデバイス（sysuptime）の最後（再）初期化以降のミリ秒数を示します。抽象データ型：unsigned32 elementid：21ステータス：現在の単位：ミリ秒
Information Elements in this section are counters all having integer values. Their values may change for every report they are used in. They cannot serve as part of a Flow Key used for mapping packets to Flows. However, potentially they can be used for selecting exported Flows, for example, by only exporting Flows with more than a threshold number of observed octets.
このセクションの情報要素は、すべてのカウンターであり、整数値を持っています。それらの値は、使用されているすべてのレポートに対して変更される場合があります。それらは、パケットをマッピングするために使用されるフローキーの一部として機能することはできません。ただし、たとえば、観測されたオクテットのしきい値以上のエクスポートフローのみを使用することにより、エクスポートされたフローの選択に使用できます。
There are running counters and delta counters. Delta counters are reset to zero each time their values are exported. Running counters continue counting independently of the Exporting Process.
実行中のカウンターとデルタカウンターがあります。デルタカウンターは、値がエクスポートされるたびにゼロにリセットされます。ランニングカウンターは、エクスポートプロセスとは独立してカウントを継続します。
There are per-Flow counters and counters related to the Metering Process and/or the Exporting Process. Per-Flow counters are Flow properties that potentially change each time a packet belonging to the Flow is observed. The set of per-Flow counters includes the Information Elements listed in the table below. Counters related to the Metering Process and/or the Exporting Process are described in Section 5.3.
計量プロセスおよび/またはエクスポートプロセスに関連するフローごとのカウンターとカウンターがあります。流量カウンターは、フローに属するパケットが観察されるたびに潜在的に変化するフロープロパティです。一流のカウンターのセットには、以下の表にリストされている情報要素が含まれています。計量プロセスおよび/またはエクスポートプロセスに関連するカウンターについては、セクション5.3で説明します。
+-----+---------------------------+-----+---------------------------+
| ID | Name | ID | Name |
+-----+---------------------------+-----+---------------------------+
| 1 | octetDeltaCount | 134 | droppedOctetTotalCount |
| 23 | postOctetDeltaCount | 135 | droppedPacketTotalCount |
| 198 | octetDeltaSumOfSquares | 19 | postMCastPacketDeltaCount |
| 85 | octetTotalCount | 20 | postMCastOctetDeltaCount |
| 171 | postOctetTotalCount | 174 | postMCastPacketTotalCount |
| 199 | octetTotalSumOfSquares | 175 | postMCastOctetTotalCount |
| 2 | packetDeltaCount | 218 | tcpSynTotalCount |
| 24 | postPacketDeltaCount | 219 | tcpFinTotalCount |
| 86 | packetTotalCount | 220 | tcpRstTotalCount |
| 172 | postPacketTotalCount | 221 | tcpPshTotalCount |
| 132 | droppedOctetDeltaCount | 222 | tcpAckTotalCount |
| 133 | droppedPacketDeltaCount | 223 | tcpUrgTotalCount |
+-----+---------------------------+-----+---------------------------+
Description: The number of octets since the previous report (if any) in incoming packets for this Flow at the Observation Point. The number of octets includes IP header(s) and IP payload. Abstract Data Type: unsigned64 Data Type Semantics: deltaCounter ElementId: 1 Status: current Units: octets
説明：観測点でのこのフローの入ってくるパケットの前のレポート（ある場合）以降のオクテットの数。オクテットの数には、IPヘッダーとIPペイロードが含まれます。抽象データ型：unsigned64データ型セマンティクス：Deltacounter ElementID：1ステータス：現在の単位：オクテット
Description: The definition of this Information Element is identical to the definition of Information Element 'octetDeltaCount', except that it reports a potentially modified value caused by a middlebox function after the packet passed the Observation Point. Abstract Data Type: unsigned64 Data Type Semantics: deltaCounter ElementId: 23 Status: current Units: octets
説明：この情報要素の定義は、パケットが観測ポイントを通過した後にミドルボックス関数によって引き起こされる潜在的に変更された値を報告することを除いて、情報要素「OctetDeltacount」の定義と同一です。抽象データ型：unsigned64データ型セマンティクス：Deltacounter ElementID：23ステータス：現在の単位：オクテット
Description: The sum of the squared numbers of octets per incoming packet since the previous report (if any) for this Flow at the Observation Point. The number of octets includes IP header(s) and IP payload. Abstract Data Type: unsigned64 ElementId: 198 Status: current
説明：観測点でのこのフローの前のレポート（ある場合）以降、着信パケットあたりのオクテットの2乗の合計。オクテットの数には、IPヘッダーとIPペイロードが含まれます。抽象データ型：unsigned64 ElementID：198ステータス：現在
Description: The total number of octets in incoming packets for this Flow at the Observation Point since the Metering Process (re-)initialization for this Observation Point. The number of octets includes IP header(s) and IP payload. Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: 85 Status: current Units: octets
説明：この観測点の計量プロセス（再）初期化以降の観測点でのこのフローの着信パケットのオクテットの総数。オクテットの数には、IPヘッダーとIPペイロードが含まれます。抽象データ型：unsigned64データ型セマンティクス：TotalCounter ElementID：85ステータス：現在の単位：オクテット
Description: The definition of this Information Element is identical to the definition of Information Element 'octetTotalCount', except that it reports a potentially modified value caused by a middlebox function after the packet passed the Observation Point. Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: 171 Status: current Units: octets
説明：この情報要素の定義は、パケットが観測ポイントを通過した後のミドルボックス関数によって引き起こされる潜在的に変更された値を報告することを除いて、情報要素の「octettotalcount」の定義と同一です。要約データ型：unsigned64データ型セマンティクス：TotalCounter ElementID：171ステータス：現在の単位：オクテット
Description: The total sum of the squared numbers of octets in incoming packets for this Flow at the Observation Point since the Metering Process (re-)initialization for this Observation Point. The number of octets includes IP header(s) and IP payload. Abstract Data Type: unsigned64 ElementId: 199 Status: current Units: octets
説明：この観測点の計量プロセス（再）初期化以来、このフローの入っているパケットのオクテットの2乗オクテット数の合計。オクテットの数には、IPヘッダーとIPペイロードが含まれます。抽象データ型：unsigned64 elementid：199ステータス：現在の単位：オクテット
Description: The number of incoming packets since the previous report (if any) for this Flow at the Observation Point.
説明：観測点でのこのフローの前のレポート（ある場合）以降の着信パケットの数。
Abstract Data Type: unsigned64 Data Type Semantics: deltaCounter ElementId: 2 Status: current Units: packets
抽象データ型：unsigned64データ型セマンティクス：Deltacounter ElementID：2ステータス：現在の単位：パケット
Description: The definition of this Information Element is identical to the definition of Information Element 'packetDeltaCount', except that it reports a potentially modified value caused by a middlebox function after the packet passed the Observation Point. Abstract Data Type: unsigned64 Data Type Semantics: deltaCounter ElementId: 24 Status: current Units: packets
説明：この情報要素の定義は、パケットが観測点を通過した後に中間ボックス関数によって引き起こされる潜在的に変更された値を報告することを除いて、情報要素「packetdeltacount」の定義と同一です。抽象データ型：unsigned64データ型セマンティクス：Deltacounter ElementID：24ステータス：現在の単位：パケット
Description: The total number of incoming packets for this Flow at the Observation Point since the Metering Process (re-)initialization for this Observation Point. Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: 86 Status: current Units: packets
説明：この観測点の計量プロセス（再）初期化以降の観測点でのこのフローの着信パケットの総数。抽象データ型：unsigned64データ型セマンティクス：TotalCounter ElementID：86ステータス：現在の単位：パケット
Description: The definition of this Information Element is identical to the definition of Information Element 'packetTotalCount', except that it reports a potentially modified value caused by a middlebox function after the packet passed the Observation Point. Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: 172 Status: current Units: packets
説明：この情報要素の定義は、パケットが観測ポイントを通過した後にミドルボックス関数によって引き起こされる潜在的に変更された値を報告することを除いて、情報要素の「packettotalcount」の定義と同一です。抽象データ型：unsigned64データ型セマンティクス：TotalCounter ElementID：172ステータス：現在の単位：パケット
Description: The number of octets since the previous report (if any) in packets of this Flow dropped by packet treatment. The number of octets includes IP header(s) and IP payload. Abstract Data Type: unsigned64 Data Type Semantics: deltaCounter ElementId: 132 Status: current Units: octets
説明：このフローのパケットの前のレポート（ある場合）以降のオクテットの数は、パケット処理によって低下しました。オクテットの数には、IPヘッダーとIPペイロードが含まれます。抽象データ型：unsigned64データ型セマンティクス：Deltacounter ElementID：132ステータス：現在の単位：オクテット
Description: The number of packets since the previous report (if any) of this Flow dropped by packet treatment. Abstract Data Type: unsigned64 Data Type Semantics: deltaCounter ElementId: 133 Status: current Units: packets
説明：このフローの前のレポート（ある場合）以降のパケットの数は、パケット処理によって低下しました。抽象データ型：unsigned64データ型セマンティクス：Deltacounter ElementID：133ステータス：現在の単位：パケット
Description: The total number of octets in packets of this Flow dropped by packet treatment since the Metering Process (re-)initialization for this Observation Point. The number of octets includes IP header(s) and IP payload. Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: 134 Status: current Units: octets
説明：この観測点の計量プロセス（再）初期化以降、このフローのパケットのオクテットの総数はパケット処理によって低下しました。オクテットの数には、IPヘッダーとIPペイロードが含まれます。抽象データ型：unsigned64データ型セマンティクス：TotalCounter ElementID：134ステータス：現在の単位：オクテット
Description: The number of packets of this Flow dropped by packet treatment since the Metering Process (re-)initialization for this Observation Point. Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: 135 Status: current Units: packets
説明：この観測点の計量プロセス（再）初期化以降、このフローのパケットの数はパケット処理によって低下しました。抽象データ型：unsigned64データ型セマンティクス：TotalCounter ElementID：135ステータス：現在の単位：パケット
Description: The number of outgoing multicast packets since the previous report (if any) sent for packets of this Flow by a multicast daemon within the Observation Domain. This property cannot necessarily be observed at the Observation Point, but may be retrieved by other means. Abstract Data Type: unsigned64 Data Type Semantics: deltaCounter ElementId: 19 Status: current Units: packets
説明：前のレポート（ある場合）が観測ドメイン内のマルチキャストデーモンによってこのフローのパケットを送信してから発信されるマルチキャストパケットの数。この特性は、必ずしも観測点で観察されることはできませんが、他の手段で取得される場合があります。抽象データ型：unsigned64データ型セマンティクス：Deltacounter ElementID：19ステータス：現在の単位：パケット
Description: The number of octets since the previous report (if any) in outgoing multicast packets sent for packets of this Flow by a multicast daemon within the Observation Domain. This property cannot necessarily be observed at the Observation Point, but may be retrieved by other means. The number of octets includes IP header(s) and IP payload. Abstract Data Type: unsigned64 Data Type Semantics: deltaCounter ElementId: 20 Status: current Units: octets
説明：オクテットの数は、観測ドメイン内のマルチキャストデーモンによってこのフローのパケットに送信された発信マルチキャストパケットの前のレポート（ある場合）以降。この特性は、必ずしも観測点で観察されることはできませんが、他の手段で取得される場合があります。オクテットの数には、IPヘッダーとIPペイロードが含まれます。抽象データ型：unsigned64データ型セマンティクス：Deltacounter ElementID：20ステータス：現在の単位：オクテット
Description: The total number of outgoing multicast packets sent for packets of this Flow by a multicast daemon within the Observation Domain since the Metering Process (re-)initialization. This property cannot necessarily be observed at the Observation Point, but may be retrieved by other means. Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: 174 Status: current Units: packets
説明：計量プロセス（再）初期化以降、観測ドメイン内のマルチキャストデーモンによってこのフローのパケットに送信される発信マルチキャストパケットの総数。この特性は、必ずしも観測点で観察されることはできませんが、他の手段で取得される場合があります。抽象データ型：unsigned64データ型セマンティクス：TotalCounter ElementID：174ステータス：現在の単位：パケット
Description: The total number of octets in outgoing multicast packets sent for packets of this Flow by a multicast daemon in the Observation Domain since the Metering Process (re-)initialization. This property cannot necessarily be observed at the Observation Point, but may be retrieved by other means. The number of octets includes IP header(s) and IP payload. Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: 175 Status: current Units: octets
説明：計量プロセス（再）初期化以降、観測ドメインのマルチキャストデーモンによってこのフローのパケットに送信される発信マルチキャストパケットのオクテットの総数。この特性は、必ずしも観測点で観察されることはできませんが、他の手段で取得される場合があります。オクテットの数には、IPヘッダーとIPペイロードが含まれます。抽象データ型：unsigned64データ型セマンティクス：TotalCounter ElementID：175ステータス：現在の単位：オクテット
Description: The total number of packets of this Flow with TCP "Synchronize sequence numbers" (SYN) flag set. Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: 218 Status: current Units: packets Reference: See RFC 793 for the definition of the TCP SYN flag.
説明：TCP「シーケンス番号を同期する」（syn）フラグセットを使用したこのフローのパケットの総数。抽象データ型：unsigned64データ型セマンティクス：TotalCounter ElementID：218ステータス：現在の単位：パケットリファレンス：TCP Synフラグの定義についてはRFC 793を参照してください。
Description: The total number of packets of this Flow with TCP "No more data from sender" (FIN) flag set. Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: 219 Status: current Units: packets Reference: See RFC 793 for the definition of the TCP FIN flag.
説明：TCP「送信者からのデータなし」（FIN）フラグセットを使用したこのフローのパケットの総数。抽象データ型：unsigned64データ型セマンティクス：TotalCounter ElementID：219ステータス：現在の単位：パケットリファレンス：TCP FINフラグの定義についてはRFC 793を参照してください。
Description: The total number of packets of this Flow with TCP "Reset the connection" (RST) flag set. Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: 220 Status: current Units: packets Reference: See RFC 793 for the definition of the TCP RST flag.
説明：TCP「接続をリセットする」（RST）フラグセットを使用したこのフローのパケットの総数。抽象データ型：unsigned64データ型セマンティクス：TotalCounter ElementID：220ステータス：現在の単位：パケットリファレンス：TCP RSTフラグの定義についてはRFC 793を参照してください。
Description: The total number of packets of this Flow with TCP "Push Function" (PSH) flag set. Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: 221 Status: current Units: packets Reference: See RFC 793 for the definition of the TCP PSH flag.
説明：TCP「プッシュ関数」（PSH）フラグセットを使用したこのフローのパケットの総数。要約データ型：unsigned64データ型セマンティクス：TotalCounter ElementID：221ステータス：現在の単位：パケットリファレンス：TCP PSHフラグの定義についてはRFC 793を参照してください。
Description: The total number of packets of this Flow with TCP "Acknowledgment field significant" (ACK) flag set. Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: 222 Status: current Units: packets Reference: See RFC 793 for the definition of the TCP ACK flag.
説明：TCPの「確認フィールドの重要」（ACK）フラグセットを使用したこのフローのパケットの総数。抽象データ型：unsigned64データ型セマンティクス：TotalCounter ElementID：222ステータス：現在の単位：パケットリファレンス：TCP ACKフラグの定義についてはRFC 793を参照してください。
Description: The total number of packets of this Flow with TCP "Urgent Pointer field significant" (URG) flag set. Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: 223 Status: current Units: packets Reference: See RFC 793 for the definition of the TCP URG flag.
説明：TCP「緊急ポインターフィールドが重要」（URG）フラグセットを使用したこのフローのパケットの総数。抽象データ型：unsigned64データ型セマンティクス：TotalCounter ElementID：223ステータス：現在の単位：パケットリファレンス：TCP URGフラグの定義についてはRFC 793を参照してください。
Information Elements in this section describe properties of Flows that are related to Flow start, Flow duration, and Flow termination, but they are not timestamps as the Information Elements in Section 5.9 are.
このセクションの情報要素は、フロースタート、フローの持続時間、およびフロー終了に関連するフローの特性について説明しますが、セクション5.9の情報要素があるようにタイムスタンプではありません。
+-----+---------------------------+-----+---------------------------+
| ID | Name | ID | Name |
+-----+---------------------------+-----+---------------------------+
| 36 | flowActiveTimeout | 161 | flowDurationMilliseconds |
| 37 | flowIdleTimeout | 162 | flowDurationMicroseconds |
| 136 | flowEndReason | 61 | flowDirection |
+-----+---------------------------+-----+---------------------------+
Description: The number of seconds after which an active Flow is timed out anyway, even if there is still a continuous flow of packets. Abstract Data Type: unsigned16 ElementId: 36 Status: current Units: seconds
説明：パケットの連続フローがまだある場合でも、とにかくアクティブなフローがタイムアウトされる秒数。抽象データ型：unsigned16 elementid：36ステータス：現在の単位：秒
Description: A Flow is considered to be timed out if no packets belonging to the Flow have been observed for the number of seconds specified by this field. Abstract Data Type: unsigned16 ElementId: 37 Status: current Units: seconds
説明：フローに属するパケットがこのフィールドで指定された秒数で観察されていない場合、フローはタイムアウトされると見なされます。抽象データ型：unsigned16 elementid：37ステータス：現在の単位：秒
Description: The reason for Flow termination. The range of values includes the following:
説明：フロー終了の理由。値の範囲には、次のものが含まれます。
0x01: idle timeout The Flow was terminated because it was considered to be idle.
0x02: active timeout The Flow was terminated for reporting purposes while it was still active, for example, after the maximum lifetime of unreported Flows was reached.
0x02：アクティブなタイムアウトは、報告目的で終了しましたが、たとえば、報告されていないフローの最大寿命に到達した後、まだアクティブでした。
0x03: end of Flow detected The Flow was terminated because the Metering Process detected signals indicating the end of the Flow, for example, the TCP FIN flag.
0x03：流れの終了は、メータープロセスがTCP FINフラグなどの流れの終了を示す信号を検出したため、流れが終了しました。
0x04: forced end The Flow was terminated because of some external event, for example, a shutdown of the Metering Process initiated by a network management application.
0x04：強制終了は、外部イベント、たとえばネットワーク管理アプリケーションによって開始された計量プロセスのシャットダウンにより、フローが終了しました。
0x05: lack of resources The Flow was terminated because of lack of resources available to the Metering Process and/or the Exporting Process.
0x05：リソースの不足メータープロセスや輸出プロセスに利用可能なリソースが不足しているため、フローは終了しました。
Abstract Data Type: unsigned8 Data Type Semantics: identifier ElementId: 136 Status: current
要約データ型：unsigned8データ型セマンティクス：識別子elementID：136ステータス：現在
Description: The difference in time between the first observed packet of this Flow and the last observed packet of this Flow. Abstract Data Type: unsigned32 ElementId: 161 Status: current Units: milliseconds
説明：このフローの最初に観察されたパケットと、このフローの最後に観察されたパケットの間の時間の違い。要約データ型：unsigned32 elementID：161ステータス：現在の単位：ミリ秒
Description: The difference in time between the first observed packet of this Flow and the last observed packet of this Flow. Abstract Data Type: unsigned32 ElementId: 162 Status: current Units: microseconds
説明：このフローの最初に観察されたパケットと、このフローの最後に観察されたパケットの間の時間の違い。要約データ型：unsigned32 elementID：162ステータス：現在の単位：マイクロ秒秒
Description: The direction of the Flow observed at the Observation Point. There are only two values defined.
説明：観測点で観察された流れの方向。定義された値は2つしかありません。
0x00: ingress flow 0x01: egress flow
0x00：イングレスフロー0x01：出力フロー
Abstract Data Type: unsigned8 Data Type Semantics: identifier ElementId: 61 Status: current
抽象データ型：unsigned8データ型セマンティクス：識別子elementId：61ステータス：現在
This section contains a single Information Element that can be used for padding of Flow Records.
このセクションには、フローレコードのパディングに使用できる単一の情報要素が含まれています。
IPFIX implementations may wish to align Information Elements within Data Records or to align entire Data Records to 4-octet or 8-octet boundaries. This can be achieved by including one or more paddingOctets Information Elements in a Data Record.
IPFIXの実装では、データレコード内の情報要素を調整するか、データレコード全体を4-OCTETまたは8-OCTETの境界に揃えることをお勧めします。これは、データレコードに1つ以上のPadningoctets情報要素を含めることで実現できます。
+-----+---------------------------+-----+---------------------------+
| ID | Name | ID | Name |
+-----+---------------------------+-----+---------------------------+
| 210 | paddingOctets | | |
+-----+---------------------------+-----+---------------------------+
Description: The value of this Information Element is always a sequence of 0x00 values. Abstract Data Type: octetArray ElementId: 210 Status: current
説明：この情報要素の値は、常に0x00値のシーケンスです。抽象データ型：OctetArray ElementID：210ステータス：現在
A key requirement for IPFIX is to allow for extending the set of Information Elements that are reported. This section defines the mechanism for extending this set.
IPFIXの重要な要件は、報告されている情報要素のセットを拡張できるようにすることです。このセクションでは、このセットを拡張するメカニズムを定義します。
Extension can be done by defining new Information Elements. Each new Information Element MUST be assigned a unique Information Element identifier as part of its definition. These unique Information Element identifiers are the connection between the record structure communicated by the protocol using Templates and a consuming application. For generally applicable Information Elements, using IETF and IANA mechanisms to extend the information model is RECOMMENDED.
拡張機能は、新しい情報要素を定義することで実行できます。それぞれの新しい情報要素には、その定義の一部として一意の情報要素識別子を割り当てる必要があります。これらの一意の情報要素識別子は、テンプレートを使用してプロトコルによって伝達されるレコード構造と消費アプリケーション間の接続です。一般的に適用可能な情報要素の場合、IETFおよびIANAメカニズムを使用して情報モデルを拡張することをお勧めします。
Names of new Information Elements SHOULD be chosen according to the naming conventions given in Section 2.3.
新しい情報要素の名前は、セクション2.3に記載されている命名規則に従って選択する必要があります。
For extensions, the type space defined in Section 3 can be used. If required, new abstract data types can be added. New abstract data types MUST be defined in IETF Standards Track documents.
拡張機能の場合、セクション3で定義されているタイプスペースを使用できます。必要に応じて、新しい抽象データ型を追加できます。新しい抽象データ型は、IETF標準の追跡ドキュメントで定義する必要があります。
Enterprises may wish to define Information Elements without registering them with IANA. IPFIX explicitly supports enterprise-specific Information Elements. Enterprise-specific Information Elements are described in Sections 2.1 and 4.
企業は、IANAに登録せずに情報要素を定義したい場合があります。IPFIXは、エンタープライズ固有の情報要素を明示的にサポートしています。エンタープライズ固有の情報要素は、セクション2.1および4で説明されています。
However, before creating enterprise-specific Information Elements, the general applicability of such Information Elements should be considered. IPFIX does not support enterprise-specific abstract data types.
ただし、企業固有の情報要素を作成する前に、そのような情報要素の一般的な適用性を考慮する必要があります。IPFIXは、エンタープライズ固有の抽象データ型をサポートしていません。
This document specifies an initial set of IPFIX Information Elements. The list of these Information Elements with their identifiers is given in Section 4. The Internet Assigned Numbers Authority (IANA) has created a new registry for IPFIX Information Element identifiers and filled it with the initial list in Section 4.
このドキュメントは、IPFIX情報要素の初期セットを指定します。識別子を含むこれらの情報要素のリストは、セクション4に記載されています。インターネットに割り当てられた数字の権限（IANA）は、IPFIX情報要素識別子の新しいレジストリを作成し、セクション4の初期リストに記入しました。
New assignments for IPFIX Information Elements will be administered by IANA through Expert Review [RFC2434], i.e., review by one of a group of experts designated by an IETF Area Director. The group of experts MUST check the requested Information Element for completeness and accuracy of the description and for correct naming according to the naming conventions in Section 2.3. Requests for Information Elements that duplicate the functionality of existing Information Elements SHOULD be declined. The smallest available identifier SHOULD be assigned to a new Information Element.
IPFIX情報要素の新しい課題は、IANAがExpert Review [RFC2434]、つまりIETFエリアディレクターによって指定された専門家グループの1人によるレビューを通じて管理されます。専門家のグループは、要求された情報要素を、説明の完全性と正確性、およびセクション2.3の命名規則に従って正しい命名を確認する必要があります。既存の情報要素の機能を複製する情報要素のリクエストは拒否する必要があります。利用可能な最小の識別子は、新しい情報要素に割り当てる必要があります。
The specification of new IPFIX Information Elements MUST use the template specified in Section 2.1 and MUST be published using a well-established and persistent publication medium. The experts will initially be drawn from the Working Group Chairs and document editors of the IPFIX and PSAMP Working Groups.
新しいIPFIX情報要素の仕様は、セクション2.1で指定されたテンプレートを使用する必要があり、確立された永続的な出版媒体を使用して公開する必要があります。専門家は、最初はIPFIXおよびPSAMPワーキンググループのワーキンググループの椅子と文書編集者から引き出されます。
Information Element #46, named mplsTopLabelType, carries MPLS label types. Values for 5 different types have initially been defined. For ensuring extensibility of this information, IANA has created a new registry for MPLS label types and filled it with the initial list from the description Information Element #46, mplsTopLabelType.
MPLSTOPLABELTYPEという名前の情報要素＃46は、MPLSラベルタイプを運びます。5つの異なるタイプの値が最初に定義されています。この情報の拡張性を確保するために、IANAはMPLSラベルタイプの新しいレジストリを作成し、説明情報要素＃46、MplStoplabelTypeの初期リストに記入しました。
New assignments for MPLS label types will be administered by IANA through Expert Review [RFC2434], i.e., review by one of a group of experts designated by an IETF Area Director. The group of experts must double check the label type definitions with already defined label types for completeness, accuracy, and redundancy. The specification of new MPLS label types MUST be published using a well-established and persistent publication medium.
MPLSラベルタイプの新しい割り当ては、INAがExpert Review [RFC2434]を通じてIANAによって管理されます。つまり、IETFエリアディレクターが指定した専門家グループの1つによってレビューが行われます。専門家のグループは、完全性、正確性、冗長性について、すでに定義されたラベルタイプを使用して、ラベルタイプの定義を再確認する必要があります。新しいMPLSラベルタイプの仕様は、確立された永続的な出版媒体を使用して公開する必要があります。
Appendix B defines an XML schema for IPFIX Information Element definitions. All Information Elements specified in this document are defined by the XML specification in Appendix A that is a valid XML record according to the schema in Appendix B. This schema may also be used for specifying further Information Elements in future extensions of the IPFIX information model in a machine-readable way.
付録Bは、IPFIX情報要素の定義のXMLスキーマを定義しています。このドキュメントで指定されたすべての情報要素は、付録Bのスキーマに従って有効なXMLレコードである付録AのXML仕様で定義されます。このスキーマは、IPFIX情報モデルの将来の拡張の詳細要素を指定するためにも使用できます。機械読み取り可能な方法。
Appendix B uses URNs to describe an XML namespace and an XML schema for IPFIX Information Elements conforming to a registry mechanism described in [RFC3688]. Two URI assignments have been made.
付録Bでは、URNSを使用して、[RFC3688]に記載されているレジストリメカニズムに準拠したIPFIX情報要素のXMLネームスペースとXMLスキーマを説明しています。2つのURI割り当てが行われました。
1. Registration for the IPFIX information model namespace * URI: urn:ietf:params:xml:ns:ipfix-info-15 * Registrant Contact: IETF IPFIX Working Group <ipfix@ietf.org>, as designated by the IESG <iesg@ietf.org>. * XML: None. Namespace URIs do not represent an XML.
1. IPFIX情報モデル名の登録 * uri：urn：ietf：params：xml：ns：ipfix-info-15 *登録者連絡先：ietf ipfixワーキンググループ<ipfix@ietf.org>、iesg <iesg@ietf.org>。* XML：なし。名前空間urisはXMLを表しません。
2. Registration for the IPFIX information model schema * URI: urn:ietf:params:xml:schema:ipfix-info-15 * Registrant Contact: IETF IPFIX Working Group <ipfix@ietf.org>, as designated by the IESG <iesg@ietf.org>. * XML: See Appendix B of this document.
2. IPFIX情報モデルの登録スキーマ * uri：urn：ietf：params：xml：xml：schema：ipfix-info-15 *登録者連絡先：IETF IPFIXワーキンググループ<ipfix@ietf.org>、iesg <iesg@ietf.org>。* XML：このドキュメントの付録Bを参照してください。
The IPFIX information model itself does not directly introduce security issues. Rather, it defines a set of attributes that may for privacy or business issues be considered sensitive information.
IPFIX情報モデル自体は、セキュリティの問題を直接導入しません。むしろ、プライバシーやビジネスの問題のための属性が機密情報と見なされる可能性のある一連の属性を定義します。
For example, exporting values of header fields may make attacks possible for the receiver of this information, which would otherwise only be possible for direct observers of the reported Flows along the data path.
たとえば、ヘッダーフィールドの値のエクスポートは、この情報の受信者に対して攻撃を可能にする可能性があります。これは、データパスに沿った報告されたフローの直接観察者のみが可能になります。
The underlying protocol used to exchange the information described here must therefore apply appropriate procedures to guarantee the integrity and confidentiality of the exported information. Such protocols are defined in separate documents, specifically the IPFIX protocol document [RFC5101].
したがって、ここで説明する情報を交換するために使用される基礎となるプロトコルは、エクスポートされた情報の完全性と機密性を保証するために適切な手順を適用する必要があります。このようなプロトコルは、別々のドキュメント、特にIPFIXプロトコルドキュメント[RFC5101]で定義されています。
This document does not specify any Information Element carrying keying material. If future extensions will do so, then appropriate precautions need to be taken for properly protecting such sensitive information.
このドキュメントでは、キーイン素材を運ぶ情報要素は指定されていません。将来の拡張機能がそうする場合、そのような機密情報を適切に保護するために適切な予防策を講じる必要があります。
The editors thank Paul Callato for creating the initial version of this document, and Thomas Dietz for developing the XSLT scripts that generate large portions of the text part of this document from the XML appendices.
編集者は、このドキュメントの初期バージョンを作成してくれたPaul Callatoと、XML付録からこのドキュメントのテキスト部分の大部分を生成するXSLTスクリプトを開発してくれたThomas Dietzに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC5101] Claise, B., "Specification of the IPFIX Protocol for the Exchange", RFC 5101, January 2008.
[RFC5101] Claise、B。、「ExchangeのIPFIXプロトコルの仕様」、RFC 5101、2008年1月。
[IEEE.754.1985] Institute of Electrical and Electronics Engineers, "Standard for Binary Floating-Point Arithmetic", IEEE Standard 754, August 1985.
[IEEE.754.1985]電気およびエレクトロニクスエンジニアの研究所、「バイナリフローティングポイント算術の標準」、IEEE Standard 754、1985年8月。
[IEEE.802-11.1999] "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications", IEEE Standard 802.11, 1999, <http://standards.ieee.org/getieee802/download/802.11- 1999.pdF>.
[IEEE.802-11.1999] "情報技術 - システム間の通信と情報交換 - ローカルおよびメトロポリタンエリアネットワーク - 特定の要件 - パート11：ワイヤレスLANメディアアクセス制御（MAC）および物理層（PHY）仕様」、IEEE標準802.1111111、1999、<http://standards.ieee.org/getieee802/download/802.11-1999.pdf>。
[IEEE.802-1Q.2003] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks", IEEE Standard 802.1Q, March 2003.
[IEEE.802-1Q.2003]電気およびエレクトロニクスエンジニアの研究所、「ローカルおよびメトロポリタンエリアネットワーク：仮想ブリッジ付きローカルエリアネットワーク」、IEEE Standard 802.1q、2003年3月。
[IEEE.802-3.2002] "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications", IEEE Standard 802.3, September 2002.
[IEEE.802-3.2002]「情報技術 - システム間の通信と情報交換 - ローカルとメトロポリタンのエリアネットワーク - 特定の要件 - パート3：衝突検出による複数アクセス（CSMA/CD）アクセス方法と物理層仕様」IEEE Standard 802.3、2002年9月。
[ISO.10646-1.1993] International Organization for Standardization, "Information Technology - Universal Multiple-octet coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane", ISO Standard 10646-1, May 1993.
[ISO.10646-1.1993]国際標準化機関、「情報技術 - ユニバーサルマルチオクテットコード化された文字セット（UCS） - パート1：アーキテクチャと基本的な多言面」、ISO標準10646-1、1993年5月。
[ISO.646.1991] International Organization for Standardization, "Information technology - ISO 7-bit coded character set for information interchange", ISO Standard 646, 1991.
[ISO.646.1991]国際標準化機関、「情報技術 - 情報交換用のISO 7ビットコード化された文字セット」、ISO Standard 646、1991。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768] Postel、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、1980年8月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC0792] Postel、J。、「インターネット制御メッセージプロトコル」、STD 5、RFC 792、1981年9月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[RFC1108] Kent, S., "U.S. Department of Defense Security Options for the Internet Protocol", RFC 1108, November 1991.
[RFC1108] Kent、S。、「インターネットプロトコルの米国国防総省セキュリティオプション」、RFC 1108、1991年11月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191] Mogul、J。およびS. Deering、「Path MTU Discovery」、RFC 1191、1990年11月。
[RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323] Jacobson、V.、Braden、R。、およびD. Borman、「高性能のためのTCP拡張」、RFC 1323、1992年5月。
[RFC1385] Wang, Z., "EIP: The Extended Internet Protocol", RFC 1385, November 1992.
[RFC1385] Wang、Z。、「EIP：The Extended Internet Protocol」、RFC 1385、1992年11月。
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812] Baker、F.、ed。、「IPバージョン4ルーターの要件」、RFC 1812、1995年6月。
[RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, selection, and registration of an Autonomous System (AS)", BCP 6, RFC 1930, March 1996.
[RFC1930]ホーキンソン、J。およびT.ベイツ、「自律システムの作成、選択、登録に関するガイドライン（AS）」、BCP 6、RFC 1930、1996年3月。
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[RFC2113] Katz、D。、「IPルーターアラートオプション」、RFC 2113、1997年2月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2578] McCloghrie、K.、Perkins、D。、およびJ. Schoenwaelder、「管理情報の構造バージョン2（SMIV2）」、STD 58、RFC 2578、1999年4月。
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999.
[RFC2629] Rose、M。、「XMLを使用したI-DSおよびRFCの書き込み」、RFC 2629、1999年6月。
[RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", RFC 2675, August 1999.
[RFC2675]ボーマン、D。、ディアリング、S。、およびR.ヒンデン、「IPv6ジャンボグラム」、RFC 2675、1999年8月。
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
[RFC2863] McCloghrie、K。およびF. Kastenholz、「The Interfaces Group MIB」、RFC 2863、2000年6月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032] Rosen、E.、Tappan、D.、Fedorkow、G.、Rekhter、Y.、Farinacci、D.、Li、T。、およびA. conta、「Mpls Label Stack ending」、RFC 3032、2001年1月。
[RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth, "Securing L2TP using IPsec", RFC 3193, November 2001.
[RFC3193] Patel、B.、Aboba、B.、Dixon、W.、Zorn、G。、およびS. Booth、「IPSECを使用したL2TPの保護」、RFC 3193、2001年11月。
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
[RFC3234]大工、B。およびS.ブリム、「ミドルボックス：分類法と問題」、RFC 3234、2002年2月。
[RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.
[RFC3260] Grossman、D。、「Diffservの新しい用語と説明」、RFC 3260、2002年4月。
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[RFC3270] Le Faucheur、F.、Wu、L.、Davie、B.、Davari、S.、Vaananen、P.、Krishnan、R.、Cheval、P。、およびJ. Heinanen、「Multi-Protocol Label Switching」（MPLS）差別化されたサービスのサポート」、RFC 3270、2002年5月。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[RFC3376] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、B。、およびA. Thyagarajan、「インターネットグループ管理プロトコル、バージョン3」、RFC 3376、2002年10月。
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, January 2003.
[RFC3444] Pras、A。およびJ. Schoenwaelder、「情報モデルとデータモデルの違いについて」、RFC 3444、2003年1月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export Version 9", RFC 3954, October 2004.
[RFC3954] Claise、B.、ed。、「Cisco Systems Netflow Services Export Version 9」、RFC 3954、2004年10月。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y.、Ed。、Li、T.、ed。、およびS. Hares、ed。、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 4291、2006年2月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302] Kent、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364] Rosen、E。およびY. Rekhter、「BGP/MPLS IP仮想プライベートネットワーク（VPNS）」、RFC 4364、2006年2月。
[RFC4382] Nadeau, T., Ed., and H. van der Linde, Ed., "MPLS/BGP Layer 3 Virtual Private Network (VPN) Management Information Base", RFC 4382, February 2006.
[RFC4382] Nadeau、T.、ed。、およびH. van der Linde、ed。、「MPLS/BGPレイヤー3仮想プライベートネットワーク（VPN）管理情報ベース」、RFC 4382、2006年2月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R.、ed。、「Stream Control Transmission Protocol」、RFC 4960、2007年9月。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
This appendix contains a machine-readable description of the IPFIX information model coded in XML. Note that this appendix is of informational nature, while the text in Section 4 (generated from this appendix) is normative.
この付録には、XMLでコード化されたIPFIX情報モデルの機械読み取り可能な説明が含まれています。この付録は情報性の性質であり、セクション4のテキスト（この付録から生成）は規範的であることに注意してください。
Using a machine-readable syntax for the information model enables the creation of IPFIX-aware tools that can automatically adapt to extensions to the information model, by simply reading updated information model specifications.
The wide availability of XML-aware tools and libraries for client devices is a primary consideration for this choice. In particular, libraries for parsing XML documents are readily available. Also, mechanisms such as the Extensible Stylesheet Language (XSL) allow for transforming a source XML document into other documents. This document was authored in XML and transformed according to [RFC2629].
クライアントデバイス用のXMLアウェアツールとライブラリの幅広い可用性は、この選択の主な考慮事項です。特に、XMLドキュメントを解析するライブラリはすぐに利用できます。また、拡張可能なStyleSheet言語（XSL）などのメカニズムにより、ソースXMLドキュメントを他のドキュメントに変換することができます。このドキュメントはXMLで執筆され、[RFC2629]に従って変換されました。
It should be noted that the use of XML in Exporters, Collectors, or other tools is not mandatory for the deployment of IPFIX. In particular, Exporting Processes do not produce or consume XML as part of their operation. It is expected that IPFIX Collectors MAY take advantage of the machine readability of the information model vs. hard coding their behavior or inventing proprietary means for accommodating extensions.
輸出業者、コレクター、またはその他のツールでのXMLの使用は、IPFIXの展開に必須ではないことに注意する必要があります。特に、エクスポートプロセスでは、操作の一部としてXMLを生成または消費しません。IPFIXコレクターは、情報モデルの機械の読みやすさを利用して、拡張機能に対応するための独自の手段を発明するためのハードコーディングまたは発明されることが期待されています。
<?xml version="1.0" encoding="UTF-8"?>
<fieldDefinitions xmlns="urn:ietf:params:xml:ns:ipfix-info"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:ipfix-info
ipfix-info.xsd">
<field name="lineCardId" dataType="unsigned32"
group="scope"
dataTypeSemantics="identifier"
elementId="141" applicability="option" status="current">
<description>
<paragraph>
An identifier of a line card that is unique per IPFIX
Device hosting an Observation Point. Typically, this
Information Element is used for limiting the scope
of other Information Elements.
</paragraph>
</description>
</field>
<field name="portId" dataType="unsigned32"
group="scope"
dataTypeSemantics="identifier"
elementId="142" applicability="option" status="current">
<description>
<paragraph>
An identifier of a line port that is unique per IPFIX
Device hosting an Observation Point. Typically, this
Information Element is used for limiting the scope
of other Information Elements.
</paragraph>
</description>
</field>
<field name="ingressInterface" dataType="unsigned32"
group="scope"
dataTypeSemantics="identifier"
elementId="10" applicability="all" status="current">
<description>
<paragraph>
The index of the IP interface where packets of this Flow
are being received. The value matches the value of managed
object 'ifIndex' as defined in RFC 2863.
Note that ifIndex values are not assigned statically to an
interface and that the interfaces may be renumbered every
time the device's management system is re-initialized, as
specified in RFC 2863.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 2863 for the definition of the ifIndex object.
</paragraph>
</reference>
</field>
<field name="egressInterface" dataType="unsigned32" group="scope" dataTypeSemantics="identifier" elementId="14" applicability="all" status="current"> <description> <paragraph> The index of the IP interface where packets of this Flow are being sent. The value matches the value of managed object 'ifIndex' as defined in RFC 2863. Note that ifIndex values are not assigned statically to an interface and that the interfaces may be renumbered every time the device's management system is re-initialized, as specified in RFC 2863.
<field name = "gegressInterface" datAtype = "unsigned32" group = "scope" datatypesemantics = "識別子" elementid = "applicability =" all "status =" current "> <説明> <パラグラフ> IPインターフェイスのインデックスこのフローのパケットが送信されている場所。値は、RFC 2863で定義されている管理されたオブジェクト「ifindex」の値と一致します。Ifindex値はインターフェイスに静的に割り当てられておらず、RFCで指定されているように、デバイスの管理システムが再目的化されるたびにインターフェイスを変更することができることに注意してください。2863。
</paragraph>
</description>
<reference>
<paragraph>
See RFC 2863 for the definition of the ifIndex object.
</paragraph>
</reference>
</field>
<field name="meteringProcessId" dataType="unsigned32"
group="scope"
dataTypeSemantics="identifier"
elementId="143" applicability="option" status="current">
<description>
<paragraph>
An identifier of a Metering Process that is unique per
IPFIX Device. Typically, this Information Element is used
for limiting the scope of other Information Elements.
Note that process identifiers are typically assigned
dynamically.
The Metering Process may be re-started with a different ID.
</paragraph>
</description>
</field>
<field name="exportingProcessId" dataType="unsigned32"
group="scope"
dataTypeSemantics="identifier"
elementId="144" applicability="option" status="current">
<description>
<paragraph>
An identifier of an Exporting Process that is unique per
IPFIX Device. Typically, this Information Element is used
for limiting the scope of other Information Elements.
Note that process identifiers are typically assigned
dynamically. The Exporting Process may be re-started
with a different ID.
</paragraph>
</description>
</field>
<field name="flowId" dataType="unsigned64"
group="scope"
dataTypeSemantics="identifier"
elementId="148" applicability="option" status="current">
<description>
<paragraph>
An identifier of a Flow that is unique within an Observation
Domain. This Information Element can be used to distinguish
between different Flows if Flow Keys such as IP addresses and
port numbers are not reported or are reported in separate
records.
</paragraph>
</description>
</field>
<field name="templateId" dataType="unsigned16"
group="scope"
dataTypeSemantics="identifier"
elementId="145" applicability="option" status="current">
<description>
<paragraph>
An identifier of a Template that is locally unique within a
combination of a Transport session and an Observation Domain.
</paragraph>
<paragraph>
Template IDs 0-255 are reserved for Template Sets, Options
Template Sets, and other reserved Sets yet to be created.
Template IDs of Data Sets are numbered from 256 to 65535.
</paragraph>
<paragraph>
Typically, this Information Element is used for limiting
the scope of other Information Elements.
Note that after a re-start of the Exporting Process Template
identifiers may be re-assigned.
</paragraph>
</description>
</field>
<field name="observationDomainId" dataType="unsigned32"
group="scope"
dataTypeSemantics="identifier"
elementId="149" applicability="option" status="current">
<description>
<paragraph>
An identifier of an Observation Domain that is locally
unique to an Exporting Process. The Exporting Process uses
the Observation Domain ID to uniquely identify to the
Collecting Process the Observation Domain where Flows
were metered. It is RECOMMENDED that this identifier is
also unique per IPFIX Device.
</paragraph>
<paragraph>
A value of 0 indicates that no specific Observation Domain
is identified by this Information Element.
</paragraph>
<paragraph>
Typically, this Information Element is used for limiting
the scope of other Information Elements.
</paragraph>
</description>
</field>
<field name="observationPointId" dataType="unsigned32"
group="scope"
dataTypeSemantics="identifier"
elementId="138" applicability="option" status="current">
<description>
<paragraph>
An identifier of an Observation Point that is unique per
Observation Domain. It is RECOMMENDED that this identifier is
also unique per IPFIX Device. Typically, this Information
Element is used for limiting the scope of other Information
Elements.
</paragraph>
</description>
</field>
<field name="commonPropertiesId" dataType="unsigned64"
group="scope"
dataTypeSemantics="identifier"
elementId="137" applicability="option" status="current">
<description>
<paragraph>
An identifier of a set of common properties that is
unique per Observation Domain and Transport Session.
Typically, this Information Element is used to link to
information reported in separate Data Records.
</paragraph>
</description>
</field>
<field name="exporterIPv4Address" dataType="ipv4Address"
dataTypeSemantics="identifier"
group="config"
elementId="130" applicability="all" status="current">
<description>
<paragraph>
The IPv4 address used by the Exporting Process. This is used
by the Collector to identify the Exporter in cases where the
identity of the Exporter may have been obscured by the use of
a proxy.
</paragraph>
</description>
</field>
<field name="exporterIPv6Address" dataType="ipv6Address"
dataTypeSemantics="identifier"
group="config"
elementId="131" applicability="all" status="current">
<description>
<paragraph>
The IPv6 address used by the Exporting Process. This is used
by the Collector to identify the Exporter in cases where the
identity of the Exporter may have been obscured by the use of
a proxy.
</paragraph>
</description>
</field>
<field name="exporterTransportPort" dataType="unsigned16"
group="config"
dataTypeSemantics="identifier"
elementId="217" applicability="all" status="current">
<description>
<paragraph>
The source port identifier from which the Exporting
Process sends Flow information. For the transport protocols
UDP, TCP, and SCTP, this is the source port number.
This field MAY also be used for future transport protocols
that have 16-bit source port identifiers. This field may
be useful for distinguishing multiple Exporting Processes
that use the same IP address.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 768 for the definition of the UDP
source port field.
See RFC 793 for the definition of the TCP
source port field.
See RFC 4960 for the definition of SCTP.
</paragraph>
<paragraph>
Additional information on defined UDP and TCP port numbers can
be found at http://www.iana.org/assignments/port-numbers.
</paragraph>
</reference>
</field>
<field name="collectorIPv4Address" dataType="ipv4Address"
dataTypeSemantics="identifier"
group="config"
elementId="211" applicability="all" status="current">
<description>
<paragraph>
An IPv4 address to which the Exporting Process sends Flow
information.
</paragraph>
</description>
</field>
<field name="collectorIPv6Address" dataType="ipv6Address"
dataTypeSemantics="identifier"
group="config"
elementId="212" applicability="all" status="current">
<description>
<paragraph>
An IPv6 address to which the Exporting Process sends Flow
information.
</paragraph>
</description>
</field>
<field name="exportInterface" dataType="unsigned32"
group="config"
dataTypeSemantics="identifier"
elementId="213" applicability="all" status="current">
<description>
<paragraph>
The index of the interface from which IPFIX Messages sent
by the Exporting Process to a Collector leave the IPFIX
Device. The value matches the value of
managed object 'ifIndex' as defined in RFC 2863.
Note that ifIndex values are not assigned statically to an
interface and that the interfaces may be renumbered every
time the device's management system is re-initialized, as
specified in RFC 2863.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 2863 for the definition of the ifIndex object.
</paragraph>
</reference>
</field>
<field name="exportProtocolVersion" dataType="unsigned8"
dataTypeSemantics="identifier"
group="config"
elementId="214" applicability="all" status="current">
<description>
<paragraph> The protocol version used by the Exporting Process for sending Flow information. The protocol version is given by the value of the Version Number field in the Message Header. </paragraph> <paragraph> The protocol version is 10 for IPFIX and 9 for NetFlow version 9. A value of 0 indicates that no export protocol is in use. </paragraph> </description> <reference> <paragraph> See the IPFIX protocol specification [RFC5101] for the definition of the IPFIX Message Header. </paragraph> <paragraph> See RFC 3954 for the definition of the NetFlow version 9 message header. </paragraph> </reference> </field>
<paragraph>フロー情報を送信するためにエクスポートプロセスで使用されるプロトコルバージョン。プロトコルバージョンは、メッセージヘッダーのバージョン番号フィールドの値によって指定されます。</paragraph> <paragraph>プロトコルバージョンはIPFIXで10、Netflowバージョン9では9です。</paragraph> </description> <seference> <paragraph> IPFIXメッセージヘッダーの定義については、IPFIXプロトコル仕様[RFC5101]を参照してください。</paragraph> <paragraph> Netflowバージョン9メッセージヘッダーの定義については、RFC 3954を参照してください。</paragraph> </reference> </field>
<field name="exportTransportProtocol" dataType="unsigned8"
group="config"
dataTypeSemantics="identifier"
elementId="215" applicability="all" status="current">
<description>
<paragraph>
The value of the protocol number used by the Exporting Process
for sending Flow information.
The protocol number identifies the IP packet payload type.
Protocol numbers are defined in the IANA Protocol Numbers
registry.
</paragraph>
<paragraph> In Internet Protocol version 4 (IPv4), this is carried in the Protocol field. In Internet Protocol version 6 (IPv6), this is carried in the Next Header field in the last extension header of the packet. </paragraph> </description> <reference> <paragraph> See RFC 791 for the specification of the IPv4 protocol field.
<パラグラフ>インターネットプロトコルバージョン4（IPv4）では、これはプロトコルフィールドにあります。インターネットプロトコルバージョン6（IPv6）では、これはパケットの最後の拡張ヘッダーの次のヘッダーフィールドに掲載されています。</paragraph> </description> <seference> <paragraph> IPv4プロトコルフィールドの仕様については、RFC 791を参照してください。
See RFC 2460 for the specification of the IPv6 protocol field. See the list of protocol numbers assigned by IANA at http://www.iana.org/assignments/protocol-numbers. </paragraph> </reference> </field>
IPv6プロトコルフィールドの仕様については、RFC 2460を参照してください。http://www.iana.org/assignments/protocol-numbersでIANAが割り当てたプロトコル番号のリストを参照してください。</paragraph> </reference> </field>
<field name="collectorTransportPort" dataType="unsigned16"
group="config"
dataTypeSemantics="identifier"
elementId="216" applicability="all" status="current">
<description>
<paragraph>
The destination port identifier to which the Exporting
Process sends Flow information. For the transport protocols
UDP, TCP, and SCTP, this is the destination port number.
This field MAY also be used for future transport protocols
that have 16-bit source port identifiers.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 768 for the definition of the UDP
destination port field.
See RFC 793 for the definition of the TCP
destination port field.
See RFC 4960 for the definition of SCTP.
</paragraph>
<paragraph>
Additional information on defined UDP and TCP port numbers can
be found at http://www.iana.org/assignments/port-numbers.
</paragraph>
</reference>
</field>
<field name="flowKeyIndicator" dataType="unsigned64" dataTypeSemantics="flags" group="config" elementId="173" applicability="all" status="current"> <description> <paragraph> This set of bit fields is used for marking the Information Elements of a Data Record that serve as Flow Key. Each bit represents an Information Element in the Data Record with the n-th bit representing the n-th Information Element. A bit set to value 1 indicates that the corresponding Information Element is a Flow Key of the reported Flow.
<field name = "flowkeyindicator" dataType = "unsigned64" datAtypeSemantics = "flags" group = "config" elementid = "applicability =" all "status =" current "> <説明> <パラグラフ>ビットフィールドのセットはです。フローキーとして機能するデータレコードの情報要素をマークするために使用されます。各ビットは、データレコードの情報要素を表し、n番目のビットはn番目の情報要素を表します。値1に少し設定すると、対応する情報要素が報告されたフローのフローキーであることを示します。
A bit set to value 0 indicates that this is not the case. </paragraph> <paragraph> If the Data Record contains more than 64 Information Elements, the corresponding Template SHOULD be designed such that all Flow Keys are among the first 64 Information Elements, because the flowKeyIndicator only contains 64 bits. If the Data Record contains less than 64 Information Elements, then the bits in the flowKeyIndicator for which no corresponding Information Element exists MUST have the value 0. </paragraph> </description> </field>
値0に少し設定されていると、これが当てはまらないことがわかります。</paragraph> <paragraph>データレコードに64を超える情報要素が含まれている場合、FlowKeyIndicatorには64ビットのみが含まれているため、すべてのフローキーが最初の64の情報要素になるように対応するテンプレートを設計する必要があります。データレコードに64未満の情報要素が含まれている場合、対応する情報要素が存在しないFlowKeyindicatorのビットには値が必要です。
<field name="exportedMessageTotalCount" dataType="unsigned64"
dataTypeSemantics="totalCounter"
group="processCounter"
elementId="41" applicability="data" status="current">
<description>
<paragraph>
The total number of IPFIX Messages that the Exporting Process
has sent since the Exporting Process (re-)initialization to
a particular Collecting Process.
The reported number excludes the IPFIX Message that carries
the counter value.
If this Information Element is sent to a particular
Collecting Process, then by default it specifies the number
of IPFIX Messages sent to this Collecting Process.
</paragraph>
</description>
<units>messages</units>
</field>
<field name="exportedOctetTotalCount" dataType="unsigned64"
dataTypeSemantics="totalCounter"
group="processCounter"
elementId="40" applicability="data" status="current">
<description>
<paragraph>
The total number of octets that the Exporting Process
has sent since the Exporting Process (re-)initialization
to a particular Collecting Process.
The value of this Information Element is calculated by
summing up the IPFIX Message Header length values of all
IPFIX Messages that were successfully sent to the Collecting
Process. The reported number excludes octets in the IPFIX
Message that carries the counter value.
If this Information Element is sent to a particular
Collecting Process, then by default it specifies the number
of octets sent to this Collecting Process.
</paragraph>
</description>
<units>octets</units>
</field>
<field name="exportedFlowRecordTotalCount" dataType="unsigned64"
group="processCounter"
dataTypeSemantics="totalCounter"
elementId="42" applicability="data" status="current">
<description>
<paragraph>
The total number of Flow Records that the Exporting
Process has sent as Data Records since the Exporting
Process (re-)initialization to a particular Collecting
Process. The reported number excludes Flow Records in
the IPFIX Message that carries the counter value.
If this Information Element is sent to a particular
Collecting Process, then by default it specifies the number
of Flow Records sent to this process.
</paragraph>
</description>
<units>flows</units>
</field>
<field name="observedFlowTotalCount" dataType="unsigned64"
dataTypeSemantics="totalCounter"
group="processCounter"
elementId="163" applicability="data" status="current">
<description>
<paragraph>
The total number of Flows observed in the Observation Domain
since the Metering Process (re-)initialization for this
Observation Point.
</paragraph>
</description>
<units>flows</units>
</field>
<field name="ignoredPacketTotalCount" dataType="unsigned64"
dataTypeSemantics="totalCounter"
group="processCounter"
elementId="164" applicability="data" status="current">
<description>
<paragraph>
The total number of observed IP packets that the
Metering Process did not process since the
(re-)initialization of the Metering Process.
</paragraph>
</description>
<units>packets</units>
</field>
<field name="ignoredOctetTotalCount" dataType="unsigned64"
dataTypeSemantics="totalCounter"
group="processCounter"
elementId="165" applicability="data" status="current">
<description>
<paragraph>
The total number of octets in observed IP packets
(including the IP header) that the Metering Process
did not process since the (re-)initialization of the
Metering Process.
</paragraph>
</description>
<units>octets</units>
</field>
<field name="notSentFlowTotalCount" dataType="unsigned64"
dataTypeSemantics="totalCounter"
group="processCounter"
elementId="166" applicability="data" status="current">
<description>
<paragraph>
The total number of Flow Records that were generated by the
Metering Process and dropped by the Metering Process or
by the Exporting Process instead of being sent to the
Collecting Process. There are several potential reasons for
this including resource shortage and special Flow export
policies.
</paragraph>
</description>
<units>flows</units>
</field>
<field name="notSentPacketTotalCount" dataType="unsigned64" dataTypeSemantics="totalCounter" group="processCounter" elementId="167" applicability="data" status="current"> <description> <paragraph> The total number of packets in Flow Records that were generated by the Metering Process and dropped by the Metering Process or by the Exporting Process instead of being sent to the Collecting Process.
<field name = "notsentpackettotalcount" dataType = "unsigned64" datAtypeSemantics = "totalcounter" group = "elementid" elementid = "167" applicability = "data" status = "> <説明> <paragraph>計量プロセスによって生成され、計量プロセスまたは輸出プロセスによってドロップされたフローレコードは、収集プロセスに送信される代わりに。
There are several potential reasons for this including
resource shortage and special Flow export policies.
</paragraph>
</description>
<units>packets</units>
</field>
<field name="notSentOctetTotalCount" dataType="unsigned64"
dataTypeSemantics="totalCounter"
group="processCounter"
elementId="168" applicability="data" status="current">
<description>
<paragraph>
The total number of octets in packets in Flow Records
that were generated by the Metering Process and
dropped by the Metering Process or by the Exporting
Process instead of being sent to the Collecting Process.
There are several potential reasons for this including
resource shortage and special Flow export policies.
</paragraph>
</description>
<units>octets</units>
</field>
<field name="ipVersion" dataType="unsigned8"
group="ipHeader"
dataTypeSemantics="identifier"
elementId="60" applicability="all" status="current">
<description>
<paragraph>
The IP version field in the IP packet header.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 791 for the definition of the version field
in the IPv4 packet header.
See RFC 2460 for the definition of the version field
in the IPv6 packet header.
Additional information on defined version numbers
can be found at
http://www.iana.org/assignments/version-numbers.
</paragraph>
</reference>
</field>
<field name="sourceIPv4Address" dataType="ipv4Address"
group="ipHeader"
dataTypeSemantics="identifier"
elementId="8" applicability="all" status="current">
<description>
<paragraph>
The IPv4 source address in the IP packet header.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 791 for the definition of the IPv4 source
address field.
</paragraph>
</reference>
</field>
<field name="sourceIPv6Address" dataType="ipv6Address"
group="ipHeader"
dataTypeSemantics="identifier"
elementId="27" applicability="all" status="current">
<description>
<paragraph>
The IPv6 source address in the IP packet header.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 2460 for the definition of the
Source Address field in the IPv6 header.
</paragraph>
</reference>
</field>
<field name="sourceIPv4PrefixLength" dataType="unsigned8"
group="ipHeader"
elementId="9" applicability="option" status="current">
<description>
<paragraph>
The number of contiguous bits that are relevant in the
sourceIPv4Prefix Information Element.
</paragraph>
</description>
<units>bits</units>
<range>0-32</range>
</field>
<field name="sourceIPv6PrefixLength" dataType="unsigned8"
group="ipHeader"
elementId="29" applicability="option" status="current">
<description>
<paragraph>
The number of contiguous bits that are relevant in the
sourceIPv6Prefix Information Element.
</paragraph>
</description>
<units>bits</units>
<range>0-128</range>
</field>
<field name="sourceIPv4Prefix" dataType="ipv4Address"
group="ipHeader"
elementId="44" applicability="data" status="current">
<description>
<paragraph>
IPv4 source address prefix.
</paragraph>
</description>
</field>
<field name="sourceIPv6Prefix" dataType="ipv6Address"
group="ipHeader"
elementId="170" applicability="data" status="current">
<description>
<paragraph>
IPv6 source address prefix.
</paragraph>
</description>
</field>
<field name="destinationIPv4Address" dataType="ipv4Address"
group="ipHeader"
dataTypeSemantics="identifier"
elementId="12" applicability="all" status="current">
<description>
<paragraph>
The IPv4 destination address in the IP packet header.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 791 for the definition of the IPv4
destination address field.
</paragraph>
</reference>
</field>
<field name="destinationIPv6Address" dataType="ipv6Address"
group="ipHeader"
dataTypeSemantics="identifier"
elementId="28" applicability="all" status="current">
<description>
<paragraph>
The IPv6 destination address in the IP packet header.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 2460 for the definition of the
Destination Address field in the IPv6 header.
</paragraph>
</reference>
</field>
<field name="destinationIPv4PrefixLength" dataType="unsigned8"
group="ipHeader"
elementId="13" applicability="option" status="current">
<description>
<paragraph>
The number of contiguous bits that are relevant in the
destinationIPv4Prefix Information Element.
</paragraph>
</description>
<units>bits</units>
<range>0-32</range>
</field>
<field name="destinationIPv6PrefixLength" dataType="unsigned8"
group="ipHeader"
elementId="30" applicability="option" status="current">
<description>
<paragraph>
The number of contiguous bits that are relevant in the
destinationIPv6Prefix Information Element.
</paragraph>
</description>
<units>bits</units>
<range>0-128</range>
</field>
<field name="destinationIPv4Prefix" dataType="ipv4Address"
group="ipHeader"
elementId="45" applicability="data" status="current">
<description>
<paragraph> IPv4 destination address prefix. </paragraph>
</description>
</field>
</field>
<field name="destinationIPv6Prefix" dataType="ipv6Address"
group="ipHeader"
elementId="169" applicability="data" status="current">
<description>
<paragraph> IPv6 destination address prefix. </paragraph>
</description>
</field>
<field name="ipTTL" dataType="unsigned8"
group="ipHeader"
elementId="192" applicability="all" status="current">
<description>
<paragraph>
For IPv4, the value of the Information Element matches
the value of the Time to Live (TTL) field in the IPv4 packet
header. For IPv6, the value of the Information Element
matches the value of the Hop Limit field in the IPv6
packet header.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 791 for the definition of the IPv4
Time to Live field.
See RFC 2460 for the definition of the IPv6
Hop Limit field.
</paragraph>
</reference>
<units>hops</units>
</field>
<field name="protocolIdentifier" dataType="unsigned8"
group="ipHeader"
dataTypeSemantics="identifier"
elementId="4" applicability="all" status="current">
<description>
<paragraph>
The value of the protocol number in the IP packet header.
The protocol number identifies the IP packet payload type.
Protocol numbers are defined in the IANA Protocol Numbers
registry.
</paragraph>
<paragraph> In Internet Protocol version 4 (IPv4), this is carried in the Protocol field. In Internet Protocol version 6 (IPv6), this is carried in the Next Header field in the last extension header of the packet. </paragraph> </description> <reference> <paragraph> See RFC 791 for the specification of the IPv4 protocol field. See RFC 2460 for the specification of the IPv6 protocol field. See the list of protocol numbers assigned by IANA at http://www.iana.org/assignments/protocol-numbers. </paragraph> </reference> </field>
<パラグラフ>インターネットプロトコルバージョン4（IPv4）では、これはプロトコルフィールドにあります。インターネットプロトコルバージョン6（IPv6）では、これはパケットの最後の拡張ヘッダーの次のヘッダーフィールドに掲載されています。</paragraph> </description> <seference> <paragraph> IPv4プロトコルフィールドの仕様については、RFC 791を参照してください。IPv6プロトコルフィールドの仕様については、RFC 2460を参照してください。http://www.iana.org/assignments/protocol-numbersでIANAが割り当てたプロトコル番号のリストを参照してください。</paragraph> </reference> </field>
<field name="nextHeaderIPv6" dataType="unsigned8"
group="ipHeader"
elementId="193" applicability="all" status="current">
<description>
<paragraph>
The value of the Next Header field of the IPv6 header.
The value identifies the type of the following IPv6
extension header or of the following IP payload.
Valid values are defined in the IANA
Protocol Numbers registry.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 2460 for the definition of the IPv6
Next Header field.
See the list of protocol numbers assigned by IANA at
http://www.iana.org/assignments/protocol-numbers.
</paragraph>
</reference>
</field>
<field name="ipDiffServCodePoint" dataType="unsigned8"
group="ipHeader"
dataTypeSemantics="identifier"
elementId="195" applicability="all" status="current">
<description>
<paragraph>
The value of a Differentiated Services Code Point (DSCP)
encoded in the Differentiated Services field. The
Differentiated Services field spans the most significant
6 bits of the IPv4 TOS field or the IPv6 Traffic Class
field, respectively.
</paragraph>
<paragraph>
This Information Element encodes only the 6 bits of the
Differentiated Services field. Therefore, its value may
range from 0 to 63.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 3260 for the definition of the
Differentiated Services field.
See RFC 1812 (Section 5.3.2) and RFC 791 for the definition
of the IPv4 TOS field. See RFC 2460 for the definition of
the IPv6 Traffic Class field.
</paragraph>
</reference>
<range>0-63</range>
</field>
<field name="ipPrecedence" dataType="unsigned8"
group="ipHeader"
dataTypeSemantics="identifier"
elementId="196" applicability="all" status="current">
<description>
<paragraph>
The value of the IP Precedence. The IP Precedence value
is encoded in the first 3 bits of the IPv4 TOS field
or the IPv6 Traffic Class field, respectively.
</paragraph>
<paragraph>
This Information Element encodes only these 3 bits.
Therefore, its value may range from 0 to 7.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 1812 (Section 5.3.3) and RFC 791
for the definition of the IP Precedence.
See RFC 1812 (Section 5.3.2) and RFC 791
for the definition of the IPv4 TOS field.
See RFC 2460 for the definition of the IPv6
Traffic Class field.
</paragraph>
</reference>
<range>0-7</range>
</field>
<field name="ipClassOfService" dataType="unsigned8"
group="ipHeader"
dataTypeSemantics="identifier"
elementId="5" applicability="all" status="current">
<description>
<paragraph>
For IPv4 packets, this is the value of the TOS field in
the IPv4 packet header. For IPv6 packets, this is the
value of the Traffic Class field in the IPv6 packet header.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 1812 (Section 5.3.2) and RFC 791
for the definition of the IPv4 TOS field.
See RFC 2460 for the definition of the IPv6
Traffic Class field.
</paragraph>
</reference>
</field>
<field name="postIpClassOfService" dataType="unsigned8"
group="ipHeader"
dataTypeSemantics="identifier"
elementId="55" applicability="all" status="current">
<description>
<paragraph>
The definition of this Information Element is identical
to the definition of Information Element
'ipClassOfService', except that it reports a
potentially modified value caused by a middlebox
function after the packet passed the Observation Point.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 791 for the definition of the IPv4
TOS field.
See RFC 2460 for the definition of the IPv6
Traffic Class field.
See RFC 3234 for the definition of middleboxes.
</paragraph>
</reference>
</field>
<field name="flowLabelIPv6" dataType="unsigned32"
group="ipHeader"
dataTypeSemantics="identifier"
elementId="31" applicability="all" status="current">
<description>
<paragraph>
The value of the IPv6 Flow Label field in the IP packet header.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 2460 for the definition of the
Flow Label field in the IPv6 packet header.
</paragraph>
</reference>
</field>
<field name="isMulticast" dataType="unsigned8"
group="ipHeader"
dataTypeSemantics="flags"
elementId="206" applicability="data" status="current">
<description>
<paragraph>
If the IP destination address is not a reserved multicast
address, then the value of all bits of the octet (including
the reserved ones) is zero.
</paragraph>
<paragraph>
The first bit of this octet is set to 1 if the Version
field of the IP header has the value 4 and if the
Destination Address field contains a reserved multicast
address in the range from 224.0.0.0 to 239.255.255.255.
Otherwise, this bit is set to 0.
</paragraph>
<paragraph>
The second and third bits of this octet are reserved for
future use.
</paragraph>
<paragraph>
The remaining bits of the octet are only set to values
other than zero if the IP Destination Address is a
reserved IPv6 multicast address. Then the fourth bit
of the octet is set to the value of the T flag in the
IPv6 multicast address and the remaining four bits are
set to the value of the scope field in the IPv6
multicast address.
</paragraph>
<artwork>
0 1 2 3 4 5 6 7
+------+------+------+------+------+------+------+------+
| MCv4 | RES. | RES. | T | IPv6 multicast scope |
+------+------+------+------+------+------+------+------+
Bit 0: set to 1 if IPv4 multicast
Bits 1-2: reserved for future use
Bit 4: set to value of T flag, if IPv6 multicast
Bits 4-7: set to value of multicast scope if IPv6 multicast
</artwork>
</description>
<reference>
<paragraph>
See RFC 1112 for the specification of reserved
IPv4 multicast addresses.
See RFC 4291 for the specification of reserved
IPv6 multicast addresses and the definition of the T flag
and the IPv6 multicast scope.
</paragraph>
</reference>
</field>
<field name="fragmentIdentification" dataType="unsigned32"
group="ipHeader"
dataTypeSemantics="identifier"
elementId="54" applicability="data" status="current">
<description>
<paragraph>
The value of the Identification field
in the IPv4 packet header or in the IPv6 Fragment header,
respectively. The value is 0 for IPv6 if there is
no fragment header.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 791 for the definition of the IPv4
Identification field.
See RFC 2460 for the definition of the
Identification field in the IPv6 Fragment header.
</paragraph>
</reference>
</field>
<field name="fragmentOffset" dataType="unsigned16"
group="ipHeader"
dataTypeSemantics="identifier"
elementId="88" applicability="all" status="current">
<description>
<paragraph>
The value of the IP fragment offset field in the
IPv4 packet header or the IPv6 Fragment header,
respectively. The value is 0 for IPv6 if there is
no fragment header.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 791 for the specification of the
fragment offset in the IPv4 header.
See RFC 2460 for the specification of the
fragment offset in the IPv6 Fragment header.
</paragraph>
</reference>
</field>
<field name="fragmentFlags" dataType="unsigned8"
group="ipHeader"
dataTypeSemantics="flags"
elementId="197" applicability="all" status="current">
<description>
<paragraph>
Fragmentation properties indicated by flags in the IPv4
packet header or the IPv6 Fragment header, respectively.
</paragraph>
<artwork>
Bit 0: (RS) Reserved. The value of this bit MUST be 0 until specified otherwise. Bit 1: (DF) 0 = May Fragment, 1 = Don't Fragment. Corresponds to the value of the DF flag in the IPv4 header. Will always be 0 for IPv6 unless a "don't fragment" feature is introduced to IPv6. Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments. Corresponds to the MF flag in the IPv4 header or to the M flag in the IPv6 Fragment header, respectively. The value is 0 for IPv6 if there is no fragment header. Bits 3-7: (DC) Don't Care. The values of these bits are irrelevant.
ビット0：（rs）予約。このビットの値は、それ以外の場合は指定されるまで0でなければなりません。ビット1：（df）0 =メイフラグメント、1 =フラグメントしないでください。IPv4ヘッダーのDFフラグの値に対応します。「断片化しない」機能がIPv6に導入されない限り、IPv6の場合は常に0になります。ビット2：（MF）0 =最後のフラグメント、1 =より多くのフラグメント。IPv4ヘッダーのMFフラグまたはIPv6フラグメントヘッダーのMフラグにそれぞれ対応します。フラグメントヘッダーがない場合、IPv6の値は0です。ビット3-7：（DC）気にしないでください。これらのビットの値は無関係です。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| R | D | M | D | D | D | D | D |
| S | F | F | C | C | C | C | C |
+---+---+---+---+---+---+---+---+
</artwork>
</description>
<reference> <paragraph> See RFC 791 for the specification of the IPv4 fragment flags. See RFC 2460 for the specification of the IPv6 Fragment header. </paragraph> </reference> </field>
<参照> <パラグラフ> IPv4フラグメントフラグの仕様については、RFC 791を参照してください。IPv6フラグメントヘッダーの仕様については、RFC 2460を参照してください。</paragraph> </reference> </field>
<field name="ipHeaderLength" dataType="unsigned8"
group="ipHeader"
elementId="189" applicability="all" status="current">
<description>
<paragraph>
The length of the IP header. For IPv6, the value of this
Information Element is 40.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 791 for the specification of the
IPv4 header.
See RFC 2460 for the specification of the
IPv6 header.
</paragraph>
</reference>
<units>octets</units>
</field>
<field name="ipv4IHL" dataType="unsigned8"
group="ipHeader"
elementId="207" applicability="all" status="current">
<description>
<paragraph>
The value of the Internet Header Length (IHL) field in
the IPv4 header. It specifies the length of the header
in units of 4 octets. Please note that its unit is
different from most of the other Information Elements
reporting length values.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 791 for the specification of the
IPv4 header.
</paragraph>
</reference>
<units>4 octets</units>
</field>
<field name="totalLengthIPv4" dataType="unsigned16"
group="ipHeader"
elementId="190" applicability="all" status="current">
<description>
<paragraph>
The total length of the IPv4 packet.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 791 for the specification of the
IPv4 total length.
</paragraph>
</reference>
<units>octets</units>
</field>
<field name="ipTotalLength" dataType="unsigned64"
group="ipHeader"
elementId="224" applicability="all" status="current">
<description>
<paragraph>
The total length of the IP packet.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 791 for the specification of the
IPv4 total length.
See RFC 2460 for the specification of the
IPv6 payload length.
See RFC 2675 for the specification of the
IPv6 jumbo payload length.
</paragraph>
</reference>
<units>octets</units>
</field>
<field name="payloadLengthIPv6" dataType="unsigned16"
group="ipHeader"
elementId="191" applicability="all" status="current">
<description>
<paragraph>
This Information Element reports the value of the Payload
Length field in the IPv6 header. Note that IPv6 extension
headers belong to the payload. Also note that in case of a
jumbo payload option the value of the Payload Length field in
the IPv6 header is zero and so will be the value reported
by this Information Element.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 2460 for the specification of the
IPv6 payload length.
See RFC 2675 for the specification of the
IPv6 jumbo payload option.
</paragraph>
</reference>
<units>octets</units>
</field>
<field name="sourceTransportPort" dataType="unsigned16"
group="transportHeader"
dataTypeSemantics="identifier"
elementId="7" applicability="all" status="current">
<description>
<paragraph>
The source port identifier in the transport header.
For the transport protocols UDP, TCP, and SCTP, this is the
source port number given in the respective header. This
field MAY also be used for future transport protocols that
have 16-bit source port identifiers.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 768 for the definition of the UDP
source port field.
See RFC 793 for the definition of the TCP
source port field.
See RFC 4960 for the definition of SCTP.
</paragraph>
<paragraph>
Additional information on defined UDP and TCP port numbers can
be found at http://www.iana.org/assignments/port-numbers.
</paragraph>
</reference>
</field>
<field name="destinationTransportPort" dataType="unsigned16"
group="transportHeader"
dataTypeSemantics="identifier"
elementId="11" applicability="all" status="current">
<description>
<paragraph>
The destination port identifier in the transport header.
For the transport protocols UDP, TCP, and SCTP, this is the
destination port number given in the respective header.
This field MAY also be used for future transport protocols
that have 16-bit destination port identifiers.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 768 for the definition of the UDP
destination port field.
See RFC 793 for the definition of the TCP
destination port field.
See RFC 4960 for the definition of SCTP.
</paragraph>
<paragraph>
Additional information on defined UDP and TCP port numbers can
be found at http://www.iana.org/assignments/port-numbers.
</paragraph>
</reference>
</field>
<field name="udpSourcePort" dataType="unsigned16"
group="transportHeader"
dataTypeSemantics="identifier"
elementId="180" applicability="all" status="current">
<description>
<paragraph>
The source port identifier in the UDP header.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 768 for the definition of the
UDP source port field.
Additional information on defined UDP port numbers can
be found at http://www.iana.org/assignments/port-numbers.
</paragraph>
</reference>
</field>
<field name="udpDestinationPort" dataType="unsigned16"
group="transportHeader"
dataTypeSemantics="identifier"
elementId="181" applicability="all" status="current">
<description>
<paragraph>
The destination port identifier in the UDP header.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 768 for the definition of the
UDP destination port field.
Additional information on defined UDP port numbers can
be found at http://www.iana.org/assignments/port-numbers.
</paragraph>
</reference>
</field>
<field name="udpMessageLength" dataType="unsigned16"
group="transportHeader"
elementId="205" applicability="all" status="current">
<description>
<paragraph>
The value of the Length field in the UDP header.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 768 for the specification of the
UDP header.
</paragraph>
</reference>
<units>octets</units>
</field>
<field name="tcpSourcePort" dataType="unsigned16"
group="transportHeader"
dataTypeSemantics="identifier"
elementId="182" applicability="all" status="current">
<description>
<paragraph>
The source port identifier in the TCP header.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 793 for the definition of the TCP
source port field.
Additional information on defined TCP port numbers can
be found at http://www.iana.org/assignments/port-numbers.
</paragraph>
</reference>
</field>
<field name="tcpDestinationPort" dataType="unsigned16"
group="transportHeader"
dataTypeSemantics="identifier"
elementId="183" applicability="all" status="current">
<description>
<paragraph>
The destination port identifier in the TCP header.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 793 for the definition of the TCP
source port field.
Additional information on defined TCP port numbers can
be found at http://www.iana.org/assignments/port-numbers.
</paragraph>
</reference>
</field>
<field name="tcpSequenceNumber" dataType="unsigned32"
group="transportHeader"
elementId="184" applicability="all" status="current">
<description>
<paragraph>
The sequence number in the TCP header.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 793 for the definition of the TCP
sequence number.
</paragraph>
</reference>
</field>
<field name="tcpAcknowledgementNumber" dataType="unsigned32"
group="transportHeader"
elementId="185" applicability="all" status="current">
<description>
<paragraph>
The acknowledgement number in the TCP header.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 793 for the definition of the TCP
acknowledgement number.
</paragraph>
</reference>
</field>
<field name="tcpWindowSize" dataType="unsigned16"
group="transportHeader"
elementId="186" applicability="all" status="current">
<description>
<paragraph>
The window field in the TCP header.
If the TCP window scale is supported,
then TCP window scale must be known
to fully interpret the value of this information.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 793 for the definition of the TCP window field.
See RFC 1323 for the definition of the TCP window scale.
</paragraph>
</reference>
</field>
<field name="tcpWindowScale" dataType="unsigned16"
group="transportHeader"
elementId="238" applicability="all" status="current">
<description>
<paragraph>
The scale of the window field in the TCP header.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 1323 for the definition of the TCP window scale.
</paragraph>
</reference>
</field>
<field name="tcpUrgentPointer" dataType="unsigned16"
group="transportHeader"
elementId="187" applicability="all" status="current">
<description>
<paragraph>
The urgent pointer in the TCP header.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 793 for the definition of the TCP
urgent pointer.
</paragraph>
</reference>
</field>
<field name="tcpHeaderLength" dataType="unsigned8"
group="transportHeader"
elementId="188" applicability="all" status="current">
<description>
<paragraph>
The length of the TCP header. Note that the value of this
Information Element is different from the value of the Data
Offset field in the TCP header. The Data Offset field
indicates the length of the TCP header in units of 4 octets.
This Information Elements specifies the length of the TCP
header in units of octets.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 793 for the definition of the
TCP header.
</paragraph>
</reference>
<units>octets</units>
</field>
<field name="icmpTypeCodeIPv4" dataType="unsigned16"
group="transportHeader"
dataTypeSemantics="identifier"
elementId="32" applicability="all" status="current">
<description>
<paragraph>
Type and Code of the IPv4 ICMP message. The combination of
both values is reported as (ICMP type * 256) + ICMP code.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 792 for the definition of the IPv4 ICMP
type and code fields.
</paragraph>
</reference>
</field>
<field name="icmpTypeIPv4" dataType="unsigned8"
group="transportHeader"
dataTypeSemantics="identifier"
elementId="176" applicability="all" status="current">
<description>
<paragraph>
Type of the IPv4 ICMP message.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 792 for the definition of the IPv4 ICMP
type field.
</paragraph>
</reference>
</field>
<field name="icmpCodeIPv4" dataType="unsigned8"
group="transportHeader"
dataTypeSemantics="identifier"
elementId="177" applicability="all" status="current">
<description>
<paragraph>
Code of the IPv4 ICMP message.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 792 for the definition of the IPv4
ICMP code field.
</paragraph>
</reference>
</field>
<field name="icmpTypeCodeIPv6" dataType="unsigned16" group="transportHeader" dataTypeSemantics="identifier" elementId="139" applicability="all" status="current"> <description> <paragraph> Type and Code of the IPv6 ICMP message. The combination of both values is reported as (ICMP type * 256) + ICMP code. </paragraph> </description> <reference> <paragraph> See RFC 4443 for the definition of the IPv6 ICMP type and code fields.
<field name = "icmptypecodeipv6" dataType = "unsigned16" group = "transportheader" dataTypeSemantics = "識別子" elementId = "139" applicability = "all" status = "> <説明> <paragraph> IPv6のタイプとコードICMPメッセージ。両方の値の組み合わせは、（ICMPタイプ * 256）ICMPコードとして報告されます。</paragraph> </description> <seference> <paragraph> IPv6 ICMPタイプとコードフィールドの定義については、RFC 4443を参照してください。
</paragraph>
</reference>
</field>
<field name="icmpTypeIPv6" dataType="unsigned8"
group="transportHeader"
dataTypeSemantics="identifier"
elementId="178" applicability="all" status="current">
<description>
<paragraph>
Type of the IPv6 ICMP message.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 4443 for the definition of the IPv6
ICMP type field.
</paragraph>
</reference>
</field>
<field name="icmpCodeIPv6" dataType="unsigned8"
group="transportHeader"
dataTypeSemantics="identifier"
elementId="179" applicability="all" status="current">
<description>
<paragraph>
Code of the IPv6 ICMP message.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 4443 for the definition of the IPv6
ICMP code field.
</paragraph>
</reference>
</field>
<field name="igmpType" dataType="unsigned8"
group="transportHeader"
dataTypeSemantics="identifier"
elementId="33" applicability="all" status="current">
<description>
<paragraph>
The type field of the IGMP message.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 3376 for the definition of the IGMP
type field.
</paragraph>
</reference>
</field>
<field name="sourceMacAddress" dataType="macAddress"
group="subIpHeader"
dataTypeSemantics="identifier"
elementId="56" applicability="data" status="current">
<description>
<paragraph>
The IEEE 802 source MAC address field.
</paragraph>
</description>
<reference>
<paragraph>
See IEEE.802-3.2002.
</paragraph>
</reference>
</field>
<field name="postSourceMacAddress" dataType="macAddress"
group="subIpHeader"
dataTypeSemantics="identifier"
elementId="81" applicability="data" status="current">
<description>
<paragraph>
The definition of this Information Element is identical
to the definition of Information Element
'sourceMacAddress', except that it reports a
potentially modified value caused by a middlebox
function after the packet passed the Observation Point.
</paragraph>
</description>
<reference>
<paragraph>
See IEEE.802-3.2002.
</paragraph>
</reference>
</field>
<field name="vlanId" dataType="unsigned16"
group="subIpHeader"
dataTypeSemantics="identifier"
elementId="58" applicability="data" status="current">
<description>
<paragraph>
The IEEE 802.1Q VLAN identifier (VID) extracted from the Tag
Control Information field that was attached to the IP packet.
</paragraph>
</description>
<reference>
<paragraph>
See IEEE.802-1Q.2003.
</paragraph>
</reference>
</field>
<field name="postVlanId" dataType="unsigned16"
group="subIpHeader"
dataTypeSemantics="identifier"
elementId="59" applicability="data" status="current">
<description>
<paragraph>
The definition of this Information Element is identical
to the definition of Information Element
'vlanId', except that it reports a
potentially modified value caused by a middlebox
function after the packet passed the Observation Point.
</paragraph>
</description>
<reference>
<paragraph>
See IEEE.802-1Q.2003.
</paragraph>
</reference>
</field>
<field name="destinationMacAddress" dataType="macAddress"
group="subIpHeader"
dataTypeSemantics="identifier"
elementId="80" applicability="data" status="current">
<description>
<paragraph>
The IEEE 802 destination MAC address field.
</paragraph>
</description>
<reference>
<paragraph>
See IEEE.802-3.2002.
</paragraph>
</reference>
</field>
<field name="postDestinationMacAddress" dataType="macAddress"
group="subIpHeader"
dataTypeSemantics="identifier"
elementId="57" applicability="data" status="current">
<description>
<paragraph>
The definition of this Information Element is identical
to the definition of Information Element
'destinationMacAddress', except that it reports a
potentially modified value caused by a middlebox
function after the packet passed the Observation Point.
</paragraph>
</description>
<reference>
<paragraph>
See IEEE.802-3.2002.
</paragraph>
</reference>
</field>
<field name="wlanChannelId" dataType="unsigned8"
group="subIpHeader"
dataTypeSemantics="identifier"
elementId="146" applicability="data" status="current">
<description>
<paragraph>
The identifier of the 802.11 (Wi-Fi) channel used.
</paragraph>
</description>
<reference>
<paragraph>
See IEEE.802-11.1999.
</paragraph>
</reference>
</field>
<field name="wlanSSID" dataType="string"
group="subIpHeader"
elementId="147" applicability="data" status="current">
<description>
<paragraph>
The Service Set IDentifier (SSID) identifying an 802.11
(Wi-Fi) network used. According to IEEE.802-11.1999, the
SSID is encoded into a string of up to 32 characters.
</paragraph>
</description>
<reference>
<paragraph>
See IEEE.802-11.1999.
</paragraph>
</reference>
</field>
<field name="mplsTopLabelTTL" dataType="unsigned8"
group="subIpHeader"
elementId="200" applicability="all" status="current">
<description>
<paragraph>
The TTL field from the top MPLS label stack entry,
i.e., the last label that was pushed.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 3032 for the specification of the
TTL field.
</paragraph>
</reference>
<units>hops</units>
</field>
<field name="mplsTopLabelExp" dataType="unsigned8" group="subIpHeader" dataTypeSemantics="flags" elementId="203" applicability="all" status="current"> <description> <paragraph> The Exp field from the top MPLS label stack entry, i.e., the last label that was pushed. </paragraph> <artwork> Bits 0-4: Don't Care, value is irrelevant. Bits 5-7: MPLS Exp field.
<field name = "mplstoplabelexp" dataType = "unsigned8"グループ= "subipheader" datatypesemantics = "flags elementid =" 203 "applicability =" all "status =" current> <paragraph>上からのExpフィールドMPLSラベルスタックエントリ、つまりプッシュされた最後のラベル。</paragraph> <Artwork>ビット0-4：気にしないでください、価値は無関係です。ビット5-7：MPLS EXPフィールド。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| don't care | Exp |
+---+---+---+---+---+---+---+---+
</artwork>
</description>
<reference>
<paragraph>
See RFC 3032 for the specification of the Exp field.
See RFC 3270 for usage of the Exp field.
</paragraph>
</reference>
</field>
</field>
<field name="postMplsTopLabelExp" dataType="unsigned8"
group="subIpHeader"
dataTypeSemantics="flags"
elementId="237" applicability="all" status="current">
<description>
<paragraph>
The definition of this Information Element is identical to the
definition of Information Element 'mplsTopLabelExp', except
that it reports a potentially modified value caused by a
middlebox function after the packet passed the Observation
Point.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 3032 for the specification of the Exp field.
See RFC 3270 for usage of the Exp field.
</paragraph>
</reference>
</field>
<field name="mplsLabelStackDepth" dataType="unsigned32"
group="subIpHeader"
elementId="202" applicability="all" status="current">
<description>
<paragraph>
The number of labels in the MPLS label stack.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 3032 for the specification of
the MPLS label stack.
</paragraph>
</reference>
<units>label stack entries</units>
</field>
<field name="mplsLabelStackLength" dataType="unsigned32"
group="subIpHeader"
elementId="201" applicability="all" status="current">
<description>
<paragraph>
The length of the MPLS label stack in units of octets.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 3032 for the specification of
the MPLS label stack.
</paragraph>
</reference>
<units>octets</units>
</field>
<field name="mplsPayloadLength" dataType="unsigned32"
group="subIpHeader"
elementId="194" applicability="all" status="current">
<description>
<paragraph>
The size of the MPLS packet without the label stack.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 3031 for the specification of
MPLS packets.
See RFC 3032 for the specification of
the MPLS label stack.
</paragraph>
</reference>
<units>octets</units>
</field>
<field name="mplsTopLabelStackSection" dataType="octetArray"
group="subIpHeader"
dataTypeSemantics="identifier"
elementId="70" applicability="all" status="current">
<description>
<paragraph>
The Label, Exp, and S fields from the top MPLS label
stack entry, i.e., from the last label that was pushed.
</paragraph>
<paragraph>
The size of this Information Element is 3 octets.
</paragraph>
<artwork>
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | Exp |S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label: Label Value, 20 bits
Exp: Experimental Use, 3 bits
S: Bottom of Stack, 1 bit
</artwork>
</description>
<reference>
<paragraph>
See RFC 3032.
</paragraph>
</reference>
</field>
<field name="mplsLabelStackSection2" dataType="octetArray"
group="subIpHeader"
dataTypeSemantics="identifier"
elementId="71" applicability="all" status="current">
<description>
<paragraph>
The Label, Exp, and S fields from the label stack entry that
was pushed immediately before the label stack entry that would
be reported by mplsTopLabelStackSection. See the definition of
mplsTopLabelStackSection for further details.
</paragraph>
<paragraph>
The size of this Information Element is 3 octets.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 3032.
</paragraph>
</reference>
</field>
<field name="mplsLabelStackSection3" dataType="octetArray"
group="subIpHeader"
dataTypeSemantics="identifier"
elementId="72" applicability="all" status="current">
<description>
<paragraph>
The Label, Exp, and S fields from the label stack entry that
was pushed immediately before the label stack entry that would
be reported by mplsLabelStackSection2. See the definition of
mplsTopLabelStackSection for further details.
</paragraph>
<paragraph>
The size of this Information Element is 3 octets.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 3032.
</paragraph>
</reference>
</field>
<field name="mplsLabelStackSection4" dataType="octetArray"
group="subIpHeader"
dataTypeSemantics="identifier"
elementId="73" applicability="all" status="current">
<description>
<paragraph>
The Label, Exp, and S fields from the label stack entry that
was pushed immediately before the label stack entry that would
be reported by mplsLabelStackSection3. See the definition of
mplsTopLabelStackSection for further details.
</paragraph>
<paragraph>
The size of this Information Element is 3 octets.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 3032.
</paragraph>
</reference>
</field>
<field name="mplsLabelStackSection5" dataType="octetArray"
group="subIpHeader"
dataTypeSemantics="identifier"
elementId="74" applicability="all" status="current">
<description>
<paragraph>
The Label, Exp, and S fields from the label stack entry that
was pushed immediately before the label stack entry that would
be reported by mplsLabelStackSection4. See the definition of
mplsTopLabelStackSection for further details.
</paragraph>
<paragraph>
The size of this Information Element is 3 octets.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 3032.
</paragraph>
</reference>
</field>
<field name="mplsLabelStackSection6" dataType="octetArray"
group="subIpHeader"
dataTypeSemantics="identifier"
elementId="75" applicability="all" status="current">
<description>
<paragraph>
The Label, Exp, and S fields from the label stack entry that
was pushed immediately before the label stack entry that would
be reported by mplsLabelStackSection5. See the definition of
mplsTopLabelStackSection for further details.
</paragraph>
<paragraph>
The size of this Information Element is 3 octets.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 3032.
</paragraph>
</reference>
</field>
<field name="mplsLabelStackSection7" dataType="octetArray"
group="subIpHeader"
dataTypeSemantics="identifier"
elementId="76" applicability="all" status="current">
<description>
<paragraph>
The Label, Exp, and S fields from the label stack entry that
was pushed immediately before the label stack entry that would
be reported by mplsLabelStackSection6. See the definition of
mplsTopLabelStackSection for further details.
</paragraph>
<paragraph>
The size of this Information Element is 3 octets.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 3032.
</paragraph>
</reference>
</field>
<field name="mplsLabelStackSection8" dataType="octetArray"
group="subIpHeader"
dataTypeSemantics="identifier"
elementId="77" applicability="all" status="current">
<description>
<paragraph>
The Label, Exp, and S fields from the label stack entry that
was pushed immediately before the label stack entry that would
be reported by mplsLabelStackSection7. See the definition of
mplsTopLabelStackSection for further details.
</paragraph>
<paragraph>
The size of this Information Element is 3 octets.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 3032.
</paragraph>
</reference>
</field>
<field name="mplsLabelStackSection9" dataType="octetArray"
group="subIpHeader"
dataTypeSemantics="identifier"
elementId="78" applicability="all" status="current">
<description>
<paragraph>
The Label, Exp, and S fields from the label stack entry that
was pushed immediately before the label stack entry that would
be reported by mplsLabelStackSection8. See the definition of
mplsTopLabelStackSection for further details.
</paragraph>
<paragraph>
The size of this Information Element is 3 octets.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 3032.
</paragraph>
</reference>
</field>
<field name="mplsLabelStackSection10" dataType="octetArray"
group="subIpHeader"
dataTypeSemantics="identifier"
elementId="79" applicability="all" status="current">
<description>
<paragraph>
The Label, Exp, and S fields from the label stack entry that
was pushed immediately before the label stack entry that would
be reported by mplsLabelStackSection9. See the definition of
mplsTopLabelStackSection for further details.
</paragraph>
<paragraph>
The size of this Information Element is 3 octets.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 3032.
</paragraph>
</reference>
</field>
<field name="ipPayloadLength" dataType="unsigned32" group="derived" elementId="204" applicability="all" status="current"> <description> <paragraph> The effective length of the IP payload. </paragraph> <paragraph> For IPv4 packets, the value of this Information Element is the difference between the total length of the IPv4 packet (as reported by Information Element totalLengthIPv4) and the length of the IPv4 header (as reported by Information Element headerLengthIPv4). </paragraph> <paragraph> For IPv6, the value of the Payload Length field in the IPv6 header is reported except in the case that the value of this field is zero and that there is a valid jumbo payload option. In this case, the value of the Jumbo Payload Length field in the jumbo payload option is reported. </paragraph> </description> <reference> <paragraph> See RFC 791 for the specification of IPv4 packets. See RFC 2460 for the specification of the IPv6 payload length. See RFC 2675 for the specification of the IPv6 jumbo payload length.
<field name = "ippayloadlength" dataType = "unsigned32" group = "派生" elementId = "204" applicability = "all" status = "current"> <説明> <パラグラフ> IPペイロードの有効長。</paragraph> <paragraph> IPv4パケットの場合、この情報要素の値は、IPv4パケットの総長さ（情報要素totallengthipv4によって報告されている）とIPv4ヘッダーの長さ（情報要素headerlengthipv44444444によって報告されています。）。</paragraph> <paragraph> IPv6の場合、このフィールドの値がゼロであり、有効なジャンボペイロードオプションがある場合を除き、IPv6ヘッダーのペイロード長フィールドの値が報告されます。この場合、ジャンボペイロードオプションのジャンボペイロード長さフィールドの値が報告されています。</paragraph> </description> <参照> <パラグラフ> IPv4パケットの仕様については、RFC 791を参照してください。IPv6ペイロード長の仕様については、RFC 2460を参照してください。IPv6ジャンボペイロード長の仕様については、RFC 2675を参照してください。
</paragraph>
</reference>
<units>octets</units>
</field>
<field name="ipNextHopIPv4Address" dataType="ipv4Address"
group="derived"
dataTypeSemantics="identifier"
elementId="15" applicability="data" status="current">
<description>
<paragraph>
The IPv4 address of the next IPv4 hop.
</paragraph>
</description>
</field>
<field name="ipNextHopIPv6Address" dataType="ipv6Address"
group="derived"
dataTypeSemantics="identifier"
elementId="62" applicability="data" status="current">
<description>
<paragraph>
The IPv6 address of the next IPv6 hop.
</paragraph>
</description>
</field>
<field name="bgpSourceAsNumber" dataType="unsigned32"
group="derived"
dataTypeSemantics="identifier"
elementId="16" applicability="all" status="current">
<description>
<paragraph>
The autonomous system (AS) number of the source IP address.
If AS path information for this Flow is only available as
an unordered AS set (and not as an ordered AS sequence),
then the value of this Information Element is 0.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 4271 for a description of BGP-4, and see RFC 1930
for the definition of the AS number.
</paragraph>
</reference>
</field>
<field name="bgpDestinationAsNumber" dataType="unsigned32"
group="derived"
dataTypeSemantics="identifier"
elementId="17" applicability="all" status="current">
<description>
<paragraph>
The autonomous system (AS) number of the destination IP
address. If AS path information for this Flow is only
available as an unordered AS set (and not as an ordered AS
sequence), then the value of this Information Element is 0.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 4271 for a description of BGP-4, and see RFC 1930 for
the definition of the AS number.
</paragraph>
</reference>
</field>
<field name="bgpNextAdjacentAsNumber" dataType="unsigned32"
group="derived"
dataTypeSemantics="identifier"
elementId="128" applicability="all" status="current">
<description>
<paragraph>
The autonomous system (AS) number of the first AS in the AS
path to the destination IP address. The path is deduced
by looking up the destination IP address of the Flow in the
BGP routing information base. If AS path information for
this Flow is only available as an unordered AS set (and not
as an ordered AS sequence), then the value of this Information
Element is 0.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 4271 for a description of BGP-4, and
see RFC 1930 for the definition of the AS number.
</paragraph>
</reference>
</field>
<field name="bgpPrevAdjacentAsNumber" dataType="unsigned32"
group="derived"
dataTypeSemantics="identifier"
elementId="129" applicability="all" status="current">
<description>
<paragraph>
The autonomous system (AS) number of the last AS in the AS
path from the source IP address. The path is deduced
by looking up the source IP address of the Flow in the BGP
routing information base. If AS path information for this
Flow is only available as an unordered AS set (and not as
an ordered AS sequence), then the value of this Information
Element is 0. In case of BGP asymmetry, the
bgpPrevAdjacentAsNumber might not be able to report the correct
value.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 4271 for a description of BGP-4, and
see RFC 1930 for the definition of the AS number.
</paragraph>
</reference>
</field>
<field name="bgpNextHopIPv4Address" dataType="ipv4Address"
group="derived"
dataTypeSemantics="identifier"
elementId="18" applicability="all" status="current">
<description>
<paragraph>
The IPv4 address of the next (adjacent) BGP hop.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 4271 for a description of BGP-4.
</paragraph>
</reference>
</field>
<field name="bgpNextHopIPv6Address" dataType="ipv6Address"
group="derived"
dataTypeSemantics="identifier"
elementId="63" applicability="all" status="current">
<description>
<paragraph>
The IPv6 address of the next (adjacent) BGP hop.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 4271 for a description of BGP-4.
</paragraph>
</reference>
</field>
<field name="mplsTopLabelType" dataType="unsigned8"
group="derived"
dataTypeSemantics="identifier"
elementId="46" applicability="data" status="current">
<description>
<paragraph>
This field identifies the control protocol that allocated the
top-of-stack label. Initial values for this field are
listed below. Further values may be assigned by IANA in
the MPLS label type registry.
</paragraph>
<artwork>
- 0x01 TE-MIDPT: Any TE tunnel mid-point or tail label
- 0x02 Pseudowire: Any PWE3 or Cisco AToM based label
- 0x03 VPN: Any label associated with VPN
- 0x04 BGP: Any label associated with BGP or BGP routing
- 0x05 LDP: Any label associated with dynamically assigned
labels using LDP
</artwork>
</description>
<reference>
<paragraph>
See RFC 3031 for the MPLS label structure.
See RFC 4364 for the association of MPLS labels
with Virtual Private Networks (VPNs).
See RFC 4271 for BGP and BGP routing.
See RFC 5036 for Label Distribution Protocol (LDP).
See the list of MPLS label types assigned by IANA at
http://www.iana.org/assignments/mpls-label-values.
</paragraph>
</reference>
</field>
<field name="mplsTopLabelIPv4Address" dataType="ipv4Address"
group="derived"
dataTypeSemantics="identifier"
elementId="47" applicability="data" status="current">
<description>
<paragraph>
The IPv4 address of the system that the MPLS top label will
cause this Flow to be forwarded to.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 3031 for the association between
MPLS labels and IP addresses.
</paragraph>
</reference>
</field>
<field name="mplsTopLabelIPv6Address" dataType="ipv6Address"
group="derived"
dataTypeSemantics="identifier"
elementId="140" applicability="data" status="current">
<description>
<paragraph>
The IPv6 address of the system that the MPLS top label will
cause this Flow to be forwarded to.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 3031 for the association between
MPLS labels and IP addresses.
</paragraph>
</reference>
</field>
<field name="mplsVpnRouteDistinguisher" dataType="octetArray" group="derived" dataTypeSemantics="identifier" elementId="90" applicability="all" status="current"> <description> <paragraph> The value of the VPN route distinguisher of a corresponding entry in a VPN routing and forwarding table. Route distinguisher ensures that the same address can be used in several different MPLS VPNs and that it is possible for BGP to carry several completely different routes to that address, one for each VPN. According to RFC 4364, the size of mplsVpnRouteDistinguisher is 8 octets. However, in RFC 4382 an octet string with flexible length was chosen for representing a VPN route distinguisher by object MplsL3VpnRouteDistinguisher. This choice was made in order to be open to future changes of the size. This idea was adopted when choosing octetArray as abstract data type for this Information Element. The maximum length of this Information Element is 256 octets. </paragraph> </description> <reference> <paragraph> See RFC 4364 for the specification of the route distinguisher. See RFC 4382 for the specification of the MPLS/BGP Layer 3 Virtual Private Network (VPN) Management Information Base. </paragraph> </reference> </field>
<field name = "mplsvpnroutedistisiouser" datatype = "octetarray" group = "派生" dataTypesemantics = "識別子" elementId = "90" applicability = "all" status = "> <説明> <paragraph> vpnルートの値VPNルーティングと転送テーブルの対応するエントリの識別者。Route Distinguisherは、いくつかの異なるMPLS VPNで同じアドレスを使用できることを保証し、BGPがそのアドレスにいくつかの完全に異なるルートを運ぶことができることを保証します。RFC 4364によると、MPLSVPNROUTEDISTISTISTISIOMERのサイズは8オクテットです。ただし、RFC 4382では、オブジェクトMPLSL3VPNROUTEDISTINGISIOMERでVPNルートの区別器を表すために、柔軟な長さのOctet Stringが選択されました。この選択は、サイズの将来の変化に開かれるために行われました。このアイデアは、この情報要素の抽象データ型としてOctetArrayを選択する際に採用されました。この情報要素の最大長は256オクテットです。</paragraph> </description> <seference> <paragraph>ルートの違いについては、RFC 4364を参照してください。MPLS/BGPレイヤー3仮想プライベートネットワーク（VPN）管理情報ベースの仕様については、RFC 4382を参照してください。</paragraph> </reference> </field>
<field name="minimumIpTotalLength" dataType="unsigned64"
group="minMax"
elementId="25" applicability="all" status="current">
<description>
<paragraph>
Length of the smallest packet observed for this Flow.
The packet length includes the IP header(s) length and
the IP payload length.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 791 for the specification of the
IPv4 total length.
See RFC 2460 for the specification of the
IPv6 payload length.
See RFC 2675 for the specification of the
IPv6 jumbo payload length.
</paragraph>
</reference>
<units>octets</units>
</field>
<field name="maximumIpTotalLength" dataType="unsigned64" group="minMax" elementId="26" applicability="all" status="current"> <description> <paragraph> Length of the largest packet observed for this Flow. The packet length includes the IP header(s) length and the IP payload length. </paragraph> </description> <reference> <paragraph> See RFC 791 for the specification of the IPv4 total length. See RFC 2460 for the specification of the IPv6 payload length. See RFC 2675 for the specification of the IPv6 jumbo payload length.
<field name = "maximipiptotallength" datatype = "unsigned64" group = "minmax" elementId = "26" applicability = "all" status = "current = <説明> <パラグラフ>このフローで観察される最大のパケットの長さ。パケットの長さには、IPヘッダーの長さとIPペイロード長が含まれます。</paragraph> </description> <参照> <パラグラフ> IPv4の合計長の仕様については、RFC 791を参照してください。IPv6ペイロード長の仕様については、RFC 2460を参照してください。IPv6ジャンボペイロード長の仕様については、RFC 2675を参照してください。
</paragraph>
</reference>
<units>octets</units>
</field>
<field name="minimumTTL" dataType="unsigned8"
group="minMax"
elementId="52" applicability="data" status="current">
<description>
<paragraph>
Minimum TTL value observed for any packet in this Flow.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 791 for the definition of the IPv4
Time to Live field.
See RFC 2460 for the definition of the IPv6
Hop Limit field.
</paragraph>
</reference>
<units>hops</units>
</field>
<field name="maximumTTL" dataType="unsigned8"
group="minMax"
elementId="53" applicability="data" status="current">
<description>
<paragraph>
Maximum TTL value observed for any packet in this Flow.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 791 for the definition of the IPv4
Time to Live field.
See RFC 2460 for the definition of the IPv6
Hop Limit field.
</paragraph>
</reference>
<units>hops</units>
</field>
<field name="ipv4Options" dataType="unsigned32"
dataTypeSemantics="flags"
group="minMax"
elementId="208" applicability="all" status="current">
<description>
<paragraph>
IPv4 options in packets of this Flow.
The information is encoded in a set of bit fields. For
each valid IPv4 option type, there is a bit in this set.
The bit is set to 1 if any observed packet of this Flow
contains the corresponding IPv4 option type. Otherwise,
if no observed packet of this Flow contained the
respective IPv4 option type, the value of the
corresponding bit is 0.
</paragraph>
<paragraph>
The list of valid IPv4 options is maintained by IANA.
Note that for identifying an option not just the 5-bit
Option Number, but all 8 bits of the Option Type need to
match one of the IPv4 options specified at
http://www.iana.org/assignments/ip-parameters.
</paragraph>
<paragraph>
Options are mapped to bits according to their option numbers.
Option number X is mapped to bit X.
The mapping is illustrated by the figure below.
</paragraph>
<artwork>
0 1 2 3 4 5 6 7
+------+------+------+------+------+------+------+------+
| EOOL | NOP | SEC | LSR | TS |E-SEC |CIPSO | RR | ...
+------+------+------+------+------+------+------+------+
8 9 10 11 12 13 14 15
+------+------+------+------+------+------+------+------+
... | SID | SSR | ZSU | MTUP | MTUR | FINN | VISA |ENCODE| ...
+------+------+------+------+------+------+------+------+
16 17 18 19 20 21 22 23
+------+------+------+------+------+------+------+------+
... |IMITD | EIP | TR |ADDEXT|RTRALT| SDB |NSAPA | DPS | ...
+------+------+------+------+------+------+------+------+
24 25 26 27 28 29 30 31
+------+------+------+------+------+------+------+------+
... | UMP | QS | to be assigned by IANA | EXP | |
+------+------+------+------+------+------+------+------+
Type Option
Bit Value Name Reference
---+-----+-------+------------------------------------
0 0 EOOL End of Options List, RFC 791
1 1 NOP No Operation, RFC 791
2 130 SEC Security, RFC 1108
3 131 LSR Loose Source Route, RFC 791
4 68 TS Time Stamp, RFC 791
5 133 E-SEC Extended Security, RFC 1108
6 134 CIPSO Commercial Security
7 7 RR Record Route, RFC 791
8 136 SID Stream ID, RFC 791
9 137 SSR Strict Source Route, RFC 791
10 10 ZSU Experimental Measurement
11 11 MTUP (obsoleted) MTU Probe, RFC 1191
12 12 MTUR (obsoleted) MTU Reply, RFC 1191
13 205 FINN Experimental Flow Control
14 142 VISA Experimental Access Control
15 15 ENCODE
16 144 IMITD IMI Traffic Descriptor
17 145 EIP Extended Internet Protocol, RFC 1385
18 82 TR Traceroute, RFC 3193
19 147 ADDEXT Address Extension
20 148 RTRALT Router Alert, RFC 2113
21 149 SDB Selective Directed Broadcast
22 150 NSAPA NSAP Address
23 151 DPS Dynamic Packet State
24 152 UMP Upstream Multicast Pkt.
25 25 QS Quick-Start
30 30 EXP RFC3692-style Experiment
30 94 EXP RFC3692-style Experiment
30 158 EXP RFC3692-style Experiment
30 222 EXP RFC3692-style Experiment
... ... ... Further options numbers
may be assigned by IANA
</artwork>
</description>
<reference>
<paragraph>
See RFC 791 for the definition of IPv4 options.
See the list of IPv4 option numbers assigned by IANA
at http://www.iana.org/assignments/ip-parameters.
</paragraph>
</reference>
</field>
<field name="ipv6ExtensionHeaders" dataType="unsigned32"
dataTypeSemantics="flags"
group="minMax"
elementId="64" applicability="all" status="current">
<description>
<paragraph>
IPv6 extension headers observed in packets of this Flow.
The information is encoded in a set of bit fields. For
each IPv6 option header, there is a bit in this set.
The bit is set to 1 if any observed packet of this Flow
contains the corresponding IPv6 extension header.
Otherwise, if no observed packet of this Flow contained
the respective IPv6 extension header, the value of the
corresponding bit is 0.
</paragraph>
<artwork>
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| Res | FRA1| RH | FRA0| UNK | Res | HOP | DST | ...
+-----+-----+-----+-----+-----+-----+-----+-----+
8 9 10 11 12 13 14 15
+-----+-----+-----+-----+-----+-----+-----+-----+
... | PAY | AH | ESP | Reserved | ...
+-----+-----+-----+-----+-----+-----+-----+-----+
16 17 18 19 20 21 22 23
+-----+-----+-----+-----+-----+-----+-----+-----+
... | Reserved | ...
+-----+-----+-----+-----+-----+-----+-----+-----+
24 25 26 27 28 29 30 31
+-----+-----+-----+-----+-----+-----+-----+-----+
... | Reserved |
+-----+-----+-----+-----+-----+-----+-----+-----+
Bit IPv6 Option Description
0, Res Reserved
1, FRA1 44 Fragmentation header - not first fragment
2, RH 43 Routing header
3, FRA0 44 Fragment header - first fragment
4, UNK Unknown Layer 4 header
(compressed, encrypted, not supported)
5, Res Reserved
6, HOP 0 Hop-by-hop option header
7, DST 60 Destination option header
8, PAY 108 Payload compression header
9, AH 51 Authentication Header
10, ESP 50 Encrypted security payload
11 to 31 Reserved
</artwork>
</description>
<reference>
<paragraph>
See RFC 2460 for the general definition of
IPv6 extension headers and for the specification of
the hop-by-hop options header, the routing header,
the fragment header, and the destination options header.
See RFC 4302 for the specification of the
authentication header.
See RFC 4303 for the specification of the
encapsulating security payload.
</paragraph>
</reference>
</field>
<field name="tcpControlBits" dataType="unsigned8"
dataTypeSemantics="flags"
group="minMax"
elementId="6" applicability="all" status="current">
<description>
<paragraph>
TCP control bits observed for packets of this Flow.
The information is encoded in a set of bit fields.
For each TCP control bit, there is a bit in this
set. A bit is set to 1 if any observed packet of this
Flow has the corresponding TCP control bit set to 1.
A value of 0 for a bit indicates that the corresponding
bit was not set in any of the observed packets
of this Flow.
</paragraph>
<artwork>
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| Reserved | URG | ACK | PSH | RST | SYN | FIN |
+-----+-----+-----+-----+-----+-----+-----+-----+
Reserved: Reserved for future use by TCP. Must be zero.
URG: Urgent Pointer field significant
ACK: Acknowledgment field significant
PSH: Push Function
RST: Reset the connection
SYN: Synchronize sequence numbers
FIN: No more data from sender
</artwork>
</description>
<reference>
<paragraph>
See RFC 793 for the definition of
the TCP control bits in the TCP header.
</paragraph>
</reference>
</field>
<field name="tcpOptions" dataType="unsigned64"
dataTypeSemantics="flags"
group="minMax"
elementId="209" applicability="all" status="current">
<description>
<paragraph>
TCP options in packets of this Flow.
The information is encoded in a set of bit fields. For
each TCP option, there is a bit in this set.
The bit is set to 1 if any observed packet of this Flow
contains the corresponding TCP option.
Otherwise, if no observed packet of this Flow contained
the respective TCP option, the value of the
corresponding bit is 0.
</paragraph>
<paragraph>
Options are mapped to bits according to their option
numbers. Option number X is mapped to bit X.
TCP option numbers are maintained by IANA.
</paragraph>
<artwork>
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+
8 9 10 11 12 13 14 15
+-----+-----+-----+-----+-----+-----+-----+-----+
... | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 |...
+-----+-----+-----+-----+-----+-----+-----+-----+
16 17 18 19 20 21 22 23
+-----+-----+-----+-----+-----+-----+-----+-----+
... | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 |...
+-----+-----+-----+-----+-----+-----+-----+-----+
. . .
。。。
56 57 58 59 60 61 62 63
+-----+-----+-----+-----+-----+-----+-----+-----+
... | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 |
+-----+-----+-----+-----+-----+-----+-----+-----+
</artwork>
</description>
<reference>
<paragraph>
See RFC 793 for the definition of TCP options.
See the list of TCP option numbers assigned by IANA
at http://www.iana.org/assignments/tcp-parameters.
</paragraph>
</reference>
</field>
<field name="flowStartSeconds" dataType="dateTimeSeconds"
group="timestamp"
elementId="150" applicability="data" status="current">
<description>
<paragraph>
The absolute timestamp of the first packet of this Flow.
</paragraph>
</description>
<units>seconds</units>
</field>
<field name="flowEndSeconds" dataType="dateTimeSeconds"
group="timestamp"
elementId="151" applicability="data" status="current">
<description>
<paragraph>
The absolute timestamp of the last packet of this Flow.
</paragraph>
</description>
<units>seconds</units>
</field>
<field name="flowStartMilliseconds" dataType="dateTimeMilliseconds"
group="timestamp"
elementId="152" applicability="data" status="current">
<description>
<paragraph>
The absolute timestamp of the first packet of this Flow.
</paragraph>
</description>
<units>milliseconds</units>
</field>
<field name="flowEndMilliseconds" dataType="dateTimeMilliseconds"
group="timestamp"
elementId="153" applicability="data" status="current">
<description>
<paragraph>
The absolute timestamp of the last packet of this Flow.
</paragraph>
</description>
<units>milliseconds</units>
</field>
<field name="flowStartMicroseconds" dataType="dateTimeMicroseconds"
group="timestamp"
elementId="154" applicability="data" status="current">
<description>
<paragraph>
The absolute timestamp of the first packet of this Flow.
</paragraph>
</description>
<units>microseconds</units>
</field>
<field name="flowEndMicroseconds" dataType="dateTimeMicroseconds"
group="timestamp"
elementId="155" applicability="data" status="current">
<description>
<paragraph>
The absolute timestamp of the last packet of this Flow.
</paragraph>
</description>
<units>microseconds</units>
</field>
<field name="flowStartNanoseconds" dataType="dateTimeNanoseconds"
group="timestamp"
elementId="156" applicability="data" status="current">
<description>
<paragraph>
The absolute timestamp of the first packet of this Flow.
</paragraph>
</description>
<units>nanoseconds</units>
</field>
<field name="flowEndNanoseconds" dataType="dateTimeNanoseconds"
group="timestamp"
elementId="157" applicability="data" status="current">
<description>
<paragraph>
The absolute timestamp of the last packet of this Flow.
</paragraph>
</description>
<units>nanoseconds</units>
</field>
<field name="flowStartDeltaMicroseconds" dataType="unsigned32"
group="timestamp"
elementId="158" applicability="data" status="current">
<description>
<paragraph>
This is a relative timestamp only valid within the scope
of a single IPFIX Message. It contains the negative time
offset of the first observed packet of this Flow relative
to the export time specified in the IPFIX Message Header.
</paragraph>
</description>
<reference>
<paragraph>
See the IPFIX protocol specification [RFC5101] for the
definition of the IPFIX Message Header.
</paragraph>
</reference>
<units>microseconds</units>
</field>
<field name="flowEndDeltaMicroseconds" dataType="unsigned32"
group="timestamp"
elementId="159" applicability="data" status="current">
<description>
<paragraph>
This is a relative timestamp only valid within the scope
of a single IPFIX Message. It contains the negative time
offset of the last observed packet of this Flow relative
to the export time specified in the IPFIX Message Header.
</paragraph>
</description>
<reference>
<paragraph>
See the IPFIX protocol specification [RFC5101] for the
definition of the IPFIX Message Header.
</paragraph>
</reference>
<units>microseconds</units>
</field>
<field name="systemInitTimeMilliseconds"
dataType="dateTimeMilliseconds"
group="timestamp"
elementId="160" applicability="data" status="current">
<description>
<paragraph>
The absolute timestamp of the last (re-)initialization of the
IPFIX Device.
</paragraph>
</description>
<units>milliseconds</units>
</field>
<field name="flowStartSysUpTime" dataType="unsigned32"
group="timestamp"
elementId="22" applicability="data" status="current">
<description>
<paragraph>
The relative timestamp of the first packet of this Flow.
It indicates the number of milliseconds since the
last (re-)initialization of the IPFIX Device (sysUpTime).
</paragraph>
</description>
<units>milliseconds</units>
</field>
<field name="flowEndSysUpTime" dataType="unsigned32"
group="timestamp"
elementId="21" applicability="data" status="current">
<description>
<paragraph>
The relative timestamp of the last packet of this Flow.
It indicates the number of milliseconds since the
last (re-)initialization of the IPFIX Device (sysUpTime).
</paragraph>
</description>
<units>milliseconds</units>
</field>
<field name="octetDeltaCount" dataType="unsigned64"
dataTypeSemantics="deltaCounter"
group="flowCounter"
elementId="1" applicability="data" status="current">
<description>
<paragraph>
The number of octets since the previous report (if any)
in incoming packets for this Flow at the Observation Point.
The number of octets includes IP header(s) and IP payload.
</paragraph>
</description>
<units>octets</units>
</field>
<field name="postOctetDeltaCount" dataType="unsigned64"
dataTypeSemantics="deltaCounter"
group="flowCounter"
elementId="23" applicability="data" status="current">
<description>
<paragraph>
The definition of this Information Element is identical
to the definition of Information Element
'octetDeltaCount', except that it reports a
potentially modified value caused by a middlebox
function after the packet passed the Observation Point.
</paragraph>
</description>
<units>octets</units>
</field>
<field name="octetDeltaSumOfSquares" dataType="unsigned64"
group="flowCounter"
elementId="198" applicability="data" status="current">
<description>
<paragraph>
The sum of the squared numbers of octets per incoming
packet since the previous report (if any) for this
Flow at the Observation Point.
The number of octets includes IP header(s) and IP payload.
</paragraph>
</description>
</field>
<field name="octetTotalCount" dataType="unsigned64"
dataTypeSemantics="totalCounter"
group="flowCounter"
elementId="85" applicability="all" status="current">
<description>
<paragraph>
The total number of octets in incoming packets
for this Flow at the Observation Point since the Metering
Process (re-)initialization for this Observation Point. The
number of octets includes IP header(s) and IP payload.
</paragraph>
</description>
<units>octets</units>
</field>
<field name="postOctetTotalCount" dataType="unsigned64"
dataTypeSemantics="totalCounter"
group="flowCounter"
elementId="171" applicability="all" status="current">
<description>
<paragraph>
The definition of this Information Element is identical
to the definition of Information Element
'octetTotalCount', except that it reports a
potentially modified value caused by a middlebox
function after the packet passed the Observation Point.
</paragraph>
</description>
<units>octets</units>
</field>
<field name="octetTotalSumOfSquares" dataType="unsigned64"
group="flowCounter"
elementId="199" applicability="all" status="current">
<description>
<paragraph>
The total sum of the squared numbers of octets in incoming
packets for this Flow at the Observation Point since the
Metering Process (re-)initialization for this Observation
Point. The number of octets includes IP header(s) and IP
payload.
</paragraph>
</description>
<units>octets</units>
</field>
<field name="packetDeltaCount" dataType="unsigned64"
dataTypeSemantics="deltaCounter"
group="flowCounter"
elementId="2" applicability="data" status="current">
<description>
<paragraph>
The number of incoming packets since the previous report
(if any) for this Flow at the Observation Point.
</paragraph>
</description>
<units>packets</units>
</field>
<field name="postPacketDeltaCount" dataType="unsigned64"
dataTypeSemantics="deltaCounter"
group="flowCounter"
elementId="24" applicability="data" status="current">
<description>
<paragraph>
The definition of this Information Element is identical
to the definition of Information Element
'packetDeltaCount', except that it reports a
potentially modified value caused by a middlebox
function after the packet passed the Observation Point.
</paragraph>
</description>
<units>packets</units>
</field>
<field name="packetTotalCount" dataType="unsigned64"
dataTypeSemantics="totalCounter"
group="flowCounter"
elementId="86" applicability="all" status="current">
<description>
<paragraph>
The total number of incoming packets for this Flow
at the Observation Point since the Metering Process
(re-)initialization for this Observation Point.
</paragraph>
</description>
<units>packets</units>
</field>
<field name="postPacketTotalCount" dataType="unsigned64"
dataTypeSemantics="totalCounter"
group="flowCounter"
elementId="172" applicability="all" status="current">
<description>
<paragraph>
The definition of this Information Element is identical
to the definition of Information Element
'packetTotalCount', except that it reports a
potentially modified value caused by a middlebox
function after the packet passed the Observation Point.
</paragraph>
</description>
<units>packets</units>
</field>
<field name="droppedOctetDeltaCount" dataType="unsigned64"
dataTypeSemantics="deltaCounter"
group="flowCounter"
elementId="132" applicability="data" status="current">
<description>
<paragraph>
The number of octets since the previous report (if any)
in packets of this Flow dropped by packet treatment.
The number of octets includes IP header(s) and IP payload.
</paragraph>
</description>
<units>octets</units>
</field>
<field name="droppedPacketDeltaCount" dataType="unsigned64"
dataTypeSemantics="deltaCounter"
group="flowCounter"
elementId="133" applicability="data" status="current">
<description>
<paragraph>
The number of packets since the previous report (if any)
of this Flow dropped by packet treatment.
</paragraph>
</description>
<units>packets</units>
</field>
<field name="droppedOctetTotalCount" dataType="unsigned64"
dataTypeSemantics="totalCounter"
group="flowCounter"
elementId="134" applicability="data" status="current">
<description>
<paragraph>
The total number of octets in packets of this Flow dropped
by packet treatment since the Metering Process
(re-)initialization for this Observation Point.
The number of octets includes IP header(s) and IP payload.
</paragraph>
</description>
<units>octets</units>
</field>
<field name="droppedPacketTotalCount" dataType="unsigned64"
dataTypeSemantics="totalCounter"
group="flowCounter"
elementId="135" applicability="data" status="current">
<description>
<paragraph>
The number of packets of this Flow dropped by packet
treatment since the Metering Process
(re-)initialization for this Observation Point.
</paragraph>
</description>
<units>packets</units>
</field>
<field name="postMCastPacketDeltaCount" dataType="unsigned64"
dataTypeSemantics="deltaCounter"
group="flowCounter"
elementId="19" applicability="data" status="current">
<description>
<paragraph>
The number of outgoing multicast packets since the
previous report (if any) sent for packets of this Flow
by a multicast daemon within the Observation Domain.
This property cannot necessarily be observed at the
Observation Point, but may be retrieved by other means.
</paragraph>
</description>
<units>packets</units>
</field>
<field name="postMCastOctetDeltaCount" dataType="unsigned64"
dataTypeSemantics="deltaCounter"
group="flowCounter"
elementId="20" applicability="data" status="current">
<description>
<paragraph>
The number of octets since the previous report (if any)
in outgoing multicast packets sent for packets of this
Flow by a multicast daemon within the Observation Domain.
This property cannot necessarily be observed at the
Observation Point, but may be retrieved by other means.
The number of octets includes IP header(s) and IP payload.
</paragraph>
</description>
<units>octets</units>
</field>
<field name="postMCastPacketTotalCount" dataType="unsigned64"
dataTypeSemantics="totalCounter"
group="flowCounter"
elementId="174" applicability="data" status="current">
<description>
<paragraph>
The total number of outgoing multicast packets sent for
packets of this Flow by a multicast daemon within the
Observation Domain since the Metering Process
(re-)initialization. This property cannot necessarily
be observed at the Observation Point, but may be retrieved
by other means.
</paragraph>
</description>
<units>packets</units>
</field>
<field name="postMCastOctetTotalCount" dataType="unsigned64"
dataTypeSemantics="totalCounter"
group="flowCounter"
elementId="175" applicability="data" status="current">
<description>
<paragraph>
The total number of octets in outgoing multicast packets
sent for packets of this Flow by a multicast daemon in the
Observation Domain since the Metering Process
(re-)initialization. This property cannot necessarily be
observed at the Observation Point, but may be retrieved by
other means.
The number of octets includes IP header(s) and IP payload.
</paragraph>
</description>
<units>octets</units>
</field>
<field name="tcpSynTotalCount" dataType="unsigned64"
dataTypeSemantics="totalCounter"
group="flowCounter"
elementId="218" applicability="data" status="current">
<description>
<paragraph>
The total number of packets of this Flow with
TCP "Synchronize sequence numbers" (SYN) flag set.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 793 for the definition of the TCP SYN flag.
</paragraph>
</reference>
<units>packets</units>
</field>
<field name="tcpFinTotalCount" dataType="unsigned64"
dataTypeSemantics="totalCounter"
group="flowCounter"
elementId="219" applicability="data" status="current">
<description>
<paragraph>
The total number of packets of this Flow with
TCP "No more data from sender" (FIN) flag set.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 793 for the definition of the TCP FIN flag.
</paragraph>
</reference>
<units>packets</units>
</field>
<field name="tcpRstTotalCount" dataType="unsigned64"
dataTypeSemantics="totalCounter"
group="flowCounter"
elementId="220" applicability="data" status="current">
<description>
<paragraph>
The total number of packets of this Flow with
TCP "Reset the connection" (RST) flag set.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 793 for the definition of the TCP RST flag.
</paragraph>
</reference>
<units>packets</units>
</field>
<field name="tcpPshTotalCount" dataType="unsigned64"
dataTypeSemantics="totalCounter"
group="flowCounter"
elementId="221" applicability="data" status="current">
<description>
<paragraph>
The total number of packets of this Flow with
TCP "Push Function" (PSH) flag set.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 793 for the definition of the TCP PSH flag.
</paragraph>
</reference>
<units>packets</units>
</field>
<field name="tcpAckTotalCount" dataType="unsigned64"
dataTypeSemantics="totalCounter"
group="flowCounter"
elementId="222" applicability="data" status="current">
<description>
<paragraph>
The total number of packets of this Flow with
TCP "Acknowledgment field significant" (ACK) flag set.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 793 for the definition of the TCP ACK flag.
</paragraph>
</reference>
<units>packets</units>
</field>
<field name="tcpUrgTotalCount" dataType="unsigned64"
dataTypeSemantics="totalCounter"
group="flowCounter"
elementId="223" applicability="data" status="current">
<description>
<paragraph>
The total number of packets of this Flow with
TCP "Urgent Pointer field significant" (URG) flag set.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 793 for the definition of the TCP URG flag.
</paragraph>
</reference>
<units>packets</units>
</field>
<field name="flowActiveTimeout" dataType="unsigned16"
group="misc"
elementId="36" applicability="all" status="current">
<description>
<paragraph>
The number of seconds after which an active Flow is timed out
anyway, even if there is still a continuous flow of packets.
</paragraph>
</description>
<units>seconds</units>
</field>
<field name="flowIdleTimeout" dataType="unsigned16"
group="misc"
elementId="37" applicability="all" status="current">
<description>
<paragraph>
A Flow is considered to be timed out if no packets belonging
to the Flow have been observed for the number of seconds
specified by this field.
</paragraph>
</description>
<units>seconds</units>
</field>
<field name="flowEndReason" dataType="unsigned8"
group="misc" dataTypeSemantics="identifier" elementId="136" applicability="data" status="current"> <description> <paragraph> The reason for Flow termination. The range of values includes the following: </paragraph> <artwork> 0x01: idle timeout The Flow was terminated because it was considered to be idle. 0x02: active timeout The Flow was terminated for reporting purposes while it was still active, for example, after the maximum lifetime of unreported Flows was reached. 0x03: end of Flow detected The Flow was terminated because the Metering Process detected signals indicating the end of the Flow, for example, the TCP FIN flag. 0x04: forced end The Flow was terminated because of some external event, for example, a shutdown of the Metering Process initiated by a network management application. 0x05: lack of resources The Flow was terminated because of lack of resources available to the Metering Process and/or the Exporting Process. </artwork> </description> </field>
group = "Misc" dataTypeSemantics = "識別子" ElementId = "136" applicability = "data" status = "current"> <description> <paragraph>フロー終了の理由。値の範囲には、次のものが含まれます。</paragraph> <artwork> 0x01：アイドルタイムアウトは、アイドルと見なされたため、フローが終了しました。0x02：アクティブなタイムアウトは、報告目的で終了しましたが、たとえば、報告されていないフローの最大寿命に到達した後、まだアクティブでした。0x03：流れの終了は、メータープロセスがTCP FINフラグなどの流れの終了を示す信号を検出したため、流れが終了しました。0x04：強制終了は、外部イベント、たとえばネットワーク管理アプリケーションによって開始された計量プロセスのシャットダウンにより、フローが終了しました。0x05：リソースの不足メータープロセスや輸出プロセスに利用可能なリソースが不足しているため、フローは終了しました。</artwork> </description> </field>
<field name="flowDurationMilliseconds" dataType="unsigned32"
group="misc"
elementId="161" applicability="data" status="current">
<description>
<paragraph>
The difference in time between the first observed packet
of this Flow and the last observed packet of this Flow.
</paragraph>
</description>
<units>milliseconds</units>
</field>
<field name="flowDurationMicroseconds" dataType="unsigned32"
group="misc"
elementId="162" applicability="data" status="current">
<description>
<paragraph>
The difference in time between the first observed packet
of this Flow and the last observed packet of this Flow.
</paragraph>
</description>
<units>microseconds</units>
</field>
<field name="flowDirection" dataType="unsigned8"
dataTypeSemantics="identifier"
group="misc"
elementId="61" applicability="data" status="current">
<description>
<paragraph>
The direction of the Flow observed at the Observation
Point. There are only two values defined.
</paragraph>
<artwork>
0x00: ingress flow
0x01: egress flow
</artwork>
</description>
</field>
<field name="paddingOctets" dataType="octetArray"
group="padding"
elementId="210" applicability="option" status="current">
<description>
<paragraph>
The value of this Information Element is always a sequence of
0x00 values.
</paragraph>
</description>
</field>
</fieldDefinitions>
</fielddefinitions>
This appendix contains a machine-readable description of the abstract data types to be used for IPFIX Information Elements and a machine-readable description of the template used for defining IPFIX Information Elements. Note that this appendix is of informational nature, while the text in Sections 2 and 3 (generated from this appendix) is normative.
この付録には、IPFIX情報要素に使用される抽象データ型の機械読み取り可能な説明と、IPFIX情報要素の定義に使用されるテンプレートの機械読み取り可能な説明が含まれています。この付録は情報性の性質のものであり、セクション2および3のテキスト（この付録から生成）は規範的であることに注意してください。
At the same time, this appendix is also an XML schema that was used for creating the XML specification of Information Elements in Appendix A. It may also be used for specifying further Information Elements in extensions of the IPFIX information model. This schema and its namespace are registered by IANA at http://www.iana.org/assignments/xml-registry/schema/ipfix.xsd.
同時に、この付録は、付録Aの情報要素のXML仕様を作成するために使用されたXMLスキーマでもあります。IPFIX情報モデルの拡張にさらなる情報要素を指定するためにも使用できます。このスキーマとそのネームスペースは、http://www.iana.org/assignments/xml-registry/schema/ipfix.xsdでianaによって登録されています。
<?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="urn:ietf:params:xml:ns:ipfix-info"
xmlns:ipfix="urn:ietf:params:xml:ns:ipfix-info"
xmlns="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<simpleType name="dataType">
<restriction base="string">
<enumeration value="unsigned8">
<annotation>
<documentation>The type "unsigned8" represents a
non-negative integer value in the range of 0 to 255.
</documentation>
</annotation>
</enumeration>
<enumeration value="unsigned16">
<annotation>
<documentation>The type "unsigned16" represents a
non-negative integer value in the range of 0 to 65535.
</documentation>
</annotation>
</enumeration>
<enumeration value="unsigned32">
<annotation>
<documentation>The type "unsigned32" represents a
non-negative integer value in the range of 0 to
4294967295.
</documentation>
</annotation>
</enumeration>
<enumeration value="unsigned64">
<annotation>
<documentation>The type "unsigned64" represents a
non-negative integer value in the range of 0 to
18446744073709551615.
</documentation>
</annotation>
</enumeration>
<enumeration value="signed8">
<annotation>
<documentation>The type "signed8" represents
an integer value in the range of -128 to 127.
</documentation>
</annotation>
</enumeration>
<enumeration value="signed16">
<annotation>
<documentation>The type "signed16" represents an
integer value in the range of -32768 to 32767.
</documentation>
</annotation>
</enumeration>
<enumeration value="signed32">
<annotation>
<documentation>The type "signed32" represents an
integer value in the range of -2147483648 to
2147483647.
</documentation>
</annotation>
</enumeration>
<enumeration value="signed64">
<annotation>
<documentation>The type "signed64" represents an
integer value in the range of -9223372036854775808
to 9223372036854775807.
</documentation>
</annotation>
</enumeration>
<enumeration value="float32">
<annotation>
<documentation>The type "float32" corresponds to an IEEE
single-precision 32-bit floating point type as defined
in [IEEE.754.1985].
</documentation>
</annotation>
</enumeration>
<enumeration value="float64"> <annotation> <documentation>The type "float64" corresponds to an IEEE double-precision 64-bit floating point type as defined in [IEEE.754.1985].
<enumeration value = "float64"> <annotation> <ドキュメント> "float64"は、[IEEE.754.1985]で定義されているIEEEダブルエシジョン64ビットフローティングポイントタイプに対応します。
</documentation>
</annotation>
</enumeration>
<enumeration value="boolean">
<annotation>
<documentation>The type "boolean" represents a binary
value. The only allowed values are "true" and "false".
</documentation>
</annotation>
</enumeration>
<enumeration value="macAddress">
<annotation>
<documentation>The type "macAddress" represents a
string of 6 octets.
</documentation>
</annotation>
</enumeration>
<enumeration value="octetArray">
<annotation>
<documentation>The type "octetArray" represents a
finite-length string of octets.
</documentation>
</annotation>
</enumeration>
<enumeration value="string">
<annotation>
<documentation>
The type "string" represents a finite-length string
of valid characters from the Unicode character encoding
set [ISO.10646-1.1993]. Unicode allows for ASCII
[ISO.646.1991] and many other international character
sets to be used.
</documentation>
</annotation>
</enumeration>
<enumeration value="dateTimeSeconds"> <annotation> <documentation> The type "dateTimeSeconds" represents a time value in units of seconds based on coordinated universal time (UTC). The choice of an epoch, for example, 00:00 UTC, January 1, 1970, is left to corresponding encoding specifications for this type, for example, the IPFIX protocol specification. Leap seconds are excluded. Note that transformation of values might be required between different encodings if different epoch values are used. </documentation> </annotation> </enumeration>
<enumeration value = "dateTimeseConds"> <Annotation> <ドキュメント>タイプ「DateTimeseConds」は、調整されたユニバーサル時間（UTC）に基づいて秒単位の時間値を表します。たとえば、1970年1月1日、00:00 UTCなどのエポックの選択は、このタイプの対応するエンコード仕様、たとえばIPFIXプロトコル仕様に任されています。跳躍秒は除外されます。異なるエポック値が使用される場合、異なるエンコーディング間で値の変換が必要になる場合があることに注意してください。</documentation> </annotation> </enumeration>
<enumeration value="dateTimeMilliseconds"> <annotation> <documentation>The type "dateTimeMilliseconds" represents a time value in units of milliseconds based on coordinated universal time (UTC). The choice of an epoch, for example, 00:00 UTC, January 1, 1970, is left to corresponding encoding specifications for this type, for example, the IPFIX protocol specification. Leap seconds are excluded. Note that transformation of values might be required between different encodings if different epoch values are used. </documentation> </annotation> </enumeration>
<enumeration value = "datetimemilliseconds"> <Annotation> <ドキュメント>タイプ "DateTimemilliseConds"は、調整されたユニバーサル時間（UTC）に基づいてミリ秒単位の時間値を表します。たとえば、1970年1月1日、00:00 UTCなどのエポックの選択は、このタイプの対応するエンコード仕様、たとえばIPFIXプロトコル仕様に任されています。跳躍秒は除外されます。異なるエポック値が使用される場合、異なるエンコーディング間で値の変換が必要になる場合があることに注意してください。</documentation> </annotation> </enumeration>
<enumeration value="dateTimeMicroseconds"> <annotation> <documentation>The type "dateTimeMicroseconds" represents a time value in units of microseconds based on coordinated universal time (UTC). The choice of an epoch, for example, 00:00 UTC, January 1, 1970, is left to corresponding encoding specifications for this type, for example, the IPFIX protocol specification. Leap seconds are excluded. Note that transformation of values might be required between different encodings if different epoch values are used. </documentation> </annotation> </enumeration>
<enumeration value = "dateTimemicRoseConds"> <Annotation> <Documentation>タイプ "DateTimemicRoseconds"は、調整されたユニバーサル時間（UTC）に基づくマイクロ秒単位の時間値を表します。たとえば、1970年1月1日、00:00 UTCなどのエポックの選択は、このタイプの対応するエンコード仕様、たとえばIPFIXプロトコル仕様に任されています。跳躍秒は除外されます。異なるエポック値が使用される場合、異なるエンコーディング間で値の変換が必要になる場合があることに注意してください。</documentation> </annotation> </enumeration>
<enumeration value="dateTimeNanoseconds"> <annotation> <documentation>The type "dateTimeNanoseconds" represents a time value in units of nanoseconds based on coordinated universal time (UTC). The choice of an epoch, for example, 00:00 UTC, January 1, 1970, is left to corresponding encoding specifications for this type, for example, the IPFIX protocol specification. Leap seconds are excluded. Note that transformation of values might be required between different encodings if different epoch values are used. </documentation> </annotation> </enumeration>
<enumeration value = "DateTimenanAnoconds"> <Annotation> <Documentation>タイプ "DateTimenanoSoconds"は、調整されたユニバーサル時間（UTC）に基づいてナノ秒単位の時間値を表します。たとえば、1970年1月1日、00:00 UTCなどのエポックの選択は、このタイプの対応するエンコード仕様、たとえばIPFIXプロトコル仕様に任されています。跳躍秒は除外されます。異なるエポック値が使用される場合、異なるエンコーディング間で値の変換が必要になる場合があることに注意してください。</documentation> </annotation> </enumeration>
<enumeration value="ipv4Address">
<annotation>
<documentation>The type "ipv4Address" represents a value
of an IPv4 address.
</documentation>
</annotation>
</enumeration>
<enumeration value="ipv6Address">
<annotation>
<documentation>The type "ipv6Address" represents a value
of an IPv6 address.
</documentation>
</annotation>
</enumeration>
</restriction>
</simpleType>
<simpleType name="dataTypeSemantics">
<restriction base="string">
<enumeration value="quantity">
<annotation>
<documentation>
A quantity value represents a discrete
measured value pertaining to the record. This is
distinguished from counters that represent an ongoing
measured value whose "odometer" reading is captured as
part of a given record. If no semantic qualifier is
given, the Information Elements that have an integral
data type should behave as a quantity.
</documentation>
</annotation>
</enumeration>
<enumeration value="totalCounter"> <annotation> <documentation> An integral value reporting the value of a counter. Counters are unsigned and wrap back to zero after reaching the limit of the type. For example, an unsigned64 with counter semantics will continue to increment until reaching the value of 2**64 - 1. At this point, the next increment will wrap its value to zero and continue counting from zero. The semantics of a total counter is similar to the semantics of counters used in SNMP, such as Counter32 defined in RFC 2578 [RFC2578]. The only difference between total counters and counters used in SNMP is that the total counters have an initial value of 0. A total counter counts independently of the export of its value. </documentation> </annotation> </enumeration>
<列挙値= "TotalCounter"> <Annotation> <Documentation>カウンターの値を報告する積分値。カウンターは署名されておらず、タイプの限界に達した後、ゼロに戻ります。たとえば、カウンターセマンティクスを備えたunsigned64は、2 ** 64-1の値に達するまで増加し続けます。総カウンターのセマンティクスは、RFC 2578 [RFC2578]で定義されているカウンター32など、SNMPで使用されるカウンターのセマンティクスに似ています。SNMPで使用される総カウンターとカウンターの唯一の違いは、合計カウンターの初期値が0であることです。合計カウンターは、その値のエクスポートとは無関係です。</documentation> </annotation> </enumeration>
<enumeration value="deltaCounter"> <annotation> <documentation> An integral value reporting the value of a counter. Counters are unsigned and wrap back to zero after reaching the limit of the type. For example, an unsigned64 with counter semantics will continue to increment until reaching the value of 2**64 - 1. At this point, the next increment will wrap its value to zero and continue counting from zero. The semantics of a delta counter is similar to the semantics of counters used in SNMP, such as Counter32 defined in RFC 2578 [RFC2578]. The only difference between delta counters and counters used in SNMP is that the delta counters have an initial value of 0. A delta counter is reset to 0 each time its value is exported. </documentation> </annotation> </enumeration>
<enumeration value = "deltacounter"> <annotation> <ドキュメント>カウンターの値を報告する積分値。カウンターは署名されておらず、タイプの限界に達した後、ゼロに戻ります。たとえば、カウンターセマンティクスを備えたunsigned64は、2 ** 64-1の値に達するまで増加し続けます。デルタカウンターのセマンティクスは、RFC 2578 [RFC2578]で定義されているカウンター32など、SNMPで使用されるカウンターのセマンティクスに似ています。SNMPで使用されているデルタカウンターとカウンターの唯一の違いは、デルタカウンターの初期値が0にあることです。デルタカウンターは、値がエクスポートされるたびに0にリセットされます。</documentation> </annotation> </enumeration>
<enumeration value="identifier">
<annotation>
<documentation>
An integral value that serves as an identifier.
Specifically, mathematical operations on two
identifiers (aside from the equality operation) are
meaningless. For example, Autonomous System ID 1 *
Autonomous System ID 2 is meaningless.
</documentation>
</annotation>
</enumeration>
<enumeration value="flags">
<annotation>
<documentation>
An integral value that actually represents a set of bit fields. Logical operations are appropriate on such values, but not other mathematical operations. Flags should always be of an unsigned type. </documentation> </annotation> </enumeration> </restriction> </simpleType>
実際に一連のビットフィールドを表す積分値。論理操作はそのような値に適していますが、他の数学操作ではありません。フラグは常に署名されていないタイプでなければなりません。</documentation> </annotation> </enumeration> </restriction> </simpletype>
<simpleType name="applicability">
<restriction base="string">
<enumeration value="data">
<annotation>
<documentation>
Used for Information Elements that are applicable to
Flow Records only.
</documentation>
</annotation>
</enumeration>
<enumeration value="option">
<annotation>
<documentation>
Used for Information Elements that are applicable to
option records only.
</documentation>
</annotation>
</enumeration>
<enumeration value="all">
<annotation>
<documentation>
Used for Information Elements that are applicable to
Flow Records as well as to option records.
</documentation>
</annotation>
</enumeration>
</restriction>
</simpleType>
<simpleType name="status"> <restriction base="string"> <enumeration value="current"> <annotation> <documentation> Indicates that the Information Element definition is current and valid.
<simpletype name = "status"> <制限ベース= "string"> <enumeration value = "current"> <annotation> <ドキュメント>情報要素の定義が最新かつ有効であることを示します。
</documentation>
</annotation>
</enumeration>
<enumeration value="deprecated">
<annotation>
<documentation>
Indicates that the Information Element definition is
obsolete, but it permits new/continued implementation
in order to foster interoperability with older/existing
implementations.
</documentation>
</annotation>
</enumeration>
<enumeration value="obsolete">
<annotation>
<documentation>
Indicates that the Information Element definition is
obsolete and should not be implemented and/or can be
removed if previously implemented.
</documentation>
</annotation>
</enumeration>
</restriction>
</simpleType>
<complexType name="text">
<choice maxOccurs="unbounded" minOccurs="0">
<element name="paragraph">
<complexType mixed="true">
<sequence>
<element maxOccurs="unbounded" minOccurs="0"
name="xref">
<complexType>
<attribute name="target" type="string"
use="required"/>
</complexType>
</element>
</sequence>
</complexType>
</element>
<element name="artwork">
<simpleType>
<restriction base="string"/>
</simpleType>
</element>
</choice>
</complexType>
<simpleType name="range">
<restriction base="string"/>
</simpleType>
<element name="fieldDefinitions">
<complexType>
<sequence>
<element maxOccurs="unbounded" minOccurs="1" name="field">
<complexType>
<sequence>
<element maxOccurs="1" minOccurs="1" name="description"
type="ipfix:text">
<annotation>
<documentation>
The semantics of this Information Element.
Describes how this Information Element is
derived from the Flow or other information
available to the observer.
</documentation>
</annotation>
</element>
<element maxOccurs="1" minOccurs="0" name="reference"
type="ipfix:text">
<annotation>
<documentation>
Identifies additional specifications that more
precisely define this item or provide additional
context for its use.
</documentation>
</annotation>
</element>
<element maxOccurs="1" minOccurs="0" name="units"
type="string">
<annotation>
<documentation>
If the Information Element is a measure of some
kind, the units identify what the measure is.
</documentation>
</annotation>
</element>
<element maxOccurs="1" minOccurs="0" name="range"
type="ipfix:range">
<annotation>
<documentation>
Some Information Elements may only be able to
take on a restricted set of values that can be
expressed as a range (e.g., 0 through 511
inclusive). If this is the case, the valid
inclusive range should be specified.
</documentation>
</annotation>
</element>
</sequence>
<attribute name="name" type="string" use="required">
<annotation>
<documentation>
A unique and meaningful name for the Information
Element.
</documentation>
</annotation>
</attribute>
<attribute name="dataType" type="ipfix:dataType" use="required"> <annotation> <documentation> One of the types listed in Section 3.1 of this document or in a future extension of the information model. The type space for attributes is constrained to facilitate implementation. The existing type space does however encompass most basic types used in modern programming languages, as well as some derived types (such as ipv4Address) that are common to this domain and useful to distinguish. </documentation> </annotation> </attribute>
<属性name = "dataType" type = "ipfix：dataType" use = "required"> <Annotation> <ドキュメント>このドキュメントのセクション3.1または情報モデルの将来の拡張にリストされているタイプの1つ。属性のタイプスペースは、実装を容易にするために制約されています。ただし、既存のタイプスペースには、最新のプログラミング言語で使用されるほとんどの基本的なタイプと、このドメインに共通し、区別するのに役立ついくつかの派生タイプ（IPv4Addressなど）が含まれます。</documentation> </annotation> </属性>
<attribute name="dataTypeSemantics"
type="ipfix:dataTypeSemantics" use="optional">
<annotation>
<documentation>
The integral types may be qualified by additional
semantic details. Valid values for the data type
semantics are specified in Section 3.2 of this
document or in a future extension of the
information model.
</documentation>
</annotation>
</attribute>
<attribute name="elementId" type="nonNegativeInteger"
use="required"> <annotation> <documentation> A numeric identifier of the Information Element. If this identifier is used without an enterprise identifier (see [RFC5101] and enterpriseId below), then it is globally unique and the list of allowed values is administered by IANA. It is used for compact identification of an Information Element when encoding Templates in the protocol. </documentation> </annotation> </attribute>
use = "必須"> <Annotation> <ドキュメント>情報要素の数値識別子。この識別子がエンタープライズ識別子（[RFC5101]と以下のEnterpriseidを参照）なしで使用されている場合、それはグローバルに一意であり、許可された値のリストはIANAによって管理されます。プロトコル内のテンプレートをエンコードするときに、情報要素のコンパクトな識別に使用されます。</documentation> </annotation> </属性>
<attribute name="enterpriseId" type="nonNegativeInteger" use="optional"> <annotation> <documentation> Enterprises may wish to define Information Elements without registering them with IANA, for example, for enterprise-internal purposes. For such Information Elements, the Information Element identifier described above is not sufficient when the Information Element is used outside the enterprise. If specifications of enterprise-specific Information Elements are made public and/or if enterprise-specific identifiers are used by the IPFIX protocol outside the enterprise, then the enterprise-specific identifier MUST be made globally unique by combining it with an enterprise identifier. Valid values for the enterpriseId are defined by IANA as Structure of Management Information (SMI) network management private enterprise codes. They are defined at http://www.iana.org/assignments/enterprise-numbers. </documentation> </annotation> </attribute>
<属性name = "EnterpriseId" Type = "non-negativeInteger" use = "optional"> <annotation> <documentation>エンタープライズは、たとえばエンタープライズ内部の目的など、IANAに登録せずに情報要素を定義したい場合があります。このような情報要素については、上記の情報要素識別子は、情報要素がエンタープライズの外で使用されている場合、十分ではありません。エンタープライズ固有の情報要素の仕様が公開されている場合、および/またはエンタープライズ固有の識別子がエンタープライズ外のIPFIXプロトコルで使用されている場合、エンタープライズ固有の識別子をエンタープライズ識別子と組み合わせることによりグローバルに一意にする必要があります。EnterpriseIDの有効な値は、IANAによって管理情報の構造（SMI）ネットワーク管理のプライベートエンタープライズコードとして定義されています。それらはhttp://www.iana.org/assignments/enterprise-numbersで定義されています。</documentation> </annotation> </属性>
<attribute name="applicability" type="ipfix:applicability" use="optional"> <annotation> <documentation> This property of an Information Element indicates in which kind of records the Information Element can be used.
<属性name = "applicability" type = "ipfix：applicability" use = "optional"> <Annotation> <Documentation>情報要素のこのプロパティは、情報要素を使用できる記録の種類を示します。
Allowed values for this property are 'data', 'option', and 'all'. </documentation> </annotation> </attribute>
このプロパティの許可された値は、「データ」、「オプション」、および「すべて」です。</documentation> </annotation> </属性>
<attribute name="status" type="ipfix:status"
use="required">
<annotation>
<documentation>
The status of the specification of this
Information Element. Allowed values are 'current',
'deprecated', and 'obsolete'.
</documentation>
</annotation>
</attribute>
<attribute name="group" type="string"
use="required">
<annotation>
<documentation>to be done ...</documentation>
</annotation>
</attribute>
</complexType>
</element>
</sequence>
</complexType>
<unique name="infoElementIdUnique">
<selector xpath="field"/>
<field xpath="elementId"/>
</unique>
</element>
</schema>
Authors' Addresses
著者のアドレス
Juergen Quittek NEC Kurfuersten-Anlage 36 Heidelberg 69115 Germany
Juergen Quittek Nec Kurfuersen-Anlage 36 Heidelberg 69115ドイツ
Phone: +49 6221 90511-15
EMail: quittek@nw.neclab.eu
URI: http://www.neclab.eu/
Stewart Bryant Cisco Systems, Inc. 250, Longwater Ave., Green Park Reading RG2 6GB United Kingdom
Stewart Bryant Cisco Systems、Inc。250、Longwater Ave.、Green Park Reading RG2 6GB英国
EMail: stbryant@cisco.com
Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 Diegem 1831 Belgium
Benoit Claise Cisco Systems、Inc。De Kleetlaan 6a B1 Diegem 1831 Belgium
Phone: +32 2 704 5622
EMail: bclaise@cisco.com
Paul Aitken Cisco Systems, Inc. 96 Commercial Quay Edinburgh EH6 6LX Scotland
Paul Aitken Cisco Systems、Inc。96コマーシャルキーエディンバラEH6 6LXスコットランド
Phone: +44 131 561 3616
EMail: paitken@cisco.com
Jeff Meyer PayPal 2211 N. First St. San Jose, CA 95131-2021 US
ジェフ・マイヤー・ペイパル2211 N.ファースト・セント・サンノゼ、CA 95131-2021 US
Phone: +1 408 976-9149
EMail: jemeyer@paypal.com
URI: http://www.paypal.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。