RFC5102 日本語訳
5102 Information Model for IP Flow Information Export. J. Quittek, S.Bryant, B. Claise, P. Aitken, J. Meyer. January 2008. (Format: TXT=335617 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
Quittekがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 5102年のNECカテゴリ: 標準化過程S.ブライアントB.Claise P.エイトケンシスコシステムズInc.J.マイヤーPayPal2008年1月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
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 Flow情報eXport(IPFIX)プロトコルのために情報モデルを定義します。 それは、交通Observation Point、交通Metering Process、およびExporting Processに関連する測定道路交通情報と情報をコード化するのに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
1. 序論…6 2. IPFIXの特性はInformation Elementsについて議定書の中で述べます…7 2.1. 情報要素仕様テンプレート…7 2.2. Information Elementsの範囲…9 2.3. 情報のためのコンベンションを要素と命名します…9 3. スペースをタイプしてください…10 3.1. 抽象データ型…10 3.1.1unsigned8…10 3.1.2unsigned16…11 3.1.3unsigned32…11 3.1.4unsigned64…11 3.1.5signed8…11 3.1.6signed16…11 3.1.7signed32…11 3.1.8signed64…11
Quittek, et al. Standards Track [Page 1] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[1ページ]。
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
3.1.9. float32…11 3.1.10float64…11 3.1.11論理演算子…12 3.1.12macAddress…12 3.1.13octetArray…12 3.1.14ストリング…12 3.1.15dateTimeSeconds…12 3.1.16dateTimeMilliseconds…12 3.1.17dateTimeMicroseconds…12 3.1.18dateTimeNanoseconds…13 3.1.19ipv4アドレス…13 3.1.20ipv6アドレス…13 3.2. データ型意味論…13 3.2.1量…13 3.2.2totalCounter…13 3.2.3deltaCounter…14 3.2.4識別子…14 3.2.5旗…14 4. 情報要素識別子…14 5. 情報要素…18 5.1. 識別子…19 5.1.1lineCardId…20 5.1.2portId…20 5.1.3ingressInterface…20 5.1.4egressInterface…21 5.1.5meteringProcessId…21 5.1.6exportingProcessId…21 5.1.7flowId…22 5.1.8templateId…22 5.1.9observationDomainId…22 5.1.10observationPointId…23 5.1.11commonPropertiesId…23 5.2. 計量と輸出は構成を処理します…23 5.2.1exporterIPv4アドレス…24 5.2.2exporterIPv6アドレス…24 5.2.3exporterTransportPort…24 5.2.4collectorIPv4アドレス…25 5.2.5collectorIPv6アドレス…25 5.2.6exportInterface…25 5.2.7exportProtocolVersion…26 5.2.8exportTransportProtocol…26 5.2.9collectorTransportPort…27 5.2.10flowKeyIndicator…27 5.3. 計量と輸出は統計を処理します…28 5.3.1exportedMessageTotalCount…28 5.3.2exportedOctetTotalCount…28 5.3.3exportedFlowRecordTotalCount…29 5.3.4observedFlowTotalCount…29
Quittek, et al. Standards Track [Page 2] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[2ページ]。
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.3.5. ignoredPacketTotalCount…29 5.3.6ignoredOctetTotalCount…30 5.3.7notSentFlowTotalCount…30 5.3.8notSentPacketTotalCount…30 5.3.9notSentOctetTotalCount…31 5.4. IPヘッダーフィールド…31 5.4.1ipVersion…31 5.4.2sourceIPv4アドレス…32 5.4.3sourceIPv6アドレス…32 5.4.4sourceIPv4PrefixLength…32 5.4.5sourceIPv6PrefixLength…33 5.4.6sourceIPv4接頭語…33 5.4.7sourceIPv6接頭語…33 5.4.8destinationIPv4アドレス…33 5.4.9destinationIPv6アドレス…34 5.4.10destinationIPv4PrefixLength…34 5.4.11destinationIPv6PrefixLength…34 5.4.12destinationIPv4接頭語…34 5.4.13destinationIPv6接頭語…35 5.4.14ipTTL…35 5.4.15protocolIdentifier…35 5.4.16nextHeaderIPv6…36 5.4.17ipDiffServCodePoint…36 5.4.18ipPrecedence…36 5.4.19ipClassOfService…37 5.4.20postIpClassOfService…37 5.4.21flowLabelIPv6…38 5.4.22isMulticast…38 5.4.23fragmentIdentification…39 5.4.24fragmentOffset…39 5.4.25fragmentFlags…39 5.4.26ipHeaderLength…40 5.4.27ipv4IHL…40 5.4.28totalLengthIPv4…41 5.4.29ipTotalLength…41 5.4.30payloadLengthIPv6…41 5.5. ヘッダーフィールドを輸送してください…42 5.5.1sourceTransportPort…42 5.5.2destinationTransportPort…42 5.5.3udpSourcePort…43 5.5.4udpDestinationPort…43 5.5.5udpMessageLength…43 5.5.6tcpSourcePort…44 5.5.7tcpDestinationPort…44 5.5.8tcpSequenceNumber…44 5.5.9tcpAcknowledgementNumber…44 5.5.10tcpWindowSize…45 5.5.11tcpWindowScale…45
Quittek, et al. Standards Track [Page 3] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[3ページ]。
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.5.12. tcpUrgentPointer…45 5.5.13tcpHeaderLength…45 5.5.14icmpTypeCodeIPv4…46 5.5.15icmpTypeIPv4…46 5.5.16icmpCodeIPv4…46 5.5.17icmpTypeCodeIPv6…46 5.5.18icmpTypeIPv6…47 5.5.19icmpCodeIPv6…47 5.5.20igmpType…47 5.6. サブIPヘッダーフィールド…48 5.6.1sourceMacAddress…48 5.6.2postSourceMacAddress…48 5.6.3vlanId…49 5.6.4postVlanId…49 5.6.5destinationMacAddress…49 5.6.6postDestinationMacAddress…49 5.6.7wlanChannelId…50 5.6.8wlanSSID…50 5.6.9mplsTopLabelTTL…50 5.6.10mplsTopLabelExp…51 5.6.11postMplsTopLabelExp…51 5.6.12mplsLabelStackDepth…51 5.6.13mplsLabelStackLength…52 5.6.14mplsPayloadLength…52 5.6.15mplsTopLabelStackSection…52 5.6.16mplsLabelStackSection2…53 5.6.17mplsLabelStackSection3…53 5.6.18mplsLabelStackSection4…53 5.6.19mplsLabelStackSection5…54 5.6.20mplsLabelStackSection6…54 5.6.21mplsLabelStackSection7…54 5.6.22mplsLabelStackSection8…55 5.6.23mplsLabelStackSection9…55 5.6.24mplsLabelStackSection10…55 5.7. パケットの特性を引き出します…56 5.7.1ipPayloadLength…56 5.7.2ipNextHopIPv4アドレス…56 5.7.3ipNextHopIPv6アドレス…57 5.7.4bgpSourceAsNumber…57 5.7.5bgpDestinationAsNumber…57 5.7.6bgpNextAdjacentAsNumber…57 5.7.7bgpPrevAdjacentAsNumber…58 5.7.8bgpNextHopIPv4アドレス…58 5.7.9bgpNextHopIPv6アドレス…58 5.7.10mplsTopLabelType…59 5.7.11mplsTopLabelIPv4アドレス…59 5.7.12mplsTopLabelIPv6アドレス…60 5.7.13mplsVpnRouteDistinguisher…60
Quittek, et al. Standards Track [Page 4] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[4ページ]。
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.8. 分/マックス流れの特性…61 5.8.1minimumIpTotalLength…61 5.8.2maximumIpTotalLength…61 5.8.3minimumTTL…61 5.8.4maximumTTL…62 5.8.5ipv4オプション…62 5.8.6ipv6ExtensionHeaders…64 5.8.7tcpControlBits…65 5.8.8tcpOptions…66 5.9. 流れタイムスタンプ…67 5.9.1flowStartSeconds…67 5.9.2flowEndSeconds…68 5.9.3flowStartMilliseconds…68 5.9.4flowEndMilliseconds…68 5.9.5flowStartMicroseconds…68 5.9.6flowEndMicroseconds…68 5.9.7flowStartNanoseconds…69 5.9.8flowEndNanoseconds…69 5.9.9flowStartDeltaMicroseconds…69 5.9.10flowEndDeltaMicroseconds…69 5.9.11systemInitTimeMilliseconds…70 5.9.12flowStartSysUpTime…70 5.9.13flowEndSysUpTime…70 5.10. 流れは反対します…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
Quittek, et al. Standards Track [Page 5] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[5ページ]。
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
5.11. 種々雑多な流れの特性…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. そっと歩きます…80 5.12.1. paddingOctets…81 6. 情報を広げて、モデル化してください…81 7. IANA問題…82 7.1. IPFIX Information Elements…82 7.2. MPLSはタイプ識別子をラベルします…82 7.3. XML名前空間と図式…83 8. セキュリティ問題…83 9. 承認…84 10. 参照…84 10.1. 標準の参照…84 10.2. 有益な参照…84 IPFIX Information Elementsの付録A.XML仕様…88 抽象データ型の付録B.XML仕様…157
1. Introduction
1. 序論
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 Flow情報eXport(IPFIX)プロトコルサーブはインターネットの上のIP交通を測定しました。 [RFC5101]のプロトコル仕様はInformation Elementsがどう伝えられるかを定義します。 Information Elementsとして、それは1セットの基本のデータ型のコード化を指定します。 しかしながら、MeteringとExporting Process(パケットObservation Point、標本抽出率、Flowタイムアウト間隔など)のFlow属性(ソースIPアドレス、パケットの数など)や情報のように、プロトコルで伝えることができるInformation Elementsのリストは[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情報モデルはInformation Elementsの間の関係を指定しませんが、それはInformation Elementsにコード化されるコンクリートをまた指定しません。 IPFIXプロトコルによって使用されるコード化以外に、IPFIX Information Elementsの他のencodingsは適用された例えば、XMLベースのencodingsであるかもしれません。
Quittek, et al. Standards Track [Page 6] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[6ページ]。
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プロトコルによって伝えられるためにInformation Elementsの(広げることができる)のリストを定義します)。 セクション2はセクション5でIPFIX Information Elementsを指定するためのテンプレートを定義します。 セクション3はIPFIX Information Elementsに利用可能な抽象データ型のセットを定義します。 セクション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 Information Elementsの仕様の構文の正当性をチェックするのにテンプレートのXMLベースの仕様、抽象データ型、およびIPFIX Information Elementsを使用できます。 処理IPFIX Information Elementsに対応するIPFIXプロトコル実現コードを発生させるのにさらにそれを使用できます。 また、さらなる過程道路交通情報がIPFIXプロトコルで送ったアプリケーションのためのコードはIPFIX Information Elementsの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.
その理由で、XMLはセクション2と3のためのソースとして機能したセクション5のためのソースとXML図式がAppendices 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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. Properties of IPFIX Protocol Information Elements
2. IPFIXプロトコル情報Elementsの特性
2.1. Information Elements Specification Template
2.1. 情報要素仕様テンプレート
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.
IPFIXプロトコルに関するメッセージの情報はIPFIX情報モデルのInformation Elementsに関してモデル化されます。 IPFIX Information Elementsはセクション5で指定されます。 Information Elements、テンプレートによる使用されて、それが以下で説明されるということであるのでこれらを指定して、。
All Information Elements specified for the IPFIX protocol either in this document or by any future extension MUST have the following properties defined:
Elementsがこのドキュメントかどんな今後の拡大でもIPFIXプロトコルに指定したすべての情報が定義された以下の特性を持たなければなりません:
name - A unique and meaningful name for the Information Element.
名前--ユニークで情報Elementに、重要な名前。
Quittek, et al. Standards Track [Page 7] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[7ページ]。
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--情報Elementの数値識別子。 この識別子が企業識別子なしで使用されるなら([RFC5101]と以下のenterpriseIdを見てください)、グローバルにユニークです、そして、許容値のリストはIANAによって管理されます。 プロトコルでTemplatesをコード化するとき、それは情報Elementのコンパクトな識別に使用されます。
description - The semantics of this Information Element. Describes
how this Information Element is derived from the Flow or other
information available to the observer.
記述--この情報Elementの意味論。 観察者にとって、利用可能なFlowか他の情報からこの情報Elementをどう得るかを説明します。
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.
dataType--タイプのひとりはこのドキュメントのセクション3.1か情報モデルの今後の拡大で記載しました。 属性のためのタイプスペースが実現を容易にするのが抑制されます。 しかしながら、既存のタイプスペースは現代のプログラミング言語で使用されるほとんどの基本型を包含します、何人かの区別するためにこのドメインに共通の、そして、役に立つ派生型(ipv4Addressなどの)と同様に。
status - The status of the specification of this Information Element.
Allowed values are 'current', 'deprecated', and 'obsolete'.
状態--この情報Elementの仕様の状態。 許容値は、'現在'で、'推奨しないこと'と、'時代遅れです'。
Enterprise-specific Information Elements MUST have the following property defined:
エンタープライズ特有のInformation Elementsには、定義された以下の特性がなければなりません:
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にそれらを登録しないで、エンタープライズはInformation Elementsを定義したがっているかもしれません。 そのようなInformation Elementsでは、情報Elementが企業の外で使用されるとき、上で説明された情報Element識別子は十分ではありません。 企業特有のInformation Elementsの仕様を公表して、企業の外のIPFIXプロトコルで企業特有の識別子を使用するなら、企業識別子にそれを結合することによって、企業特有の識別子をグローバルにユニークにしなければなりません。 enterpriseIdのための有効値はIANAによってManagement情報(SMI)ネットワークマネージメント私企業コードのStructureと定義されます。 それらは http://www.iana.org/assignments/enterprise- 番号で定義されます。
All Information Elements specified for the IPFIX protocol either in this document or by any future extension MAY have the following properties defined:
Elementsがこのドキュメントかどんな今後の拡大でも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か情報モデルの今後の拡大で指定されます。
Quittek, et al. Standards Track [Page 8] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[8ページ]。
units - If the Information Element is a measure of some kind, the
units identify what the measure is.
ユニット--情報Elementがある種の基準であるなら、ユニットは、測定が何であるかを特定します。
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.
及んでください--Information Elementsが範囲として言い表すことができる制限されたセットの値を呈することができるだけであるかもしれない、(例えば、0〜511、包括的である、) これがそうであるなら、有効な包括的な範囲は指定されるべきです。
reference - Identifies additional specifications that more precisely
define this item or provide additional context for its use.
参照--より正確にこの項目を定義するか、または追加文脈を使用に提供する追加仕様を特定します。
2.2. Scope of Information Elements
2.2. Information Elementsの範囲
By default, most Information Elements have a scope specified in their definitions.
デフォルトで、ほとんどのInformation Elementsが彼らの定義で範囲を指定させます。
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 それぞれElementsがセクション5.2で定義して、5.3が「特定のMetering Process」か「特定のExporting Process」についてデフォルトを持っている情報。
o The Information Elements defined in Sections 5.4-5.11 have a scope
of "a specific Flow".
o Elementsがセクション5.4-5.11で定義した情報は「特定のFlow」の範囲を持っています。
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].
Option Templatesによって定義されたData Recordsの中では、IPFIXプロトコルは情報Element範囲の、より遠い制限を許します。 新しい範囲は、1つ以上の範囲分野によって指定されて、すべての指定された範囲値の組み合わせと定義されます。 IPFIXの上の.1が[RFC5101]で見るセクション3.4.2を見てください。
2.3. Naming Conventions for Information Elements
2.3. 情報のためのコンベンションを要素と命名します。
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.
以下の命名規則は、本書では情報をElementsと命名するのに使用されました。 モデルの拡大が同じコンベンションを使用するのは、お勧めです。
o Names of Information Elements should be descriptive.
o Information Elementsという名前は描写的であるべきです。
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 Information Elementsという企業特有でない名前はIPFIX情報モデルの中でユニークであるに違いありません。 エンタープライズ特有の情報Elements SHOULD、ベンダー名で、前に置かれてください。
o Names of Information Elements start with non-capitalized letters.
o Information Elementsという名前は非大文字で書かれた手紙から始まります。
Quittek, et al. Standards Track [Page 9] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[9ページ]。
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 Middleboxes[RFC3234]はDifferentiated Service Code Point(DSCP)値かソースIPアドレスなどのFlow資産を変えるかもしれません。 IPFIX Observation Pointが潜在的にFlowのパケットを変更する1middleboxesの前のFlowの経路に位置しているなら、変更がmiddleboxesで働いた後にまた、Flowの特性を報告するのは望ましいかもしれません。 例はパケットの情報Element classOfServiceIPv4でコード化されるService(TOS)分野のIPv4 Typeを変えるパケットマーカーの前のObservation Pointです。 そして、情報Element classOfServiceIPv4によって観測されて、報告された値は、Observation Pointで有効ですが、パケットのときにパケットマーカーが渡された後有効であるというわけではありません。 TOS分野の変化値であり、IPFIX情報モデルがInformation Elementsにそれを使用すると報告するには、名前接頭語「ポスト」、例えば、"postClassOfServiceIPv4""を持ってください。 必ずObservation Pointで観測されるというわけではありませんが、FlowのObservation Domainの中でテーブルをマークする例えば十分信頼できるとパケットマーカーを分析することによって考えられた他の手段で入手されるFlow資産に関する接頭語「ポスト」レポートのInformation Elements。
3. Type Space
3. スペースをタイプしてください。
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 Information Elementsの仕様に使用できる抽象データ型を説明します。 セクション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'、'識別子'、または'旗'でそれらのデータ型意味論をさらに指定できます。
3.1. Abstract Data Types
3.1. 抽象データ型
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情報モデルの今後の拡大で指定されるかもしれないことに注意してください。
3.1.1. unsigned8
3.1.1. unsigned8
The type "unsigned8" represents a non-negative integer value in the range of 0 to 255.
タイプしてください。「unsigned8"は0〜255の範囲に非負の整数値を表します」。
Quittek, et al. Standards Track [Page 10] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[10ページ]。
3.1.2. unsigned16
3.1.2. unsigned16
The type "unsigned16" represents a non-negative integer value in the range of 0 to 65535.
タイプしてください。「unsigned16"は0〜65535の範囲に非負の整数値を表します」。
3.1.3. unsigned32
3.1.3. unsigned32
The type "unsigned32" represents a non-negative integer value in the range of 0 to 4294967295.
タイプしてください。「unsigned32"は0〜4294967295の範囲に非負の整数値を表します」。
3.1.4. unsigned64
3.1.4. unsigned64
The type "unsigned64" represents a non-negative integer value in the range of 0 to 18446744073709551615.
タイプしてください。「unsigned64"は0〜18446744073709551615の範囲に非負の整数値を表します」。
3.1.5. signed8
3.1.5. signed8
The type "signed8" represents an integer value in the range of -128 to 127.
タイプしてください。「signed8"は-128〜127の範囲に整数値を表します」。
3.1.6. signed16
3.1.6. signed16
The type "signed16" represents an integer value in the range of -32768 to 32767.
タイプしてください。「signed16"は-32768〜32767の範囲に整数値を表します」。
3.1.7. signed32
3.1.7. signed32
The type "signed32" represents an integer value in the range of -2147483648 to 2147483647.
タイプしてください。「signed32"は-2147483648〜2147483647の範囲に整数値を表します」。
3.1.8. signed64
3.1.8. signed64
The type "signed64" represents an integer value in the range of -9223372036854775808 to 9223372036854775807.
タイプしてください。「signed64"は-9223372036854775808〜9223372036854775807の範囲に整数値を表します」。
3.1.9. float32
3.1.9. float32
The type "float32" corresponds to an IEEE single-precision 32-bit floating point type as defined in [IEEE.754.1985].
タイプ、「float32"が定義されるとしてIEEEの単精度の32ビットの浮動小数点タイプに文通している、[IEEE、.754、.1985、]、」
3.1.10. float64
3.1.10. float64
The type "float64" corresponds to an IEEE double-precision 64-bit floating point type as defined in [IEEE.754.1985].
タイプ、「float64"が定義されるとしてIEEEの倍精度の64ビットの浮動小数点タイプに文通している、[IEEE、.754、.1985、]、」
Quittek, et al. Standards Track [Page 11] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[11ページ]。
3.1.11. boolean
3.1.11. 論理演算子
The type "boolean" represents a binary value. The only allowed values are "true" and "false".
タイプ「論理演算子」は2進の値を表します。 唯一の許容値が、「本当で」「誤っています」。
3.1.12. macAddress
3.1.12. macAddress
The type "macAddress" represents a string of 6 octets.
タイプ「macAddress」は一連の6つの八重奏を表します。
3.1.13. octetArray
3.1.13. octetArray
The type "octetArray" represents a finite-length string of octets.
タイプ"octetArray"は八重奏の有限長さのストリングを表します。
3.1.14. string
3.1.14. ストリング
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.
タイプ「ストリング」はユニコード文字符号化セット[ISO.10646-1.1993]から有効なキャラクタの有限長さのストリングを代表します。 ユニコードは、ASCII[ISO.646.1991]と他の多くの国際的な人物セットが使用されるのを許容します。
3.1.15. dateTimeSeconds
3.1.15. dateTimeSeconds
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)に基づくユニットの秒に時間的価値を表します。 時代の選択、例えば、協定世界時0時0分(1970年1月1日)はこのタイプのために仕様をコード化しながら相当するのに残されます、例えば、IPFIXが仕様を議定書の中で述べます。 飛躍秒は除かれます。 異なった時代値が使用されているなら値の変換が異なったencodingsの間で必要であるかもしれないことに注意してください。
3.1.16. dateTimeMilliseconds
3.1.16. dateTimeMilliseconds
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)に基づくユニットのミリセカンドで時間的価値を表します。 時代の選択、例えば、協定世界時0時0分(1970年1月1日)はこのタイプのために仕様をコード化しながら相当するのに残されます、例えば、IPFIXが仕様を議定書の中で述べます。 飛躍秒は除かれます。 異なった時代値が使用されているなら値の変換が異なったencodingsの間で必要であるかもしれないことに注意してください。
3.1.17. dateTimeMicroseconds
3.1.17. dateTimeMicroseconds
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
タイプ「dateTimeMicroseconds」は連携ユニバーサルタイム(UTC)に基づくユニットのマイクロセカンドのときに時間的価値を表します。 例えば、協定世界時0時0分(1970年1月1日)が残される時代の選択
Quittek, et al. Standards Track [Page 12] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[12ページ]。
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.
このタイプのために仕様をコード化しながら対応している、例えば、IPFIXは仕様を議定書の中で述べます。 飛躍秒は除かれます。 異なった時代値が使用されているなら値の変換が異なったencodingsの間で必要であるかもしれないことに注意してください。
3.1.18. dateTimeNanoseconds
3.1.18. dateTimeNanoseconds
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.
タイプ「dateTimeNanoseconds」は連携ユニバーサルタイム(UTC)に基づくユニットの数ナノ秒に時間的価値を表します。 時代の選択、例えば、協定世界時0時0分(1970年1月1日)はこのタイプのために仕様をコード化しながら相当するのに残されます、例えば、IPFIXが仕様を議定書の中で述べます。 飛躍秒は除かれます。 異なった時代値が使用されているなら値の変換が異なったencodingsの間で必要であるかもしれないことに注意してください。
3.1.19. ipv4Address
3.1.19. ipv4Address
The type "ipv4Address" represents a value of an IPv4 address.
タイプ「ipv4Address」はIPv4アドレスの値を表します。
3.1.20. ipv6Address
3.1.20. ipv6Address
The type "ipv6Address" represents a value of an IPv6 address.
タイプ「ipv6Address」はIPv6アドレスの値を表します。
3.2. Data Type Semantics
3.2. データ型意味論
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情報モデルの今後の拡大で指定されるかもしれないことに注意してください。
3.2.1. quantity
3.2.1. 量
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.
量の値は記録に関係する離散的な測定値を表します。 これは「オドメーター」読書が与えられた記録の一部としてキャプチャされる進行中の測定値を表すカウンタと区別されます。 どんな意味資格を与える人も与えないなら、不可欠のデータ型を持っているInformation Elementsは量として振る舞うべきです。
3.2.2. totalCounter
3.2.2. totalCounter
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
カウンタの値を報告する整数値。 カウンタは、未署名であり、タイプの限界に達した後に、ゼロへの後部を包装します。 例えば、カウンタ意味論があるunsigned64は、2**の値に達するまで64--1を増加し続けるでしょう。 ここに、次の増分は、値をゼロに包装して、ゼロから数え続けるでしょう。 総カウンタの意味論はSNMPで使用されるカウンタの意味論と同様です、RFC2578[RFC2578]で定義されたCounter32などのように。 総カウンタとカウンタの唯一の違い
Quittek, et al. Standards Track [Page 13] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[13ページ]。
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.
SNMPで使用されているのは、総カウンタには0の初期の値があるということです。 総カウンタは価値の輸出の如何にかかわらず数えられます。
3.2.3. deltaCounter
3.2.3. deltaCounter
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を増加し続けるでしょう。 ここに、次の増分は、値をゼロに包装して、ゼロから数え続けるでしょう。 デルタカウンタの意味論はSNMPで使用されるカウンタの意味論と同様です、RFC2578[RFC2578]で定義されたCounter32などのように。 デルタカウンタとSNMPで使用されるカウンタの唯一の違いはデルタカウンタには0の初期の値があるということです。 値がエクスポートされるたびにデルタカウンタは0にリセットされます。
3.2.4. identifier
3.2.4. 識別子
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つの識別子(平等操作は別として)における数学の操作は無意味です。 例えば、Autonomous System ID1*自治のSystem ID2は無意味です。
3.2.5. flags
3.2.5. 旗
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.
実際に1セットの噛み付いている分野を表す整数値。 論理演算は他の数学の操作ではなく、そのような値で適切です。 未署名のタイプには旗がいつもあるはずです。
4. Information Element Identifiers
4. 情報要素識別子
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.
Information Elementsがこのドキュメントのセクション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のサブ範囲の情報Element識別子値はNetFlowバージョン9[RFC3954]によって使用されるフィールド・タイプと互換性があります。
Quittek, et al. Standards Track [Page 14] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[14ページ]。
+---------------------------------+---------------------------------+ | 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. | +---------------------------------+---------------------------------+
+---------------------------------+---------------------------------+ | IANAによって割り当てられることの範囲| 記述| | 情報Element識別子| | +---------------------------------+---------------------------------+ | 0 | 予約にされる。 | | 1-127 | 情報Element識別子| | | NetFlowバージョンと互換性があります。| | | 9分野は[RFC3954]をタイプします。 | | 128-32767 | 詳細要素| | | 識別子。 | +---------------------------------+---------------------------------+
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.
エンタープライズ特有の情報Element識別子には、同じ1-32767の範囲がありますが、それらは副業識別子に結びつけられます。 また、企業特有のInformation Elementsに関しては、情報Element識別子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の範囲の中で任意にエンタープライズ特有の情報Element識別子を選ぶことができます。 同じ識別子は異なる役割のために他の企業によって割り当てられるかもしれません。
Still, Collecting Processes can distinguish these Information Elements because the Information Element identifier is coupled with an enterprise identifier.
それでも、情報Element識別子が企業識別子に結びつけられるので、Collecting ProcessesはこれらのInformation Elementsを区別できます。
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.
SMIネットワークマネージメント私企業コード番号としてエンタープライズ識別子をIANAに登録しなければなりません。 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によって使用されるフィールド・タイプと互換性がある情報Element識別子[RFC3954]の概要を与えます。
Quittek, et al. Standards Track [Page 15] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[15ページ]。
+----+----------------------------+-------+-------------------------+ | 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| | | +----+----------------------------+-------+-------------------------+
+----+----------------------------+-------+-------------------------+ | ID| 名前| ID| 名前| +----+----------------------------+-------+-------------------------+ | 1 | octetDeltaCount| 43 | 予約されます。| | 2 | packetDeltaCount| 44 | sourceIPv4Prefix| | 3 | 予約されます。| 45 | destinationIPv4Prefix| | 4 | protocolIdentifier| 46 | mplsTopLabelType| | 5 | ipClassOfService| 47 | mplsTopLabelIPv4Address| | 6 | tcpControlBits| 48-51 | 予約されます。| | 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 | 予約されます。| | 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 | 予約されます。| | 34 | 予約されます。| 85 | octetTotalCount| | 35 | 予約されます。| 86 | packetTotalCount| | 36 | flowActiveTimeout| 87 | 予約されます。| | 37 | flowIdleTimeout| 88 | fragmentOffset| | 38 | 予約されます。| 89 | 予約されます。| | 39 | 予約されます。| 90 |mplsVpnRouteDistinguisher| | 40 | exportedOctetTotalCount|91-127 | 予約されます。| | 41 | exportedMessageTotalCount| | | | 42 |exportedFlowRecordTotalCount| | | +----+----------------------------+-------+-------------------------+
Quittek, et al. Standards Track [Page 16] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[16ページ]。
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].
以下のリストは、セクション5で指定される情報Element識別子の概要を与えて、既に[RFC3954]で指定された情報Element識別子のリストを広げています。
+-----+---------------------------+-----+---------------------------+ | 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| 名前| ID| 名前| +-----+---------------------------+-----+---------------------------+ | 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|
Quittek, et al. Standards Track [Page 17] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[17ページ]。
+-----+---------------------------+-----+---------------------------+ | 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 | +-----+---------------------------+-----+---------------------------+
+-----+---------------------------+-----+---------------------------+ | ID| 名前| ID| 名前| +-----+---------------------------+-----+---------------------------+ | 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| +-----+---------------------------+-----+---------------------------+
5. Information Elements
5. 情報要素
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情報モデルのInformation Elementsについて説明します。 それらの意味論と彼らの適用性に従って、要素は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を引き出しました。 分/マックス流れの特性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のInformation Elementsなどのように、Information Elementsはパケットの分野から派生するか、パケット処理によってパケットをFlowsに写像するのに使用されるFlowキーズとして通常勤めることができます。
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
Flowキーズとして機能しないなら、パケットによってそれらの値は独身のFlowの中で変化するかもしれません。 値がパケットの分野かパケット処理から引き出されて、それらの値が情報モデルが定義するIPFIXですが、パケットによって独身のFlowの中で変化するかもしれない値が自決したことでのInformation Elementsに関しては、対応するFlowに関して最初のパケットは見ました、情報Elementの記述が明らかに異なった意味論を指定しない場合。 この簡単な規則で、すべてを書きます。
Quittek, et al. Standards Track [Page 18] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[18ページ]。
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.
Flowの最初のパケットであるときにElementsが一度ヘッダーフィールドに話した情報は観測されます。 同じFlowの一層の観測されたパケットのために、グループ8-11のInformation Elementsなどの1つ以上のパケットに依存するFlowの特性だけが、アップデートする必要があります。
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.
例えば、「postClassOfServiceIPv4"、実際に観測所で観測されましたが、観測ドメインの中で他の手段で検索された特性を報告しないでください。」名前をもっているInformation Elementsには「ポスト」接頭語があって、 middlebox機能があれば、パケットがObservation Pointを渡した後にFlow資産を変えながら、Observation Domainの中でこれらのInformation Elementsを使用できます。
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].
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].
5.1. Identifiers
5.1. 識別子
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.
Elementsが以下のテーブルで分類した情報はIPFIXアーキテクチャ、IPFIX Device、または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.
通常、それらのいくつかが、他のInformation Elementsの範囲を制限するのに使用されます。 しかしながら、他のInformation Elementsは、範囲を制限するのに使用されるかもしれません。 また、5月の下に記載されたInformation Elementsが範囲を制限すること以外の目的に使用されることに注意してください。
+-----+---------------------------+-----+---------------------------+ | 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 | | | +-----+---------------------------+-----+---------------------------+
+-----+---------------------------+-----+---------------------------+ | ID| 名前| ID| 名前| +-----+---------------------------+-----+---------------------------+ | 141 | lineCardId| 148 | flowId| | 142 | portId| 145 | templateId| | 10 | ingressInterface| 149 | observationDomainId| | 14 | egressInterface| 138 | observationPointId| | 143 | meteringProcessId| 137 | commonPropertiesId| | 144 | exportingProcessId| | | +-----+---------------------------+-----+---------------------------+
Quittek, et al. Standards Track [Page 19] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[19ページ]。
5.1.1. lineCardId
5.1.1. lineCardId
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
記述: Observation Pointを接待するIPFIX Device単位でユニークな系列カードに関する識別子。 通常、この情報Elementは、他のInformation Elementsの範囲を制限するのに使用されます。 抽象データ型: unsigned32 Data Type Semantics: 識別子ElementId: 141状態: 電流
5.1.2. portId
5.1.2. portId
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
記述: Observation Pointを接待するIPFIX Device単位でユニークな系列ポートに関する識別子。 通常、この情報Elementは、他のInformation Elementsの範囲を制限するのに使用されます。 抽象データ型: unsigned32 Data Type Semantics: 識別子ElementId: 142状態: 電流
5.1.3. ingressInterface
5.1.3. ingressInterface
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.
記述: このFlowのパケットが受け取られているIPインタフェースのインデックス。 値はRFC2863で定義されるように管理オブジェクト'ifIndex'の値に合っています。 ifIndex値が静的にインタフェースに割り当てられないで、デバイスのマネージメントシステムが再初期化されるときはいつも、インタフェースが番号を付け替えられるかもしれないことに注意してください、RFC2863で指定されるように。 抽象データ型: unsigned32 Data Type Semantics: 識別子ElementId: 10状態: 現在のReference: ifIndexオブジェクトの定義に関してRFC2863を見てください。
Quittek, et al. Standards Track [Page 20] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[20ページ]。
5.1.4. egressInterface
5.1.4. egressInterface
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.
記述: このFlowのパケットが送られるIPインタフェースのインデックス。 値はRFC2863で定義されるように管理オブジェクト'ifIndex'の値に合っています。 ifIndex値が静的にインタフェースに割り当てられないで、デバイスのマネージメントシステムが再初期化されるときはいつも、インタフェースが番号を付け替えられるかもしれないことに注意してください、RFC2863で指定されるように。 抽象データ型: unsigned32 Data Type Semantics: 識別子ElementId: 14状態: 現在のReference: ifIndexオブジェクトの定義に関してRFC2863を見てください。
5.1.5. meteringProcessId
5.1.5. meteringProcessId
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 Device単位でユニークなMetering Processに関する識別子。 通常、この情報Elementは、他のInformation Elementsの範囲を制限するのに使用されます。 プロセス識別子がダイナミックに通常割り当てられることに注意してください。 Metering Processは異なったIDと共に再開されるかもしれません。 抽象データ型: unsigned32 Data Type Semantics: 識別子ElementId: 143状態: 電流
5.1.6. exportingProcessId
5.1.6. exportingProcessId
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 Device単位でユニークなExporting Processに関する識別子。 通常、この情報Elementは、他のInformation Elementsの範囲を制限するのに使用されます。 プロセス識別子がダイナミックに通常割り当てられることに注意してください。 Exporting Processは異なったIDと共に再開されるかもしれません。 抽象データ型: unsigned32 Data Type Semantics: 識別子ElementId: 144状態: 電流
Quittek, et al. Standards Track [Page 21] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[21ページ]。
5.1.7. flowId
5.1.7. flowId
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
記述: Observation Domainの中でユニークなFlowに関する識別子。 IPアドレスやポートナンバーなどのFlowキーズが報告されないか、または別々の記録で報告されるなら、異なったFlowsを見分けるのにこの情報Elementを使用できます。 抽象データ型: unsigned64 Data Type Semantics: 識別子ElementId: 148状態: 電流
5.1.8. templateId
5.1.8. templateId
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
記述: Transportセッションの組み合わせの中で局所的にユニークなTemplateとObservation Domainに関する識別子。 テンプレートID0-255は、Template Sets、Options Template Sets、および他の予約されたSetsにもかかわらず、作成されるために予約されます。 Data SetsのテンプレートIDは256〜65535まで付番されます。 通常、この情報Elementは、他のInformation Elementsの範囲を制限するのに使用されます。 Exporting Process Template識別子の再開が再選任されたかもしれない後にそれに注意してください。 抽象データ型: unsigned16 Data Type Semantics: 識別子ElementId: 145状態: 電流
5.1.9. observationDomainId
5.1.9. observationDomainId
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
記述: 局所的にExporting ProcessにユニークなObservation Domainに関する識別子。 Exporting Processは、唯一、Flowsが計量されたObservation DomainをCollecting Processに特定するのにObservation Domain IDを使用します。 また、この識別子もIPFIX Device単位でユニークであることは、RECOMMENDEDです。 0の値は、どんな特定のObservation Domainもこの情報Elementによって特定されないのを示します。 通常、この情報Elementは、他のInformation Elementsの範囲を制限するのに使用されます。 抽象データ型: unsigned32 Data Type Semantics: 識別子ElementId: 149状態: 電流
Quittek, et al. Standards Track [Page 22] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[22ページ]。
5.1.10. observationPointId
5.1.10. observationPointId
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
記述: Observation Domain単位でユニークなObservation Pointに関する識別子。 また、この識別子もIPFIX Device単位でユニークであることは、RECOMMENDEDです。 通常、この情報Elementは、他のInformation Elementsの範囲を制限するのに使用されます。 抽象データ型: unsigned32 Data Type Semantics: 識別子ElementId: 138状態: 電流
5.1.11. commonPropertiesId
5.1.11. commonPropertiesId
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
記述: 1セットのObservation DomainとTransport Session単位でユニークな通有性に関する識別子。 通常、この情報Elementは、別々のData Recordsで報告された情報にリンクするのに使用されます。 抽象データ型: unsigned64 Data Type Semantics: 識別子ElementId: 137状態: 電流
5.2. Metering and Exporting Process Configuration
5.2. プロセス構成を計量して、エクスポートします。
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.
このセクションのInformation ElementsはMetering ProcessかExporting Processの構成について説明します。 これらのInformation Elementsのセットは以下のテーブルに記載されています。
+-----+--------------------------+-----+----------------------------+ | ID | Name | ID | Name | +-----+--------------------------+-----+----------------------------+ | 130 | exporterIPv4Address | 213 | exportInterface | | 131 | exporterIPv6Address | 214 | exportProtocolVersion | | 217 | exporterTransportPort | 215 | exportTransportProtocol | | 211 | collectorIPv4Address | 216 | collectorTransportPort | | 212 | collectorIPv6Address | 173 | flowKeyIndicator | +-----+--------------------------+-----+----------------------------+
+-----+--------------------------+-----+----------------------------+ | ID| 名前| ID| 名前| +-----+--------------------------+-----+----------------------------+ | 130 | exporterIPv4Address| 213 | exportInterface| | 131 | exporterIPv6Address| 214 | exportProtocolVersion| | 217 | exporterTransportPort| 215 | exportTransportProtocol| | 211 | collectorIPv4Address| 216 | collectorTransportPort| | 212 | collectorIPv6Address| 173 | flowKeyIndicator| +-----+--------------------------+-----+----------------------------+
Quittek, et al. Standards Track [Page 23] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[23ページ]。
5.2.1. exporterIPv4Address
5.2.1. exporterIPv4Address
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
記述: Exporting Processによって使用されたIPv4アドレス。 これは、Exporterのアイデンティティがプロキシの使用であいまいにされたかもしれない場合でExporterを特定するのにCollectorによって使用されます。 抽象データ型: ipv4Addressデータ型意味論: 識別子ElementId: 130状態: 電流
5.2.2. exporterIPv6Address
5.2.2. exporterIPv6Address
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
記述: Exporting Processによって使用されたIPv6アドレス。 これは、Exporterのアイデンティティがプロキシの使用であいまいにされたかもしれない場合でExporterを特定するのにCollectorによって使用されます。 抽象データ型: ipv6Addressデータ型意味論: 識別子ElementId: 131状態: 電流
5.2.3. exporterTransportPort
5.2.3. exporterTransportPort
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.
記述: Exporting Processが情報をFlowに送るソースポート識別子。 トランスポート・プロトコルのUDP、TCP、およびSCTPにおいて、これはソースポート番号です。 また、この分野は16ビットのソースポート識別子を持っている将来のトランスポート・プロトコルに使用されるかもしれません。 この分野は同じIPアドレスを使用する複数のExporting Processesを区別することの役に立つかもしれません。 抽象データ型: unsigned16 Data Type Semantics: 識別子ElementId: 217状態: 現在のReference: UDPソースポート分野の定義に関してRFC768を見てください。 TCPソースポート分野の定義に関してRFC793を見てください。 SCTPの定義に関してRFC4960を見てください。 http://www.iana.org/assignments/port-numbers で定義されたUDPとTCPポートナンバーに関する追加情報を見つけることができます。
Quittek, et al. Standards Track [Page 24] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[24ページ]。
5.2.4. collectorIPv4Address
5.2.4. collectorIPv4Address
Description:
An IPv4 address to which the Exporting Process sends Flow
information.
Abstract Data Type: ipv4Address
Data Type Semantics: identifier
ElementId: 211
Status: current
記述: Exporting ProcessがFlow情報を送るIPv4アドレス。 抽象データ型: ipv4Addressデータ型意味論: 識別子ElementId: 211状態: 電流
5.2.5. collectorIPv6Address
5.2.5. collectorIPv6Address
Description:
An IPv6 address to which the Exporting Process sends Flow
information.
Abstract Data Type: ipv6Address
Data Type Semantics: identifier
ElementId: 212
Status: current
記述: Exporting ProcessがFlow情報を送るIPv6アドレス。 抽象データ型: ipv6Addressデータ型意味論: 識別子ElementId: 212状態: 電流
5.2.6. exportInterface
5.2.6. exportInterface
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.
記述: Exporting ProcessによってCollectorに送られたIPFIX MessagesがIPFIX Deviceを外すインタフェースのインデックス。 値はRFC2863で定義されるように管理オブジェクト'ifIndex'の値に合っています。 ifIndex値が静的にインタフェースに割り当てられないで、デバイスのマネージメントシステムが再初期化されるときはいつも、インタフェースが番号を付け替えられるかもしれないことに注意してください、RFC2863で指定されるように。 抽象データ型: unsigned32 Data Type Semantics: 識別子ElementId: 213状態: 現在のReference: ifIndexオブジェクトの定義に関してRFC2863を見てください。
Quittek, et al. Standards Track [Page 25] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[25ページ]。
5.2.7. exportProtocolVersion
5.2.7. exportProtocolVersion
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.
記述: 送付Flow情報にExporting Processによって使用されたプロトコルバージョン。 Message HeaderのバージョンNumber分野の値でプロトコルバージョンを与えます。 プロトコルバージョンは、IPFIXのための10とNetFlowバージョン9のための9です。 0の値は、どんな輸出プロトコルも使用中でないことを示します。 抽象データ型: unsigned8 Data Type Semantics: 識別子ElementId: 214状態: 現在のReference: IPFIX Message Headerの定義のためのIPFIXプロトコル仕様[RFC5101]を見てください。 NetFlowバージョン9メッセージヘッダーの定義に関してRFC3954を見てください。
5.2.8. exportTransportProtocol
5.2.8. exportTransportProtocol
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.
記述: 送付Flow情報にExporting Processによって使用されたプロトコル番号の値。 プロトコル番号はIPパケットペイロードタイプを特定します。 プロトコル番号はIANAプロトコル民数記登録で定義されます。 インターネットプロトコルバージョン4(IPv4)では、これはプロトコル分野で運ばれます。 インターネットプロトコルバージョン6(IPv6)では、これはパケットの最後の拡張ヘッダーのNext Header分野で運ばれます。 抽象データ型: unsigned8 Data Type Semantics: 識別子ElementId: 215状態: 現在のReference: IPv4プロトコル分野の仕様に関してRFC791を見てください。 IPv6プロトコル分野の仕様に関してRFC2460を見てください。 プロトコル番号のリストがIANAによって http://www.iana.org/assignments/protocol-numbers に割り当てられるのを見てください。
Quittek, et al. Standards Track [Page 26] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[26ページ]。
5.2.9. collectorTransportPort
5.2.9. collectorTransportPort
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.
記述: Exporting ProcessがFlow情報を送る仕向港識別子。 トランスポート・プロトコルのUDP、TCP、およびSCTPのために、これは目的地ポートナンバーです。 また、この分野は16ビットのソースポート識別子を持っている将来のトランスポート・プロトコルに使用されるかもしれません。 抽象データ型: unsigned16 Data Type Semantics: 識別子ElementId: 216状態: 現在のReference: UDP仕向港分野の定義に関してRFC768を見てください。 TCP仕向港分野の定義に関してRFC793を見てください。 SCTPの定義に関してRFC4960を見てください。 http://www.iana.org/assignments/port-numbers で定義されたUDPとTCPポートナンバーに関する追加情報を見つけることができます。
5.2.10. flowKeyIndicator
5.2.10. flowKeyIndicator
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
記述: このセットの噛み付いている分野は、Data RecordのInformation ElementsのためにFlow Keyとしてそのサーブをマークするのに使用されます。 各ビットは、第n情報Elementを表しながら、Data Recordにn番目のビットで情報Elementを表します。 少し、1を評価するセットは、対応する情報Elementが報告されたFlowのFlow Keyであることを示します。 少し、0を評価するセットは、これがそうでないことを示します。 Data Recordは最初の64の中にすべてのFlowキーズがある設計されたそのようなものがInformation Elementsであったなら64以上Information Elements、対応するTemplate SHOULDを含んでいます、flowKeyIndicatorが64ビットしか含んでいないので。 Data Recordが64未満Information Elementsを含むなら、どんな対応する情報Elementも存在しないflowKeyIndicatorのビットには、値0がなければなりません。 抽象データ型: unsigned64 Data Type Semantics: 旗のElementId: 173状態: 電流
Quittek, et al. Standards Track [Page 27] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[27ページ]。
5.3. Metering and Exporting Process Statistics
5.3. プロセス統計を計量して、エクスポートします。
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.
このセクションのInformation ElementsはMetering Process、そして/または、Exporting Processの統計について説明します。 これらのInformation Elementsのセットは以下のテーブルに記載されています。
+-----+-----------------------------+-----+-------------------------+ | ID | Name | ID | Name | +-----+-----------------------------+-----+-------------------------+ | 41 | exportedMessageTotalCount | 165 | ignoredOctetTotalCount | | 40 | exportedOctetTotalCount | 166 | notSentFlowTotalCount | | 42 | exportedFlowRecordTotalCount| 167 | notSentPacketTotalCount | | 163 | observedFlowTotalCount | 168 | notSentOctetTotalCount | | 164 | ignoredPacketTotalCount | | | +-----+-----------------------------+-----+-------------------------+
+-----+-----------------------------+-----+-------------------------+ | ID| 名前| ID| 名前| +-----+-----------------------------+-----+-------------------------+ | 41 | exportedMessageTotalCount| 165 | ignoredOctetTotalCount| | 40 | exportedOctetTotalCount| 166 | notSentFlowTotalCount| | 42 | exportedFlowRecordTotalCount| 167 | notSentPacketTotalCount| | 163 | observedFlowTotalCount| 168 | notSentOctetTotalCount| | 164 | ignoredPacketTotalCount| | | +-----+-----------------------------+-----+-------------------------+
5.3.1. exportedMessageTotalCount
5.3.1. exportedMessageTotalCount
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
記述: Exporting Process以来Exporting Processが送るIPFIX Messagesの総数、(再、)、特定のCollecting Processへの初期化。 報告された数は対価を運ぶIPFIX Messageを除きます。 この情報Elementを特定のCollecting Processに送るなら、デフォルトで、それはこのCollecting Processに送られたIPFIX Messagesの数を指定します。 抽象データ型: unsigned64 Data Type Semantics: totalCounter ElementId: 41状態: 現在のUnits: メッセージ
5.3.2. exportedOctetTotalCount
5.3.2. exportedOctetTotalCount
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
記述: Exporting Process以来Exporting Processが送る八重奏の総数、(再、)、特定のCollecting Processへの初期化。 この情報Elementの値は、首尾よくCollecting Processに送られたすべてのIPFIX MessagesのIPFIX Message Header長さの値をまとめることによって、計算されます。 報告された数は対価を運ぶIPFIX Messageで八重奏を除きます。 この情報Elementを特定のCollecting Processに送るなら、デフォルトで、それはこのCollecting Processに送られた八重奏の数を指定します。 抽象データ型: unsigned64 Data Type Semantics: totalCounter ElementId: 40状態: 電流
Quittek, et al. Standards Track [Page 28] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[28ページ]。
Units: octets
ユニット: 八重奏
5.3.3. exportedFlowRecordTotalCount
5.3.3. exportedFlowRecordTotalCount
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
記述: Exporting Process以来Exporting ProcessがData Recordsとして送るFlow Recordsの総数、(再、)、特定のCollecting Processへの初期化。 報告された数は対価を運ぶIPFIX MessageでFlow Recordsを除きます。 この情報Elementを特定のCollecting Processに送るなら、デフォルトで、それはこのプロセスに送られたFlow Recordsの数を指定します。 抽象データ型: unsigned64 Data Type Semantics: totalCounter ElementId: 42状態: 現在のUnits: 流れ
5.3.4. observedFlowTotalCount
5.3.4. observedFlowTotalCount
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
記述: Metering Process以来Flowsの総数がObservation Domainで見た、(再、)、このObservation Pointのための初期化。 抽象データ型: unsigned64 Data Type Semantics: totalCounter ElementId: 163状態: 現在のUnits: 流れ
5.3.5. ignoredPacketTotalCount
5.3.5. ignoredPacketTotalCount
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
記述: Metering Processがした観測されたIPパケットの総数が以来処理されない、(再、)、Metering Processの初期化。 抽象データ型: unsigned64 Data Type Semantics: totalCounter ElementId: 164状態: 現在のUnits: パケット
Quittek, et al. Standards Track [Page 29] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[29ページ]。
5.3.6. ignoredOctetTotalCount
5.3.6. ignoredOctetTotalCount
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
記述: Metering Processがした観測されたIPパケット(IPヘッダーを含んでいる)の八重奏の総数が以来処理されない、(再、)、Metering Processの初期化。 抽象データ型: unsigned64 Data Type Semantics: totalCounter ElementId: 165状態: 現在のUnits: 八重奏
5.3.7. notSentFlowTotalCount
5.3.7. notSentFlowTotalCount
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
記述: Collecting Processに送ることの代わりに、Metering Processによって生成されて、Metering ProcessかExporting Processによって下げられたFlow Recordsの総数。 リソース不足と特別なFlow輸出方針を含むこのいくつかの潜在的理由があります。 抽象データ型: unsigned64 Data Type Semantics: totalCounter ElementId: 166状態: 現在のUnits: 流れ
5.3.8. notSentPacketTotalCount
5.3.8. notSentPacketTotalCount
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
記述: Metering Processによって生成されて、Metering Processに立ち寄ったFlow RecordsかCollecting Processに送ることの代わりにExporting Processによるパケットの総数。 リソース不足と特別なFlow輸出方針を含むこのいくつかの潜在的理由があります。 抽象データ型: unsigned64 Data Type Semantics: totalCounter ElementId: 167状態: 現在のUnits: パケット
Quittek, et al. Standards Track [Page 30] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[30ページ]。
5.3.9. notSentOctetTotalCount
5.3.9. notSentOctetTotalCount
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
記述: Metering Processによって生成されて、Metering Processに立ち寄ったFlow RecordsかCollecting Processに送ることの代わりにExporting Processによるパケットの八重奏の総数。 リソース不足と特別なFlow輸出方針を含むこのいくつかの潜在的理由があります。 抽象データ型: unsigned64 Data Type Semantics: totalCounter ElementId: 168状態: 現在のUnits: 八重奏
5.4. IP Header Fields
5.4. IPヘッダーフィールド
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から派生しているヘッダーフィールドが詳細と組み合わせて評価するこのセクションのInformation Elements。
+-----+----------------------------+-----+--------------------------+ | 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 | +-----+----------------------------+-----+--------------------------+
+-----+----------------------------+-----+--------------------------+ | ID| 名前| ID| 名前| +-----+----------------------------+-----+--------------------------+ | 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| +-----+----------------------------+-----+--------------------------+
5.4.1. ipVersion
5.4.1. ipVersion
Description:
The IP version field in the IP packet header.
Abstract Data Type: unsigned8
Data Type Semantics: identifier
ElementId: 60
Status: current
記述: IPパケットのヘッダーのIPバージョン分野。 抽象データ型: unsigned8 Data Type Semantics: 識別子ElementId: 60状態: 電流
Quittek, et al. Standards Track [Page 31] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[31ページ]。
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.
参照: IPv4パケットのヘッダーとのバージョン分野の定義に関してRFC791を見てください。 IPv6パケットのヘッダーとのバージョン分野の定義に関してRFC2460を見てください。 http://www.iana.org/assignments/version-numbers で定義されたバージョン番号に関する追加情報を見つけることができます。
5.4.2. sourceIPv4Address
5.4.2. sourceIPv4Address
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状態: 現在のReference: IPv4ソースアドレス・フィールドの定義に関してRFC791を見てください。
5.4.3. sourceIPv6Address
5.4.3. sourceIPv6Address
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状態: 現在のReference: IPv6ヘッダーとのSource Address分野の定義に関してRFC2460を見てください。
5.4.4. sourceIPv4PrefixLength
5.4.4. sourceIPv4PrefixLength
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.
記述: sourceIPv4Prefix情報Elementで関連している隣接のビットの数。 抽象データ型: unsigned8 ElementId: 9状態: 現在のUnits: ビットRange: 有効枠は0-32です。
Quittek, et al. Standards Track [Page 32] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[32ページ]。
5.4.5. sourceIPv6PrefixLength
5.4.5. sourceIPv6PrefixLength
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.
記述: sourceIPv6Prefix情報Elementで関連している隣接のビットの数。 抽象データ型: unsigned8 ElementId: 29状態: 現在のUnits: ビットRange: 有効枠は0-128です。
5.4.6. sourceIPv4Prefix
5.4.6. sourceIPv4Prefix
Description:
IPv4 source address prefix.
Abstract Data Type: ipv4Address
ElementId: 44
Status: current
記述: IPv4ソースアドレス接頭語。 抽象データ型: ipv4Address ElementId: 44状態: 電流
5.4.7. sourceIPv6Prefix
5.4.7. sourceIPv6Prefix
Description:
IPv6 source address prefix.
Abstract Data Type: ipv6Address
ElementId: 170
Status: current
記述: IPv6ソースアドレス接頭語。 抽象データ型: ipv6Address ElementId: 170状態: 電流
5.4.8. destinationIPv4Address
5.4.8. destinationIPv4Address
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状態: 現在のReference: IPv4目的地アドレス・フィールドの定義に関してRFC791を見てください。
Quittek, et al. Standards Track [Page 33] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[33ページ]。
5.4.9. destinationIPv6Address
5.4.9. destinationIPv6Address
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状態: 現在のReference: IPv6ヘッダーとのDestination Address分野の定義に関してRFC2460を見てください。
5.4.10. destinationIPv4PrefixLength
5.4.10. destinationIPv4PrefixLength
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情報Elementで関連している隣接のビットの数。 抽象データ型: unsigned8 ElementId: 13状態: 現在のUnits: ビットRange: 有効枠は0-32です。
5.4.11. destinationIPv6PrefixLength
5.4.11. destinationIPv6PrefixLength
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.
記述: destinationIPv6Prefix情報Elementで関連している隣接のビットの数。 抽象データ型: unsigned8 ElementId: 30状態: 現在のUnits: ビットRange: 有効枠は0-128です。
5.4.12. destinationIPv4Prefix
5.4.12. destinationIPv4Prefix
Description:
IPv4 destination address prefix.
Abstract Data Type: ipv4Address
ElementId: 45
Status: current
記述: IPv4目的地アドレス接頭語。 抽象データ型: ipv4Address ElementId: 45状態: 電流
Quittek, et al. Standards Track [Page 34] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[34ページ]。
5.4.13. destinationIPv6Prefix
5.4.13. destinationIPv6Prefix
Description:
IPv6 destination address prefix.
Abstract Data Type: ipv6Address
ElementId: 169
Status: current
記述: IPv6目的地アドレス接頭語。 抽象データ型: ipv6Address ElementId: 169状態: 電流
5.4.14. ipTTL
5.4.14. ipTTL
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.
記述: IPv4に関しては、情報Elementの値はIPv4パケットのヘッダーのLive(TTL)分野にTimeの値を合わせます。 IPv6に関しては、情報Elementの値はIPv6パケットのヘッダーのHop Limit分野の値に合っています。 抽象データ型: unsigned8 ElementId: 192状態: 現在のUnits: ホップReference: Live分野へのIPv4 Timeの定義に関してRFC791を見てください。 IPv6 Hop Limit分野の定義に関してRFC2460を見てください。
5.4.15. protocolIdentifier
5.4.15. protocolIdentifier
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)では、これはパケットの最後の拡張ヘッダーのNext Header分野で運ばれます。 抽象データ型: unsigned8 Data Type Semantics: 識別子ElementId: 4状態: 現在のReference: IPv4プロトコル分野の仕様に関してRFC791を見てください。 IPv6プロトコル分野の仕様に関してRFC2460を見てください。 プロトコル番号のリストがIANAによって http://www.iana.org/assignments/protocol-numbers に割り当てられるのを見てください。
Quittek, et al. Standards Track [Page 35] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[35ページ]。
5.4.16. nextHeaderIPv6
5.4.16. nextHeaderIPv6
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ヘッダーのNext Header分野の値。 値は以下のIPv6拡張ヘッダーか以下のIPペイロードのタイプを特定します。 有効値はIANAプロトコル民数記登録で定義されます。 抽象データ型: unsigned8 ElementId: 193状態: 現在のReference: IPv6 Next Header分野の定義に関してRFC2460を見てください。 プロトコル番号のリストがIANAによって http://www.iana.org/assignments/protocol-numbers に割り当てられるのを見てください。
5.4.17. ipDiffServCodePoint
5.4.17. ipDiffServCodePoint
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.
記述: Differentiated Services分野でコード化されたDifferentiated Services Code Point(DSCP)の値。 Differentiated ServicesはIPv4 TOS分野の最も重要な6ビットかIPv6 Traffic Classがそれぞれさばく長さをさばきます。 この情報ElementはDifferentiated Services分野の6ビットだけをコード化します。 したがって、値は0〜63まで及ぶかもしれません。 抽象データ型: unsigned8 Data Type Semantics: 識別子ElementId: 195状態: 現在のRange: 有効枠は0-63です。 参照: Differentiated Services分野の定義に関してRFC3260を見てください。 IPv4 TOS分野の定義に関してRFC1812(セクション5.3.2)とRFC791を見てください。 IPv6 Traffic Class分野の定義に関してRFC2460を見てください。
5.4.18. ipPrecedence
5.4.18. ipPrecedence
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
記述: IP Precedenceの値。 IP Precedence価値はIPv4 TOS分野かIPv6 Traffic Class分野の最初の3ビットでそれぞれコード化されます。 この情報Elementはこれらの3ビットだけをコード化します。 したがって、値は0〜7まで及ぶかもしれません。 抽象データ型: unsigned8 Data Type Semantics: 識別子ElementId: 196状態: 電流
Quittek, et al. Standards Track [Page 36] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[36ページ]。
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.
範囲: 有効枠は0-7です。 参照: IP Precedenceの定義に関してRFC1812(セクション5.3.3)とRFC791を見てください。 IPv4 TOS分野の定義に関してRFC1812(セクション5.3.2)とRFC791を見てください。 IPv6 Traffic Class分野の定義に関してRFC2460を見てください。
5.4.19. ipClassOfService
5.4.19. ipClassOfService
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パケットのヘッダーのTraffic Class分野の値です。 抽象データ型: unsigned8 Data Type Semantics: 識別子ElementId: 5状態: 現在のReference: IPv4 TOS分野の定義に関してRFC1812(セクション5.3.2)とRFC791を見てください。 IPv6 Traffic Class分野の定義に関してRFC2460を見てください。
5.4.20. postIpClassOfService
5.4.20. postIpClassOfService
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.
記述: この情報Elementの定義は情報Element'ipClassOfService'の定義と同じです、パケットがObservation Pointを渡した後にmiddlebox機能によって引き起こされた潜在的に変更された値を報告するのを除いて。 抽象データ型: unsigned8 Data Type Semantics: 識別子ElementId: 55状態: 現在のReference: IPv4 TOS分野の定義に関してRFC791を見てください。 IPv6 Traffic Class分野の定義に関してRFC2460を見てください。 middleboxesの定義に関してRFC3234を見てください。
Quittek, et al. Standards Track [Page 37] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[37ページ]。
5.4.21. flowLabelIPv6
5.4.21. flowLabelIPv6
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 Flow Label分野の値。 抽象データ型: unsigned32 Data Type Semantics: 識別子ElementId: 31状態: 現在のReference: IPv6パケットのヘッダーとのFlow Label分野の定義に関してRFC2460を見てください。
5.4.22. isMulticast
5.4.22. isMulticast
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があって、Destination Address分野が224.0からの範囲の予約されたマルチキャストアドレスを含んでいるならこの八重奏の最初のビットが1に設定される、.0、.0、239.255 .255 .255。 さもなければ、このビットは0に設定されます。 この八重奏の2番目と3番目のビットは今後の使用のために予約されます。 八重奏の残っているビットはIP Destination Addressが予約されたIPv6マルチキャストアドレスである場合にだけゼロ以外の値に設定されます。 次に、八重奏の4番目のビットはIPv6マルチキャストアドレスのT旗の値に設定されます、そして、残っている4ビットはIPv6マルチキャストアドレスの範囲分野の値に設定されます。
0 1 2 3 4 5 6 7
+------+------+------+------+------+------+------+------+
| MCv4 | RES. | RES. | T | IPv6 multicast scope |
+------+------+------+------+------+------+------+------+
0 1 2 3 4 5 6 7 +------+------+------+------+------+------+------+------+ | MCv4| RES。 | RES。 | T| IPv6マルチキャスト範囲| +------+------+------+------+------+------+------+------+
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マルチキャストBits1-2であるなら1にセットしてください: 未来に予約されて、Bit4を使用してください: IPv6マルチキャストBits4-7であるならTの値に旗を設定してください: マルチキャスト範囲の値に、IPv6マルチキャストであるなら、セットします。
Abstract Data Type: unsigned8 Data Type Semantics: flags ElementId: 206 Status: current
抽象データ型: unsigned8 Data Type Semantics: 旗のElementId: 206状態: 電流
Quittek, et al. Standards Track [Page 38] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[38ページ]。
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.
参照: 予約されたIPv4マルチキャストアドレスの仕様に関してRFC1112を見てください。 予約されたIPv6マルチキャストアドレスの仕様とT旗とIPv6マルチキャスト範囲の定義に関してRFC4291を見てください。
5.4.23. fragmentIdentification
5.4.23. fragmentIdentification
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 FragmentヘッダーのIdentification分野の値。 断片ヘッダーが全くなければ、値はIPv6のための0です。 抽象データ型: unsigned32 Data Type Semantics: 識別子ElementId: 54状態: 現在のReference: IPv4 Identification分野の定義に関してRFC791を見てください。 IPv6 FragmentヘッダーとのIdentification分野の定義に関してRFC2460を見てください。
5.4.24. fragmentOffset
5.4.24. fragmentOffset
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.
記述: IP断片の値はそれぞれIPv4パケットのヘッダーかIPv6 Fragmentヘッダーの分野を相殺しました。 断片ヘッダーが全くなければ、値はIPv6のための0です。 抽象データ型: unsigned16 Data Type Semantics: 識別子ElementId: 88状態: 現在のReference: 断片の仕様のためのRFC791がIPv4ヘッダーで相殺するのを見てください。 断片の仕様のためのRFC2460がIPv6 Fragmentヘッダーで相殺するのを見てください。
5.4.25. fragmentFlags
5.4.25. fragmentFlags
Description:
Fragmentation properties indicated by flags in the IPv4 packet
header or the IPv6 Fragment header, respectively.
記述: それぞれIPv4パケットのヘッダーかIPv6 Fragmentヘッダーで旗で示された断片化の特性。
Bit 0: (RS) Reserved.
The value of this bit MUST be 0 until specified
otherwise.
ビット0: (RS) 予約にされる。 別の方法で指定されるまで、このビットの価値は0であるに違いありません。
Quittek, et al. Standards Track [Page 39] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[39ページ]。
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 = 5月の断片、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は、より多くの断片と等しいです。 IPv6 FragmentヘッダーでそれぞれIPv4ヘッダーのMF旗、または、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 |
+---+---+---+---+---+---+---+---+
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 Data Type Semantics: 旗のElementId: 197状態: 現在のReference: IPv4断片旗の仕様に関してRFC791を見てください。 IPv6 Fragmentヘッダーの仕様に関してRFC2460を見てください。
5.4.26. ipHeaderLength
5.4.26. ipHeaderLength
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に関しては、この情報Elementの値は40です。 抽象データ型: unsigned8 ElementId: 189状態: 現在のUnits: 八重奏Reference: IPv4ヘッダーの仕様に関してRFC791を見てください。 IPv6ヘッダーの仕様に関してRFC2460を見てください。
5.4.27. ipv4IHL
5.4.27. ipv4IHL
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ヘッダーのインターネットHeader Length(IHL)分野の値。 それは4つの八重奏のユニットのヘッダーの長さを指定します。 ユニットは長さの値を報告するもう片方のInformation Elementsの大部分と異なっています。
Quittek, et al. Standards Track [Page 40] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[40ページ]。
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状態: 現在のUnits: 4 八重奏Reference: IPv4ヘッダーの仕様に関してRFC791を見てください。
5.4.28. totalLengthIPv4
5.4.28. totalLengthIPv4
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状態: 現在のUnits: 八重奏Reference: IPv4の仕様に関してRFC791を見てください。全長。
5.4.29. ipTotalLength
5.4.29. ipTotalLength
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状態: 現在のUnits: 八重奏Reference: IPv4の仕様に関してRFC791を見てください。全長。 IPv6ペイロード長の仕様に関してRFC2460を見てください。 IPv6のジャンボなペイロード長の仕様に関してRFC2675を見てください。
5.4.30. payloadLengthIPv6
5.4.30. payloadLengthIPv6
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.
記述: この情報ElementはIPv6ヘッダーの有効搭載量Length分野の値を報告します。 IPv6拡張ヘッダーがペイロードに属すことに注意してください。 また、ジャンボなペイロードオプションの場合のIPv6ヘッダーの有効搭載量Length分野の値がゼロであり、この情報Elementによって報告された値もそうになることに注意してください。 抽象データ型: unsigned16 ElementId: 191状態: 現在のUnits: 八重奏Reference: IPv6ペイロード長の仕様に関してRFC2460を見てください。 IPv6のジャンボなペイロードオプションの仕様に関してRFC2675を見てください。
Quittek, et al. Standards Track [Page 41] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[41ページ]。
5.5. Transport Header Fields
5.5. 輸送ヘッダーフィールド
The set of Information Elements related to transport header fields and length includes the Information Elements listed in the table below.
輸送ヘッダーフィールドと長さに関連するInformation ElementsのセットはElementsが以下のテーブルにリストアップした情報を含んでいます。
+-----+---------------------------+-----+---------------------------+ | 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 | +-----+---------------------------+-----+---------------------------+
+-----+---------------------------+-----+---------------------------+ | ID| 名前| ID| 名前| +-----+---------------------------+-----+---------------------------+ | 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| +-----+---------------------------+-----+---------------------------+
5.5.1. sourceTransportPort
5.5.1. sourceTransportPort
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 Data Type Semantics: 識別子ElementId: 7状態: 現在のReference: UDPソースポート分野の定義に関してRFC768を見てください。 TCPソースポート分野の定義に関してRFC793を見てください。 SCTPの定義に関してRFC4960を見てください。 http://www.iana.org/assignments/port-numbers で定義されたUDPとTCPポートナンバーに関する追加情報を見つけることができます。
5.5.2. destinationTransportPort
5.5.2. destinationTransportPort
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.
記述: 輸送ヘッダーの仕向港識別子。 トランスポート・プロトコルのUDP、TCP、およびSCTPのために、これはそれぞれのヘッダーで与えられた目的地ポートナンバーです。 また、この分野は16ビットの仕向港識別子を持っている将来のトランスポート・プロトコルに使用されるかもしれません。
Quittek, et al. Standards Track [Page 42] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[42ページ]。
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 Data Type Semantics: 識別子ElementId: 11状態: 現在のReference: UDP仕向港分野の定義に関してRFC768を見てください。 TCP仕向港分野の定義に関してRFC793を見てください。 SCTPの定義に関してRFC4960を見てください。 http://www.iana.org/assignments/port-numbers で定義されたUDPとTCPポートナンバーに関する追加情報を見つけることができます。
5.5.3. udpSourcePort
5.5.3. udpSourcePort
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 Data Type Semantics: 識別子ElementId: 180状態: 現在のReference: UDPソースポート分野の定義に関してRFC768を見てください。 http://www.iana.org/assignments/port-numbers で定義されたUDPポートナンバーに関する追加情報を見つけることができます。
5.5.4. udpDestinationPort
5.5.4. udpDestinationPort
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 Data Type Semantics: 識別子ElementId: 181状態: 現在のReference: UDP仕向港分野の定義に関してRFC768を見てください。 http://www.iana.org/assignments/port-numbers で定義されたUDPポートナンバーに関する追加情報を見つけることができます。
5.5.5. udpMessageLength
5.5.5. udpMessageLength
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ヘッダーのLength分野の値。 抽象データ型: unsigned16 ElementId: 205状態: 現在のUnits: 八重奏Reference: UDPヘッダーの仕様に関してRFC768を見てください。
Quittek, et al. Standards Track [Page 43] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[43ページ]。
5.5.6. tcpSourcePort
5.5.6. tcpSourcePort
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 Data Type Semantics: 識別子ElementId: 182状態: 現在のReference: TCPソースポート分野の定義に関してRFC793を見てください。 http://www.iana.org/assignments/port-numbers で定義されたTCPポートナンバーに関する追加情報を見つけることができます。
5.5.7. tcpDestinationPort
5.5.7. tcpDestinationPort
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 Data Type Semantics: 識別子ElementId: 183状態: 現在のReference: TCPソースポート分野の定義に関してRFC793を見てください。 http://www.iana.org/assignments/port-numbers で定義されたTCPポートナンバーに関する追加情報を見つけることができます。
5.5.8. tcpSequenceNumber
5.5.8. tcpSequenceNumber
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状態: 現在のReference: TCP一連番号の定義に関してRFC793を見てください。
5.5.9. tcpAcknowledgementNumber
5.5.9. tcpAcknowledgementNumber
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状態: 現在のReference: TCP承認番号の定義に関してRFC793を見てください。
Quittek, et al. Standards Track [Page 44] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[44ページ]。
5.5.10. tcpWindowSize
5.5.10. tcpWindowSize
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状態: 現在のReference: TCP窓の分野の定義に関してRFC793を見てください。 TCP窓のスケールの定義に関してRFC1323を見てください。
5.5.11. tcpWindowScale
5.5.11. tcpWindowScale
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.
記述: TCPヘッダーの窓の分野のスケール。 抽象データ型: unsigned16 ElementId: 238状態: 現在のReference: TCP窓のスケールの定義に関してRFC1323を見てください。
5.5.12. tcpUrgentPointer
5.5.12. tcpUrgentPointer
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状態: 現在のReference: TCPの緊急の指針の定義に関してRFC793を見てください。
5.5.13. tcpHeaderLength
5.5.13. tcpHeaderLength
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ヘッダーの長さ。 この情報Elementの値がTCPヘッダーのData Offset分野の値と異なっていることに注意してください。 Data Offset分野は4つの八重奏のユニットのTCPヘッダーの長さを示します。 このInformation Elementsはユニットの八重奏における、TCPヘッダーの長さを指定します。 抽象データ型: unsigned8 ElementId: 188状態: 現在のUnits: 八重奏Reference: TCPヘッダーの定義に関してRFC793を見てください。
Quittek, et al. Standards Track [Page 45] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[45ページ]。
5.5.14. icmpTypeCodeIPv4
5.5.14. icmpTypeCodeIPv4
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メッセージのタイプとCode。 両方の値の組み合わせは+ (ICMPタイプ*256)ICMPコードとして報告されます。 抽象データ型: unsigned16 Data Type Semantics: 識別子ElementId: 32状態: 現在のReference: IPv4 ICMPタイプとコード分野の定義に関してRFC792を見てください。
5.5.15. icmpTypeIPv4
5.5.15. icmpTypeIPv4
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 Data Type Semantics: 識別子ElementId: 176状態: 現在のReference: IPv4 ICMPタイプ分野の定義に関してRFC792を見てください。
5.5.16. icmpCodeIPv4
5.5.16. icmpCodeIPv4
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 Data Type Semantics: 識別子ElementId: 177状態: 現在のReference: IPv4 ICMPコード分野の定義に関してRFC792を見てください。
5.5.17. icmpTypeCodeIPv6
5.5.17. icmpTypeCodeIPv6
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メッセージのタイプとCode。 両方の値の組み合わせは+ (ICMPタイプ*256)ICMPコードとして報告されます。 抽象データ型: unsigned16 Data Type Semantics: 識別子ElementId: 139状態: 現在のReference: IPv6 ICMPタイプとコード分野の定義に関してRFC4443を見てください。
Quittek, et al. Standards Track [Page 46] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[46ページ]。
5.5.18. icmpTypeIPv6
5.5.18. icmpTypeIPv6
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 Data Type Semantics: 識別子ElementId: 178状態: 現在のReference: IPv6 ICMPタイプ分野の定義に関してRFC4443を見てください。
5.5.19. icmpCodeIPv6
5.5.19. icmpCodeIPv6
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 Data Type Semantics: 識別子ElementId: 179状態: 現在のReference: IPv6 ICMPコード分野の定義に関してRFC4443を見てください。
5.5.20. igmpType
5.5.20. igmpType
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 Data Type Semantics: 識別子ElementId: 33状態: 現在のReference: IGMPタイプ分野の定義に関してRFC3376を見てください。
Quittek, et al. Standards Track [Page 47] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[47ページ]。
5.6. Sub-IP Header Fields
5.6. サブIPヘッダーフィールド
The set of Information Elements related to Sub-IP header fields includes the Information Elements listed in the table below.
Sub-IPヘッダーフィールドに関連するInformation ElementsのセットはElementsが以下のテーブルにリストアップした情報を含んでいます。
+-----+---------------------------+-----+---------------------------+ | 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 | +-----+---------------------------+-----+---------------------------+
+-----+---------------------------+-----+---------------------------+ | ID| 名前| ID| 名前| +-----+---------------------------+-----+---------------------------+ | 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| +-----+---------------------------+-----+---------------------------+
5.6.1. sourceMacAddress
5.6.1. sourceMacAddress
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.
記述: IEEE802ソースMACは分野を扱います。 抽象データ型: macAddressデータ型意味論: 識別子ElementId: 56状態: 現在のReference: IEEE.802-3.2002を見てください。
5.6.2. postSourceMacAddress
5.6.2. postSourceMacAddress
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.
記述: この情報Elementの定義は情報Element'sourceMacAddress'の定義と同じです、パケットがObservation Pointを渡した後にmiddlebox機能によって引き起こされた潜在的に変更された値を報告するのを除いて。 抽象データ型: macAddressデータ型意味論: 識別子ElementId: 81状態: 現在のReference: IEEE.802-3.2002を見てください。
Quittek, et al. Standards Track [Page 48] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[48ページ]。
5.6.3. vlanId
5.6.3. vlanId
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パケットに付けられたTag Control情報分野から抜粋されたIEEE 802.1Q VLAN識別子(VID)。 抽象データ型: unsigned16 Data Type Semantics: 識別子ElementId: 58状態: 現在のReference: IEEE.802-1Q.2003を見てください。
5.6.4. postVlanId
5.6.4. postVlanId
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.
記述: この情報Elementの定義は情報Element'vlanId'の定義と同じです、パケットがObservation Pointを渡した後にmiddlebox機能によって引き起こされた潜在的に変更された値を報告するのを除いて。 抽象データ型: unsigned16 Data Type Semantics: 識別子ElementId: 59状態: 現在のReference: IEEE.802-1Q.2003を見てください。
5.6.5. destinationMacAddress
5.6.5. destinationMacAddress
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.
記述: IEEE802の目的地MACは分野を扱います。 抽象データ型: macAddressデータ型意味論: 識別子ElementId: 80状態: 現在のReference: IEEE.802-3.2002を見てください。
5.6.6. postDestinationMacAddress
5.6.6. postDestinationMacAddress
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
記述: この情報Elementの定義は情報Element'destinationMacAddress'の定義と同じです、パケットがObservation Pointを渡した後にmiddlebox機能によって引き起こされた潜在的に変更された値を報告するのを除いて。 抽象データ型: macAddressデータ型意味論: 識別子ElementId: 57状態: 電流
Quittek, et al. Standards Track [Page 49] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[49ページ]。
Reference:
See IEEE.802-3.2002.
参照: IEEE.802-3.2002を見てください。
5.6.7. wlanChannelId
5.6.7. wlanChannelId
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.
記述: (Wi-Fi)チャンネルが使用した802.11のものに関する識別子。 抽象データ型: unsigned8 Data Type Semantics: 識別子ElementId: 146状態: 現在のReference: IEEE.802-11.1999を見てください。
5.6.8. wlanSSID
5.6.8. wlanSSID
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)ネットワークが使用したService Set IDentifier(SSID)特定。 IEEE.802-11.1999によると、SSIDは一連の最大32のキャラクタにコード化されます。 抽象データ型: ElementIdを結んでください: 147状態: 現在のReference: IEEE.802-11.1999を見てください。
5.6.9. mplsTopLabelTTL
5.6.9. mplsTopLabelTTL
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.
記述: TTLは先端からMPLSラベルスタックエントリー、すなわち、押された最後のラベルをさばきます。 抽象データ型: unsigned8 ElementId: 200状態: 現在のUnits: ホップReference: TTL分野の仕様に関してRFC3032を見てください。
Quittek, et al. Standards Track [Page 50] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[50ページ]。
5.6.10. mplsTopLabelExp
5.6.10. mplsTopLabelExp
Description:
The Exp field from the top MPLS label stack entry, i.e., the last
label that was pushed.
記述: Expは先端からMPLSラベルスタックエントリー、すなわち、押された最後のラベルをさばきます。
Bits 0-4: Don't Care, value is irrelevant.
Bits 5-7: MPLS Exp field.
ビット0-4: しないでください。Care、値は無関係です。 ビット5-7: MPLS Exp分野。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| don't care | Exp |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 気にかけないでください。| 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 Data Type Semantics: 旗のElementId: 203状態: 現在のReference: Exp分野の仕様に関してRFC3032を見てください。 Exp分野の用法に関してRFC3270を見てください。
5.6.11. postMplsTopLabelExp
5.6.11. postMplsTopLabelExp
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.
記述: この情報Elementの定義は情報Element'mplsTopLabelExp'の定義と同じです、パケットがObservation Pointを渡した後にmiddlebox機能によって引き起こされた潜在的に変更された値を報告するのを除いて。 抽象データ型: unsigned8 Data Type Semantics: 旗のElementId: 237状態: 現在のReference: Exp分野の仕様に関してRFC3032を見てください。 Exp分野の用法に関してRFC3270を見てください。
5.6.12. mplsLabelStackDepth
5.6.12. mplsLabelStackDepth
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状態: 現在のUnits: スタックエントリーをReferenceとラベルしてください: MPLSラベルスタックの仕様に関してRFC3032を見てください。
Quittek, et al. Standards Track [Page 51] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[51ページ]。
5.6.13. mplsLabelStackLength
5.6.13. mplsLabelStackLength
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状態: 現在のUnits: 八重奏Reference: MPLSラベルスタックの仕様に関してRFC3032を見てください。
5.6.14. mplsPayloadLength
5.6.14. mplsPayloadLength
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状態: 現在のUnits: 八重奏Reference: MPLSパケットの仕様に関してRFC3031を見てください。 MPLSラベルスタックの仕様に関してRFC3032を見てください。
5.6.15. mplsTopLabelStackSection
5.6.15. mplsTopLabelStackSection
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からのLabel、Exp、およびS分野はスタックエントリーをラベルします、すなわち、押された最後のラベルから。 この情報Elementのサイズは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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ラベル| Exp|S| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label: Label Value, 20 bits
Exp: Experimental Use, 3 bits
S: Bottom of Stack, 1 bit
以下をラベルしてください。 Value、20ビットをExpとラベルしてください: 実験的なUse、3ビットS: Stack、噛み付かれた1の下部
Abstract Data Type: octetArray
Data Type Semantics: identifier
ElementId: 70
Status: current
Reference:
See RFC 3032.
抽象データ型: octetArrayデータ型意味論: 識別子ElementId: 70状態: 現在のReference: RFC3032を見てください。
Quittek, et al. Standards Track [Page 52] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[52ページ]。
5.6.16. mplsLabelStackSection2
5.6.16. mplsLabelStackSection2
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.
記述: ラベルからのLabel、Exp、およびS分野はmplsTopLabelStackSectionによって報告されるラベルスタックエントリーの直前押されたエントリーを積み重ねます。 さらに詳しい明細についてはmplsTopLabelStackSectionの定義を見てください。 この情報Elementのサイズは3つの八重奏です。 抽象データ型: octetArrayデータ型意味論: 識別子ElementId: 71状態: 現在のReference: RFC3032を見てください。
5.6.17. mplsLabelStackSection3
5.6.17. mplsLabelStackSection3
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.
記述: ラベルからのLabel、Exp、およびS分野はmplsLabelStackSection2によって報告されるラベルスタックエントリーの直前押されたエントリーを積み重ねます。 さらに詳しい明細についてはmplsTopLabelStackSectionの定義を見てください。 この情報Elementのサイズは3つの八重奏です。 抽象データ型: octetArrayデータ型意味論: 識別子ElementId: 72状態: 現在のReference: RFC3032を見てください。
5.6.18. mplsLabelStackSection4
5.6.18. mplsLabelStackSection4
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.
記述: ラベルからのLabel、Exp、およびS分野はmplsLabelStackSection3によって報告されるラベルスタックエントリーの直前押されたエントリーを積み重ねます。 さらに詳しい明細についてはmplsTopLabelStackSectionの定義を見てください。 この情報Elementのサイズは3つの八重奏です。 抽象データ型: octetArrayデータ型意味論: 識別子ElementId: 73状態: 現在のReference: RFC3032を見てください。
Quittek, et al. Standards Track [Page 53] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[53ページ]。
5.6.19. mplsLabelStackSection5
5.6.19. mplsLabelStackSection5
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.
記述: ラベルからのLabel、Exp、およびS分野はmplsLabelStackSection4によって報告されるラベルスタックエントリーの直前押されたエントリーを積み重ねます。 さらに詳しい明細についてはmplsTopLabelStackSectionの定義を見てください。 この情報Elementのサイズは3つの八重奏です。 抽象データ型: octetArrayデータ型意味論: 識別子ElementId: 74状態: 現在のReference: RFC3032を見てください。
5.6.20. mplsLabelStackSection6
5.6.20. mplsLabelStackSection6
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.
記述: ラベルからのLabel、Exp、およびS分野はmplsLabelStackSection5によって報告されるラベルスタックエントリーの直前押されたエントリーを積み重ねます。 さらに詳しい明細についてはmplsTopLabelStackSectionの定義を見てください。 この情報Elementのサイズは3つの八重奏です。 抽象データ型: octetArrayデータ型意味論: 識別子ElementId: 75状態: 現在のReference: RFC3032を見てください。
5.6.21. mplsLabelStackSection7
5.6.21. mplsLabelStackSection7
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.
記述: ラベルからのLabel、Exp、およびS分野はmplsLabelStackSection6によって報告されるラベルスタックエントリーの直前押されたエントリーを積み重ねます。 さらに詳しい明細についてはmplsTopLabelStackSectionの定義を見てください。 この情報Elementのサイズは3つの八重奏です。 抽象データ型: octetArrayデータ型意味論: 識別子ElementId: 76状態: 現在のReference: RFC3032を見てください。
Quittek, et al. Standards Track [Page 54] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[54ページ]。
5.6.22. mplsLabelStackSection8
5.6.22. mplsLabelStackSection8
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.
記述: ラベルからのLabel、Exp、およびS分野はmplsLabelStackSection7によって報告されるラベルスタックエントリーの直前押されたエントリーを積み重ねます。 さらに詳しい明細についてはmplsTopLabelStackSectionの定義を見てください。 この情報Elementのサイズは3つの八重奏です。 抽象データ型: octetArrayデータ型意味論: 識別子ElementId: 77状態: 現在のReference: RFC3032を見てください。
5.6.23. mplsLabelStackSection9
5.6.23. mplsLabelStackSection9
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.
記述: ラベルからのLabel、Exp、およびS分野はmplsLabelStackSection8によって報告されるラベルスタックエントリーの直前押されたエントリーを積み重ねます。 さらに詳しい明細についてはmplsTopLabelStackSectionの定義を見てください。 この情報Elementのサイズは3つの八重奏です。 抽象データ型: octetArrayデータ型意味論: 識別子ElementId: 78状態: 現在のReference: RFC3032を見てください。
5.6.24. mplsLabelStackSection10
5.6.24. mplsLabelStackSection10
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.
記述: ラベルからのLabel、Exp、およびS分野はmplsLabelStackSection9によって報告されるラベルスタックエントリーの直前押されたエントリーを積み重ねます。 さらに詳しい明細についてはmplsTopLabelStackSectionの定義を見てください。 この情報Elementのサイズは3つの八重奏です。 抽象データ型: octetArrayデータ型意味論: 識別子ElementId: 79状態: 現在のReference: RFC3032を見てください。
Quittek, et al. Standards Track [Page 55] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[55ページ]。
5.7. Derived Packet Properties
5.7. 派生しているパケットの特性
The set of Information Elements derived from packet properties (for example, values of header fields) includes the Information Elements listed in the table below.
パケットの特性(例えば、ヘッダーフィールドの値)から得られたInformation ElementsのセットはElementsが以下のテーブルにリストアップした情報を含んでいます。
+-----+---------------------------+-----+---------------------------+ | 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 | | | +-----+---------------------------+-----+---------------------------+
+-----+---------------------------+-----+---------------------------+ | ID| 名前| ID| 名前| +-----+---------------------------+-----+---------------------------+ | 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| | | +-----+---------------------------+-----+---------------------------+
5.7.1. ipPayloadLength
5.7.1. ipPayloadLength
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パケットに関しては、この情報Elementの値はIPv4パケット(情報Element totalLengthIPv4によって報告されるように)の全長とIPv4ヘッダーの長さの違い(情報Element headerLengthIPv4によって報告されるように)です。 この分野の値がゼロでありIPv6に関して、IPv6ヘッダーの有効搭載量Length分野の値を除いて、報告されます、そして、有効なジャンボなペイロードオプションがあります。 この場合、ジャンボなペイロードオプションにおける、Jumbo有効搭載量Length分野の値は報告されます。 抽象データ型: unsigned32 ElementId: 204状態: 現在のUnits: 八重奏Reference: IPv4パケットの仕様に関してRFC791を見てください。 IPv6ペイロード長の仕様に関してRFC2460を見てください。 IPv6のジャンボなペイロード長の仕様に関してRFC2675を見てください。
5.7.2. ipNextHopIPv4Address
5.7.2. ipNextHopIPv4Address
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状態: 電流
Quittek, et al. Standards Track [Page 56] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[56ページ]。
5.7.3. ipNextHopIPv6Address
5.7.3. ipNextHopIPv6Address
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状態: 電流
5.7.4. bgpSourceAsNumber
5.7.4. bgpSourceAsNumber
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)番号。 単に順不同のASがセットしたので(そして、どんな規則正しいAS系列としても、そうしません)このFlowのためのAS経路情報が利用可能であるなら、この情報Elementの値は0です。 抽象データ型: unsigned32 Data Type Semantics: 識別子ElementId: 16状態: 現在のReference: BGP-4の記述に関してRFC4271を見てください、そして、AS番号の定義に関してRFC1930を見てください。
5.7.5. bgpDestinationAsNumber
5.7.5. bgpDestinationAsNumber
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)番号。 単に順不同のASがセットしたので(そして、どんな規則正しいAS系列としても、そうしません)このFlowのためのAS経路情報が利用可能であるなら、この情報Elementの値は0です。 抽象データ型: unsigned32 Data Type Semantics: 識別子ElementId: 17状態: 現在のReference: BGP-4の記述に関してRFC4271を見てください、そして、AS番号の定義に関してRFC1930を見てください。
5.7.6. bgpNextAdjacentAsNumber
5.7.6. bgpNextAdjacentAsNumber
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ルーティング情報ベースの中でFlowの送付先IPアドレスを調べることによって、推論されます。 単に順不同のASがセットしたので(そして、どんな規則正しいAS系列としても、そうしません)このFlowのためのAS経路情報が利用可能であるなら、この情報Elementの値は0です。
Quittek, et al. Standards Track [Page 57] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[57ページ]。
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 Data Type Semantics: 識別子ElementId: 128状態: 現在のReference: BGP-4の記述に関してRFC4271を見てください、そして、AS番号の定義に関してRFC1930を見てください。
5.7.7. bgpPrevAdjacentAsNumber
5.7.7. bgpPrevAdjacentAsNumber
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ルーティング情報ベースの中でFlowのソースIPアドレスを調べることによって、推論されます。 単に順不同のASがセットしたので(そして、どんな規則正しいAS系列としても、そうしません)このFlowのためのAS経路情報が利用可能であるなら、この情報Elementの値は0です。 BGP非対称の場合には、bgpPrevAdjacentAsNumberは正しい値を報告できないかもしれません。 抽象データ型: unsigned32 Data Type Semantics: 識別子ElementId: 129状態: 現在のReference: BGP-4の記述に関してRFC4271を見てください、そして、AS番号の定義に関してRFC1930を見てください。
5.7.8. bgpNextHopIPv4Address
5.7.8. bgpNextHopIPv4Address
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状態: 現在のReference: BGP-4の記述に関してRFC4271を見てください。
5.7.9. bgpNextHopIPv6Address
5.7.9. bgpNextHopIPv6Address
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状態: 現在のReference: BGP-4の記述に関してRFC4271を見てください。
Quittek, et al. Standards Track [Page 58] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[58ページ]。
5.7.10. mplsTopLabelType
5.7.10. mplsTopLabelType
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
- 0×01Te-MIDPT: どんなTEのトンネルの中間のポイントやテールラベルも--0×02Pseudowire: どんなPWE3やシスコのAToMのベースのラベルも--0×03VPN: VPNに関連しているどんなラベルも--0×04BGP: BGPかBGPルーティングに関連しているどんなラベルも--0×05 自由民主党、: 自由民主党を使用するダイナミックに割り当てられたラベルに関連しているどんなラベル
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 Data Type Semantics: 識別子ElementId: 46状態: 現在のReference: MPLSラベル構造にRFC3031を見てください。 Virtual兵士のNetworks(VPNs)があるMPLSラベルの協会のためにRFC4364を見てください。 BGPとBGPルーティングに関してRFC4271を見てください。 ラベル分配プロトコル(自由民主党)に関してRFC5036を見てください。 MPLSラベル形式のリストがIANAによって http://www.iana.org/assignments/mpls-label-values に割り当てられるのを見てください。
5.7.11. mplsTopLabelIPv4Address
5.7.11. mplsTopLabelIPv4Address
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のトップラベルでこのFlowを進めるシステムのIPv4アドレス。 抽象データ型: ipv4Addressデータ型意味論: 識別子ElementId: 47状態: 現在のReference: MPLSラベルとIPアドレスとの協会のためにRFC3031を見てください。
Quittek, et al. Standards Track [Page 59] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[59ページ]。
5.7.12. mplsTopLabelIPv6Address
5.7.12. mplsTopLabelIPv6Address
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のトップラベルでこのFlowを進めるシステムのIPv6アドレス。 抽象データ型: ipv6Addressデータ型意味論: 識別子ElementId: 140状態: 現在のReference: MPLSラベルとIPアドレスとの協会のためにRFC3031を見てください。
5.7.13. mplsVpnRouteDistinguisher
5.7.13. mplsVpnRouteDistinguisher
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ルートdistinguisherの値。 ルートdistinguisherは数個の異なったMPLS VPNsで同じアドレスを使用できて、BGPが数個の完全に異なったルートをそのアドレスまで運ぶのが、可能であることを確実にします、各VPNあたり1つ。 RFC4364によると、mplsVpnRouteDistinguisherのサイズは8つの八重奏です。 しかしながら、RFC4382年に、フレキシブルな長さがある八重奏ストリングはオブジェクトMplsL3VpnRouteDistinguisherによってVPNルートdistinguisherを表すのに選ばれました。 サイズの将来の変化に開かれるようにこの選択をしました。 この情報Elementのための抽象データ型としてoctetArrayを選ぶとき、この考えは採用されました。 この情報Elementの最大の長さは256の八重奏です。 抽象データ型: octetArrayデータ型意味論: 識別子ElementId: 90状態: 現在のReference: ルートdistinguisherの仕様に関してRFC4364を見てください。 MPLS/BGP Layer3Virtual兵士のNetwork(VPN)管理Information基地の仕様に関してRFC4382を見てください。
Quittek, et al. Standards Track [Page 60] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[60ページ]。
5.8. Min/Max Flow Properties
5.8. 分/マックス流れの特性
Information Elements in this section are results of minimum or maximum operations over all packets of a Flow.
このセクションのInformation ElementsはFlowのすべてのパケットの上の最小の、または、最大の操作の結果です。
+-----+---------------------------+-----+---------------------------+ | ID | Name | ID | Name | +-----+---------------------------+-----+---------------------------+ | 25 | minimumIpTotalLength | 208 | ipv4Options | | 26 | maximumIpTotalLength | 64 | ipv6ExtensionHeaders | | 52 | minimumTTL | 6 | tcpControlBits | | 53 | maximumTTL | 209 | tcpOptions | +-----+---------------------------+-----+---------------------------+
+-----+---------------------------+-----+---------------------------+ | ID| 名前| ID| 名前| +-----+---------------------------+-----+---------------------------+ | 25 | minimumIpTotalLength| 208 | ipv4Options| | 26 | maximumIpTotalLength| 64 | ipv6ExtensionHeaders| | 52 | minimumTTL| 6 | tcpControlBits| | 53 | maximumTTL| 209 | tcpOptions| +-----+---------------------------+-----+---------------------------+
5.8.1. minimumIpTotalLength
5.8.1. minimumIpTotalLength
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.
記述: 最も小さいパケットの長さはこのFlowに関して見ました。 パケット長はIPヘッダーの長さとIPペイロード長を含んでいます。 抽象データ型: unsigned64 ElementId: 25状態: 現在のUnits: 八重奏Reference: IPv4の仕様に関してRFC791を見てください。全長。 IPv6ペイロード長の仕様に関してRFC2460を見てください。 IPv6のジャンボなペイロード長の仕様に関してRFC2675を見てください。
5.8.2. maximumIpTotalLength
5.8.2. maximumIpTotalLength
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.
記述: 最も大きいパケットの長さはこのFlowに関して見ました。 パケット長はIPヘッダーの長さとIPペイロード長を含んでいます。 抽象データ型: unsigned64 ElementId: 26状態: 現在のUnits: 八重奏Reference: IPv4の仕様に関してRFC791を見てください。全長。 IPv6ペイロード長の仕様に関してRFC2460を見てください。 IPv6のジャンボなペイロード長の仕様に関してRFC2675を見てください。
5.8.3. minimumTTL
5.8.3. minimumTTL
Description:
Minimum TTL value observed for any packet in this Flow.
記述: 最小のTTL値はこのFlowのどんなパケットのためにも見ました。
Quittek, et al. Standards Track [Page 61] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[61ページ]。
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状態: 現在のUnits: ホップReference: Live分野へのIPv4 Timeの定義に関してRFC791を見てください。 IPv6 Hop Limit分野の定義に関してRFC2460を見てください。
5.8.4. maximumTTL
5.8.4. maximumTTL
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値はこのFlowのどんなパケットのためにも見ました。 抽象データ型: unsigned8 ElementId: 53状態: 現在のUnits: ホップReference: Live分野へのIPv4 Timeの定義に関してRFC791を見てください。 IPv6 Hop Limit分野の定義に関してRFC2460を見てください。
5.8.5. ipv4Options
5.8.5. ipv4Options
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.
記述: このFlowのパケットのIPv4オプション。 情報は噛み付いている分野のセットでコード化されます。 それぞれの有効なIPv4オプションタイプのために、セットがこれに少しあります。 このFlowのどれか観測されたパケットが対応するIPv4オプションタイプを含んでいるなら、ビットは1に設定されます。 さもなければ、このFlowのどんな観測されたパケットもそれぞれのIPv4オプションタイプを含まなかったなら、対応するビットの価値は0です。 有効なIPv4オプションのリストはIANAによって維持されます。 オプションを特定すると、ちょうどIPv4オプションのしかし、Option Number、Option Typeのすべての8ビットが合わせる必要がある5ビット1つが http://www.iana.org/assignments/ip-parameters で指定したというわけではないことに注意してください。 それらのオプション番号によると、オプションはビットに写像されます。 オプション番号XはビットX.に写像されます。マッピングは以下の図によって例証されます。
0 1 2 3 4 5 6 7
+------+------+------+------+------+------+------+------+
| EOOL | NOP | SEC | LSR | TS |E-SEC |CIPSO | RR | ...
+------+------+------+------+------+------+------+------+
0 1 2 3 4 5 6 7 +------+------+------+------+------+------+------+------+ | EOOL| NOP| SEC| LSR| t|電子SEC|CIPSO| RR| ... +------+------+------+------+------+------+------+------+
8 9 10 11 12 13 14 15
+------+------+------+------+------+------+------+------+
... | SID | SSR | ZSU | MTUP | MTUR | FINN | VISA |ENCODE| ...
+------+------+------+------+------+------+------+------+
8 9 10 11 12 13 14 15 +------+------+------+------+------+------+------+------+ ... | シド| SSR| ZSU| MTUP| MTUR| フィンランド人| ビザ|エンコード| ... +------+------+------+------+------+------+------+------+
16 17 18 19 20 21 22 23
16 17 18 19 20 21 22 23
Quittek, et al. Standards Track [Page 62] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[62ページ]。
+------+------+------+------+------+------+------+------+
... |IMITD | EIP | TR |ADDEXT|RTRALT| SDB |NSAPA | DPS | ...
+------+------+------+------+------+------+------+------+
+------+------+------+------+------+------+------+------+ ... |IMITD| EIP| TR|ADDEXT|RTRALT| SDB|NSAPA| 毎秒壊変数| ... +------+------+------+------+------+------+------+------+
24 25 26 27 28 29 30 31
+------+------+------+------+------+------+------+------+
... | UMP | QS | to be assigned by IANA | EXP | |
+------+------+------+------+------+------+------+------+
24 25 26 27 28 29 30 31 +------+------+------+------+------+------+------+------+ ... | UMP| QS| 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
オプションビット値の名前参照をタイプしてください。---+-----+-------+------------------------------------ オプションリストの0 0EOOLエンド、RFC791 1 1NOPいいえ操作、RFC791 2の130秒のセキュリティ、RFC1108 3の131のLSRのゆるい送信元経路、RFC791 4の68tのタイムスタンプ、133RFC791 5電子秒拡張しているセキュリティ、セキュリティ7 7のRRの記録的なルート、RFC1108 6 134CIPSOコマーシャルRFC791 8 136SID Stream ID、RFC791 9の137のSSRの厳しい送信元経路、RFC791 10 10のZSUの実験的な測定11 11MTUP(時代遅れにされる)MTUは調べます、RFC1191 12 12MTUR(時代遅れにされる)MTU回答; RFC1191 13 205フィンランド人実験フロー制御14 142のビザの実験的なアクセス制御15 15エンコード16 144IMITD IMIトラフィック記述子17 145EIPはインターネットプロトコルを広げました、RFC、1385 18、82兆トレースルート、RFC3193 19 147ADDEXTが、拡大20が148RTRALTルータ警戒(RFC2113 21 149SDB選択している指示された放送22 150NSAPA NSAPアドレス23 151の毎秒壊変数のダイナミックなパケット州24の152のUMPの上流のマルチキャストPkt)であると扱います。 25 25QSクィックスタート30 30EXP RFC3692-スタイル実験30 94EXP RFC3692-スタイル実験30 158EXP RFC3692-スタイル実験30 222EXP RFC3692-スタイル実験… ... ... さらなるオプション番号はIANAによって割り当てられるかもしれません。
Abstract Data Type: unsigned32 Data Type Semantics: flags ElementId: 208
抽象データ型: unsigned32 Data Type Semantics: 旗のElementId: 208
Quittek, et al. Standards Track [Page 63] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[63ページ]。
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.
状態: 現在のReference: IPv4オプションの定義に関してRFC791を見てください。 IPv4オプション番号のリストがIANAによって http://www.iana.org/assignments/ip-parameters に割り当てられるのを見てください。
5.8.6. ipv6ExtensionHeaders
5.8.6. ipv6ExtensionHeaders
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拡張ヘッダーはこのFlowのパケットで見ました。 情報は噛み付いている分野のセットでコード化されます。 それぞれのIPv6オプションヘッダーのために、セットがこれに少しあります。 このFlowのどれか観測されたパケットが対応するIPv6拡張ヘッダーを含むなら、ビットは1に設定されます。 さもなければ、このFlowのどんな観測されたパケットもそれぞれのIPv6拡張ヘッダーを含まなかったなら、対応するビットの価値は0です。
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| Res | FRA1| RH | FRA0| UNK | Res | HOP | DST | ...
+-----+-----+-----+-----+-----+-----+-----+-----+
0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | Res| FRA1| 右手| FRA0| UNK| Res| ホップ| DST| ... +-----+-----+-----+-----+-----+-----+-----+-----+
8 9 10 11 12 13 14 15
+-----+-----+-----+-----+-----+-----+-----+-----+
... | PAY | AH | ESP | Reserved | ...
+-----+-----+-----+-----+-----+-----+-----+-----+
8 9 10 11 12 13 14 15 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | 賃金| ああ| 超能力| 予約されます。| ... +-----+-----+-----+-----+-----+-----+-----+-----+
16 17 18 19 20 21 22 23
+-----+-----+-----+-----+-----+-----+-----+-----+
... | Reserved | ...
+-----+-----+-----+-----+-----+-----+-----+-----+
16 17 18 19 20 21 22 23 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | 予約されます。| ... +-----+-----+-----+-----+-----+-----+-----+-----+
24 25 26 27 28 29 30 31
+-----+-----+-----+-----+-----+-----+-----+-----+
... | Reserved |
+-----+-----+-----+-----+-----+-----+-----+-----+
24 25 26 27 28 29 30 31 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | 予約されます。| +-----+-----+-----+-----+-----+-----+-----+-----+
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
0、Res Reserved1、FRA1 44Fragmentationヘッダー--2は最初に断片化しません、RH43ルート設定ヘッダー3、FRA0 44Fragmentヘッダー--4、UNK Unknown Layer4ヘッダー(圧縮されて、暗号化されたサポートされるのではなく、)5は最初に断片化します、Res Reserved6、HOP0ホップによるHopオプションヘッダー7、DST60Destinationオプションヘッダー
Quittek, et al. Standards Track [Page 64] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[64ページ]。
8, PAY 108 Payload compression header
9, AH 51 Authentication Header
10, ESP 50 Encrypted security payload
11 to 31 Reserved
8 PAY108有効搭載量圧縮ヘッダー9、AH51Authentication Header10、超能力50Encryptedセキュリティペイロード11〜31Reserved
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 Data Type Semantics: 旗のElementId: 64状態: 現在のReference: IPv6拡張ヘッダーの一般的な定義とホップごとのオプションヘッダー、ルーティングヘッダー、断片ヘッダー、および目的地オプションヘッダーの仕様に関してRFC2460を見てください。 認証ヘッダーの仕様に関してRFC4302を見てください。 要約のセキュリティペイロードの仕様に関してRFC4303を見てください。
5.8.7. tcpControlBits
5.8.7. tcpControlBits
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コントロールビットはこのFlowのパケットのために見ました。 情報は噛み付いている分野のセットでコード化されます。 それぞれのTCPコントロールビットのために、セットがこれに少しあります。 このFlowのどんな観測されたパケットでも対応するTCPコントロールビットを1に設定するなら、1に少し設定されます。 しばらく0の値は、対応するビットがこのFlowの観測されたパケットのいずれにも設定されなかったのを示します。
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| Reserved | URG | ACK | PSH | RST | SYN | FIN |
+-----+-----+-----+-----+-----+-----+-----+-----+
0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | 予約されます。| URG| ACK| PSH| RST| SYN| フィン| +-----+-----+-----+-----+-----+-----+-----+-----+
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: 緊急のPointerは重要な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 Data Type Semantics: 旗のElementId: 6状態: 現在のReference: TCPヘッダーとのTCPコントロールビットの定義に関してRFC793を見てください。
Quittek, et al. Standards Track [Page 65] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[65ページ]。
5.8.8. tcpOptions
5.8.8. tcpOptions
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.
記述: このFlowのパケットのTCPオプション。 情報は噛み付いている分野のセットでコード化されます。 それぞれのTCPオプションのために、セットがこれに少しあります。 このFlowのどれか観測されたパケットが対応するTCPオプションを含んでいるなら、ビットは1に設定されます。 さもなければ、このFlowのどんな観測されたパケットもそれぞれのTCPオプションを含まなかったなら、対応するビットの価値は0です。 それらのオプション番号によると、オプションはビットに写像されます。 オプション番号Xはビットに写像されて、X. TCPオプション番号がIANAによって維持されるということです。
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+
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 |...
+-----+-----+-----+-----+-----+-----+-----+-----+
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 |...
+-----+-----+-----+-----+-----+-----+-----+-----+
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 |
+-----+-----+-----+-----+-----+-----+-----+-----+
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 Data Type Semantics: 旗のElementId: 209状態: 現在のReference: TCPオプションの定義に関してRFC793を見てください。 TCPオプション番号のリストがIANAによって http://www.iana.org/assignments/tcp-parameters に割り当てられるのを見てください。
Quittek, et al. Standards Track [Page 66] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[66ページ]。
5.9. Flow Timestamps
5.9. 流れタイムスタンプ
Information Elements in this section are timestamps of events.
このセクションのInformation Elementsはイベントに関するタイムスタンプです。
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.
タイムスタンプflowStartSeconds、flowEndSeconds、flowStartMilliseconds、flowEndMilliseconds、flowStartMicroseconds、flowEndMicroseconds、flowStartNanoseconds、flowEndNanoseconds、およびsystemInitTimeMillisecondsは絶対であり、明確な一定時間ベースを持っています、例えば、協定世界時0000の1970年1月1日以来の秒数などのように。
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 Messageの範囲の中で有効なだけの相対的なタイムスタンプです。 それらはIPFIX Message Headerで指定された輸出時間に比例して否定的時間オフセットを含んでいます。 これらのデルタカウンタでコード化できる最大の時間オフセットは、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.
タイムスタンプのflowStartSysUpTimeとflowEndSysUpTimeが最終に比例して時間を示す相対的なタイムスタンプである、(再、)、IPFIX Deviceの初期化。 最終時間を報告する、(再、)、初期化、例えば、Option Templatesによって定義されたData Recordsで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 | +-----+---------------------------+-----+---------------------------+
+-----+---------------------------+-----+---------------------------+ | ID| 名前| ID| 名前| +-----+---------------------------+-----+---------------------------+ | 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| +-----+---------------------------+-----+---------------------------+
5.9.1. flowStartSeconds
5.9.1. flowStartSeconds
Description:
The absolute timestamp of the first packet of this Flow.
Abstract Data Type: dateTimeSeconds
ElementId: 150
Status: current
Units: seconds
記述: このFlowの最初のパケットの絶対タイムスタンプ。 抽象データ型: dateTimeSeconds ElementId: 150状態: 現在のUnits: 秒
Quittek, et al. Standards Track [Page 67] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[67ページ]。
5.9.2. flowEndSeconds
5.9.2. flowEndSeconds
Description:
The absolute timestamp of the last packet of this Flow.
Abstract Data Type: dateTimeSeconds
ElementId: 151
Status: current
Units: seconds
記述: このFlowの最後のパケットの絶対タイムスタンプ。 抽象データ型: dateTimeSeconds ElementId: 151状態: 現在のUnits: 秒
5.9.3. flowStartMilliseconds
5.9.3. flowStartMilliseconds
Description:
The absolute timestamp of the first packet of this Flow.
Abstract Data Type: dateTimeMilliseconds
ElementId: 152
Status: current
Units: milliseconds
記述: このFlowの最初のパケットの絶対タイムスタンプ。 抽象データ型: dateTimeMilliseconds ElementId: 152状態: 現在のUnits: ミリセカンド
5.9.4. flowEndMilliseconds
5.9.4. flowEndMilliseconds
Description:
The absolute timestamp of the last packet of this Flow.
Abstract Data Type: dateTimeMilliseconds
ElementId: 153
Status: current
Units: milliseconds
記述: このFlowの最後のパケットの絶対タイムスタンプ。 抽象データ型: dateTimeMilliseconds ElementId: 153状態: 現在のUnits: ミリセカンド
5.9.5. flowStartMicroseconds
5.9.5. flowStartMicroseconds
Description:
The absolute timestamp of the first packet of this Flow.
Abstract Data Type: dateTimeMicroseconds
ElementId: 154
Status: current
Units: microseconds
記述: このFlowの最初のパケットの絶対タイムスタンプ。 抽象データ型: dateTimeMicroseconds ElementId: 154状態: 現在のUnits: マイクロセカンド
5.9.6. flowEndMicroseconds
5.9.6. flowEndMicroseconds
Description:
The absolute timestamp of the last packet of this Flow.
Abstract Data Type: dateTimeMicroseconds
ElementId: 155
Status: current
Units: microseconds
記述: このFlowの最後のパケットの絶対タイムスタンプ。 抽象データ型: dateTimeMicroseconds ElementId: 155状態: 現在のUnits: マイクロセカンド
Quittek, et al. Standards Track [Page 68] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[68ページ]。
5.9.7. flowStartNanoseconds
5.9.7. flowStartNanoseconds
Description:
The absolute timestamp of the first packet of this Flow.
Abstract Data Type: dateTimeNanoseconds
ElementId: 156
Status: current
Units: nanoseconds
記述: このFlowの最初のパケットの絶対タイムスタンプ。 抽象データ型: dateTimeNanoseconds ElementId: 156状態: 現在のUnits: ナノ秒
5.9.8. flowEndNanoseconds
5.9.8. flowEndNanoseconds
Description:
The absolute timestamp of the last packet of this Flow.
Abstract Data Type: dateTimeNanoseconds
ElementId: 157
Status: current
Units: nanoseconds
記述: このFlowの最後のパケットの絶対タイムスタンプ。 抽象データ型: dateTimeNanoseconds ElementId: 157状態: 現在のUnits: ナノ秒
5.9.9. flowStartDeltaMicroseconds
5.9.9. flowStartDeltaMicroseconds
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 Messageの範囲の中で有効なだけの相対的なタイムスタンプです。 それはIPFIX Message Headerで指定された輸出時間に比例してこのFlowの最初の観測されたパケットの否定的時間オフセットを含んでいます。 抽象データ型: unsigned32 ElementId: 158状態: 現在のUnits: マイクロセカンドReference: IPFIX Message Headerの定義のためのIPFIXプロトコル仕様[RFC5101]を見てください。
5.9.10. flowEndDeltaMicroseconds
5.9.10. flowEndDeltaMicroseconds
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 Messageの範囲の中で有効なだけの相対的なタイムスタンプです。 それはIPFIX Message Headerで指定された輸出時間に比例してこのFlowの最後に観測されたパケットの否定的時間オフセットを含んでいます。 抽象データ型: unsigned32 ElementId: 159状態: 現在のUnits: マイクロセカンドReference: IPFIX Message Headerの定義のためのIPFIXプロトコル仕様[RFC5101]を見てください。
Quittek, et al. Standards Track [Page 69] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[69ページ]。
5.9.11. systemInitTimeMilliseconds
5.9.11. systemInitTimeMilliseconds
Description:
The absolute timestamp of the last (re-)initialization of the
IPFIX Device.
Abstract Data Type: dateTimeMilliseconds
ElementId: 160
Status: current
Units: milliseconds
記述: 最終絶対タイムスタンプ、(再、)、IPFIX Deviceの初期化。 抽象データ型: dateTimeMilliseconds ElementId: 160状態: 現在のUnits: ミリセカンド
5.9.12. flowStartSysUpTime
5.9.12. flowStartSysUpTime
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
記述: このFlowの最初のパケットの相対的なタイムスタンプ。 最終以来のミリセカンドの数を示す、(再、)、IPFIX Device(sysUpTime)の初期化。 抽象データ型: unsigned32 ElementId: 22状態: 現在のUnits: ミリセカンド
5.9.13. flowEndSysUpTime
5.9.13. flowEndSysUpTime
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
記述: このFlowの最後のパケットの相対的なタイムスタンプ。 最終以来のミリセカンドの数を示す、(再、)、IPFIX Device(sysUpTime)の初期化。 抽象データ型: unsigned32 ElementId: 21状態: 現在のUnits: ミリセカンド
5.10. Per-Flow Counters
5.10. 1流れあたりのカウンタ
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.
このセクションのInformation Elementsはすべて、整数値があるカウンタです。 それらの値はそれらが使用されるあらゆるレポートのために変化するかもしれません。 それらはパケットをFlowsに写像するのに使用されるFlow Keyの一部として機能できません。 しかしながら、潜在的に、例えば、Flowsであるとエクスポートされた選択に観測された八重奏の敷居番号以上でFlowsをエクスポートするだけでそれらを使用できます。
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.
実行しているカウンタとデルタカウンタがあります。 デルタカウンタは、それらの値がエクスポートされる各回のゼロを合わせるためにリセットされます。 実行しているカウンタは、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
1流れあたりのカウンタとMetering Process、そして/または、Exporting Processに関連するカウンタがあります。 1流れあたりのカウンタはそれが潜在的にそれぞれの時間aパケット属を変えるFlow土地です。
Quittek, et al. Standards Track [Page 70] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[70ページ]。
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.
Flowは観測されます。 1流れあたりのカウンタのセットはElementsが以下のテーブルにリストアップした情報を含んでいます。 Metering Process、そして/または、Exporting Processに関連するカウンタはセクション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 | +-----+---------------------------+-----+---------------------------+
+-----+---------------------------+-----+---------------------------+ | ID| 名前| ID| 名前| +-----+---------------------------+-----+---------------------------+ | 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| +-----+---------------------------+-----+---------------------------+
5.10.1. octetDeltaCount
5.10.1. octetDeltaCount
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
記述: このFlowのためのObservation Pointの入って来るパケットの予報(もしあれば)以来の八重奏の数。 八重奏の数はIPヘッダーとIPペイロードを含んでいます。 抽象データ型: unsigned64 Data Type Semantics: deltaCounter ElementId: 1つの状態: 現在のUnits: 八重奏
5.10.2. postOctetDeltaCount
5.10.2. postOctetDeltaCount
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
記述: この情報Elementの定義は情報Element'octetDeltaCount'の定義と同じです、パケットがObservation Pointを渡した後にmiddlebox機能によって引き起こされた潜在的に変更された値を報告するのを除いて。 抽象データ型: unsigned64 Data Type Semantics: deltaCounter ElementId: 23状態: 現在のUnits: 八重奏
Quittek, et al. Standards Track [Page 71] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[71ページ]。
5.10.3. octetDeltaSumOfSquares
5.10.3. octetDeltaSumOfSquares
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
記述: Observation PointのこのFlowのための予報(もしあれば)以来の入って来るパケットあたりの八重奏の二乗された数。 八重奏の数はIPヘッダーとIPペイロードを含んでいます。 抽象データ型: unsigned64 ElementId: 198状態: 電流
5.10.4. octetTotalCount
5.10.4. octetTotalCount
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
記述: Metering Process以来のObservation PointのこのFlowのための入って来るパケットの八重奏の総数、(再、)、このObservation Pointのための初期化。 八重奏の数はIPヘッダーとIPペイロードを含んでいます。 抽象データ型: unsigned64 Data Type Semantics: totalCounter ElementId: 85状態: 現在のUnits: 八重奏
5.10.5. postOctetTotalCount
5.10.5. postOctetTotalCount
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
記述: この情報Elementの定義は情報Element'octetTotalCount'の定義と同じです、パケットがObservation Pointを渡した後にmiddlebox機能によって引き起こされた潜在的に変更された値を報告するのを除いて。 抽象データ型: unsigned64 Data Type Semantics: totalCounter ElementId: 171状態: 現在のUnits: 八重奏
5.10.6. octetTotalSumOfSquares
5.10.6. octetTotalSumOfSquares
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
記述: Metering Process以来のObservation PointのこのFlowのための入って来るパケットの八重奏の二乗された数の総合計、(再、)、このObservation Pointのための初期化。 八重奏の数はIPヘッダーとIPペイロードを含んでいます。 抽象データ型: unsigned64 ElementId: 199状態: 現在のUnits: 八重奏
Quittek, et al. Standards Track [Page 72] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[72ページ]。
5.10.7. packetDeltaCount
5.10.7. packetDeltaCount
Description:
The number of incoming packets since the previous report (if any)
for this Flow at the Observation Point.
記述: Observation PointのこのFlowのための予報(もしあれば)以来の入って来るパケットの数。
Abstract Data Type: unsigned64 Data Type Semantics: deltaCounter ElementId: 2 Status: current Units: packets
抽象データ型: unsigned64 Data Type Semantics: deltaCounter ElementId: 2状態: 現在のUnits: パケット
5.10.8. postPacketDeltaCount
5.10.8. postPacketDeltaCount
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
記述: この情報Elementの定義は情報Element'packetDeltaCount'の定義と同じです、パケットがObservation Pointを渡した後にmiddlebox機能によって引き起こされた潜在的に変更された値を報告するのを除いて。 抽象データ型: unsigned64 Data Type Semantics: deltaCounter ElementId: 24状態: 現在のUnits: パケット
5.10.9. packetTotalCount
5.10.9. packetTotalCount
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
記述: Metering Process以来のObservation PointのこのFlowのための入って来るパケットの総数、(再、)、このObservation Pointのための初期化。 抽象データ型: unsigned64 Data Type Semantics: totalCounter ElementId: 86状態: 現在のUnits: パケット
Quittek, et al. Standards Track [Page 73] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[73ページ]。
5.10.10. postPacketTotalCount
5.10.10. postPacketTotalCount
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
記述: この情報Elementの定義は情報Element'packetTotalCount'の定義と同じです、パケットがObservation Pointを渡した後にmiddlebox機能によって引き起こされた潜在的に変更された値を報告するのを除いて。 抽象データ型: unsigned64 Data Type Semantics: totalCounter ElementId: 172状態: 現在のUnits: パケット
5.10.11. droppedOctetDeltaCount
5.10.11. droppedOctetDeltaCount
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
記述: このFlowのパケットの予報(もしあれば)以来の八重奏の数はパケット処理に立ち寄りました。 八重奏の数はIPヘッダーとIPペイロードを含んでいます。 抽象データ型: unsigned64 Data Type Semantics: deltaCounter ElementId: 132状態: 現在のUnits: 八重奏
5.10.12. droppedPacketDeltaCount
5.10.12. droppedPacketDeltaCount
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
記述: このFlowに関する予報(もしあれば)以来のパケットの数はパケット処理に立ち寄りました。 抽象データ型: unsigned64 Data Type Semantics: deltaCounter ElementId: 133状態: 現在のUnits: パケット
5.10.13. droppedOctetTotalCount
5.10.13. droppedOctetTotalCount
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
記述: Metering Process以来このFlowのパケットの八重奏の総数がパケット処理に立ち寄った、(再、)、このObservation Pointのための初期化。 八重奏の数はIPヘッダーとIPペイロードを含んでいます。 抽象データ型: unsigned64 Data Type Semantics: totalCounter ElementId: 134状態: 現在のUnits: 八重奏
Quittek, et al. Standards Track [Page 74] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[74ページ]。
5.10.14. droppedPacketTotalCount
5.10.14. droppedPacketTotalCount
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
記述: Metering Process以来このFlowのパケットの数がパケット処理に立ち寄った、(再、)、このObservation Pointのための初期化。 抽象データ型: unsigned64 Data Type Semantics: totalCounter ElementId: 135状態: 現在のUnits: パケット
5.10.15. postMCastPacketDeltaCount
5.10.15. postMCastPacketDeltaCount
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
記述: 予報(もしあれば)以来の出発しているマルチキャストパケットの数はObservation Domainの中のマルチキャストデーモンによるこのFlowのパケットのために発信しました。 この特性は、必ずObservation Pointで観測できるというわけではありませんが、他の手段で検索されるかもしれません。 抽象データ型: unsigned64 Data Type Semantics: deltaCounter ElementId: 19状態: 現在のUnits: パケット
5.10.16. postMCastOctetDeltaCount
5.10.16. postMCastOctetDeltaCount
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
記述: 出発しているマルチキャストパケットの予報(もしあれば)以来の八重奏の数はObservation Domainの中のマルチキャストデーモンによるこのFlowのパケットのために発信しました。 この特性は、必ずObservation Pointで観測できるというわけではありませんが、他の手段で検索されるかもしれません。 八重奏の数はIPヘッダーとIPペイロードを含んでいます。 抽象データ型: unsigned64 Data Type Semantics: deltaCounter ElementId: 20状態: 現在のUnits: 八重奏
Quittek, et al. Standards Track [Page 75] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[75ページ]。
5.10.17. postMCastPacketTotalCount
5.10.17. postMCastPacketTotalCount
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
記述: Metering Process以来出発しているマルチキャストパケットの総数がObservation Domainの中のマルチキャストデーモンによるこのFlowのパケットのために発信した、(再、)、初期化。 この特性は、必ずObservation Pointで観測できるというわけではありませんが、他の手段で検索されるかもしれません。 抽象データ型: unsigned64 Data Type Semantics: totalCounter ElementId: 174状態: 現在のUnits: パケット
5.10.18. postMCastOctetTotalCount
5.10.18. postMCastOctetTotalCount
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
記述: Metering Process以来出発しているマルチキャストパケットの八重奏の総数がObservation DomainのマルチキャストデーモンによるこのFlowのパケットのために発信した、(再、)、初期化。 この特性は、必ずObservation Pointで観測できるというわけではありませんが、他の手段で検索されるかもしれません。 八重奏の数はIPヘッダーとIPペイロードを含んでいます。 抽象データ型: unsigned64 Data Type Semantics: totalCounter ElementId: 175状態: 現在のUnits: 八重奏
5.10.19. tcpSynTotalCount
5.10.19. tcpSynTotalCount
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.
記述: 「一連番号を同期させてください」(SYN)が旗を揚げさせるTCPとこのFlowのパケットの総数はセットしました。 抽象データ型: unsigned64 Data Type Semantics: totalCounter ElementId: 218状態: 現在のUnits: パケットReference: TCP SYN旗の定義に関してRFC793を見てください。
Quittek, et al. Standards Track [Page 76] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[76ページ]。
5.10.20. tcpFinTotalCount
5.10.20. tcpFinTotalCount
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.
記述: 「送付者からのそれ以上のデータがない」(FIN)が旗を揚げさせるTCPとこのFlowのパケットの総数はセットしました。 抽象データ型: unsigned64 Data Type Semantics: totalCounter ElementId: 219状態: 現在のUnits: パケットReference: TCP FIN旗の定義に関してRFC793を見てください。
5.10.21. tcpRstTotalCount
5.10.21. tcpRstTotalCount
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とこのFlowのパケットが「接続をリセットした」という(RST)旗はセットしました。 抽象データ型: unsigned64 Data Type Semantics: totalCounter ElementId: 220状態: 現在のUnits: パケットReference: TCP RST旗の定義に関してRFC793を見てください。
5.10.22. tcpPshTotalCount
5.10.22. tcpPshTotalCount
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.
記述: 「プッシュ機能」(PSH)が旗を揚げさせるTCPとこのFlowのパケットの総数はセットしました。 抽象データ型: unsigned64 Data Type Semantics: totalCounter ElementId: 221状態: 現在のUnits: パケットReference: TCP PSH旗の定義に関してRFC793を見てください。
Quittek, et al. Standards Track [Page 77] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[77ページ]。
5.10.23. tcpAckTotalCount
5.10.23. tcpAckTotalCount
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.
記述: (ACK)が旗を揚げさせるTCPが「承認分野重要」のこのFlowのパケットの総数はセットしました。 抽象データ型: unsigned64 Data Type Semantics: totalCounter ElementId: 222状態: 現在のUnits: パケットReference: TCP ACK旗の定義に関してRFC793を見てください。
5.10.24. tcpUrgTotalCount
5.10.24. tcpUrgTotalCount
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.
記述: (URG)が旗を揚げさせるTCPが「緊急のPointer分野重要」のこのFlowのパケットの総数はセットしました。 抽象データ型: unsigned64 Data Type Semantics: totalCounter ElementId: 223状態: 現在のUnits: パケットReference: TCP URG旗の定義に関してRFC793を見てください。
5.11. Miscellaneous Flow Properties
5.11. 種々雑多な流れの特性
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.
このセクションのInformation ElementsはFlow始め、Flow持続時間、およびFlow終了に関連するFlowsの特性について説明しますが、彼らはセクション5.9のInformation Elementsのようにタイムスタンプではありません。
+-----+---------------------------+-----+---------------------------+ | ID | Name | ID | Name | +-----+---------------------------+-----+---------------------------+ | 36 | flowActiveTimeout | 161 | flowDurationMilliseconds | | 37 | flowIdleTimeout | 162 | flowDurationMicroseconds | | 136 | flowEndReason | 61 | flowDirection | +-----+---------------------------+-----+---------------------------+
+-----+---------------------------+-----+---------------------------+ | ID| 名前| ID| 名前| +-----+---------------------------+-----+---------------------------+ | 36 | flowActiveTimeout| 161 | flowDurationMilliseconds| | 37 | flowIdleTimeout| 162 | flowDurationMicroseconds| | 136 | flowEndReason| 61 | flowDirection| +-----+---------------------------+-----+---------------------------+
Quittek, et al. Standards Track [Page 78] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[78ページ]。
5.11.1. flowActiveTimeout
5.11.1. flowActiveTimeout
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
記述: それでも、そこであってもアクティブなFlowが外でとにかく調節されている秒の数はパケットの連続した流れです。 抽象データ型: unsigned16 ElementId: 36状態: 現在のUnits: 秒
5.11.2. flowIdleTimeout
5.11.2. flowIdleTimeout
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
記述: Flowに属すパケットが全くこの分野によって指定された秒数に関して観察されていないなら、Flowが調節されると考えられます。 抽象データ型: unsigned16 ElementId: 37状態: 現在のUnits: 秒
5.11.3. flowEndReason
5.11.3. flowEndReason
Description:
The reason for Flow termination. The range of values includes the
following:
記述: Flow終了の理由。 値の範囲は以下を含んでいます:
0x01: idle timeout
The Flow was terminated because it was considered to be
idle.
0×01: タイムアウトを空費してください。それが活動していないと考えられたので、Flowは終えられました。
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.
0×02: Flowがそれが例えばunreported Flowsの最大の生涯の後にまだアクティブであった間、目的を報告しながら終えられたアクティブなタイムアウトに達しました。
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.
0×03: Metering Processが、信号がFlowの端を示すのを検出したので検出されたFlowではFlowが終えられた終わり、例えば、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.
0×04: Flowが例えばMetering Processの閉鎖がネットワークマネージメントアプリケーションで開始した何らかの外部のイベントで終えられた無理矢理の終わり。
Quittek, et al. Standards Track [Page 79] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[79ページ]。
0x05: lack of resources
The Flow was terminated because of lack of resources
available to the Metering Process and/or the Exporting
Process.
0×05: 財源不足はFlowが終えられたMetering Process、そして/または、Exporting Processに利用可能なリソースに欠けています。
Abstract Data Type: unsigned8 Data Type Semantics: identifier ElementId: 136 Status: current
抽象データ型: unsigned8 Data Type Semantics: 識別子ElementId: 136状態: 電流
5.11.4. flowDurationMilliseconds
5.11.4. flowDurationMilliseconds
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
記述: このFlowの最初の観測されたパケットとこのFlowの最後に観測されたパケットの間で時間内にの違い。 抽象データ型: unsigned32 ElementId: 161状態: 現在のUnits: ミリセカンド
5.11.5. flowDurationMicroseconds
5.11.5. flowDurationMicroseconds
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
記述: このFlowの最初の観測されたパケットとこのFlowの最後に観測されたパケットの間で時間内にの違い。 抽象データ型: unsigned32 ElementId: 162状態: 現在のUnits: マイクロセカンド
5.11.6. flowDirection
5.11.6. flowDirection
Description:
The direction of the Flow observed at the Observation Point.
There are only two values defined.
記述: Flowの方向はObservation Pointで見ました。 定義された2つの値しかありません。
0x00: ingress flow
0x01: egress flow
0×00: イングレス流動0x01: 出口流動
Abstract Data Type: unsigned8 Data Type Semantics: identifier ElementId: 61 Status: current
抽象データ型: unsigned8 Data Type Semantics: 識別子ElementId: 61状態: 電流
5.12. Padding
5.12. 詰め物
This section contains a single Information Element that can be used for padding of Flow Records.
このセクションはFlow Recordsの詰め物に使用できる独身の情報Elementを含みます。
Quittek, et al. Standards Track [Page 80] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[80ページ]。
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実装は、Data Recordsの中でInformation Elementsを並べたいか、または4八重奏の、または、8八重奏の境界に全体のData Recordsを並べたがっているかもしれません。 Data Recordの1人以上のpaddingOctets Information Elementsを含んでいることによって、これを達成できます。
+-----+---------------------------+-----+---------------------------+ | ID | Name | ID | Name | +-----+---------------------------+-----+---------------------------+ | 210 | paddingOctets | | | +-----+---------------------------+-----+---------------------------+
+-----+---------------------------+-----+---------------------------+ | ID| 名前| ID| 名前| +-----+---------------------------+-----+---------------------------+ | 210 | paddingOctets| | | +-----+---------------------------+-----+---------------------------+
5.12.1. paddingOctets
5.12.1. paddingOctets
Description:
The value of this Information Element is always a sequence of 0x00
values.
Abstract Data Type: octetArray
ElementId: 210
Status: current
記述: いつもこの情報Elementの値は0×00の値の系列です。 抽象データ型: octetArray ElementId: 210状態: 電流
6. Extending the Information Model
6. 情報モデルを広げています。
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に、主要な要件は報告されるInformation Elementsのセットを広げると考慮することです。 このセクションは、このセットを広げるためにメカニズムを定義します。
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.
新しいInformation Elementsを定義することによって、拡大できます。 定義の一部としてユニークな情報Element識別子をそれぞれの新しい情報Elementに割り当てなければなりません。 これらのユニークな情報Element識別子はプロトコルによってTemplatesを使用することで伝えられた記録的な構造と消費アプリケーションとの関係です。 一般に適切なInformation Elements、IETFを使用して、およびIANAメカニズムが情報モデルを広げるのは、RECOMMENDEDです。
Names of new Information Elements SHOULD be chosen according to the naming conventions given in Section 2.3.
名前、新しい情報Elements SHOULDでは、命名規則当然のことに従って、セクション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 Standards Trackドキュメントで新しい抽象データ型を定義しなければなりません。
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にそれらを登録しないで、エンタープライズはInformation Elementsを定義したがっているかもしれません。 IPFIXは明らかに企業特有のInformation Elementsをサポートします。 エンタープライズ特有のInformation Elementsはセクション2.1と4で説明されます。
Quittek, et al. Standards Track [Page 81] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[81ページ]。
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.
しかしながら、企業特有のInformation Elementsを創造する前に、そのようなInformation Elementsの一般的な適用性は考えられるべきです。 IPFIXは企業特有の抽象データ型をサポートしません。
7. IANA Considerations
7. IANA問題
7.1. IPFIX Information Elements
7.1. IPFIX Information Elements
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 Information Elementsの1人の始発を指定します。 セクション4でそれらの識別子をもっているこれらのInformation Elementsのリストを与えます。 インターネットAssigned民数記Authority(IANA)はIPFIX情報Element識別子のために新しい登録を作成して、セクション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 Information Elementsのための新しい課題はExpert Review[RFC2434](すなわち、IETF Areaディレクターによって任命された専門家のグループの1つによるレビュー)を通してIANAによって管理されるでしょう。 セクション2.3の命名規則によると、専門家のグループは記述の完全性と精度と正しい命名がないかどうか要求された情報Elementをチェックしなければなりません。 既存の情報Elements SHOULDの機能性をコピーするInformation Elementsのために、傾けられるよう要求します。 最も小さい利用可能な識別子SHOULD、新しい情報Elementに割り当てられてください。
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 Information Elementsの仕様をセクション2.1で指定されたテンプレートを使用しなければならなくて、安定していて永続的な公表媒体を使用して、発表しなければなりません。 初めは、IPFIXとPSAMP Working Groupsの作業部会Chairsとドキュメントエディタから専門家を得るでしょう。
7.2. MPLS Label Type Identifier
7.2. MPLSラベル形式識別子
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という情報Element#46はMPLSラベル形式を運びます。 5つの異なったタイプのための値は初めは、定義されました。 この情報の伸展性を確実にするために、IANAはMPLSラベル形式のために新しい登録を作成して、記述情報Element#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ラベル形式のための新しい課題はExpert Review[RFC2434](すなわち、IETF Areaディレクターによって任命された専門家のグループの1つによるレビュー)を通してIANAによって管理されるでしょう。 専門家のグループは既に定義されたラベルによるラベル形式定義が完全性、精度、および冗長のためにタイプするチェックを倍にしなければなりません。 安定していて永続的な公表媒体を使用して、新しいMPLSラベル形式の仕様を発表しなければなりません。
Quittek, et al. Standards Track [Page 82] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[82ページ]。
7.3. XML Namespace and Schema
7.3. XML名前空間と図式
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情報Element定義のためにXML図式を定義します。 Information Elementsが指定したすべてがAppendix Aで本書ではXML仕様で定義されます、すなわち、また、Appendix B.This図式の図式に従った有効なXML記録は、機械可読な道における、IPFIX情報モデルの今後の拡大で一層のInformation Elementsを指定するのに使用されるかもしれません。
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は、[RFC3688]で説明された登録メカニズムに従うIPFIX Information ElementsのためにXML名前空間とXML図式について説明するのにURNsを使用します。 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のための登録: つぼ:ietf:params:xml:ナノ秒: ipfixインフォメーション15*記入者Contact: IETF IPFIX Working Group <ipfix@ietf.org 、gt;、 IESG <iesg@ietf.org によって指定される、gt。 * XML: なし。 名前空間URIは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のための登録: つぼ:ietf:params:xml:図式: ipfixインフォメーション15*記入者Contact: IETF IPFIX Working Group <ipfix@ietf.org 、gt;、 IESG <iesg@ietf.org によって指定される、gt。 * XML: このドキュメントのAppendix Bを見てください。
8. Security Considerations
8. セキュリティ問題
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情報モデル自体は直接安全保障問題を紹介しません。 むしろ、それはそうするかもしれない1セットの属性を定義します。プライバシーかビジネス問題には、機密情報であると考えられてください。
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.
例えば、ヘッダーフィールドの輸出値で、攻撃はこのそうでなければ報告されたFlowsのダイレクト観察者だけに、データ経路に沿って可能であるだろうという情報の受信機に可能になるかもしれません。
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.
このドキュメントは、材料を合わせながら、どんな情報Element携帯も指定しません。 今後の拡大がそうするなら、適切な注意は、適切にそのような機密情報を保護するのに取られる必要があります。
Quittek, et al. Standards Track [Page 83] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[83ページ]。
9. Acknowledgements
9. 承認
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.
このドキュメントの初期のバージョンを作成して頂いて、ポールCallatoに感謝します、そして、エディタは、XML付録からのこのドキュメントのテキスト部分の大半を生成するXSLTスクリプトを開発するためにトーマス・ディーツに感謝します。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC5101] Claise, B., "Specification of the IPFIX Protocol for the
Exchange", RFC 5101, January 2008.
[RFC5101] Claise、B.、「交換のためのIPFIXプロトコルの仕様」、RFC5101、2008年1月。
10.2. Informative References
10.2. 有益な参照
[IEEE.754.1985]
Institute of Electrical and Electronics Engineers,
"Standard for Binary Floating-Point Arithmetic", IEEE
Standard 754, August 1985.
[IEEE、.754、.1985、]、米国電気電子技術者学会、「2進の浮動小数点の演算の規格」、IEEE規格754、8月1985
[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 Medium Access Control(MAC)とPhysical Layer(PHY)仕様」、IEEE Standard802.11、1999、<http://standards.ieee.org/getieee802/ダウンロード/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の標準の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 Standard802.3、2002年9月。
Quittek, et al. Standards Track [Page 84] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[84ページ]。
[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]国際標準化機構、「情報Technology--普遍的なMultiple-八重奏コード化された文字コード(UCS)--第1部:、」 「アーキテクチャと基本多言語水準」(ISO規格10646-1)は1993がそうするかもしれません。
[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 Standard646、1991
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC0768] ポステル、J.、「ユーザー・データグラム・プロトコル」、STD6、RFC768、1980年8月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[RFC0791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981.
[RFC0792] ポステル、J.、「インターネット・コントロール・メッセージ・プロトコル」、STD5、RFC792、1981年9月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC0793] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
[RFC1108] Kent, S., "U.S. Department of Defense Security Options for
the Internet Protocol", RFC 1108, November 1991.
[RFC1108] ケント、S.、「インターネットプロトコルのための米国国防総省のセキュリティオプション」、RFC1108、1991年11月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, August 1989.
[RFC1112] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、1989年8月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990.
[RFC1191] ムガール人とJ.とS.デアリング、「経路MTU探索」、RFC1191、1990年11月。
[RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions
for High Performance", RFC 1323, May 1992.
[RFC1323]ジェーコブソン(V.とブレーデン、R.とD.ボーマン、「高性能のためのTCP拡張子」RFC1323)は1992がそうするかもしれません。
[RFC1385] Wang, Z., "EIP: The Extended Internet Protocol", RFC 1385,
November 1992.
[RFC1385]ワング、Z.、「EIP:」 「拡張インターネットプロトコル」、RFC1385、1992年11月。
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
RFC 1812, June 1995.
[RFC1812] ベイカー、F.、エド、「IPバージョン4ルータのための要件」、RFC1812、6月1995日
[RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation,
selection, and registration of an Autonomous System (AS)",
BCP 6, RFC 1930, March 1996.
[RFC1930]Hawkinson、J.とT.ベイツ、「Autonomous System(AS)の作成、選択、および登録のためのガイドライン」BCP6、RFC1930(1996年3月)。
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February
1997.
[RFC2113] キャッツ、D.、「IPルータ警戒オプション」、RFC2113、1997年2月。
Quittek, et al. Standards Track [Page 85] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[85ページ]。
[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問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Structure of Management Information Version 2 (SMIv2)",
STD 58, RFC 2578, April 1999.
[RFC2578] McCloghrie、K.、パーキンス、D.、およびJ.Schoenwaelder、「経営情報バージョン2(SMIv2)の構造」、STD58、RFC2578(1999年4月)。
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
M. [RFC2629]ローズ、RFC2629、「XMLを使用することでI-DsとRFCsに書く」6月1999日
[RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms",
RFC 2675, August 1999.
1999年8月の[RFC2675]ボーマンとD.とデアリング、S.とR.Hinden、「IPv6 Jumbograms」RFC2675。
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, June 2000.
[RFC2863] McCloghrieとK.とF.Kastenholz、「インタフェースはMIBを分類する」RFC2863、2000年6月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] ローゼンとE.とViswanathan、A.とR.Callon、「Multiprotocolラベル切り換えアーキテクチャ」、RFC3031、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] ローゼン、E.、タッパン、D.、Fedorkow、G.、Rekhter、Y.、ファリナッチ、D.、李、T.、およびA.コンタ、「MPLSラベルスタックコード化」、RFC3032(2001年1月)。
[RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth,
"Securing L2TP using IPsec", RFC 3193, November 2001.
[RFC3193] パテルとB.とAbobaとB.とディクソンとW.とゾルン、G.とS.ブース、「IPsecを使用することでL2TPを固定します」、RFC3193、2001年11月。
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
Issues", RFC 3234, February 2002.
[RFC3234]大工、B.、およびS.があふれそうになる、「Middleboxes:」 「分類学と問題」、RFC3234、2月2002日
[RFC3260] Grossman, D., "New Terminology and Clarifications for
Diffserv", RFC 3260, April 2002.
[RFC3260] グロースマンと、D.と、「Diffservのための新しい用語と明確化」、RFC3260、4月2002日
[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.、ウー、L.、デイビー、B.、Davari、S.、バーナネン、P.、クリシュナン、R.、シェヴァル、P.、およびJ.Heinanen、「差別化されたサービスのマルチプロトコルラベルの切り換え(MPLS)サポート」、RFC3270)は2002がそうするかもしれません。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002.
[RFC3376] カイン、B.とデアリングとS.とKouvelasとI.とフェナー、B.とA.Thyagarajan、「インターネット集団経営は議定書を作ります、バージョン3インチ、RFC3376、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、「情報モデルとデータモデルの違い」、RFC3444、2003年1月。
Quittek, et al. Standards Track [Page 86] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[86ページ]。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[RFC3688] 食事、M.、「IETF XML登録」、BCP81、RFC3688、2004年1月。
[RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export
Version 9", RFC 3954, October 2004.
[RFC3954] Claise、B.、エド、「シスコシステムズのNetFlowサービスはバージョン9インチ、RFC3954に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.(エド)、李、T.(エド)、およびS.野兎(エド)、「境界ゲートウェイは4(BGP-4)について議定書の中で述べます」、RFC4271、2006年1月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4291] HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC4291、2006年2月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
2005.
[RFC4302] ケント、S.、「IP認証ヘッダー」、RFC4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005.
[RFC4303]ケント、S.、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC4303、2005年12月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]ローゼンとE.とY.Rekhter、「BGP/MPLS IP仮想私設網(VPNs)」、RFC4364 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]ナドー、T.、エドH.バンderリンデ(エド)、「MPLS/BGPは3仮想私設網(VPN)管理情報ベースを層にします」、RFC4382、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.
[RFC4443] コンタ、A.、デアリング、S.、およびM.グプタ(エド)、「インターネットへのインターネット・コントロール・メッセージ・プロトコル(ICMPv6)はバージョン6(IPv6)仕様を議定書の中で述べます」、RFC4443、2006年3月。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, September 2007.
[RFC4960] スチュワート、R.、エド、「ストリーム制御伝動プロトコル」、RFC4960、9月2007日
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, October 2007.
[RFC5036] アンデション、L.、エド、Minei、I.、エド、B.トーマス、エド、「自由民主党仕様」、RFC5036、10月2007日
Quittek, et al. Standards Track [Page 87] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[87ページ]。
Appendix A. XML Specification of IPFIX Information Elements
IPFIX Information Elementsの付録A.XML仕様
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.
情報モデルに機械可読な構文を使用すると、自動的に拡大に順応できるIPFIX意識しているツールの作成は情報モデルに可能にされます、単にアップデートされた情報モデル仕様を読むことによって。
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ドキュメントのためのライブラリは容易に特に、利用可能です。 また、Extensible Stylesheet Language(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.
Exporters、Collectors、または他のツールにおけるXMLの使用がIPFIXの展開に義務的でないことに注意されるべきです。 Exporting Processesは彼らの操作の一部としてXMLを特に、生産もしませんし、消費もしません。 彼らの振舞いをコード化するか、または拡大を収容するための独占手段を発明して、IPFIX Collectorsが困難に対して情報モデルのマシン読み易さを利用するかもしれないと予想されます。
<?xml version="1.0" encoding="UTF-8"?>
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ>。
<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">
<fieldDefinitions xmlnsは「つぼ:ietf:params:xml:ナノ秒: ipfixインフォメーション」xmlnsと等しいです: xsiが" http://www.w3.org/2001/XMLSchema-instance "xsi: schemaLocation=と等しい、「つぼ:ietf:params:xml:ナノ秒: ipfixインフォメーション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"
「識別子」「<フィールド名="lineCardId"dataTypeは「unsigned32"グループ=」範囲と等しく」dataTypeSemantics=elementIdが「141」適用性=「オプション」状態=と等しい、「現在の「Observation Pointを接待するIPFIX Device単位でユニークな系列カードに関する><記述><パラグラフ>An識別子。」 通常、この情報Elementは、他のInformation Elementsの範囲を制限するのに使用されます。 </パラグラフ></記述></分野><フィールド名="portId"データ型式="unsigned32""
Quittek, et al. Standards Track [Page 88] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[88ページ]。
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>
「識別子」グループ=「範囲」dataTypeSemantics=elementIdが「142」適用性=「オプション」状態=と等しい、「現在の「Observation Pointを接待するIPFIX Device単位でユニークな系列ポートに関する><記述><パラグラフ>An識別子。」 通常、この情報Elementは、他のInformation Elementsの範囲を制限するのに使用されます。 </パラグラフ></記述></分野>。
<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>
「<フィールド名="ingressInterface"dataTypeは「unsigned32"グループ=」範囲と等しく」dataTypeSemanticsが「」 10インチの適用性=すべて」という「識別子」elementId=状態=と等しい、「現在の「IPのインデックスがこのFlowのパケットが受け取られているところに連結する><記述><パラグラフ>。」 値はRFC2863で定義されるように管理オブジェクト'ifIndex'の値に合っています。 ifIndex値が静的にインタフェースに割り当てられないで、デバイスのマネージメントシステムが再初期化されるときはいつも、インタフェースが番号を付け替えられるかもしれないことに注意してください、RFC2863で指定されるように。 </パラグラフ></記述><参照><はifIndexオブジェクトの定義のために>See RFC2863について短い記事を書きます。 </パラグラフ></参照></分野>。
<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.
「<フィールド名="egressInterface"dataTypeは「unsigned32"グループ=」範囲と等しく」dataTypeSemanticsが「」 14インチの適用性=すべて」という「識別子」elementId=状態=と等しい、「現在の「IPのインデックスがこのFlowのパケットが送られるところに連結する><記述><パラグラフ>。」 値はRFC2863で定義されるように管理オブジェクト'ifIndex'の値に合っています。 ifIndex値が静的にインタフェースに割り当てられないで、デバイスのマネージメントシステムが再初期化されるときはいつも、インタフェースが番号を付け替えられるかもしれないことに注意してください、RFC2863で指定されるように。
Quittek, et al. Standards Track [Page 89] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[89ページ]。
</paragraph>
</description>
<reference>
<paragraph>
See RFC 2863 for the definition of the ifIndex object.
</paragraph>
</reference>
</field>
</パラグラフ></記述><参照><はifIndexオブジェクトの定義のために>See RFC2863について短い記事を書きます。 </パラグラフ></参照></分野>。
<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>
「識別子」「<フィールド名="meteringProcessId"dataTypeは「unsigned32"グループ=」範囲と等しく」dataTypeSemantics=elementIdが「143」適用性=「オプション」状態=と等しい、「現在の「IPFIX Device単位でユニークなMetering Processに関する><記述><パラグラフ>An識別子。」 通常、この情報Elementは、他のInformation Elementsの範囲を制限するのに使用されます。 プロセス識別子がダイナミックに通常割り当てられることに注意してください。 Metering Processは異なったIDと共に再開されるかもしれません。 </パラグラフ></記述></分野>。
<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>
「識別子」「<フィールド名="exportingProcessId"dataTypeは「unsigned32"グループ=」範囲と等しく」dataTypeSemantics=elementIdが「144」適用性=「オプション」状態=と等しい、「現在の「IPFIX Device単位でユニークなExporting Processに関する><記述><パラグラフ>An識別子。」 通常、この情報Elementは、他のInformation Elementsの範囲を制限するのに使用されます。 プロセス識別子がダイナミックに通常割り当てられることに注意してください。 Exporting Processは異なったIDと共に再開されるかもしれません。 </パラグラフ></記述></分野>。
<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
「識別子」「<フィールド名="flowId"dataTypeは「unsigned64"グループ=」範囲と等しく」dataTypeSemantics=elementIdが「148」適用性=「オプション」状態=と等しい、「現在の「Observationの中でユニークなFlowに関する><記述><パラグラフ>An識別子」
Quittek, et al. Standards Track [Page 90] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[90ページ]。
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>
ドメイン。 IPアドレスやポートナンバーなどのFlowキーズが報告されないか、または別々の記録で報告されるなら、異なったFlowsを見分けるのにこの情報Elementを使用できます。 </パラグラフ></記述></分野>。
<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>
「識別子」「<フィールド名="templateId"dataTypeは「unsigned16"グループ=」範囲と等しく」dataTypeSemantics=elementIdが「145」適用性=「オプション」状態=と等しい、「現在の「Transportセッションの組み合わせの中で局所的にユニークなTemplateとObservation Domainに関する><記述><パラグラフ>An識別子。」 </パラグラフ><パラグラフ>Template ID0-255は、Template Sets、Options Template Sets、および他の予約されたSetsにもかかわらず、作成されるために予約されます。 Data SetsのテンプレートIDは256〜65535まで付番されます。 </パラグラフ><パラグラフ>Typically、この情報Elementは、他のInformation Elementsの範囲を制限するのに使用されます。 Exporting Process Template識別子の再開が再選任されたかもしれない後にそれに注意してください。 </パラグラフ></記述></分野>。
<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>
「識別子」「<フィールド名="observationDomainId"dataTypeは「unsigned32"グループ=」範囲と等しく」dataTypeSemantics=elementIdが「149」適用性=「オプション」状態=と等しい、「現在の「局所的にExporting ProcessにユニークなObservation Domainに関する><記述><パラグラフ>An識別子。」 Exporting Processは、唯一、Flowsが計量されたObservation DomainをCollecting Processに特定するのにObservation Domain IDを使用します。 また、この識別子もIPFIX Device単位でユニークであることは、RECOMMENDEDです。 0の</パラグラフ><パラグラフ>A価値は、どんな特定のObservation Domainもこの情報Elementによって特定されないのを示します。 </パラグラフ>。
Quittek, et al. Standards Track [Page 91] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[91ページ]。
<paragraph>
Typically, this Information Element is used for limiting
the scope of other Information Elements.
</paragraph>
</description>
</field>
<パラグラフ>Typically、この情報Elementは、他のInformation Elementsの範囲を制限するのに使用されます。 </パラグラフ></記述></分野>。
<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>
「識別子」「<フィールド名="observationPointId"dataTypeは「unsigned32"グループ=」範囲と等しく」dataTypeSemantics=elementIdが「138」適用性=「オプション」状態=と等しい、「現在の「Observation Domain単位でユニークなObservation Pointに関する><記述><パラグラフ>An識別子。」 また、この識別子もIPFIX Device単位でユニークであることは、RECOMMENDEDです。 通常、この情報Elementは、他のInformation Elementsの範囲を制限するのに使用されます。 「識別子」「</パラグラフ></記述></分野><フィールド名="commonPropertiesId"dataTypeは「unsigned64"グループ=」範囲と等しく」dataTypeSemantics=elementIdが「137」適用性=「オプション」状態=と等しい、「現在の「aに関するAn識別子が設定したObservation Domain単位でユニークな通有性とTransport Sessionの><記述><パラグラフ>。」 通常、この情報Elementは、別々のData Recordsで報告された情報にリンクするのに使用されます。 </パラグラフ></記述></分野>。
<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>
<フィールド名=「exporterIPv4Address」dataType=「ipv4Address」dataTypeSemantics=「識別子」グループ=「コンフィグ」elementId=「130」適用性が「all」の状態=と等しい、「現在の「IPv4アドレスがExporting Processで使用した><記述><パラグラフ>。」 これは、Exporterのアイデンティティがプロキシの使用であいまいにされたかもしれない場合でExporterを特定するのにCollectorによって使用されます。 </パラグラフ></記述></分野>。
Quittek, et al. Standards Track [Page 92] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[92ページ]。
<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>
<フィールド名=「exporterIPv6Address」dataType=「ipv6Address」dataTypeSemantics=「識別子」グループ=「コンフィグ」elementId=「131」適用性が「all」の状態=と等しい、「現在の「IPv6アドレスがExporting Processで使用した><記述><パラグラフ>。」 これは、Exporterのアイデンティティがプロキシの使用であいまいにされたかもしれない場合でExporterを特定するのにCollectorによって使用されます。 </パラグラフ></記述></分野>。
<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>
><記述><は>について短い記事を書きます。「識別子」elementId=「217」「<フィールド名="exporterTransportPort"dataTypeは「unsigned16"グループ=」コンフィグと等しく」dataTypeSemantics=適用性が「all」の状態=と等しい、「現在、「Exporting ProcessがFlow情報を送るソースポート識別子、」 トランスポート・プロトコルのUDP、TCP、およびSCTPにおいて、これはソースポート番号です。 また、この分野は16ビットのソースポート識別子を持っている将来のトランスポート・プロトコルに使用されるかもしれません。 この分野は同じIPアドレスを使用する複数のExporting Processesを区別することの役に立つかもしれません。 </パラグラフ></記述><参照><はUDPソースポート分野の定義のために>See RFC768について短い記事を書きます。 TCPソースポート分野の定義に関してRFC793を見てください。 SCTPの定義に関してRFC4960を見てください。 http://www.iana.org/assignments/port-numbers で定義されたUDPとTCPポートナンバーの</パラグラフ><パラグラフ>Additional情報を見つけることができます。 </パラグラフ></参照></分野>。
<field name="collectorIPv4Address" dataType="ipv4Address"
dataTypeSemantics="identifier"
group="config"
elementId="211" applicability="all" status="current">
<フィールド名=「collectorIPv4Address」dataType=「ipv4Address」dataTypeSemantics=「識別子」グループ=「コンフィグ」elementId=「211」適用性が「all」の状態=と等しい、「現在の">"
Quittek, et al. Standards Track [Page 93] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[93ページ]。
<description>
<paragraph>
An IPv4 address to which the Exporting Process sends Flow
information.
</paragraph>
</description>
</field>
Exporting Processが情報をFlowに送るAn IPv4が扱う<記述><パラグラフ>。 </パラグラフ></記述></分野>。
<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>
<フィールド名=「collectorIPv6Address」dataType=「ipv6Address」dataTypeSemantics=「識別子」グループ=「コンフィグ」elementId=「212」適用性が「all」の状態=と等しい、「現在の「Exporting Processが情報をFlowに送るAn IPv6が扱う><記述><パラグラフ>。」 </パラグラフ></記述></分野>。
<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>
「識別子」elementId=「213」「<フィールド名="exportInterface"dataTypeは「unsigned32"グループ=」コンフィグと等しく」dataTypeSemantics=適用性が「all」の状態=と等しい、「現在の「どのIPFIX MessagesがExporting Processで発信したか、そして、a CollectorまでのインタフェースのインデックスがIPFIX Deviceを残す><記述><パラグラフ>。」 値はRFC2863で定義されるように管理オブジェクト'ifIndex'の値に合っています。 ifIndex値が静的にインタフェースに割り当てられないで、デバイスのマネージメントシステムが再初期化されるときはいつも、インタフェースが番号を付け替えられるかもしれないことに注意してください、RFC2863で指定されるように。 </パラグラフ></記述><参照><はifIndexオブジェクトの定義のために>See RFC2863について短い記事を書きます。 </パラグラフ></参照></分野>。
<field name="exportProtocolVersion" dataType="unsigned8"
dataTypeSemantics="identifier"
group="config"
elementId="214" applicability="all" status="current">
<description>
「<フィールド名="exportProtocolVersion"dataType=「unsigned8" dataTypeSemantics=」識別子」グループ=「コンフィグ」elementId=「214」適用性が「all」の状態=と等しい、「電流「><記述>」
Quittek, et al. Standards Track [Page 94] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[94ページ]。
<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>
プロトコルバージョンが送付Flow情報にExporting Processで使用した<パラグラフ>。 Message HeaderのバージョンNumber分野の値でプロトコルバージョンを与えます。 </パラグラフ><は>について短い記事を書きます。プロトコルバージョンは、IPFIXのための10とNetFlowバージョン9のための9です。 0の値は、どんな輸出プロトコルも使用中でないことを示します。 </パラグラフ></記述><参照><パラグラフ>See IPFIXはIPFIX Message Headerの定義のための仕様[RFC5101]を議定書の中で述べます。 </パラグラフ><はNetFlowバージョン9メッセージヘッダーの定義のために>See RFC3954について短い記事を書きます。 </パラグラフ></参照></分野>。
<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>
「識別子」elementId=「215」「<フィールド名="exportTransportProtocol"dataTypeは「unsigned8"グループ=」コンフィグと等しく」dataTypeSemantics=適用性が「all」の状態=と等しい、「現在の「プロトコル番号の値が送付Flow情報にExporting Processで使用した><記述><パラグラフ>。」 プロトコル番号はIPパケットペイロードタイプを特定します。 プロトコル番号はIANAプロトコル民数記登録で定義されます。 </パラグラフ>。
<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.
<は>Inインターネットプロトコルバージョン4(IPv4)について短い記事を書いて、これはプロトコル分野で運ばれます。 インターネットプロトコルバージョン6(IPv6)では、これはパケットの最後の拡張ヘッダーのNext Header分野で運ばれます。 IPv4プロトコルの仕様のための>See RFC791がさばく</パラグラフ></記述><参照><パラグラフ。
Quittek, et al. Standards Track [Page 95] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[95ページ]。
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プロトコル分野の仕様に関してRFC2460を見てください。 プロトコル番号のリストがIANAによって http://www.iana.org/assignments/protocol-numbers に割り当てられるのを見てください。 </パラグラフ></参照></分野>。
<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>
「識別子」elementId=「216」「<フィールド名="collectorTransportPort"dataTypeは「unsigned16"グループ=」コンフィグと等しく」dataTypeSemantics=適用性が「all」の状態=と等しい、「現在の「目的地が識別子を移植する><記述><パラグラフ>Exporting ProcessがFlow情報を送る。」 トランスポート・プロトコルのUDP、TCP、およびSCTPのために、これは目的地ポートナンバーです。 また、この分野は16ビットのソースポート識別子を持っている将来のトランスポート・プロトコルに使用されるかもしれません。 UDP仕向港の定義のための>See RFC768がさばく</パラグラフ></記述><参照><パラグラフ。 TCP仕向港分野の定義に関してRFC793を見てください。 SCTPの定義に関してRFC4960を見てください。 http://www.iana.org/assignments/port-numbers で定義されたUDPとTCPポートナンバーの</パラグラフ><パラグラフ>Additional情報を見つけることができます。 </パラグラフ></参照></分野>。
<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.
「173」の「<フィールド名="flowKeyIndicator"dataTypeは「unsigned64" dataTypeSemantics=」旗と等しく」グループ=「コンフィグ」elementId=適用性が「all」の状態=と等しい、「「>Thisが設定する噛み付いている分野の><記述><パラグラフはData RecordのInformation ElementsのためにFlow Keyとしてそのサーブをマークするのに使用されます」現在の。 各ビットは、第n情報Elementを表しながら、Data Recordにn番目のビットで情報Elementを表します。 少し、1を評価するセットは、対応する情報Elementが報告されたFlowのFlow Keyであることを示します。
Quittek, et al. Standards Track [Page 96] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[96ページ]。
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を評価するセットは、これがそうでないことを示します。 </パラグラフ><パラグラフ>If Data Recordは最初の64の中にすべてのFlowキーズがある設計されたそのようなものがInformation Elementsであったなら64以上Information Elements、対応するTemplate SHOULDを含んでいます、flowKeyIndicatorが64ビットしか含んでいないので。 Data Recordが64未満Information Elementsを含むなら、どんな対応する情報Elementも存在しないflowKeyIndicatorのビットには、値0がなければなりません。 </パラグラフ></記述></分野>。
<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>
<フィールド名="exportedMessageTotalCount"dataTypeが「unsigned64" dataTypeSemantics="totalCounter"グループ="processCounter"elementId=「41インチの適用性=」データ」状態=と等しい、「現在、「合計が付番するExporting Process以来Exporting Processが送るIPFIX Messagesの><記述><パラグラフ>、(再、)、特定のCollecting Processへの初期化、」 報告された数は対価を運ぶIPFIX Messageを除きます。 この情報Elementを特定のCollecting Processに送るなら、デフォルトで、それはこのCollecting Processに送られたIPFIX Messagesの数を指定します。 </パラグラフ></記述><ユニット>メッセージ</ユニット></分野>。
<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
<フィールド名="exportedOctetTotalCount"dataTypeが「unsigned64" dataTypeSemantics="totalCounter"グループ="processCounter"elementId=「40インチの適用性=」データ」状態=と等しい、「現在、「合計が付番するExporting Process以来Exporting Processが送る八重奏の><記述><パラグラフ>、(再、)、特定のCollecting Processへの初期化、」 この情報Elementの値は、首尾よくCollecting Processに送られたすべてのIPFIX MessagesのIPFIX Message Header長さの値をまとめることによって、計算されます。 報告された数は対価を運ぶIPFIX Messageで八重奏を除きます。 この情報Elementを事項に送るなら
Quittek, et al. Standards Track [Page 97] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[97ページ]。
Collecting Process, then by default it specifies the number
of octets sent to this Collecting Process.
</paragraph>
</description>
<units>octets</units>
</field>
Processを集めて、デフォルトで、次に、それはこのCollecting Processに送られた八重奏の数を指定します。 </パラグラフ></記述><ユニット>八重奏</ユニット></分野>。
<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>
<フィールド名="exportedFlowRecordTotalCount"dataTypeが「unsigned64"グループ="processCounter"dataTypeSemantics="totalCounter"elementId=「42インチの適用性=」データ」状態=と等しい、「現在、「合計が付番するExporting Process以来Exporting ProcessがData Recordsとして送るFlow Recordsの><記述><パラグラフ>、(再、)、特定のCollecting Processへの初期化、」 報告された数は対価を運ぶIPFIX MessageでFlow Recordsを除きます。 この情報Elementを特定のCollecting Processに送るなら、デフォルトで、それはこのプロセスに送られたFlow Recordsの数を指定します。 </パラグラフ></記述><ユニット>流れ</ユニット></分野>。
<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>
<フィールド名="observedFlowTotalCount"dataTypeが等しい、「"totalCounter"グループ="processCounter"unsigned64" dataTypeSemantics=elementIdが「163」適用性=「データ」状態=と等しい、「現在、「Metering Process以来Flowsの総数がObservation Domainで観測した><記述><パラグラフ>、(再、)、このObservation Pointのための初期化、」 </パラグラフ></記述><ユニット>流れ</ユニット></分野>。
<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
<フィールド名="ignoredPacketTotalCount"dataTypeが等しい、「"totalCounter"グループ="processCounter"unsigned64" dataTypeSemantics=elementIdが「164」適用性=「データ」状態=と等しい、「現在、「合計が付番するMetering Processが以来処理しなかった観測されたIPパケットの><記述><パラグラフ>、」
Quittek, et al. Standards Track [Page 98] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[98ページ]。
(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>
<フィールド名="ignoredOctetTotalCount"dataTypeが等しい、「"totalCounter"グループ="processCounter"unsigned64" dataTypeSemantics=elementIdが「165」適用性=「データ」状態=と等しい、「現在、「合計が付番する中の八重奏の><記述><パラグラフ>がMetering Processが以来処理しなかったIPパケット(IPヘッダーを含んでいる)を観察した、(再、)、Metering Processの初期化、」 </パラグラフ></記述><ユニット>八重奏</ユニット></分野>。
<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>
<フィールド名="notSentFlowTotalCount"dataTypeが等しい、「"totalCounter"グループ="processCounter"unsigned64" dataTypeSemantics=elementIdが「166」適用性=「データ」状態=と等しい、「現在の「合計が付番するCollecting Processに送ることの代わりに、Metering Processによって生成されて、Metering ProcessかExporting Processによって下げられたFlow Recordsの><記述><パラグラフ>。」 リソース不足と特別なFlow輸出方針を含むこのいくつかの潜在的理由があります。 </パラグラフ></記述><ユニット>流れ</ユニット></分野>。
<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.
<フィールド名="notSentPacketTotalCount"dataTypeが等しい、「"totalCounter"グループ="processCounter"unsigned64" dataTypeSemantics=elementIdが「167」適用性=「データ」状態=と等しい、「現在の「合計が付番するMetering Processによって生成されて、Metering Processに立ち寄ったFlow RecordsかCollecting Processに送ることの代わりにExporting Processによるパケットの><記述><パラグラフ>。」
Quittek, et al. Standards Track [Page 99] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[99ページ]。
There are several potential reasons for this including
resource shortage and special Flow export policies.
</paragraph>
</description>
<units>packets</units>
</field>
リソース不足と特別なFlow輸出方針を含むこのいくつかの潜在的理由があります。 </パラグラフ></記述><ユニット>パケット</ユニット></分野>。
<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>
<フィールド名="notSentOctetTotalCount"dataTypeが等しい、「"totalCounter"グループ="processCounter"unsigned64" dataTypeSemantics=elementIdが「168」適用性=「データ」状態=と等しい、「現在の「合計が付番するMetering Processによって生成されて、Metering Processに立ち寄ったFlow RecordsかCollecting Processに送ることの代わりにExporting Processによるパケットの八重奏の><記述><パラグラフ>。」 リソース不足と特別なFlow輸出方針を含むこのいくつかの潜在的理由があります。 </パラグラフ></記述><ユニット>八重奏</ユニット></分野>。
<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>
<フィールド名="ipVersion"dataTypeが等しい、「unsigned8"グループ="ipHeader"dataTypeSemanticsが「」 60インチの適用性=すべて」という「識別子」elementId=状態=と等しい、「現在の「IPバージョンがIPパケットのヘッダーでさばく><記述><パラグラフ>。」 バージョンの定義のための>See RFC791がIPv4パケットのヘッダーでさばく</パラグラフ></記述><参照><パラグラフ。 IPv6パケットのヘッダーとのバージョン分野の定義に関してRFC2460を見てください。 http://www.iana.org/assignments/version-numbers で定義されたバージョン番号に関する追加情報を見つけることができます。 </パラグラフ></参照></分野>。
<field name="sourceIPv4Address" dataType="ipv4Address"
group="ipHeader"
<フィールド名=「sourceIPv4Address」データ型式=「ipv4Address」グループ="ipHeader"
Quittek, et al. Standards Track [Page 100] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[100ページ]。
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>
「dataTypeSemanticsが「」 8インチの適用性=すべて」という「識別子」elementId=状態=と等しい、「「IPv4が出典を明示する><記述><パラグラフ>は中でIPパケットのヘッダーに演説します」現在の。 IPv4ソースアドレスの定義のための>See RFC791がさばく</パラグラフ></記述><参照><パラグラフ。 </パラグラフ></参照></分野>。
<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>
「「ipv6Address」グループ="ipHeader"<フィールド名=「sourceIPv6Address」dataType=dataTypeSemanticsが「」 27インチの適用性=すべて」という「識別子」elementId=状態=と等しい、「「IPv6が出典を明示する><記述><パラグラフ>は中でIPパケットのヘッダーに演説します」現在の。 Source Addressの定義のための>See RFC2460がIPv6ヘッダーでさばく</パラグラフ></記述><参照><パラグラフ。 </パラグラフ></参照></分野>。
<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>
><記述><は>について短い記事を書きます。<フィールド名="sourceIPv4PrefixLength"dataTypeが「unsigned8"グループ="ipHeader"elementId=「9インチの適用性=」オプション」状態=と等しい、「現在、「sourceIPv4Prefix情報Elementで関連している隣接のビットの数、」 </パラグラフ></記述><ユニット>ビット</単位><範囲の>0-32</範囲></分野>。
<field name="sourceIPv6PrefixLength" dataType="unsigned8"
group="ipHeader"
elementId="29" applicability="option" status="current">
<フィールド名="sourceIPv6PrefixLength"dataTypeが「unsigned8"グループ="ipHeader"elementId=「29インチの適用性=」オプション」状態=と等しい、「現在の">"
Quittek, et al. Standards Track [Page 101] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[101ページ]。
<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>
<記述><は>について短い記事を書きます。sourceIPv6Prefix情報Elementで関連している隣接のビットの数。 </パラグラフ></記述><ユニット>ビット</単位><範囲の>0-128</範囲></分野>。
<field name="sourceIPv4Prefix" dataType="ipv4Address"
group="ipHeader"
elementId="44" applicability="data" status="current">
<description>
<paragraph>
IPv4 source address prefix.
</paragraph>
</description>
</field>
「<フィールド名="sourceIPv4Prefix"dataType=「ipv4Address」グループ="ipHeader"elementId=「44インチの適用性=」データ」状態が等しい、「現在の「><記述><パラグラフ>IPv4ソースアドレス接頭語。」 </パラグラフ></記述></分野>。
<field name="sourceIPv6Prefix" dataType="ipv6Address"
group="ipHeader"
elementId="170" applicability="data" status="current">
<description>
<paragraph>
IPv6 source address prefix.
</paragraph>
</description>
</field>
「ipv6Address」グループ="ipHeader"<フィールド名="sourceIPv6Prefix"dataType=elementIdが「170」適用性=「データ」状態=と等しい、「現在の「><記述><パラグラフ>IPv6ソースアドレス接頭語。」 </パラグラフ></記述></分野>。
<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>
「「ipv4Address」グループ="ipHeader"<フィールド名=「destinationIPv4Address」dataType=dataTypeSemanticsが「」 12インチの適用性=すべて」という「識別子」elementId=状態=と等しい、「現在の「IPv4の目的地がIPパケットのヘッダーで扱う><記述><パラグラフ>。」 IPv4送付先アドレスの定義のための>See RFC791がさばく</パラグラフ></記述><参照><パラグラフ。 </パラグラフ></参照></分野>。
<field name="destinationIPv6Address" dataType="ipv6Address"
<フィールド名=「destinationIPv6Address」データ型式=「ipv6Address」
Quittek, et al. Standards Track [Page 102] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[102ページ]。
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>
「グループ="ipHeader"dataTypeSemanticsが「」 28インチの適用性=すべて」という「識別子」elementId=状態=と等しい、「現在の「IPv6の目的地がIPパケットのヘッダーで扱う><記述><パラグラフ>。」 Destination Addressの定義のための>See RFC2460がIPv6ヘッダーでさばく</パラグラフ></記述><参照><パラグラフ。 </パラグラフ></参照></分野>。
<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>
><記述><は>について短い記事を書きます。<フィールド名="destinationIPv4PrefixLength"dataTypeが「unsigned8"グループ="ipHeader"elementId=「13インチの適用性=」オプション」状態=と等しい、「現在、「destinationIPv4Prefix情報Elementで関連している隣接のビットの数、」 </パラグラフ></記述><ユニット>ビット</単位><範囲の>0-32</範囲></分野>。
<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>
><記述><は>について短い記事を書きます。<フィールド名="destinationIPv6PrefixLength"dataTypeが「unsigned8"グループ="ipHeader"elementId=「30インチの適用性=」オプション」状態=と等しい、「現在、「destinationIPv6Prefix情報Elementで関連している隣接のビットの数、」 </パラグラフ></記述><ユニット>ビット</単位><範囲の>0-128</範囲></分野>。
<field name="destinationIPv4Prefix" dataType="ipv4Address"
group="ipHeader"
elementId="45" applicability="data" status="current">
<description>
<paragraph> IPv4 destination address prefix. </paragraph>
</description>
「<フィールド名="destinationIPv4Prefix"dataType=「ipv4Address」グループ="ipHeader"elementId=「45インチの適用性=」データ」状態が等しい、「現在の「><記述><パラグラフ>IPv4目的地アドレス接頭語。」 </パラグラフ></記述>。
Quittek, et al. Standards Track [Page 103] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[103ページ]。
</field>
</分野>。
<field name="destinationIPv6Prefix" dataType="ipv6Address"
group="ipHeader"
elementId="169" applicability="data" status="current">
<description>
<paragraph> IPv6 destination address prefix. </paragraph>
</description>
</field>
「ipv6Address」グループ="ipHeader"<フィールド名="destinationIPv6Prefix"dataType=elementIdが「169」適用性=「データ」状態=と等しい、「現在の「><記述><パラグラフ>IPv6目的地アドレス接頭語。」 </パラグラフ></記述></分野>。
<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>
<フィールド名="ipTTL"dataTypeが等しい、「unsigned8"グループ="ipHeader"elementId=「192」適用性が「all」の状態=と等しい、「「><記述><パラグラフ>For IPv4、情報Elementの値はIPv4パケットのヘッダーのLive(TTL)分野にTimeの値を合わせます」現在の。 IPv6に関しては、情報Elementの値はIPv6パケットのヘッダーのHop Limit分野の値に合っています。 LiveへのIPv4 Timeの定義のための>See RFC791がさばく</パラグラフ></記述><参照><パラグラフ。 IPv6 Hop Limit分野の定義に関してRFC2460を見てください。 </パラグラフ></参照><ユニット>は</ユニット></分野>を飛び越します。
<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>
><記述><は>について短い記事を書きます。<フィールド名="protocolIdentifier"dataTypeが等しい、「unsigned8"グループ="ipHeader"dataTypeSemanticsが「」 4インチの適用性=すべて」という「識別子」elementId=状態=と等しい、「現在、「IPパケットのヘッダーのプロトコル番号の値、」 プロトコル番号はIPパケットペイロードタイプを特定します。 プロトコル番号はIANAプロトコル民数記登録で定義されます。 </パラグラフ>。
<paragraph>
In Internet Protocol version 4 (IPv4), this is carried in the
Protocol field. In Internet Protocol version 6 (IPv6), this
<は>Inインターネットプロトコルバージョン4(IPv4)について短い記事を書いて、これはプロトコル分野で運ばれます。 インターネットプロトコルバージョン6(IPv6)でこれ
Quittek, et al. Standards Track [Page 104] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[104ページ]。
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>
パケットの最後の拡張ヘッダーのNext Header分野では、運ばれます。 IPv4プロトコルの仕様のための>See RFC791がさばく</パラグラフ></記述><参照><パラグラフ。 IPv6プロトコル分野の仕様に関してRFC2460を見てください。 プロトコル番号のリストがIANAによって http://www.iana.org/assignments/protocol-numbers に割り当てられるのを見てください。 </パラグラフ></参照></分野>。
<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>
<フィールド名=、「nextHeaderIPv6" dataTypeが等しい、「unsigned8"グループ="ipHeader"elementId=「193」適用性が「all」の状態=と等しい、「現在の「Next Headerの値がさばくIPv6ヘッダーの><記述><パラグラフ>。」 値は以下のIPv6拡張ヘッダーか以下のIPペイロードのタイプを特定します。 有効値はIANAプロトコル民数記登録で定義されます。 </パラグラフ></記述><参照><はIPv6 Next Header分野の定義のために>See RFC2460について短い記事を書きます。 プロトコル番号のリストがIANAによって http://www.iana.org/assignments/protocol-numbers に割り当てられるのを見てください。 </パラグラフ></参照></分野>。
<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
<フィールド名="ipDiffServCodePoint"dataTypeが等しい、「「識別子」elementId=「195」unsigned8"グループ="ipHeader"dataTypeSemantics=適用性が「all」の状態=と等しい、「現在の「Differentiated Services Code Point(DSCP)の値がDifferentiated Services分野でコード化した><記述><パラグラフ>。」 Differentiated Services分野はIPv4 TOS分野かIPv6 Traffic Classの最も重要な6ビットを測ります。
Quittek, et al. Standards Track [Page 105] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[105ページ]。
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>
それぞれ、さばきます。 </パラグラフ><パラグラフ>This情報ElementはDifferentiated Services分野の6ビットだけをコード化します。 したがって、値は0〜63まで及ぶかもしれません。 </パラグラフ></記述><参照><はDifferentiated Services分野の定義のために>See RFC3260について短い記事を書きます。 IPv4 TOS分野の定義に関してRFC1812(セクション5.3.2)とRFC791を見てください。 IPv6 Traffic Class分野の定義に関してRFC2460を見てください。 </パラグラフ></参照><範囲の>0-63</範囲></分野>。
<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>
<フィールド名="ipPrecedence"dataTypeが等しい、「「識別子」elementId=「196」unsigned8"グループ="ipHeader"dataTypeSemantics=適用性が「all」の状態=と等しい、「現在、「><記述><パラグラフ>、IP Precedenceの値、」 IP Precedence価値はIPv4 TOS分野かIPv6 Traffic Class分野の最初の3ビットでそれぞれコード化されます。 </パラグラフ><パラグラフ>This情報Elementはこれらの3ビットだけをコード化します。 したがって、値は0〜7まで及ぶかもしれません。 </パラグラフ></記述><参照><はIP Precedenceの定義のために>See RFC1812(セクション5.3.3)とRFC791について短い記事を書きます。 IPv4 TOS分野の定義に関してRFC1812(セクション5.3.2)とRFC791を見てください。 IPv6 Traffic Class分野の定義に関してRFC2460を見てください。 </パラグラフ></参照><範囲の>0-7</範囲></分野>。
Quittek, et al. Standards Track [Page 106] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[106ページ]。
<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>
<フィールド名="ipClassOfService"dataTypeが等しい、「unsigned8"グループ="ipHeader"dataTypeSemanticsが「」 5インチの適用性=すべて」という「識別子」elementId=状態=と等しい、「現在、「><記述><パラグラフ>For IPv4パケット、これはIPv4パケットのヘッダーのTOS分野の値です」。 IPv6パケットに関しては、これはIPv6パケットのヘッダーのTraffic Class分野の値です。 </パラグラフ></記述><参照><はIPv4 TOS分野の定義のために>See RFC1812(セクション5.3.2)とRFC791について短い記事を書きます。 IPv6 Traffic Class分野の定義に関してRFC2460を見てください。 </パラグラフ></参照></分野>。
<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>
><記述><はこの情報Elementの定義が同じである>について短い記事を書きます。<フィールド名="postIpClassOfService"dataTypeが等しい、「unsigned8"グループ="ipHeader"dataTypeSemanticsが「」 55インチの適用性=すべて」という「識別子」elementId=状態=と等しい、「現在、「パケットの後に情報Element'ipClassOfService'middlebox機能によって引き起こされた潜在的に変更された値を報告するのを除いて、定義がObservation Pointを渡した、」 </パラグラフ></記述><参照><はIPv4 TOS分野の定義のために>See RFC791について短い記事を書きます。 IPv6 Traffic Class分野の定義に関してRFC2460を見てください。 middleboxesの定義に関してRFC3234を見てください。 </パラグラフ></参照></分野>。
<field name="flowLabelIPv6" dataType="unsigned32"
group="ipHeader"
dataTypeSemantics="identifier"
<フィールド名=、「flowLabelIPv6"データ型式=「unsigned32"グループ="ipHeader"dataTypeSemantics=「識別子」」
Quittek, et al. Standards Track [Page 107] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[107ページ]。
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>
「elementIdが「31インチの適用性は」 すべてと等しい」という状態=と等しい、「現在の「IPv6 Flow Labelの値がIPパケットのヘッダーでさばく><記述><パラグラフ>。」 Flow Labelの定義のための>See RFC2460がIPv6パケットのヘッダーでさばく</パラグラフ></記述><参照><パラグラフ。 </パラグラフ></参照></分野>。
<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 |
<フィールド名="isMulticast"dataTypeが等しい、「unsigned8"グループ="ipHeader"dataTypeSemantics=が「206」適用性=「データ」elementId=状態=に「旗を揚げさせる」、「現在の「><記述><パラグラフ>If受信者IPアドレスが予約されたマルチキャストアドレスでない、そして、八重奏(予約されたものを含んでいる)のすべてのビットの価値はゼロです」。 IPヘッダーのバージョン分野で値4があって、Destination Address分野が224.0からの範囲の予約されたマルチキャストアドレスを含むなら1番目が噛み付いたこの八重奏の</パラグラフ><パラグラフ>が1に用意ができている、.0、.0、239.255 .255 .255。 さもなければ、このビットは0に設定されます。 </パラグラフ><は>について短い記事を書きます。この八重奏の2番目と3番目のビットは未来の使用のために予約されます。 </パラグラフ><は>について短い記事を書きます。八重奏の残っているビットはIP Destination Addressが予約されたIPv6マルチキャストアドレスである場合にだけゼロ以外の値に設定されます。 次に、八重奏の4番目のビットはIPv6マルチキャストアドレスのT旗の値に設定されます、そして、残っている4ビットはIPv6マルチキャストアドレスの範囲分野の値に設定されます。 </パラグラフ><アートワーク>0 1 2 3 4 5 6 7+------+------+------+------+------+------+------+------+ | MCv4| RES。 | RES。 | T| IPv6マルチキャスト範囲|
Quittek, et al. Standards Track [Page 108] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[108ページ]。
+------+------+------+------+------+------+------+------+
+------+------+------+------+------+------+------+------+
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>
ビット0: IPv4マルチキャストBits1-2であるなら1にセットしてください: 未来に予約されて、Bit4を使用してください: IPv6マルチキャストBits4-7であるならTの値に旗を設定してください: IPv6マルチキャスト</アートワーク></記述><参照><であるならマルチキャスト範囲の値に設定されて、予約されたIPv4マルチキャストアドレスの仕様のために>See RFC1112について短い記事を書いてください。 予約されたIPv6マルチキャストアドレスの仕様とT旗とIPv6マルチキャスト範囲の定義に関してRFC4291を見てください。 </パラグラフ></参照></分野>。
<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>
<フィールド名="fragmentIdentification"dataTypeが「unsigned32"グループ="ipHeader"dataTypeSemantics=「識別子」elementId=「54インチの適用性=」データ」状態=と等しい、「「><記述><はそれぞれIdentificationの値がIPv4パケットのヘッダーかIPv6 Fragmentヘッダーでさばく>について短い記事を書きます」現在の。 断片ヘッダーが全くなければ、値はIPv6のための0です。 </パラグラフ></記述><参照><はIPv4 Identification分野の定義のために>See RFC791について短い記事を書きます。 IPv6 FragmentヘッダーとのIdentification分野の定義に関してRFC2460を見てください。 </パラグラフ></参照></分野>。
<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
<フィールド名="fragmentOffset"dataTypeが等しい、「unsigned16"グループ="ipHeader"dataTypeSemanticsが「」 88インチの適用性=すべて」という「識別子」elementId=状態=と等しい、「現在、「IP断片オフセットの値が中でさばく><記述><パラグラフ>、」
Quittek, et al. Standards Track [Page 109] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[109ページ]。
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>
それぞれIPv4パケットのヘッダーかIPv6 Fragmentヘッダー 断片ヘッダーが全くなければ、値はIPv6のための0です。 断片の仕様のための>See RFC791がIPv4ヘッダーで相殺する</パラグラフ></記述><参照><パラグラフ。 断片の仕様のためのRFC2460がIPv6 Fragmentヘッダーで相殺するのを見てください。 </パラグラフ></参照></分野>。
<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>
<フィールド名=「fragmentFlags」dataTypeが等しい、「unsigned8"グループ="ipHeader"dataTypeSemantics=が「all」のelementId=「197」適用性=状態=に「旗を揚げさせる」、「現在の「IPv4パケットのヘッダーかIPv6 Fragmentヘッダーで旗でそれぞれ示された><記述><パラグラフ>Fragmentationの特性。」 </パラグラフ><アートワーク>。
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 = 5月の断片、1=は断片化しません。 IPv4ヘッダーのDF旗の値に対応しています。 「断片化しないでください」という特徴がIPv6に紹介されないと、いつもIPv6のための0でしょう。 ビット2: (mf) 0 = 最後に断片化してください、そして、1は、より多くの断片と等しいです。 IPv6 FragmentヘッダーでそれぞれIPv4ヘッダーのMF旗、または、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>
0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | R| D| M| D| D| D| D| D| | S| F| F| C| C| C| C| C| +---+---+---+---+---+---+---+---+ </アートワーク></記述>。
Quittek, et al. Standards Track [Page 110] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[110ページ]。
<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の仕様のための>See RFC791が断片化する<参照><パラグラフは弛みます。 IPv6 Fragmentヘッダーの仕様に関してRFC2460を見てください。 </パラグラフ></参照></分野>。
<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>
<フィールド名="ipHeaderLength"dataTypeが等しい、「unsigned8"グループ="ipHeader"elementId=「189」適用性が「all」の状態=と等しい、「現在の「IPヘッダーの長さの><記述><パラグラフ>。」 IPv6に関しては、この情報Elementの値は40です。 </パラグラフ></記述><参照><はIPv4ヘッダーの仕様のために>See RFC791について短い記事を書きます。 IPv6ヘッダーの仕様に関してRFC2460を見てください。 </パラグラフ></参照><ユニット>八重奏</ユニット></分野>。
<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>
<フィールド名="ipv4IHL"dataTypeが等しい、「unsigned8"グループ="ipHeader"elementId=「207」適用性が「all」の状態=と等しい、「現在の「インターネットHeader Length(IHL)の値がIPv4ヘッダーでさばく><記述><パラグラフ>。」 それは4つの八重奏のユニットのヘッダーの長さを指定します。 ユニットは長さの値を報告するもう片方のInformation Elementsの大部分と異なっています。 </パラグラフ></記述><参照><はIPv4ヘッダーの仕様のために>See RFC791について短い記事を書きます。 </パラグラフ></参照>。
Quittek, et al. Standards Track [Page 111] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[111ページ]。
<units>4 octets</units>
</field>
<ユニット>4八重奏</ユニット></分野>。
<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>
><記述><は>について短い記事を書きます。<フィールド名=、「totalLengthIPv4" dataTypeが等しい、「unsigned16"グループ="ipHeader"elementId=「190」適用性が「all」の状態=と等しい、「現在、「IPv4パケットの全長、」 </パラグラフ></記述><参照><はIPv4の仕様のために>See RFC791について短い記事を書きます。全長。 </パラグラフ></参照><ユニット>八重奏</ユニット></分野>。
<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>
<フィールド名="ipTotalLength"dataTypeが等しい、「unsigned64"グループ="ipHeader"elementId=「224」適用性が「all」の状態=と等しい、「現在、「><記述><パラグラフ>、IPパケットの全長、」 </パラグラフ></記述><参照><はIPv4の仕様のために>See RFC791について短い記事を書きます。全長。 IPv6ペイロード長の仕様に関してRFC2460を見てください。 IPv6のジャンボなペイロード長の仕様に関してRFC2675を見てください。 </パラグラフ></参照><ユニット>八重奏</ユニット></分野>。
<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
<フィールド名=、「payloadLengthIPv6" dataTypeが等しい、「unsigned16"グループ="ipHeader"elementId=「191」適用性が「all」の状態=と等しい、「「><記述><パラグラフ>This情報ElementはIPv6ヘッダーの有効搭載量Length分野について値を報告します」現在の。 そのIPv6拡張子に注意してください。
Quittek, et al. Standards Track [Page 112] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[112ページ]。
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>
ヘッダーはペイロードに属します。 また、ジャンボなペイロードオプションの場合のIPv6ヘッダーの有効搭載量Length分野の値がゼロであり、この情報Elementによって報告された値もそうになることに注意してください。 </パラグラフ></記述><参照><はIPv6ペイロード長の仕様のために>See RFC2460について短い記事を書きます。 IPv6のジャンボなペイロードオプションの仕様に関してRFC2675を見てください。 </パラグラフ></参照><ユニット>八重奏</ユニット></分野>。
<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>
><記述><は>について短い記事を書きます。<フィールド名="sourceTransportPort"dataTypeが等しい、「unsigned16"グループ="transportHeader"dataTypeSemanticsが「」 7インチの適用性=すべて」という「識別子」elementId=状態=と等しい、「現在、「輸送ヘッダーのソースポート識別子、」 トランスポート・プロトコルのUDP、TCP、およびSCTPにおいて、これはそれぞれのヘッダーで与えられたソースポート番号です。 また、この分野は16ビットのソースポート識別子を持っている将来のトランスポート・プロトコルに使用されるかもしれません。 </パラグラフ></記述><参照><はUDPソースポート分野の定義のために>See RFC768について短い記事を書きます。 TCPソースポート分野の定義に関してRFC793を見てください。 SCTPの定義に関してRFC4960を見てください。 http://www.iana.org/assignments/port-numbers で定義されたUDPとTCPポートナンバーの</パラグラフ><パラグラフ>Additional情報を見つけることができます。 </パラグラフ></参照></分野>。
<field name="destinationTransportPort" dataType="unsigned16"
group="transportHeader"
dataTypeSemantics="identifier"
"destinationTransportPort"データ型式=「unsigned16"グループ="transportHeader"dataTypeSemantics=「識別子」」という<フィールド名=
Quittek, et al. Standards Track [Page 113] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[113ページ]。
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>
><記述><は>について短い記事を書きます。「elementIdが「11インチの適用性は」 すべてと等しい」という状態=と等しい、「現在、「輸送ヘッダーの仕向港識別子、」 トランスポート・プロトコルのUDP、TCP、およびSCTPのために、これはそれぞれのヘッダーで与えられた目的地ポートナンバーです。 また、この分野は16ビットの仕向港識別子を持っている将来のトランスポート・プロトコルに使用されるかもしれません。 UDP仕向港の定義のための>See RFC768がさばく</パラグラフ></記述><参照><パラグラフ。 TCP仕向港分野の定義に関してRFC793を見てください。 SCTPの定義に関してRFC4960を見てください。 http://www.iana.org/assignments/port-numbers で定義されたUDPとTCPポートナンバーの</パラグラフ><パラグラフ>Additional情報を見つけることができます。 </パラグラフ></参照></分野>。
<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>
<フィールド名="udpSourcePort"dataTypeが等しい、「「識別子」elementId=「180」unsigned16"グループ="transportHeader"dataTypeSemantics=適用性が「all」の状態=と等しい、「現在、「><記述><パラグラフ>、UDPヘッダーのソースポート識別子、」 </パラグラフ></記述><参照><はUDPソースポート分野の定義のために>See RFC768について短い記事を書きます。 http://www.iana.org/assignments/port-numbers で定義されたUDPポートナンバーに関する追加情報を見つけることができます。 </パラグラフ></参照></分野>。
<field name="udpDestinationPort" dataType="unsigned16"
group="transportHeader"
dataTypeSemantics="identifier"
elementId="181" applicability="all" status="current">
<フィールド名="udpDestinationPort"dataTypeが等しい、「「識別子」elementId=「181」unsigned16"グループ="transportHeader"dataTypeSemantics=適用性が「all」の状態=と等しい、「現在の">"
Quittek, et al. Standards Track [Page 114] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[114ページ]。
<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>
<記述><は>について短い記事を書きます。UDPヘッダーの仕向港識別子。 UDP仕向港の定義のための>See RFC768がさばく</パラグラフ></記述><参照><パラグラフ。 http://www.iana.org/assignments/port-numbers で定義されたUDPポートナンバーに関する追加情報を見つけることができます。 </パラグラフ></参照></分野>。
<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>
<フィールド名="udpMessageLength"dataTypeが等しい、「unsigned16"グループ="transportHeader"elementId=「205」適用性が「all」の状態=と等しい、「現在の「Lengthの値がUDPヘッダーでさばく><記述><パラグラフ>。」 </パラグラフ></記述><参照><はUDPヘッダーの仕様のために>See RFC768について短い記事を書きます。 </パラグラフ></参照><ユニット>八重奏</ユニット></分野>。
<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>
<フィールド名="tcpSourcePort"dataTypeが等しい、「「識別子」elementId=「182」unsigned16"グループ="transportHeader"dataTypeSemantics=適用性が「all」の状態=と等しい、「現在、「><記述><パラグラフ>、TCPヘッダーのソースポート識別子、」 </パラグラフ></記述><参照><はTCPソースポート分野の定義のために>See RFC793について短い記事を書きます。 http://www.iana.org/assignments/port-numbers で定義されたTCPポートナンバーに関する追加情報を見つけることができます。 </パラグラフ>。
Quittek, et al. Standards Track [Page 115] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[115ページ]。
</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>
<フィールド名="tcpDestinationPort"dataTypeが等しい、「「識別子」elementId=「183」unsigned16"グループ="transportHeader"dataTypeSemantics=適用性が「all」の状態=と等しい、「現在、「目的地が識別子を移植する><記述><パラグラフ>、TCPヘッダー、」 </パラグラフ></記述><参照><はTCPソースポート分野の定義のために>See RFC793について短い記事を書きます。 http://www.iana.org/assignments/port-numbers で定義されたTCPポートナンバーに関する追加情報を見つけることができます。 </パラグラフ></参照></分野>。
<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>
<フィールド名="tcpSequenceNumber"dataTypeが等しい、「unsigned32"グループ="transportHeader"elementId=「184」適用性が「all」の状態=と等しい、「現在、「><記述><パラグラフ>、TCPヘッダーの一連番号、」 </パラグラフ></記述><参照><はTCP一連番号の定義のために>See RFC793について短い記事を書きます。 </パラグラフ></参照></分野>。
<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>
<フィールド名="tcpAcknowledgementNumber"dataTypeが等しい、「unsigned32"グループ="transportHeader"elementId=「185」適用性が「all」の状態=と等しい、「現在の「承認がTCPヘッダーで付番する><記述><パラグラフ>。」 </パラグラフ></記述><参照><パラグラフ>。
Quittek, et al. Standards Track [Page 116] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[116ページ]。
See RFC 793 for the definition of the TCP
acknowledgement number.
</paragraph>
</reference>
</field>
TCP承認番号の定義に関してRFC793を見てください。 </パラグラフ></参照></分野>。
<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>
<フィールド名="tcpWindowSize"dataTypeが等しい、「unsigned16"グループ="transportHeader"elementId=「186」適用性が「all」の状態=と等しい、「現在の「窓がTCPヘッダーでさばく><記述><パラグラフ>。」 TCP窓のスケールがサポートされるなら、この情報の値を完全に解釈するのをTCP窓のスケールを知らなければなりません。 </パラグラフ></記述><参照><はTCP窓の分野の定義のために>See RFC793について短い記事を書きます。 TCP窓のスケールの定義に関してRFC1323を見てください。 </パラグラフ></参照></分野>。
<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>
<フィールド名="tcpWindowScale"dataTypeが等しい、「unsigned16"グループ="transportHeader"elementId=「238」適用性が「all」の状態=と等しい、「現在の「TCPヘッダーの窓の分野のスケールの><記述><パラグラフ>。」 TCPの窓の定義のための>See RFC1323がスケーリングする</パラグラフ></記述><参照><パラグラフ。 </パラグラフ></参照></分野>。
<field name="tcpUrgentPointer" dataType="unsigned16"
group="transportHeader"
elementId="187" applicability="all" status="current">
<description>
<paragraph>
The urgent pointer in the TCP header.
</paragraph>
</description>
<フィールド名="tcpUrgentPointer"dataTypeが等しい、「unsigned16"グループ="transportHeader"elementId=「187」適用性が「all」の状態=と等しい、「現在、「><記述><パラグラフ>、TCPヘッダーの緊急の指針、」 </パラグラフ></記述>。
Quittek, et al. Standards Track [Page 117] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[117ページ]。
<reference>
<paragraph>
See RFC 793 for the definition of the TCP
urgent pointer.
</paragraph>
</reference>
</field>
<参照><はTCPの緊急の指針の定義のために>See RFC793について短い記事を書きます。 </パラグラフ></参照></分野>。
<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>
<フィールド名="tcpHeaderLength"dataTypeが等しい、「unsigned8"グループ="transportHeader"elementId=「188」適用性が「all」の状態=と等しい、「現在の「TCPヘッダーの長さの><記述><パラグラフ>。」 この情報Elementの値がTCPヘッダーのData Offset分野の値と異なっていることに注意してください。 Data Offset分野は4つの八重奏のユニットのTCPヘッダーの長さを示します。 このInformation Elementsはユニットの八重奏における、TCPヘッダーの長さを指定します。 </パラグラフ></記述><参照><はTCPヘッダーの定義のために>See RFC793について短い記事を書きます。 </パラグラフ></参照><ユニット>八重奏</ユニット></分野>。
<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>
<フィールド名=、「icmpTypeCodeIPv4" dataTypeが等しい、「unsigned16"グループ="transportHeader"dataTypeSemanticsが「」 32インチの適用性=すべて」という「識別子」elementId=状態=と等しい、「現在の「IPv4 ICMPメッセージの><記述><パラグラフの>TypeとCode。」 両方の値の組み合わせは+ (ICMPタイプ*256)ICMPコードとして報告されます。 IPv4 ICMPの定義のための>See RFC792がタイプして、コードがさばく</パラグラフ></記述><参照><パラグラフ。 </パラグラフ></参照></分野>。
Quittek, et al. Standards Track [Page 118] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[118ページ]。
<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>
<フィールド名=、「icmpTypeIPv4" dataTypeが等しい、「「識別子」elementId=「176」unsigned8"グループ="transportHeader"dataTypeSemantics=適用性が「all」の状態=と等しい、「電流「IPv4 ICMPメッセージの><記述><パラグラフ>Type。」 IPv4 ICMPタイプの定義のための>See RFC792がさばく</パラグラフ></記述><参照><パラグラフ。 </パラグラフ></参照></分野>。
<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>
<フィールド名=、「icmpCodeIPv4" dataTypeが等しい、「「識別子」elementId=「177」unsigned8"グループ="transportHeader"dataTypeSemantics=適用性が「all」の状態=と等しい、「電流「IPv4 ICMPメッセージの><記述><パラグラフ>Code。」 IPv4 ICMPコードの定義のための>See RFC792がさばく</パラグラフ></記述><参照><パラグラフ。 </パラグラフ></参照></分野>。
<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.
<フィールド名=、「icmpTypeCodeIPv6" dataTypeが等しい、「「識別子」elementId=「139」unsigned16"グループ="transportHeader"dataTypeSemantics=適用性が「all」の状態=と等しい、「電流「IPv6 ICMPメッセージの><記述><パラグラフの>TypeとCode。」 両方の値の組み合わせは+ (ICMPタイプ*256)ICMPコードとして報告されます。 IPv6 ICMPの定義のための>See RFC4443がタイプして、コードがさばく</パラグラフ></記述><参照><パラグラフ。
Quittek, et al. Standards Track [Page 119] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[119ページ]。
</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>
<フィールド名=、「icmpTypeIPv6" dataTypeが等しい、「「識別子」elementId=「178」unsigned8"グループ="transportHeader"dataTypeSemantics=適用性が「all」の状態=と等しい、「電流「IPv6 ICMPメッセージの><記述><パラグラフ>Type。」 IPv6 ICMPタイプの定義のための>See RFC4443がさばく</パラグラフ></記述><参照><パラグラフ。 </パラグラフ></参照></分野>。
<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>
<フィールド名=、「icmpCodeIPv6" dataTypeが等しい、「「識別子」elementId=「179」unsigned8"グループ="transportHeader"dataTypeSemantics=適用性が「all」の状態=と等しい、「電流「IPv6 ICMPメッセージの><記述><パラグラフ>Code。」 IPv6 ICMPコードの定義のための>See RFC4443がさばく</パラグラフ></記述><参照><パラグラフ。 </パラグラフ></参照></分野>。
<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>
<フィールド名="igmpType"dataTypeが等しい、「unsigned8"グループ="transportHeader"dataTypeSemanticsが「」 33インチの適用性=すべて」という「識別子」elementId=状態=と等しい、「現在の「タイプがさばくIGMPメッセージの><記述><パラグラフ>。」 </パラグラフ></記述><参照>。
Quittek, et al. Standards Track [Page 120] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[120ページ]。
<paragraph>
See RFC 3376 for the definition of the IGMP
type field.
</paragraph>
</reference>
</field>
IGMPタイプの定義のための>See RFC3376がさばく<パラグラフ。 </パラグラフ></参照></分野>。
<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>
「<フィールド名=「sourceMacAddress」dataType=「macAddress」グループ="subIpHeader"dataTypeSemantics=「識別子」elementId=「56インチの適用性=」データ」状態が等しい、「現在の「IEEE802ソースMACアドレスがさばく><記述><パラグラフ>。」 </パラグラフ></記述><参照><パラグラフ>はIEEE.802-3.2002を見ます。 </パラグラフ></参照></分野>。
<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>
><記述><はこの情報Elementの定義が同じである>について短い記事を書きます。「<フィールド名=「postSourceMacAddress」dataType=「macAddress」グループ="subIpHeader"dataTypeSemantics=「識別子」elementId=「81インチの適用性=」データ」状態が等しい、「現在、「パケットの後に情報Element'sourceMacAddress'middlebox機能によって引き起こされた潜在的に変更された値を報告するのを除いて、定義がObservation Pointを渡した、」 </パラグラフ></記述><参照><パラグラフ>はIEEE.802-3.2002を見ます。 </パラグラフ></参照></分野>。
<field name="vlanId" dataType="unsigned16"
group="subIpHeader"
dataTypeSemantics="identifier"
elementId="58" applicability="data" status="current">
<description>
<フィールド名="vlanId"dataTypeが「unsigned16"グループ="subIpHeader"dataTypeSemantics=「識別子」elementId=「58インチの適用性=」データ」状態=と等しい、「電流「><記述>」
Quittek, et al. Standards Track [Page 121] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[121ページ]。
<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>
IEEE 802.1Q VLAN識別子(VID)がIPパケットに付けられたTag Control情報分野から抽出した<パラグラフ>。 </パラグラフ></記述><参照><パラグラフ>はIEEE.802-1Q.2003を見ます。 </パラグラフ></参照></分野>。
<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>
><記述><はこの情報Elementの定義が同じである>について短い記事を書きます。<フィールド名="postVlanId"dataTypeが「unsigned16"グループ="subIpHeader"dataTypeSemantics=「識別子」elementId=「59インチの適用性=」データ」状態=と等しい、「現在、「パケットの後に情報Element'vlanId'middlebox機能によって引き起こされた潜在的に変更された値を報告するのを除いて、定義がObservation Pointを渡した、」 </パラグラフ></記述><参照><パラグラフ>はIEEE.802-1Q.2003を見ます。 </パラグラフ></参照></分野>。
<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>
「<フィールド名=「destinationMacAddress」dataType=「macAddress」グループ="subIpHeader"dataTypeSemantics=「識別子」elementId=「80インチの適用性=」データ」状態が等しい、「現在の「IEEE802送付先MACアドレスがさばく><記述><パラグラフ>。」 </パラグラフ></記述><参照><パラグラフ>はIEEE.802-3.2002を見ます。 </パラグラフ></参照></分野>。
Quittek, et al. Standards Track [Page 122] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[122ページ]。
<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>
><記述><はこの情報Elementの定義が同じである>について短い記事を書きます。「<フィールド名=「postDestinationMacAddress」dataType=「macAddress」グループ="subIpHeader"dataTypeSemantics=「識別子」elementId=「57インチの適用性=」データ」状態が等しい、「現在、「パケットの後に情報Element'destinationMacAddress'middlebox機能によって引き起こされた潜在的に変更された値を報告するのを除いて、定義がObservation Pointを渡した、」 </パラグラフ></記述><参照><パラグラフ>はIEEE.802-3.2002を見ます。 </パラグラフ></参照></分野>。
<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>
<フィールド名="wlanChannelId"dataTypeが等しい、「「識別子」unsigned8"グループ="subIpHeader"dataTypeSemantics=elementIdが「146」適用性=「データ」状態=と等しい、「現在の「802.11(Wi-Fi)チャンネルに関する識別子が使用した><記述><パラグラフ>。」 </パラグラフ></記述><参照><パラグラフ>はIEEE.802-11.1999を見ます。 </パラグラフ></参照></分野>。
<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>
><記述><は>について短い記事を書きます。「ストリング」グループ="subIpHeader"<フィールド名="wlanSSID"dataType=elementIdが「147」適用性=「データ」状態=と等しい、「現在、「802.11(Wi-Fi)ネットワークが使用したService Set IDentifier(SSID)特定、」 IEEE.802-11.1999によると、SSIDは一連の最大32のキャラクタにコード化されます。 </パラグラフ></記述><参照><パラグラフ>。
Quittek, et al. Standards Track [Page 123] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[123ページ]。
See IEEE.802-11.1999.
</paragraph>
</reference>
</field>
IEEE.802-11.1999を見てください。 </パラグラフ></参照></分野>。
<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>
<フィールド名="mplsTopLabelTTL"dataTypeが等しい、「unsigned8"グループ="subIpHeader"elementId=「200」適用性が「all」の状態=と等しい、「現在の「TTLがMPLSがスタックエントリー、すなわち、押された最後のラベルをラベルする先端からさばく><記述><パラグラフ>。」 </パラグラフ></記述><参照><はTTL分野の仕様のために>See RFC3032について短い記事を書きます。 </パラグラフ></参照><ユニット>は</ユニット></分野>を飛び越します。
<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.
<フィールド名="mplsTopLabelExp"dataTypeが等しい、「unsigned8"グループ="subIpHeader"dataTypeSemantics=が「all」のelementId=「203」適用性=状態=に「旗を揚げさせる」、「現在の「ExpがMPLSがスタックエントリー、すなわち、押された最後のラベルをラベルする先端からさばく><記述><パラグラフ>。」 </パラグラフ><アートワーク>ビット0-4: しないでください。Care、値は無関係です。 ビット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>
0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 気にかけないでください。| Exp| +---+---+---+---+---+---+---+---+</アートワーク></記述><参照><はExp分野の仕様のために>See RFC3032について短い記事を書きます。 Exp分野の用法に関してRFC3270を見てください。 </パラグラフ></参照>。
Quittek, et al. Standards Track [Page 124] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[124ページ]。
</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>
><記述><はこの情報Elementの定義が同じである>について短い記事を書きます。<フィールド名="postMplsTopLabelExp"dataTypeが等しい、「unsigned8"グループ="subIpHeader"dataTypeSemantics=が「all」のelementId=「237」適用性=状態=に「旗を揚げさせる」、「現在、「情報Element'mplsTopLabelExpの定義であり、'報告するのを除いて、パケットの後のmiddlebox機能によって引き起こされた潜在的に変更された値はObservation Pointを渡しました」。 </パラグラフ></記述><参照><はExp分野の仕様のために>See RFC3032について短い記事を書きます。 Exp分野の用法に関してRFC3270を見てください。 </パラグラフ></参照></分野>。
<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>
<フィールド名="mplsLabelStackDepth"dataTypeが等しい、「unsigned32"グループ="subIpHeader"elementId=「202」適用性が「all」の状態=と等しい、「現在の「MPLSのラベルの数がスタックとラベルする><記述><パラグラフ>。」 MPLSの仕様のための>See RFC3032がスタックとラベルする</パラグラフ></記述><参照><パラグラフ。 </パラグラフ></参照><ユニット>ラベルスタックエントリー</ユニット></分野>。
<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>
<フィールド名="mplsLabelStackLength"dataTypeが等しい、「unsigned32"グループ="subIpHeader"elementId=「201」適用性が「all」の状態=と等しい、「現在の「ユニットの八重奏における、MPLSラベルスタックの長さの><記述><パラグラフ>。」 </パラグラフ></記述>。
Quittek, et al. Standards Track [Page 125] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[125ページ]。
<reference>
<paragraph>
See RFC 3032 for the specification of
the MPLS label stack.
</paragraph>
</reference>
<units>octets</units>
</field>
MPLSの仕様のための>See RFC3032がスタックとラベルする<参照><パラグラフ。 </パラグラフ></参照><ユニット>八重奏</ユニット></分野>。
<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>
<フィールド名="mplsPayloadLength"dataTypeが等しい、「unsigned32"グループ="subIpHeader"elementId=「194」適用性が「all」の状態=と等しい、「現在の「ラベルスタックのないMPLSパケットのサイズの><記述><パラグラフ>。」 </パラグラフ></記述><参照><はMPLSパケットの仕様のために>See RFC3031について短い記事を書きます。 MPLSラベルスタックの仕様に関してRFC3032を見てください。 </パラグラフ></参照><ユニット>八重奏</ユニット></分野>。
<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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
「"octetArray"グループ="subIpHeader"<フィールド名="mplsTopLabelStackSection"dataType=dataTypeSemanticsが「」 70インチの適用性=すべて」という「識別子」elementId=状態=と等しい、「現在の「Label、Exp、およびすなわち、先頭のMPLSラベルスタックエントリー、最終からのS分野がラベルする押された><記述><パラグラフ>。」 この情報Elementのサイズの</パラグラフ><パラグラフ>は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+++++++++++++++++++++++++| ラベル| Exp|S| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label: Label Value, 20 bits
以下をラベルしてください。 ラベルValue、20ビット
Quittek, et al. Standards Track [Page 126] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[126ページ]。
Exp: Experimental Use, 3 bits
S: Bottom of Stack, 1 bit
</artwork>
</description>
<reference>
<paragraph>
See RFC 3032.
</paragraph>
</reference>
</field>
Exp: 実験的なUse、3ビットS: Stack、1ビットの</アートワーク></記述><参照><パラグラフ>See RFC3032の下部 </パラグラフ></参照></分野>。
<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>
<フィールド名=、「"octetArray"グループ="subIpHeader"mplsLabelStackSection2" dataType=dataTypeSemanticsが「」 71インチの適用性=すべて」という「識別子」elementId=状態=と等しい、「現在の「mplsTopLabelStackSectionによって報告されるラベルスタックエントリーのLabel、Exp、およびSが押されたラベルスタックエントリーからさばく><パラグラフ>に直前><記述。」 さらに詳しい明細についてはmplsTopLabelStackSectionの定義を見てください。 この情報Elementのサイズの</パラグラフ><パラグラフ>は3つの八重奏です。 </パラグラフ></記述><参照><パラグラフ>はRFC3032を見ます。 </パラグラフ></参照></分野>。
<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>
<フィールド名=、「"octetArray"グループ="subIpHeader"mplsLabelStackSection3" dataType=dataTypeSemanticsが「」 72インチの適用性=すべて」という「識別子」elementId=状態=と等しい、「現在の「mplsLabelStackSection2によって報告されるラベルスタックエントリーのLabel、Exp、およびSが押されたラベルスタックエントリーからさばく><パラグラフ>に直前><記述。」 さらに詳しい明細についてはmplsTopLabelStackSectionの定義を見てください。 この情報Elementのサイズの</パラグラフ><パラグラフ>は3つの八重奏です。 </パラグラフ></記述>。
Quittek, et al. Standards Track [Page 127] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[127ページ]。
<reference>
<paragraph>
See RFC 3032.
</paragraph>
</reference>
</field>
<参照><パラグラフ>はRFC3032を見ます。 </パラグラフ></参照></分野>。
<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>
<フィールド名=、「"octetArray"グループ="subIpHeader"mplsLabelStackSection4" dataType=dataTypeSemanticsが「」 73インチの適用性=すべて」という「識別子」elementId=状態=と等しい、「現在の「mplsLabelStackSection3によって報告されるラベルスタックエントリーのLabel、Exp、およびSが押されたラベルスタックエントリーからさばく><パラグラフ>に直前><記述。」 さらに詳しい明細についてはmplsTopLabelStackSectionの定義を見てください。 この情報Elementのサイズの</パラグラフ><パラグラフ>は3つの八重奏です。 </パラグラフ></記述><参照><パラグラフ>はRFC3032を見ます。 </パラグラフ></参照></分野>。
<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>
<フィールド名=、「"octetArray"グループ="subIpHeader"mplsLabelStackSection5" dataType=dataTypeSemanticsが「」 74インチの適用性=すべて」という「識別子」elementId=状態=と等しい、「現在の「mplsLabelStackSection4によって報告されるラベルスタックエントリーのLabel、Exp、およびSが押されたラベルスタックエントリーからさばく><パラグラフ>に直前><記述。」 さらに詳しい明細についてはmplsTopLabelStackSectionの定義を見てください。 この情報Elementのサイズの</パラグラフ><パラグラフ>は3つの八重奏です。 </パラグラフ></記述><参照><パラグラフ>はRFC3032を見ます。 </パラグラフ>。
Quittek, et al. Standards Track [Page 128] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[128ページ]。
</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>
<フィールド名=、「"octetArray"グループ="subIpHeader"mplsLabelStackSection6" dataType=dataTypeSemanticsが「」 75インチの適用性=すべて」という「識別子」elementId=状態=と等しい、「現在の「mplsLabelStackSection5によって報告されるラベルスタックエントリーのLabel、Exp、およびSが押されたラベルスタックエントリーからさばく><パラグラフ>に直前><記述。」 さらに詳しい明細についてはmplsTopLabelStackSectionの定義を見てください。 この情報Elementのサイズの</パラグラフ><パラグラフ>は3つの八重奏です。 </パラグラフ></記述><参照><パラグラフ>はRFC3032を見ます。 </パラグラフ></参照></分野>。
<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>
<フィールド名=、「"octetArray"グループ="subIpHeader"mplsLabelStackSection7" dataType=dataTypeSemanticsが「」 76インチの適用性=すべて」という「識別子」elementId=状態=と等しい、「現在の「mplsLabelStackSection6によって報告されるラベルスタックエントリーのLabel、Exp、およびSが押されたラベルスタックエントリーからさばく><パラグラフ>に直前><記述。」 さらに詳しい明細についてはmplsTopLabelStackSectionの定義を見てください。 この情報Elementのサイズの</パラグラフ><パラグラフ>は3つの八重奏です。 </パラグラフ></記述><参照><パラグラフ>はRFC3032を見ます。 </パラグラフ></参照></分野>。
<field name="mplsLabelStackSection8" dataType="octetArray"
<フィールド名=「mplsLabelStackSection8"データ型式="octetArray"」
Quittek, et al. Standards Track [Page 129] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[129ページ]。
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>
「グループ="subIpHeader"dataTypeSemanticsが「」 77インチの適用性=すべて」という「識別子」elementId=状態=と等しい、「現在の「mplsLabelStackSection7によって報告されるラベルスタックエントリーのLabel、Exp、およびSが押されたラベルスタックエントリーからさばく><パラグラフ>に直前><記述。」 さらに詳しい明細についてはmplsTopLabelStackSectionの定義を見てください。 この情報Elementのサイズの</パラグラフ><パラグラフ>は3つの八重奏です。 </パラグラフ></記述><参照><パラグラフ>はRFC3032を見ます。 </パラグラフ></参照></分野>。
<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>
<フィールド名=、「"octetArray"グループ="subIpHeader"mplsLabelStackSection9" dataType=dataTypeSemanticsが「」 78インチの適用性=すべて」という「識別子」elementId=状態=と等しい、「現在の「mplsLabelStackSection8によって報告されるラベルスタックエントリーのLabel、Exp、およびSが押されたラベルスタックエントリーからさばく><パラグラフ>に直前><記述。」 さらに詳しい明細についてはmplsTopLabelStackSectionの定義を見てください。 この情報Elementのサイズの</パラグラフ><パラグラフ>は3つの八重奏です。 </パラグラフ></記述><参照><パラグラフ>はRFC3032を見ます。 </パラグラフ></参照></分野>。
<field name="mplsLabelStackSection10" dataType="octetArray"
group="subIpHeader"
dataTypeSemantics="identifier"
elementId="79" applicability="all" status="current">
<description>
<フィールド名=、「"octetArray"グループ="subIpHeader"mplsLabelStackSection10" dataType=dataTypeSemanticsが「」 79インチの適用性=すべて」という「識別子」elementId=状態=と等しい、「電流「><記述>」
Quittek, et al. Standards Track [Page 130] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[130ページ]。
<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>
ラベルスタックエントリーのLabel、Exp、およびSが押されたラベルスタックエントリーからさばく<パラグラフ>に直前、それはmplsLabelStackSection9によって報告されるでしょう。 さらに詳しい明細についてはmplsTopLabelStackSectionの定義を見てください。 この情報Elementのサイズの</パラグラフ><パラグラフ>は3つの八重奏です。 </パラグラフ></記述><参照><パラグラフ>はRFC3032を見ます。 </パラグラフ></参照></分野>。
<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.
「"ipPayloadLength"dataType=「unsigned32"グループ=」が引き出した<フィールド名=」elementId=「204」適用性が「all」の状態=と等しい、「電流「IPペイロードの有効長の><記述><パラグラフ>。」 </パラグラフ><パラグラフ>For IPv4パケットであり、この情報Elementの値はIPv4パケット(情報Element totalLengthIPv4によって報告されるように)の全長とIPv4ヘッダーの長さの違い(情報Element headerLengthIPv4によって報告されるように)です。 </パラグラフ><パラグラフ>For IPv6、そこのこの分野の値がゼロとそれでありIPv6ヘッダーのLength分野が報告される有効搭載量の値は有効なジャンボなペイロードオプションです。 この場合、ジャンボなペイロードオプションにおける、Jumbo有効搭載量Length分野の値は報告されます。 </パラグラフ></記述><参照><はIPv4パケットの仕様のために>See RFC791について短い記事を書きます。 IPv6ペイロード長の仕様に関してRFC2460を見てください。 IPv6のジャンボなペイロード長の仕様に関してRFC2675を見てください。
Quittek, et al. Standards Track [Page 131] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[131ページ]。
</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>
「<フィールド名=「ipNextHopIPv4Address」dataType=「ipv4Address」グループ=「派生している」dataTypeSemantics=「識別子」elementId=「15インチの適用性=」データ」状態が等しい、「現在の「IPv4が記述する次のIPv4ホップの><記述><パラグラフ>。」 </パラグラフ></記述></分野>。
<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>
「<フィールド名=「ipNextHopIPv6Address」dataType=「ipv6Address」グループ=「派生している」dataTypeSemantics=「識別子」elementId=「62インチの適用性=」データ」状態が等しい、「現在の「IPv6が記述する次のIPv6ホップの><記述><パラグラフ>。」 </パラグラフ></記述></分野>。
<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>
「"bgpSourceAsNumber"dataType=「unsigned32"グループ=」が引き出した<フィールド名=」dataTypeSemanticsが「」 16インチの適用性=すべて」という「識別子」elementId=状態=と等しい、「現在の「自律システム(AS)が付番するソースIPアドレスの><記述><パラグラフ>。」 単に順不同のASがセットしたので(そして、どんな規則正しいAS系列としても、そうしません)このFlowのためのAS経路情報が利用可能であるなら、この情報Elementの値は0です。 </パラグラフ></記述><参照><はBGP-4の記述のために>See RFC4271について短い記事を書いて、AS番号の定義に関してRFC1930を見ます。 </パラグラフ></参照></分野>。
<field name="bgpDestinationAsNumber" dataType="unsigned32"
<フィールド名="bgpDestinationAsNumber"データ型式="unsigned32""
Quittek, et al. Standards Track [Page 132] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[132ページ]。
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>
「グループ=が「」 17インチの適用性=すべて」という「識別子」elementId=dataTypeSemantics=状態=を「派生した」、「現在の「自律システム(AS)が付番する送付先IPアドレスの><記述><パラグラフ>。」 単に順不同のASがセットしたので(そして、どんな規則正しいAS系列としても、そうしません)このFlowのためのAS経路情報が利用可能であるなら、この情報Elementの値は0です。 </パラグラフ></記述><参照><はBGP-4の記述のために>See RFC4271について短い記事を書いて、AS番号の定義に関してRFC1930を見ます。 </パラグラフ></参照></分野>。
<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>
「識別子」elementId=「128」「"bgpNextAdjacentAsNumber"dataType=「unsigned32"グループ=」が引き出した<フィールド名=」dataTypeSemantics=適用性が「all」の状態=と等しい、「現在の「自律システム(AS)が付番する送付先IPアドレスへのAS経路における最初のASの><記述><パラグラフ>。」 経路は、BGPルーティング情報ベースの中でFlowの送付先IPアドレスを調べることによって、推論されます。 単に順不同のASがセットしたので(そして、どんな規則正しいAS系列としても、そうしません)このFlowのためのAS経路情報が利用可能であるなら、この情報Elementの値は0です。 </パラグラフ></記述><参照><はBGP-4の記述のために>See RFC4271について短い記事を書いて、AS番号の定義に関してRFC1930を見ます。 </パラグラフ></参照></分野>。
<field name="bgpPrevAdjacentAsNumber" dataType="unsigned32"
group="derived"
dataTypeSemantics="identifier"
elementId="129" applicability="all" status="current">
<description>
<paragraph>
「識別子」elementId=「129」「"bgpPrevAdjacentAsNumber"dataType=「unsigned32"グループ=」が引き出した<フィールド名=」dataTypeSemantics=適用性が「all」の状態=と等しい、「電流「><記述><パラグラフ>」
Quittek, et al. Standards Track [Page 133] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[133ページ]。
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>
ソースIPアドレスからのAS経路の最後のASの自律システム(AS)番号。 経路は、BGPルーティング情報ベースの中でFlowのソースIPアドレスを調べることによって、推論されます。 単に順不同のASがセットしたので(そして、どんな規則正しいAS系列としても、そうしません)このFlowのためのAS経路情報が利用可能であるなら、この情報Elementの値は0です。 BGP非対称の場合には、bgpPrevAdjacentAsNumberは正しい値を報告できないかもしれません。 </パラグラフ></記述><参照><はBGP-4の記述のために>See RFC4271について短い記事を書いて、AS番号の定義に関してRFC1930を見ます。 </パラグラフ></参照></分野>。
<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>
「グループ=が「派生した」「bgpNextHopIPv4Address」dataType=「ipv4Address」という<フィールド名=dataTypeSemanticsが「」 18インチの適用性=すべて」という「識別子」elementId=状態=と等しい、「現在の「IPv4が記述する次の(隣接する)のBGPホップの><記述><パラグラフ>。」 </パラグラフ></記述><参照><はBGP-4の記述のために>See RFC4271について短い記事を書きます。 </パラグラフ></参照></分野>。
<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>
「グループ=が「派生した」「bgpNextHopIPv6Address」dataType=「ipv6Address」という<フィールド名=dataTypeSemanticsが「」 63インチの適用性=すべて」という「識別子」elementId=状態=と等しい、「現在の「IPv6が記述する次の(隣接する)のBGPホップの><記述><パラグラフ>。」 </パラグラフ></記述><参照><はBGP-4の記述のために>See RFC4271について短い記事を書きます。 </パラグラフ>。
Quittek, et al. Standards Track [Page 134] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[134ページ]。
</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>
「<フィールド名="mplsTopLabelType"dataType=「unsigned8"グループ=」は「46インチの適用性=」「識別子」」 dataTypeSemantics=elementId=データを引き出した」という状態が等しい、「現在、「>Thisがさばく><記述><パラグラフはスタックの先端ラベルを割り当てた制御プロトコルを特定します」。 この分野への初期の値は以下に記載されています。 さらなる値はMPLSラベル形式登録のIANAによって割り当てられるかもしれません。 </パラグラフ><アートワーク>--0×01Te-MIDPT: どんなTEのトンネルの中間のポイントやテールラベルも--0×02Pseudowire: どんなPWE3やシスコのAToMのベースのラベルも--0×03VPN: VPNに関連しているどんなラベルも--0×04BGP: BGPかBGPルーティングに関連しているどんなラベルも--0×05 自由民主党、: どんなラベルもMPLSラベル構造のために自由民主党</アートワーク></記述><参照><パラグラフを使用するダイナミックに割り当てられたラベルに>See RFC3031を関連づけました。 Virtual兵士のNetworks(VPNs)があるMPLSラベルの協会のためにRFC4364を見てください。 BGPとBGPルーティングに関してRFC4271を見てください。 ラベル分配プロトコル(自由民主党)に関してRFC5036を見てください。 MPLSラベル形式のリストがIANAによって http://www.iana.org/assignments/mpls-label-values に割り当てられるのを見てください。 </パラグラフ></参照></分野>。
<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>
「<フィールド名=「mplsTopLabelIPv4Address」dataType=「ipv4Address」グループ=「派生している」dataTypeSemantics=「識別子」elementId=「47インチの適用性=」データ」状態が等しい、「現在の「IPv4が記述するMPLSのトップラベルでこのFlowを進めるシステムの><記述><パラグラフ>。」 </パラグラフ></記述><参照><パラグラフ>。
Quittek, et al. Standards Track [Page 135] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[135ページ]。
See RFC 3031 for the association between
MPLS labels and IP addresses.
</paragraph>
</reference>
</field>
MPLSラベルとIPアドレスとの協会のためにRFC3031を見てください。 </パラグラフ></参照></分野>。
<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>
「識別子」グループ=が「派生した」「mplsTopLabelIPv6Address」dataType=「ipv6Address」という<フィールド名=dataTypeSemantics=elementIdが「140」適用性=「データ」状態=と等しい、「現在の「IPv6が記述するMPLSのトップラベルでこのFlowを進めるシステムの><記述><パラグラフ>。」 MPLSの間の協会のための>See RFC3031が分類する</パラグラフ></記述><参照><パラグラフとIPアドレス。 </パラグラフ></参照></分野>。
<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
「"octetArray"という"mplsVpnRouteDistinguisher"という<フィールド名=dataType=グループ=が「」 90インチの適用性=すべて」という「識別子」elementId=dataTypeSemantics=状態=を「派生した」、「現在の「VPNの値がより多くのdistinguisherに発送するVPNルーティングと推進テーブルの対応するエントリーの><記述><パラグラフ>。」 ルートdistinguisherは数個の異なったMPLS VPNsで同じアドレスを使用できて、BGPが数個の完全に異なったルートをそのアドレスまで運ぶのが、可能であることを確実にします、各VPNあたり1つ。 RFC4364によると、mplsVpnRouteDistinguisherのサイズは8つの八重奏です。 しかしながら、RFC4382年に、フレキシブルな長さがある八重奏ストリングは物のMplsL3VpnRouteDistinguisherによってVPNルートdistinguisherを表すのに選ばれました。 サイズの将来の変化に開かれるようにこの選択をしました。 この情報Elementのための抽象データ型としてoctetArrayを選ぶとき、この考えは採用されました。 この情報Elementの最大の長さは256の八重奏です。 </パラグラフ></記述><参照><はルートの仕様のために>See RFC4364について短い記事を書きます。
Quittek, et al. Standards Track [Page 136] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[136ページ]。
distinguisher. See RFC 4382 for the specification
of the MPLS/BGP Layer 3 Virtual Private Network (VPN)
Management Information Base.
</paragraph>
</reference>
</field>
distinguisher。 MPLS/BGP Layer3Virtual兵士のNetwork(VPN)管理Information基地の仕様に関してRFC4382を見てください。 </パラグラフ></参照></分野>。
<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>
<フィールド名="minimumIpTotalLength"dataTypeが等しい、「unsigned64"グループ="minMax"elementIdが「25インチの適用性は」 すべてと等しい」という状態=と等しい、「「最も小さいパケットの><記述><パラグラフ>LengthはこのFlowに関して見ました」現在の。 パケット長はIPヘッダーの長さとIPペイロード長を含んでいます。 </パラグラフ></記述><参照><はIPv4の仕様のために>See RFC791について短い記事を書きます。全長。 IPv6ペイロード長の仕様に関してRFC2460を見てください。 IPv6のジャンボなペイロード長の仕様に関してRFC2675を見てください。 </パラグラフ></参照><ユニット>八重奏</ユニット></分野>。
<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.
<フィールド名="maximumIpTotalLength"dataTypeが等しい、「unsigned64"グループ="minMax"elementIdが「26インチの適用性は」 すべてと等しい」という状態=と等しい、「「最も大きいパケットの><記述><パラグラフ>LengthはこのFlowに関して見ました」現在の。 パケット長はIPヘッダーの長さとIPペイロード長を含んでいます。 </パラグラフ></記述><参照><はIPv4の仕様のために>See RFC791について短い記事を書きます。全長。 IPv6ペイロード長の仕様に関してRFC2460を見てください。 IPv6のジャンボなペイロード長の仕様に関してRFC2675を見てください。
Quittek, et al. Standards Track [Page 137] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[137ページ]。
</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>
<フィールド名="minimumTTL"dataTypeが「unsigned8"グループ="minMax"elementId=「52インチの適用性=」データ」状態=と等しい、「「>Minimum TTLが評価する><記述><パラグラフはこのFlowのどんなパケットのためにも見ました」現在の。 LiveへのIPv4 Timeの定義のための>See RFC791がさばく</パラグラフ></記述><参照><パラグラフ。 IPv6 Hop Limit分野の定義に関してRFC2460を見てください。 </パラグラフ></参照><ユニット>は</ユニット></分野>を飛び越します。
<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>
<フィールド名="maximumTTL"dataTypeが「unsigned8"グループ="minMax"elementId=「53インチの適用性=」データ」状態=と等しい、「「>Maximum TTLが評価する><記述><パラグラフはこのFlowのどんなパケットのためにも見ました」現在の。 LiveへのIPv4 Timeの定義のための>See RFC791がさばく</パラグラフ></記述><参照><パラグラフ。 IPv6 Hop Limit分野の定義に関してRFC2460を見てください。 </パラグラフ></参照><ユニット>は</ユニット></分野>を飛び越します。
<field name="ipv4Options" dataType="unsigned32"
dataTypeSemantics="flags"
group="minMax"
elementId="208" applicability="all" status="current">
<description>
「208」の「<フィールド名=「ipv4Options」dataTypeは「unsigned32" dataTypeSemantics=」旗と等しく」グループ="minMax"elementId=適用性が「all」の状態=と等しい、「電流「><記述>」
Quittek, et al. Standards Track [Page 138] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[138ページ]。
<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 | ...
+------+------+------+------+------+------+------+------+
このFlowのパケットの<パラグラフ>IPv4オプション。 情報は噛み付いている分野のセットでコード化されます。 それぞれの有効なIPv4オプションタイプのために、セットがこれに少しあります。 このFlowのどれか観測されたパケットが対応するIPv4オプションタイプを含んでいるなら、ビットは1に設定されます。 さもなければ、このFlowのどんな観測されたパケットもそれぞれのIPv4オプションタイプを含まなかったなら、対応するビットの価値は0です。 有効なIPv4のリストがゆだねる</パラグラフ><パラグラフ>はIANAによって維持されます。 オプションを特定すると、ちょうどIPv4オプションのしかし、Option Number、Option Typeのすべての8ビットが合わせる必要がある5ビット1つが http://www.iana.org/assignments/ip-parameters で指定したというわけではないことに注意してください。 それらのオプション番号によると、</パラグラフ><パラグラフ>Optionsはビットに写像されます。 オプション番号XはビットX.に写像されます。マッピングは以下の図によって例証されます。 </パラグラフ><アートワーク>0 1 2 3 4 5 6 7+------+------+------+------+------+------+------+------+ | EOOL| NOP| SEC| LSR| t|電子SEC|CIPSO| RR| ... +------+------+------+------+------+------+------+------+
8 9 10 11 12 13 14 15
+------+------+------+------+------+------+------+------+
... | SID | SSR | ZSU | MTUP | MTUR | FINN | VISA |ENCODE| ...
+------+------+------+------+------+------+------+------+
8 9 10 11 12 13 14 15 +------+------+------+------+------+------+------+------+ ... | シド| SSR| ZSU| MTUP| MTUR| フィンランド人| ビザ|エンコード| ... +------+------+------+------+------+------+------+------+
16 17 18 19 20 21 22 23
+------+------+------+------+------+------+------+------+
... |IMITD | EIP | TR |ADDEXT|RTRALT| SDB |NSAPA | DPS | ...
+------+------+------+------+------+------+------+------+
16 17 18 19 20 21 22 23 +------+------+------+------+------+------+------+------+ ... |IMITD| EIP| TR|ADDEXT|RTRALT| SDB|NSAPA| 毎秒壊変数| ... +------+------+------+------+------+------+------+------+
24 25 26 27 28 29 30 31
+------+------+------+------+------+------+------+------+
... | UMP | QS | to be assigned by IANA | EXP | |
+------+------+------+------+------+------+------+------+
24 25 26 27 28 29 30 31 +------+------+------+------+------+------+------+------+ ... | UMP| QS| IANAによって割り当てられるように| EXP| | +------+------+------+------+------+------+------+------+
Type Option
Bit Value Name Reference
---+-----+-------+------------------------------------
0 0 EOOL End of Options List, RFC 791
1 1 NOP No Operation, RFC 791
オプションビット値の名前参照をタイプしてください。---+-----+-------+------------------------------------ オプションリストの0 0EOOLエンド、RFC791 1 1NOPいいえ操作、RFC791
Quittek, et al. Standards Track [Page 139] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[139ページ]。
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
2 130 SECセキュリティ、RFC1108 3の131のLSRのゆるい送信元経路、RFC791 4の68tのタイムスタンプ、133RFC791 5電子秒拡張しているセキュリティ、セキュリティ7 7のRRの記録的なルート、RFC1108 6 134CIPSOコマーシャルRFC791 8 136SID Stream ID、RFC791 9の137のSSRの厳しい送信元経路、RFC791 10 10のZSUの実験的な測定11 11MTUP(時代遅れにされる)MTUは調べます、RFC1191 12 12MTUR(時代遅れにされる)MTU回答; RFC1191 13 205フィンランド人実験フロー制御14 142のビザの実験用アクセス管理15 15エンコード16 144IMITD IMI交通記述子17 145EIPはインターネットプロトコルを広げました、RFC、1385 18、82兆トレースルート、RFC3193 19 147ADDEXTが拡大20 148RTRALTルータ警戒(RFC2113 21 149SDB選択している指示された放送22 150NSAPA NSAPアドレス23 151の毎秒壊変数のダイナミックなパケット州24の152のUMPの上流のマルチキャストPkt)を記述します。 25 25QSクィックスタート30 30EXP RFC3692-スタイル実験30 94EXP RFC3692-スタイル実験30 158EXP RFC3692-スタイル実験30 222EXP RFC3692-スタイル実験… ... ... さらなるオプション番号は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>
</アートワーク></記述><参照><はIPv4オプションの定義のために>See RFC791について短い記事を書きます。 IPv4オプション番号のリストがIANAによって http://www.iana.org/assignments/ip-parameters に割り当てられるのを見てください。 </パラグラフ></参照></分野>。
<field name="ipv6ExtensionHeaders" dataType="unsigned32"
dataTypeSemantics="flags"
group="minMax"
elementId="64" applicability="all" status="current">
<description>
<paragraph>
「<フィールド名=「ipv6ExtensionHeaders」dataTypeは「unsigned32" dataTypeSemantics=」旗と等しく」グループ="minMax"elementIdが「64インチの適用性は」 すべてと等しい」という状態=と等しい、「電流「><記述><パラグラフ>」
Quittek, et al. Standards Track [Page 140] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[140ページ]。
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 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+
IPv6拡張ヘッダーはこのFlowのパケットで見ました。 情報は噛み付いている分野のセットでコード化されます。 それぞれのIPv6オプションヘッダーのために、セットがこれに少しあります。 このFlowのどれか観測されたパケットが対応するIPv6拡張ヘッダーを含むなら、ビットは1に設定されます。 さもなければ、このFlowのどんな観測されたパケットもそれぞれのIPv6拡張ヘッダーを含まなかったなら、対応するビットの価値は0です。 </パラグラフ><アートワーク>0 1 2 3 4 5 6 7+-----+-----+-----+-----+-----+-----+-----+-----+ | Res| FRA1| 右手| FRA0| UNK| Res| ホップ| DST| ... +-----+-----+-----+-----+-----+-----+-----+-----+
8 9 10 11 12 13 14 15
+-----+-----+-----+-----+-----+-----+-----+-----+
... | PAY | AH | ESP | Reserved | ...
+-----+-----+-----+-----+-----+-----+-----+-----+
8 9 10 11 12 13 14 15 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | 賃金| ああ| 超能力| 予約されます。| ... +-----+-----+-----+-----+-----+-----+-----+-----+
16 17 18 19 20 21 22 23
+-----+-----+-----+-----+-----+-----+-----+-----+
... | Reserved | ...
+-----+-----+-----+-----+-----+-----+-----+-----+
24 25 26 27 28 29 30 31
+-----+-----+-----+-----+-----+-----+-----+-----+
... | Reserved |
+-----+-----+-----+-----+-----+-----+-----+-----+
16 17 18 19 20 21 22 23 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | 予約されます。| ... +-----+-----+-----+-----+-----+-----+-----+-----+ 24 25 26 27 28 29 30 31 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | 予約されます。| +-----+-----+-----+-----+-----+-----+-----+-----+
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 Option記述0、Res Reserved1、FRA1 44Fragmentationヘッダー--2は最初に断片化しません、RH43ルート設定ヘッダー3、FRA0 44Fragmentヘッダー--4、UNK Unknown Layer4ヘッダー(圧縮されて、コード化された支持されるのではなく、)5は最初に断片化します、Res Reserved6、HOP0ホップによるHopオプションヘッダー7; DST60Destinationはヘッダー8にゆだねます、PAY108有効搭載量圧縮ヘッダー9、AH51Authentication Header10、11〜31Reserved</アートワーク></記述><参照><が一般的な定義のための>See RFC2460について短い記事を書く超能力50Encryptedセキュリティペイロード
Quittek, et al. Standards Track [Page 141] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[141ページ]。
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>
拡張ヘッダーとホップごとのオプションヘッダーの仕様のためのIPv6、ルーティングヘッダー、断片ヘッダー、および目的地オプションヘッダー。 認証ヘッダーの仕様に関してRFC4302を見てください。 要約のセキュリティペイロードの仕様に関してRFC4303を見てください。 </パラグラフ></参照></分野>。
<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 |
+-----+-----+-----+-----+-----+-----+-----+-----+
「<フィールド名=「tcpControlBits」dataTypeは「unsigned8" dataTypeSemantics=」旗と等しく」グループ="minMax"elementIdが「6インチの適用性は」 すべてと等しい」という状態=と等しい、「現在の「このFlowのパケットのために観察された><記述><パラグラフ>TCPコントロールビット。」 情報は噛み付いている分野のセットでコード化されます。 それぞれのTCPコントロールビットのために、セットがこれに少しあります。 このFlowのどんな観測されたパケットでも対応するTCPコントロールビットを1に設定するなら、1に少し設定されます。 しばらく0の値は、対応するビットがこのFlowの観測されたパケットのいずれにも設定されなかったのを示します。 </パラグラフ><アートワーク>0 1 2 3 4 5 6 7+-----+-----+-----+-----+-----+-----+-----+-----+ | 予約されます。| URG| ACK| PSH| RST| SYN| フィン| +-----+-----+-----+-----+-----+-----+-----+-----+
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>
予約される: 今後の使用のために、TCPによって予約されます。 ゼロにならなければならなくなってください。 URG: 緊急のPointerは重要なACKをさばきます: 承認分野の重要なPSH: 機能RSTを押してください: 接続SYNをリセットしてください: 一連番号FINを連動させてください: 送付者</アートワーク></記述><参照><からのそれ以上のデータはTCPヘッダーとのTCPコントロールビットの定義のために>See RFC793について短い記事を書きません。 </パラグラフ></参照></分野>。
Quittek, et al. Standards Track [Page 142] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[142ページ]。
<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 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+
「209」の「<フィールド名=「tcpOptions」dataTypeは「unsigned64" dataTypeSemantics=」旗と等しく」グループ="minMax"elementId=適用性が「all」の状態=と等しい、「現在の「このFlowのパケットの><記述><パラグラフ>TCPオプション。」 情報は噛み付いている分野のセットでコード化されます。 それぞれのTCPオプションのために、セットがこれに少しあります。 このFlowのどれか観測されたパケットが対応するTCPオプションを含んでいるなら、ビットは1に設定されます。 さもなければ、このFlowのどんな観測されたパケットもそれぞれのTCPオプションを含まなかったなら、対応するビットの価値は0です。 それらのオプション番号によると、</パラグラフ><パラグラフ>Optionsはビットに写像されます。 オプション番号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 |...
+-----+-----+-----+-----+-----+-----+-----+-----+
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 |...
+-----+-----+-----+-----+-----+-----+-----+-----+
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
56 57 58 59 60 61 62 63 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | +-----+-----+-----+-----+-----+-----+-----+-----+ TCPの定義のための>See RFC793がゆだねる</アートワーク></記述><参照><パラグラフ。 TCPオプション番号のリストがIANAによって割り当てられるのを見てください。
Quittek, et al. Standards Track [Page 143] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[143ページ]。
at http://www.iana.org/assignments/tcp-parameters.
</paragraph>
</reference>
</field>
http://www.iana.org/assignments/tcp-parameters で。 </パラグラフ></参照></分野>。
<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>
><記述><は>について短い記事を書きます。「dateTimeSeconds」グループ=「タイムスタンプ」<フィールド名=「flowStartSeconds」dataType=elementIdが「150」適用性=「データ」状態=と等しい、「現在、「このFlowの最初のパケットの絶対タイムスタンプ、」 </パラグラフ></記述><ユニット>秒</単位></分野>。
<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>
><記述><は>について短い記事を書きます。「dateTimeSeconds」グループ=「タイムスタンプ」<フィールド名=「flowEndSeconds」dataType=elementIdが「151」適用性=「データ」状態=と等しい、「現在、「このFlowの最後のパケットの絶対タイムスタンプ、」 </パラグラフ></記述><ユニット>秒</単位></分野>。
<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>
><記述><は>について短い記事を書きます。「dateTimeMilliseconds」グループ=「タイムスタンプ」<フィールド名=「flowStartMilliseconds」dataType=elementIdが「152」適用性=「データ」状態=と等しい、「現在、「このFlowの最初のパケットの絶対タイムスタンプ、」 </パラグラフ></記述><ユニット>ミリセカンド</ユニット></分野>。
<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>
><記述><は>について短い記事を書きます。「dateTimeMilliseconds」グループ=「タイムスタンプ」<フィールド名=「flowEndMilliseconds」dataType=elementIdが「153」適用性=「データ」状態=と等しい、「現在、「このFlowの最後のパケットの絶対タイムスタンプ、」 </パラグラフ></記述><ユニット>ミリセカンド</ユニット></分野>。
Quittek, et al. Standards Track [Page 144] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[144ページ]。
<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>
><記述><は>について短い記事を書きます。「dateTimeMicroseconds」グループ=「タイムスタンプ」<フィールド名=「flowStartMicroseconds」dataType=elementIdが「154」適用性=「データ」状態=と等しい、「現在、「このFlowの最初のパケットの絶対タイムスタンプ、」 </パラグラフ></記述><ユニット>マイクロセカンド</ユニット></分野>。
<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>
><記述><は>について短い記事を書きます。「dateTimeMicroseconds」グループ=「タイムスタンプ」<フィールド名=「flowEndMicroseconds」dataType=elementIdが「155」適用性=「データ」状態=と等しい、「現在、「このFlowの最後のパケットの絶対タイムスタンプ、」 </パラグラフ></記述><ユニット>マイクロセカンド</ユニット></分野>。
<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>
><記述><は>について短い記事を書きます。「dateTimeNanoseconds」グループ=「タイムスタンプ」<フィールド名=「flowStartNanoseconds」dataType=elementIdが「156」適用性=「データ」状態=と等しい、「現在、「このFlowの最初のパケットの絶対タイムスタンプ、」 </パラグラフ></記述><ユニット>数ナノ秒</ユニット></分野>。
<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>
><記述><は>について短い記事を書きます。「dateTimeNanoseconds」グループ=「タイムスタンプ」<フィールド名=「flowEndNanoseconds」dataType=elementIdが「157」適用性=「データ」状態=と等しい、「現在、「このFlowの最後のパケットの絶対タイムスタンプ、」 </パラグラフ></記述><ユニット>数ナノ秒</ユニット></分野>。
<field name="flowStartDeltaMicroseconds" dataType="unsigned32"
group="timestamp"
elementId="158" applicability="data" status="current">
<description>
「<フィールド名「flowStartDeltaMicroseconds」という=dataType=「unsigned32"グループ=」タイムスタンプ」elementIdが「158」適用性=「データ」状態=と等しい、「電流「><記述>」
Quittek, et al. Standards Track [Page 145] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[145ページ]。
<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>
<パラグラフ>Thisは独身のIPFIX Messageの範囲の中で有効なだけの相対的なタイムスタンプです。 それはIPFIX Message Headerで指定された輸出時間に比例してこのFlowの最初の観測されたパケットの否定的時間オフセットを含んでいます。 </パラグラフ></記述><参照><パラグラフ>See IPFIXはIPFIX Message Headerの定義のための仕様[RFC5101]を議定書の中で述べます。 </パラグラフ></参照><ユニット>マイクロセカンド</ユニット></分野>。
<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>
「<フィールド名「flowEndDeltaMicroseconds」という=dataType=「unsigned32"グループ=」タイムスタンプ」elementIdが「159」適用性=「データ」状態=と等しい、「現在、「><記述><パラグラフ>Thisは独身のIPFIX Messageの範囲の中で有効なだけの相対的なタイムスタンプです」。 それはIPFIX Message Headerで指定された輸出時間に比例してこのFlowの最後に観測されたパケットの否定的時間オフセットを含んでいます。 </パラグラフ></記述><参照><パラグラフ>See IPFIXはIPFIX Message Headerの定義のための仕様[RFC5101]を議定書の中で述べます。 </パラグラフ></参照><ユニット>マイクロセカンド</ユニット></分野>。
<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>
「dateTimeMilliseconds」グループ=「タイムスタンプ」<フィールド名=「systemInitTimeMilliseconds」dataType=elementIdが「160」適用性=「データ」状態=と等しい、「現在、「><記述><パラグラフ>、最終絶対タイムスタンプ、(再、)、IPFIX Deviceの初期化、」 </パラグラフ></記述><ユニット>ミリセカンド</ユニット></分野>。
Quittek, et al. Standards Track [Page 146] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[146ページ]。
<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>
「<フィールド名="flowStartSysUpTime"dataType」 =「unsigned32"グループ=」タイムスタンプelementId=「22インチの適用性=」データ」状態が等しい、「現在、「><記述><パラグラフ>、このFlowの最初のパケットの相対的なタイムスタンプ、」 最終以来のミリセカンドの数を示す、(再、)、IPFIX Device(sysUpTime)の初期化。 </パラグラフ></記述><ユニット>ミリセカンド</ユニット></分野>。
<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>
「<フィールド名="flowEndSysUpTime"dataType」 =「unsigned32"グループ=」タイムスタンプelementId=「21インチの適用性=」データ」状態が等しい、「現在、「><記述><パラグラフ>、このFlowの最後のパケットの相対的なタイムスタンプ、」 最終以来のミリセカンドの数を示す、(再、)、IPFIX Device(sysUpTime)の初期化。 </パラグラフ></記述><ユニット>ミリセカンド</ユニット></分野>。
<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>
<フィールド名="octetDeltaCount"dataTypeが「unsigned64" dataTypeSemantics="deltaCounter"グループ="flowCounter"elementId=「1インチの適用性=」データ」状態=と等しい、「現在の「前以来の八重奏の数がObservation PointのこのFlowのために入って来るパケットで(もしあれば)報告する><記述><パラグラフ>。」 八重奏の数はIPヘッダーとIPペイロードを含んでいます。 </パラグラフ></記述><ユニット>八重奏</ユニット></分野>。
<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
<フィールド名="postOctetDeltaCount"dataTypeが「unsigned64" dataTypeSemantics="deltaCounter"グループ="flowCounter"elementId=「23インチの適用性=」データ」状態=と等しい、「現在、「この情報Elementの定義が同じである><記述><パラグラフ>、情報Elementの定義、」
Quittek, et al. Standards Track [Page 147] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[147ページ]。
'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>
'octetDeltaCount'、報告するのを除いて、パケットの後のmiddlebox機能によって引き起こされた潜在的に変更された値はObservation Pointを渡しました。 </パラグラフ></記述><ユニット>八重奏</ユニット></分野>。
<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>
<フィールド名=「octetDeltaSumOfSquares」dataTypeが等しい、「unsigned64"グループ="flowCounter"elementIdが「198」適用性=「データ」状態=と等しい、「「><記述><はObservation PointのこのFlowのために>について八重奏の二乗された数の予報以来の入って来るパケットあたりの合計(もしあれば)で短い記事を書きます」現在の。 八重奏の数はIPヘッダーとIPペイロードを含んでいます。 </パラグラフ></記述></分野>。
<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>
<フィールド名="octetTotalCount"dataTypeが等しい、「unsigned64" dataTypeSemanticsが= 「85インチの適用性は」 すべてと等しい」という"totalCounter"グループ="flowCounter"elementId状態=と等しい、「現在、「合計が付番するMetering Process以来のObservation PointのこのFlowのための入って来るパケットの八重奏の><記述><パラグラフ>、(再、)、このObservation Pointのための初期化、」 八重奏の数はIPヘッダーとIPペイロードを含んでいます。 </パラグラフ></記述><ユニット>八重奏</ユニット></分野>。
<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>
><記述><はこの情報Elementの定義が同じである>について短い記事を書きます。<フィールド名="postOctetTotalCount"dataTypeが等しい、「"totalCounter"グループ="flowCounter"elementId=「171」unsigned64" dataTypeSemantics=適用性が「all」の状態=と等しい、「現在、「情報Element'octetTotalCountの定義であり、'報告するのを除いて、パケットの後のmiddlebox機能によって引き起こされた潜在的に変更された値はObservation Pointを渡しました」。 </パラグラフ>。
Quittek, et al. Standards Track [Page 148] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[148ページ]。
</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>
<フィールド名=「octetTotalSumOfSquares」dataTypeが等しい、「unsigned64"グループ="flowCounter"elementId=「199」適用性が「all」の状態=と等しい、「現在、「合計がまとめるMetering Process以来のObservation PointのこのFlowのための入って来るパケットの八重奏の二乗された数の><記述><パラグラフ>、(再、)、このObservation Pointのための初期化、」 八重奏の数はIPヘッダーとIPペイロードを含んでいます。 </パラグラフ></記述><ユニット>八重奏</ユニット></分野>。
<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>
<フィールド名="packetDeltaCount"dataTypeが「unsigned64" dataTypeSemantics="deltaCounter"グループ="flowCounter"elementId=「2インチの適用性=」データ」状態=と等しい、「現在の「前以来の入って来るパケットの数がObservation PointのこのFlowのために(もしあれば)報告する><記述><パラグラフ>。」 </パラグラフ></記述><ユニット>パケット</ユニット></分野>。
<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>
><記述><はこの情報Elementの定義が同じである>について短い記事を書きます。<フィールド名="postPacketDeltaCount"dataTypeが「unsigned64" dataTypeSemantics="deltaCounter"グループ="flowCounter"elementId=「24インチの適用性=」データ」状態=と等しい、「現在、「パケットの後に情報Element'packetDeltaCount'middlebox機能によって引き起こされた潜在的に変更された値を報告するのを除いて、定義がObservation Pointを渡した、」 </パラグラフ></記述><ユニット>パケット</ユニット></分野>。
Quittek, et al. Standards Track [Page 149] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[149ページ]。
<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>
<フィールド名="packetTotalCount"dataTypeが等しい、「unsigned64" dataTypeSemanticsが= 「86インチの適用性は」 すべてと等しい」という"totalCounter"グループ="flowCounter"elementId状態=と等しい、「現在、「合計が付番するMetering Process以来のObservation PointのこのFlowのための入って来るパケットの><記述><パラグラフ>、(再、)、このObservation Pointのための初期化、」 </パラグラフ></記述><ユニット>パケット</ユニット></分野>。
<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>
><記述><はこの情報Elementの定義が同じである>について短い記事を書きます。<フィールド名="postPacketTotalCount"dataTypeが等しい、「"totalCounter"グループ="flowCounter"elementId=「172」unsigned64" dataTypeSemantics=適用性が「all」の状態=と等しい、「現在、「情報Element'packetTotalCountの定義であり、'報告するのを除いて、パケットの後のmiddlebox機能によって引き起こされた潜在的に変更された値はObservation Pointを渡しました」。 </パラグラフ></記述><ユニット>パケット</ユニット></分野>。
<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>
<フィールド名="droppedOctetDeltaCount"dataTypeが等しい、「"deltaCounter"グループ="flowCounter"unsigned64" dataTypeSemantics=elementIdが「132」適用性=「データ」状態=と等しい、「現在の「このFlowのパケットの予報(もしあれば)以来の八重奏の数がパケット処理で落とした><記述><パラグラフ>。」 八重奏の数はIPヘッダーとIPペイロードを含んでいます。 </パラグラフ></記述><ユニット>八重奏</ユニット></分野>。
<field name="droppedPacketDeltaCount" dataType="unsigned64"
dataTypeSemantics="deltaCounter"
group="flowCounter"
elementId="133" applicability="data" status="current">
<フィールド名="droppedPacketDeltaCount"dataTypeが等しい、「"deltaCounter"グループ="flowCounter"unsigned64" dataTypeSemantics=elementIdが「133」適用性=「データ」状態=と等しい、「現在の">"
Quittek, et al. Standards Track [Page 150] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[150ページ]。
<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>
このFlowに関する予報(もしあれば)以来のパケットの数がパケット処理で落とした<記述><パラグラフ>。 </パラグラフ></記述><ユニット>パケット</ユニット></分野>。
<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>
<フィールド名="droppedOctetTotalCount"dataTypeが等しい、「"totalCounter"グループ="flowCounter"unsigned64" dataTypeSemantics=elementIdが「134」適用性=「データ」状態=と等しい、「現在、「Metering Process以来このFlowのパケットの八重奏の総数がパケット処理で落とした><記述><パラグラフ>、(再、)、このObservation Pointのための初期化、」 八重奏の数はIPヘッダーとIPペイロードを含んでいます。 </パラグラフ></記述><ユニット>八重奏</ユニット></分野>。
<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>
<フィールド名="droppedPacketTotalCount"dataTypeが等しい、「"totalCounter"グループ="flowCounter"unsigned64" dataTypeSemantics=elementIdが「135」適用性=「データ」状態=と等しい、「現在、「Metering Process以来このFlowのパケットの数がパケット処理で落とした><記述><パラグラフ>、(再、)、このObservation Pointのための初期化、」 </パラグラフ></記述><ユニット>パケット</ユニット></分野>。
<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
<フィールド名="postMCastPacketDeltaCount"dataTypeが「unsigned64" dataTypeSemantics="deltaCounter"グループ="flowCounter"elementId=「19インチの適用性=」データ」状態=と等しい、「現在の「予報(もしあれば)以来の出発しているマルチキャストパケットの数がObservation Domainの中のマルチキャストデーモンによるこのFlowのパケットのために送った><記述><パラグラフ>。」 必ずこの特性を観測できるというわけではありません。
Quittek, et al. Standards Track [Page 151] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[151ページ]。
Observation Point, but may be retrieved by other means.
</paragraph>
</description>
<units>packets</units>
</field>
他の手段で検索されるかもしれないのを除いた観測Point。 </パラグラフ></記述><ユニット>パケット</ユニット></分野>。
<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>
<フィールド名="postMCastOctetDeltaCount"dataTypeが「unsigned64" dataTypeSemantics="deltaCounter"グループ="flowCounter"elementId=「20インチの適用性=」データ」状態=と等しい、「現在の「出発しているマルチキャストパケットの予報(もしあれば)以来の八重奏の数がObservation Domainの中のマルチキャストデーモンによるこのFlowのパケットのために送った><記述><パラグラフ>。」 この特性は、必ずObservation Pointで観測できるというわけではありませんが、他の手段で検索されるかもしれません。 八重奏の数はIPヘッダーとIPペイロードを含んでいます。 </パラグラフ></記述><ユニット>八重奏</ユニット></分野>。
<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>
<フィールド名="postMCastPacketTotalCount"dataTypeが等しい、「"totalCounter"グループ="flowCounter"unsigned64" dataTypeSemantics=elementIdが「174」適用性=「データ」状態=と等しい、「現在、「出発しているマルチキャストパケットの総数がこのFlowのパケットのためにMetering Process以来のObservation Domainの中のマルチキャストデーモンで送った><記述><パラグラフ>、(再、)、初期化、」 この特性は、必ずObservation Pointで観測できるというわけではありませんが、他の手段で検索されるかもしれません。 </パラグラフ></記述><ユニット>パケット</ユニット></分野>。
<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
<フィールド名="postMCastOctetTotalCount"dataTypeが等しい、「"totalCounter"グループ="flowCounter"unsigned64" dataTypeSemantics=elementIdが「175」適用性=「データ」状態=と等しい、「現在、「中の出発しているマルチキャストパケットの八重奏の総数がマルチキャストデーモンによるこのFlowのパケットのために送った><記述><パラグラフ>、」
Quittek, et al. Standards Track [Page 152] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[152ページ]。
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>
計量の過程以来の観測ドメイン、(再、)、初期化。 この特性は、必ずObservation Pointで観測できるというわけではありませんが、他の手段で検索されるかもしれません。 八重奏の数はIPヘッダーとIPペイロードを含んでいます。 </パラグラフ></記述><ユニット>八重奏</ユニット></分野>。
<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>
<フィールド名="tcpSynTotalCount"dataTypeが等しい、「"totalCounter"グループ="flowCounter"unsigned64" dataTypeSemantics=elementIdが「218」適用性=「データ」状態=と等しい、「現在の「合計が付番するTCPとこのFlowのパケットの><記述><パラグラフ>を「一連番号を同期させる」という(SYN)旗のセット。」 TCP SYNの定義のための>See RFC793が旗を揚げさせる</パラグラフ></記述><参照><パラグラフ。 </パラグラフ></参照><ユニット>パケット</ユニット></分野>。
<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>
<フィールド名="tcpFinTotalCount"dataTypeが等しい、「"totalCounter"グループ="flowCounter"unsigned64" dataTypeSemantics=elementIdが「219」適用性=「データ」状態=と等しい、「現在、「TCP「送付者からのそれ以上のデータがありません」(FIN)があるこのFlowのパケットの総数が旗を揚げさせる><記述><パラグラフ>はセットしました」。 TCP FINの定義のための>See RFC793が旗を揚げさせる</パラグラフ></記述><参照><パラグラフ。 </パラグラフ></参照><ユニット>パケット</ユニット></分野>。
<field name="tcpRstTotalCount" dataType="unsigned64"
dataTypeSemantics="totalCounter"
<フィールド名="tcpRstTotalCount"データ型式=「unsigned64" dataTypeSemantics="totalCounter"」
Quittek, et al. Standards Track [Page 153] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[153ページ]。
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>
グループ="flowCounter"elementIdが「220」適用性=「データ」状態=と等しい、「電流「TCPとこのFlowのパケットの総数が(RST)旗の設定していた状態で「接続をリセットした」という><記述><パラグラフ>。」 TCP RSTの定義のための>See RFC793が旗を揚げさせる</パラグラフ></記述><参照><パラグラフ。 </パラグラフ></参照><ユニット>パケット</ユニット></分野>。
<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>
<フィールド名="tcpPshTotalCount"dataTypeが等しい、「"totalCounter"グループ="flowCounter"unsigned64" dataTypeSemantics=elementIdが「221」適用性=「データ」状態=と等しい、「「設定されて、TCPとこのFlowのパケットの総数が「機能を押す」という><記述><パラグラフ>(PSH)は旗を揚げさせる」電流。 TCP PSHの定義のための>See RFC793が旗を揚げさせる</パラグラフ></記述><参照><パラグラフ。 </パラグラフ></参照><ユニット>パケット</ユニット></分野>。
<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>
<フィールド名="tcpAckTotalCount"dataTypeが等しい、「"totalCounter"グループ="flowCounter"unsigned64" dataTypeSemantics=elementIdが「222」適用性=「データ」状態=と等しい、「現在、「TCPが「承認分野重要」のこのFlow(ACK)のパケットの総数が旗を揚げさせる><記述><パラグラフ>はセットしました」。 TCP ACKの定義のための>See RFC793が旗を揚げさせる</パラグラフ></記述><参照><パラグラフ。 </パラグラフ>。
Quittek, et al. Standards Track [Page 154] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[154ページ]。
</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>
<フィールド名="tcpUrgTotalCount"dataTypeが等しい、「"totalCounter"グループ="flowCounter"unsigned64" dataTypeSemantics=elementIdが「223」適用性=「データ」状態=と等しい、「現在、「TCPが「緊急のPointer分野重要」のこのFlow(URG)のパケットの総数が旗を揚げさせる><記述><パラグラフ>はセットしました」。 TCP URGの定義のための>See RFC793が旗を揚げさせる</パラグラフ></記述><参照><パラグラフ。 </パラグラフ></参照><ユニット>パケット</ユニット></分野>。
<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>
「<フィールド名="flowActiveTimeout"dataTypeは「unsigned16"グループ=」雑ネタと等しく」elementIdが「36インチの適用性は」 すべてと等しい」という状態=と等しい、「現在、「><記述><パラグラフ>、アクティブなFlowが外でとにかく調節されている秒数パケットの連続した流れがまだあっても </パラグラフ></記述><ユニット>秒</単位></分野>。
<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>
「<フィールド名="flowIdleTimeout"dataTypeは「unsigned16"グループ=」雑ネタと等しく」elementIdが「37インチの適用性は」 すべてと等しい」という状態=と等しい、「「Flowに属すパケットが全くこの分野によって指定された秒数に関して観察されていないなら、><記述><パラグラフ>A Flowが調節されると考えられます」現在の。 </パラグラフ></記述><ユニット>秒</単位></分野>。
<field name="flowEndReason" dataType="unsigned8"
<フィールド名="flowEndReason"データ型式="unsigned8""
Quittek, et al. Standards Track [Page 155] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[155ページ]。
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>
><記述><は>について短い記事を書きます。「識別子」グループ=「雑ネタ」dataTypeSemantics=elementIdが「136」適用性=「データ」状態=と等しい、「現在、「Flow終了の理由、」 値の範囲は以下を含んでいます: </パラグラフ><アートワーク>0x01: タイムアウトを空費してください。それが活動していないと考えられたので、Flowは終えられました。 0×02: Flowがそれが例えばunreported Flowsの最大の生涯の後にまだアクティブであった間、目的を報告しながら終えられたアクティブなタイムアウトに達しました。 0×03: Metering Processが、信号がFlowの端を示すのを検出したので検出されたFlowではFlowが終えられた終わり、例えば、TCP FINは弛みます。 0×04: Flowが例えばMetering Processの閉鎖がネットワークマネージメントアプリケーションで起こしたいくつかの外部の出来事で終えられた無理矢理の終わり。 0×05: 財源不足はFlowが終えられたMetering Process、そして/または、Exporting Processに利用可能なリソースに欠けています。 </アートワーク></記述></分野>。
<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>
「<フィールド名=「flowDurationMilliseconds」dataTypeは「unsigned32"グループ=」雑ネタと等しく」elementIdが「161」適用性=「データ」状態=と等しい、「現在の「違いがこのFlowの最初の観測されたパケットとこのFlowの最後に観測されたパケットの間で中で調節する><記述><パラグラフ>。」 </パラグラフ></記述><ユニット>ミリセカンド</ユニット></分野>。
<field name="flowDurationMicroseconds" dataType="unsigned32"
group="misc"
elementId="162" applicability="data" status="current">
<description>
「<フィールド名=「flowDurationMicroseconds」dataTypeは「unsigned32"グループ=」雑ネタと等しく」elementIdが「162」適用性=「データ」状態=と等しい、「電流「><記述>」
Quittek, et al. Standards Track [Page 156] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[156ページ]。
<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>
違いがこのFlowの最初の観測されたパケットとこのFlowの最後に観測されたパケットの間で中で調節する<パラグラフ>。 </パラグラフ></記述><ユニット>マイクロセカンド</ユニット></分野>。
<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>
「<フィールド名=「flowDirection」 dataType=「unsigned8" dataTypeSemantics=」識別子」グループ=「雑ネタ」elementId=「61インチの適用性=」データ」状態が等しい、「現在の「Flowの指示がObservation Pointで観測した><記述><パラグラフ>。」 定義された2つの値しかありません。 </パラグラフ><アートワーク>0x00: イングレス流動0x01: 出口流れ</アートワーク></記述></分野>。
<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>
><記述><は>について短い記事を書きます。"octetArray"というelementIdを「そっと歩く」「paddingOctets」という<フィールド名=dataType=グループ=が「210」適用性=「オプション」状態=と等しい、「現在、「いつもこの情報Elementの値が0×00の値の系列である、」 </パラグラフ></記述></分野>。
</fieldDefinitions>
</fieldDefinitions>。
Appendix B. XML Specification of Abstract Data Types
抽象データ型の付録B.XML仕様
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 Information Elementsに使用されるべき抽象データ型の機械可読な記述とIPFIX Information Elementsを定義するのに使用されるテンプレートのマシンの読み込み可能な記述を含んでいます。 この付録が情報的に自然であることに注意してください、セクション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
同時に、また、この付録は作成するそれがInformation ElementsのXML仕様が使用されていたXML図式です。
Quittek, et al. Standards Track [Page 157] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[157ページ]。
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.Itは、IPFIX情報モデルの拡大で一層のInformation Elementsを指定するのに使用されるかもしれません。 この図式とその名前空間は http://www.iana.org/assignments/xml-registry/schema/ipfix.xsd にIANAによって登録されます。
<?xml version="1.0" encoding="UTF-8"?>
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ>。
<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">
<図式targetNamespaceは「つぼ:ietf:params:xml:ナノ秒: ipfixインフォメーション」xmlnsと等しいです: ipfix=「つぼ:ietf:params:xml:ナノ秒: ipfixインフォメーション」xmlnsが" http://www.w3.org/2001/XMLSchema "elementFormDefault=と等しい、「適切な">"
<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>
タイプしてください。<simpleTypeが=を命名する、「dataType「><制限ベース=」ストリング、「><列挙価値が等しい、「unsigned8"><注釈><ドキュメンテーション>、「unsigned8"は0〜255の範囲に非負の整数値を表します」。 </ドキュメンテーション></注釈></列挙>。
<enumeration value="unsigned16">
<annotation>
<documentation>The type "unsigned16" represents a
non-negative integer value in the range of 0 to 65535.
</documentation>
</annotation>
</enumeration>
タイプしてください。<列挙価値が等しい、「unsigned16"><注釈><ドキュメンテーション>、「unsigned16"は0〜65535の範囲に非負の整数値を表します」。 </ドキュメンテーション></注釈></列挙>。
<enumeration value="unsigned32">
<annotation>
<documentation>The type "unsigned32" represents a
non-negative integer value in the range of 0 to
4294967295.
</documentation>
</annotation>
</enumeration>
タイプしてください。<列挙価値が等しい、「unsigned32"><注釈><ドキュメンテーション>、「unsigned32"は0〜4294967295の範囲に非負の整数値を表します」。 </ドキュメンテーション></注釈></列挙>。
<enumeration value="unsigned64">
<annotation>
<documentation>The type "unsigned64" represents a
non-negative integer value in the range of 0 to
18446744073709551615.
</documentation>
</annotation>
</enumeration>
タイプしてください。<列挙価値が等しい、「unsigned64"><注釈><ドキュメンテーション>、「unsigned64"は0〜18446744073709551615の範囲に非負の整数値を表します」。 </ドキュメンテーション></注釈></列挙>。
Quittek, et al. Standards Track [Page 158] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[158ページ]。
<enumeration value="signed8">
<annotation>
<documentation>The type "signed8" represents
an integer value in the range of -128 to 127.
</documentation>
</annotation>
</enumeration>
タイプしてください。<列挙価値が等しい、「signed8"><注釈><ドキュメンテーション>、「signed8"は-128〜127の範囲に整数値を表します」。 </ドキュメンテーション></注釈></列挙>。
<enumeration value="signed16">
<annotation>
<documentation>The type "signed16" represents an
integer value in the range of -32768 to 32767.
</documentation>
</annotation>
</enumeration>
タイプしてください。<列挙価値が等しい、「signed16"><注釈><ドキュメンテーション>、「signed16"は-32768〜32767の範囲に整数値を表します」。 </ドキュメンテーション></注釈></列挙>。
<enumeration value="signed32">
<annotation>
<documentation>The type "signed32" represents an
integer value in the range of -2147483648 to
2147483647.
</documentation>
</annotation>
</enumeration>
タイプしてください。<列挙価値が等しい、「signed32"><注釈><ドキュメンテーション>、「signed32"は-2147483648〜2147483647の範囲に整数値を表します」。 </ドキュメンテーション></注釈></列挙>。
<enumeration value="signed64">
<annotation>
<documentation>The type "signed64" represents an
integer value in the range of -9223372036854775808
to 9223372036854775807.
</documentation>
</annotation>
</enumeration>
タイプしてください。<列挙価値が等しい、「signed64"><注釈><ドキュメンテーション>、「signed64"は-9223372036854775808〜9223372036854775807の範囲に整数値を表します」。 </ドキュメンテーション></注釈></列挙>。
<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>
<列挙価値が等しい、「タイプのfloat32"><注釈><ドキュメンテーション>、「float32"が定義されるとしてIEEEの単精度の32ビットの浮動小数点タイプに文通している、[IEEE、.754、.1985、]、」 </ドキュメンテーション></注釈></列挙>。
<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].
<列挙価値が等しい、「タイプのfloat64"><注釈><ドキュメンテーション>、「float64"が定義されるとしてIEEEの倍精度の64ビットの浮動小数点タイプに文通している、[IEEE、.754、.1985、]、」
Quittek, et al. Standards Track [Page 159] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[159ページ]。
</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>
<列挙価値が等しい、「論理演算子、「タイプ「論理演算子」が表す><注釈><ドキュメンテーション>、2進の値、」 唯一の許容値が、「本当で」「誤っています」。 </ドキュメンテーション></注釈></列挙>。
<enumeration value="macAddress">
<annotation>
<documentation>The type "macAddress" represents a
string of 6 octets.
</documentation>
</annotation>
</enumeration>
<列挙価値が等しい、「macAddress、「タイプの>><注釈><ドキュメンテーション「macAddress」が一連の6つの八重奏を表します」。 </ドキュメンテーション></注釈></列挙>。
<enumeration value="octetArray">
<annotation>
<documentation>The type "octetArray" represents a
finite-length string of octets.
</documentation>
</annotation>
</enumeration>
<列挙価値が等しい、「octetArray、「タイプの>><注釈><ドキュメンテーション"octetArray"が八重奏の有限長さのストリングを表します」。 </ドキュメンテーション></注釈></列挙>。
<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>
<列挙価値が等しい、「ストリング、「タイプが「結ぶ」><注釈><ドキュメンテーション>はセット[ISO.10646-1.1993]をコード化するユニコード文字から有効なキャラクタの有限長さのストリングを表します」。 ユニコードは、ASCII[ISO.646.1991]と他の多くの国際的な人物セットが使用されるのを許容します。 </ドキュメンテーション></注釈></列挙>。
<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
<列挙価値が等しい、「dateTimeSeconds、「タイプの>><注釈><ドキュメンテーション「dateTimeSeconds」が連携ユニバーサルタイム(UTC)に基づくユニットの秒に時間的価値を表します」。 時代の選択、例えば、協定世界時0時0分(1970年1月1日)はこのタイプのために仕様をコード化しながら対応する例えば、IPFIXに残されます。
Quittek, et al. Standards Track [Page 160] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[160ページ]。
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>
仕様を議定書の中で述べてください。 飛躍秒は除かれます。 異なった時代値が使用されているなら値の変化が異なったencodingsの間で必要であるかもしれないことに注意してください。 </ドキュメンテーション></注釈></列挙>。
<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>
<列挙価値が等しい、「dateTimeMilliseconds、「タイプの>><注釈><ドキュメンテーション「dateTimeMilliseconds」が連携ユニバーサルタイム(UTC)に基づくユニットのミリセカンドで時間的価値を表します」。 時代の選択、例えば、協定世界時0時0分(1970年1月1日)はこのタイプのために仕様をコード化しながら相当するのに残されます、例えば、IPFIXが仕様を議定書の中で述べます。 飛躍秒は除かれます。 異なった時代値が使用されているなら値の変化が異なったencodingsの間で必要であるかもしれないことに注意してください。 </ドキュメンテーション></注釈></列挙>。
<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>
<列挙価値が等しい、「dateTimeMicroseconds、「タイプの>><注釈><ドキュメンテーション「dateTimeMicroseconds」が連携ユニバーサルタイム(UTC)に基づくユニットのマイクロセカンドのときに時間的価値を表します」。 時代の選択、例えば、協定世界時0時0分(1970年1月1日)はこのタイプのために仕様をコード化しながら相当するのに残されます、例えば、IPFIXが仕様を議定書の中で述べます。 飛躍秒は除かれます。 異なった時代値が使用されているなら値の変化が異なったencodingsの間で必要であるかもしれないことに注意してください。 </ドキュメンテーション></注釈></列挙>。
<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
<列挙価値が等しい、「dateTimeNanoseconds、「タイプの>><注釈><ドキュメンテーション「dateTimeNanoseconds」が連携ユニバーサルタイム(UTC)に基づくユニットの数ナノ秒に時間的価値を表します」。 時代の選択、例えば、協定世界時0時0分(1970年1月1日)はこのタイプのために仕様をコード化しながら対応する例えば、IPFIXに残されます。
Quittek, et al. Standards Track [Page 161] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[161ページ]。
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>
仕様を議定書の中で述べてください。 飛躍秒は除かれます。 異なった時代値が使用されているなら値の変化が異なったencodingsの間で必要であるかもしれないことに注意してください。 </ドキュメンテーション></注釈></列挙>。
<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>
<列挙価値が等しい、「ipv4Address、「タイプの>><注釈><ドキュメンテーション「ipv4Address」がIPv4アドレスの値を表します」。 </ドキュメンテーション></注釈></列挙><列挙価値が等しい、「ipv6Address、「タイプの>><注釈><ドキュメンテーション「ipv6Address」がIPv6アドレスの値を表します」。 </ドキュメンテーション></注釈></列挙></制限></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>
dataTypeSemantics「><制限ベース=」は「><列挙価値=」量を結びます。<simpleTypeが=を命名する、「「><注釈><ドキュメンテーション>A量の価値は記録に関しながら、離散的な測定値を表します」。 これは「オドメーター」読書が与えられた記録の一部として捕らえられる進行中の測定値を表すカウンタと区別されます。 どんな意味資格を与える人も与えないなら、不可欠のデータ型を持っているInformation Elementsは量として振る舞うべきです。 </ドキュメンテーション></注釈></列挙>。
<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
<列挙価値が等しい、「totalCounter、「カウンタの値を報告する><注釈><ドキュメンテーション>An整数値。」 カウンタは、無記名であり、タイプの限界に達した後に、ゼロへの後部を包装します。 例えば、カウンタ意味論があるunsigned64は、続けるでしょう。
Quittek, et al. Standards Track [Page 162] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[162ページ]。
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>
2**の値に達するまで64--1を増加してください。 ここに、次の増分は、値をゼロに包装して、ゼロから数え続けるでしょう。 総カウンタの意味論はSNMPで使用されるカウンタの意味論と同様です、RFC2578[RFC2578]で定義されたCounter32などのように。 総カウンタとSNMPで使用されるカウンタの唯一の違いは総カウンタには0の初期の値があるということです。 総カウンタは価値の輸出の如何にかかわらず数えられます。 </ドキュメンテーション></注釈></列挙>。
<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>
<列挙価値が等しい、「deltaCounter、「カウンタの値を報告する><注釈><ドキュメンテーション>An整数値。」 カウンタは、無記名であり、タイプの限界に達した後に、ゼロへの後部を包装します。 例えば、カウンタ意味論があるunsigned64は、2**の値に達するまで64--1を増加し続けるでしょう。 ここに、次の増分は、値をゼロに包装して、ゼロから数え続けるでしょう。 デルタカウンタの意味論はSNMPで使用されるカウンタの意味論と同様です、RFC2578[RFC2578]で定義されたCounter32などのように。 デルタカウンタとSNMPで使用されるカウンタの唯一の違いはデルタカウンタには0の初期の値があるということです。 デルタカウンタは値を輸出するたびに0にリセットされます。 </ドキュメンテーション></注釈></列挙>。
<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>
<列挙価値が等しい、「「識別子として機能する><注釈><ドキュメンテーション>An整数値」という識別子 明確に、2つの識別子(平等操作は別として)における数学の操作は無意味です。 例えば、Autonomous System ID1*自治のSystem ID2は無意味です。 </ドキュメンテーション></注釈></列挙>。
<enumeration value="flags">
<annotation>
<documentation>
<列挙価値が等しい、「「><注釈><ドキュメンテーション>」に旗を揚げさせます。
Quittek, et al. Standards Track [Page 163] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[163ページ]。
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>
実際に1セットの噛み付いている分野を表す整数値。 論理演算は他の数学の操作ではなく、そのような値で適切です。 無記名のタイプには旗がいつもあるはずです。 </ドキュメンテーション></注釈></列挙></制限></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>
<simpleTypeが=を命名する、「「Information ElementsのためのFlow Recordsだけに適切な><注釈><ドキュメンテーション>Used。」という適用性「><制限ベース=」ストリング「><列挙価値=」データ </ドキュメンテーション></注釈></列挙>。
<enumeration value="option">
<annotation>
<documentation>
Used for Information Elements that are applicable to
option records only.
</documentation>
</annotation>
</enumeration>
<列挙価値が等しい、「「Information Elementsのためのオプション記録だけに適切な><注釈><ドキュメンテーション>Used」をゆだねてください。 </ドキュメンテーション></注釈></列挙>。
<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>
<列挙価値が等しい、「すべての「Information Elementsのためのオプション記録に関してまた、Flow Recordsに適切な><注釈><ドキュメンテーション>Used。」 </ドキュメンテーション></注釈></列挙></制限></simpleType>。
<simpleType name="status">
<restriction base="string">
<enumeration value="current">
<annotation>
<documentation>
Indicates that the Information Element definition
is current and valid.
<simpleTypeが=を命名する、「状態「><制限ベース=」ストリング「><列挙価値=」電流、「情報Element定義がそうである><注釈><ドキュメンテーション>Indicates、現在であって有効である、」
Quittek, et al. Standards Track [Page 164] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[164ページ]。
</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>
<列挙価値が等しい、「推奨しなさ、「><注釈><ドキュメンテーション>Indicates、情報Element定義が時代遅れですが、より古いか既存の実現で相互運用性を伸ばすために新しいか継続的な実現を可能にする、」 </ドキュメンテーション></注釈></列挙><列挙価値が等しい、「「情報Element定義を時代遅れであり、あるはずがない><注釈><ドキュメンテーション>Indicatesを実行される、そして/または、以前に実行されるなら、取り外すことができます」時代遅れの。 </ドキュメンテーション></注釈></列挙></制限></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>
「「><complexTypeは=を混ぜた」という本当の「テキスト「>の<の特選しているmaxOccurs=」限りない」<=complexType名前=minOccurs「0インチの><要素名=」パラグラフ「><系列><要素maxOccurs=」限りない」minOccurs=「0インチ名前=「xref「><complexType><属性名=」目標」タイプ=「ストリング」」; 使用は「必要」/></complexType></要素></系列></complexType>要素><要素名前=</「アートワーク「><simpleType><制限ベース=」ストリング」/></simpleType></要素></選択></complexType>と等しいです。
Quittek, et al. Standards Track [Page 165] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[165ページ]。
<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>
<simpleType名前=「範囲「><制限ベース=」ストリング」/></simpleType><要素名=の「fieldDefinitions「><complexType><系列><要素maxOccurs=」限りない」minOccurs=「1インチ」; 「分野「><complexType><系列><要素maxOccurs=」1インチminOccurs=「1インチの名前=」記述」タイプ=と=を命名してください、「ipfix: テキスト、「><注釈><ドキュメンテーション>、この情報Elementの意味論、」 . 観察者</ドキュメンテーション></注釈></要素>に、利用可能なFlowか他の情報からこの情報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>
「1インチのminOccurs=」0インチが命名する<要素maxOccurs=が「参照」タイプ=と等しい、「ipfix: テキスト、「より正確にこの項目を定義するか、または追加文脈を使用に提供する>の<のドキュメンテーションの>のIdentifiesの追加<注釈>仕様。」 </ドキュメンテーション></注釈></要素>。
<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>
<要素maxOccurs=「1インチのminOccurs=」0インチ名前=「ユニット」が=をタイプする、「ストリング、「><注釈><ドキュメンテーション>If情報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
「1インチのminOccurs=」0インチが命名する<要素maxOccurs=が「範囲」タイプ=と等しい、「ipfix: 「><注釈><ドキュメンテーション>Some Information Elementsはそれが制限されたセットの値であることができるところで取ることができるだけであるかもしれない」範囲
Quittek, et al. Standards Track [Page 166] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[166ページ]。
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>
範囲として言い表される、(例えば、0〜511、包括的である、) これがそうであるなら、有効な包括的な範囲は指定されるべきです。 </ドキュメンテーション></注釈></要素></系列>。
<attribute name="name" type="string" use="required">
<annotation>
<documentation>
A unique and meaningful name for the Information
Element.
</documentation>
</annotation>
</attribute>
<属性名前=「名前」タイプが「ストリング」使用=と等しい、「「>の<のドキュメンテーションの>のAユニークで情報Elementに、重要な<注釈>名」を必要とします。 </ドキュメンテーション></注釈></属性>。
<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>
<属性名前="dataType"が=「ipfix: dataType」使用=をタイプする、「「タイプの><注釈><ドキュメンテーション>1つはこのドキュメントのセクション3.1か情報モデルの今後の拡大で記載しました」必要な。 属性のためのタイプスペースが実現を容易にするのが抑制されます。 しかしながら、既存のタイプスペースは現代のプログラミング言語で使用されるほとんどの基本型を包含します、何人かの区別するためにこのドメインに共通の、そして、役に立つ派生型(ipv4Addressなどの)と同様に。 </ドキュメンテーション></注釈></属性>。
<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>
<属性名前=「dataTypeSemantics」が=「ipfix: dataTypeSemantics」使用=をタイプする、「「不可欠がタイプする><注釈><ドキュメンテーション>は追加意味詳細によって資格があるかもしれません」任意の。 データ型意味論のための有効値はこのドキュメントのセクション3.2か情報モデルの今後の拡大で指定されます。 </ドキュメンテーション></注釈></属性>。
<attribute name="elementId" type="nonNegativeInteger"
<属性名前="elementId"は="nonNegativeInteger"をタイプします。
Quittek, et al. Standards Track [Page 167] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[167ページ]。
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>
=を使用してください、「「情報Elementの>の<のドキュメンテーションの>のA数値<注釈>識別子」を必要とします。 この識別子が企業識別子なしで使用されるなら([RFC5101]と以下のenterpriseIdを見てください)、グローバルにユニークです、そして、許容値のリストはIANAによって管理されます。 プロトコルでTemplatesをコード化するとき、それは情報Elementのコンパクトな識別に使用されます。 </ドキュメンテーション></注釈></属性>。
<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>
<属性名前="enterpriseId"が="nonNegativeInteger"使用=をタイプする、「任意の「>エンタープライズが例えば、企業内部の目的のためにIANAにそれらを登録しないでInformation Elementsを定義したがっているかもしれない><注釈><ドキュメンテーション。」 そのようなInformation Elementsでは、情報Elementが企業の外で使用されるとき、上で説明された情報Element識別子は十分ではありません。 企業特有のInformation Elementsの仕様を公表して、企業の外のIPFIXプロトコルで企業特有の識別子を使用するなら、企業識別子にそれを結合することによって、企業特有の識別子をグローバルにユニークにしなければなりません。 enterpriseIdのための有効値はIANAによってManagement情報(SMI)ネットワークマネージメント私企業コードのStructureと定義されます。 それらは http://www.iana.org/assignments/enterprise-numbers で定義されます。 </ドキュメンテーション></注釈></属性>。
<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.
<属性名前=「適用性」タイプ=が「: 適用性をipfixする」という使用が等しい、「「情報Elementの><注釈><ドキュメンテーション>Thisの特性は、どの種類に関する記録で情報Elementを使用できるのを示します」任意の。
Quittek, et al. Standards Track [Page 168] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[168ページ]。
Allowed values for this property are 'data',
'option', and 'all'.
</documentation>
</annotation>
</attribute>
この特性のための値が許容されているのは、'データ'と、'オプション'と、'すべて'です。 </ドキュメンテーション></注釈></属性>。
<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>
<属性名前=「状態」タイプ=が「: 状態をipfixする」という使用が等しい、「必要である、「><注釈><ドキュメンテーション>、この情報Elementの仕様の状態、」 許容値は、'現在'で、'推奨しないこと'と、'時代遅れです'。 </ドキュメンテーション></注釈></属性><属性名前=「グループ」タイプが「ストリング」使用=と等しい、「「されるべき><注釈><ドキュメンテーション>」が必要でした。</ドキュメンテーション></注釈></属性>。
</complexType>
</element>
</sequence>
</complexType>
</complexType></要素></系列></complexType>。
<unique name="infoElementIdUnique">
<selector xpath="field"/>
<ユニークな名前=「infoElementIdUnique「><セレクタxpath=」分野」/>。
<field xpath="elementId"/>
</unique>
</element>
</schema>
<分野xpath="elementId"/></ユニークな></要素></図式>。
Quittek, et al. Standards Track [Page 169] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[169ページ]。
Authors' Addresses
作者のアドレス
Juergen Quittek NEC Kurfuersten-Anlage 36 Heidelberg 69115 Germany
ユルゲンQuittek NEC Kurfuersten-原基36ハイデルベルグ69115ドイツ
Phone: +49 6221 90511-15 EMail: quittek@nw.neclab.eu URI: http://www.neclab.eu/
以下に電話をしてください。 +49 6221 90511-15 メールしてください: quittek@nw.neclab.eu ユリ: http://www.neclab.eu/
Stewart Bryant Cisco Systems, Inc. 250, Longwater Ave., Green Park Reading RG2 6GB United Kingdom
スチュワートブライアントシスコシステムズInc.250、Longwater Ave、グリーンパーク読書RG2 6GBイギリス
EMail: stbryant@cisco.com
メール: stbryant@cisco.com
Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 Diegem 1831 Belgium
ブノワClaiseシスコシステムズInc.De Kleetlaan 6a b1 Diegem1831ベルギー
Phone: +32 2 704 5622 EMail: bclaise@cisco.com
以下に電話をしてください。 +32 2 704 5622はメールされます: bclaise@cisco.com
Paul Aitken Cisco Systems, Inc. 96 Commercial Quay Edinburgh EH6 6LX Scotland
ポールエイトケンシスコシステムズInc.96の商業波止場エディンバラEH6 6LXスコットランド
Phone: +44 131 561 3616 EMail: paitken@cisco.com
以下に電話をしてください。 +44 3616年の131 561メール: paitken@cisco.com
Jeff Meyer PayPal 2211 N. First St. San Jose, CA 95131-2021 US
最初に、ジェフマイヤーPayPal2211N.聖カリフォルニア95131-2021サンノゼ(米国)
Phone: +1 408 976-9149 EMail: jemeyer@paypal.com URI: http://www.paypal.com
以下に電話をしてください。 +1 408 976-9149 メールしてください: jemeyer@paypal.com ユリ: http://www.paypal.com
Quittek, et al. Standards Track [Page 170] RFC 5102 IPFIX Information Model January 2008
Quittek、他 規格はIPFIX情報モデル2008年1月にRFC5102を追跡します[170ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を記述してください。
Quittek, et al. Standards Track [Page 171]
Quittek、他 標準化過程[171ページ]
一覧
スポンサーリンク
