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
December 2007
Information Model for IP Flow Information Export
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.
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.
Table of Contents
1. Introduction ....................................................6
2. Properties of IPFIX Protocol Information Elements ...............7
2.1. Information Elements Specification Template ................7
2.2. Scope of Information Elements ..............................9
2.3. Naming Conventions for Information Elements ................9
3. Type Space .....................................................10
3.1. Abstract Data Types .......................................10
3.1.1. unsigned8 ..........................................10
3.1.2. unsigned16 .........................................11
3.1.3. unsigned32 .........................................11
3.1.4. unsigned64 .........................................11
3.1.5. signed8 ............................................11
3.1.6. signed16 ...........................................11
3.1.7. signed32 ...........................................11
3.1.8. signed64 ...........................................11
3.1.9. float32 ............................................11
3.1.10. float64 ...........................................11
3.1.11. boolean ...........................................12
3.1.12. macAddress ........................................12
3.1.13. octetArray ........................................12
3.1.14. string ............................................12
3.1.15. dateTimeSeconds ...................................12
3.1.16. dateTimeMilliseconds ..............................12
3.1.17. dateTimeMicroseconds ..............................12
3.1.18. dateTimeNanoseconds ...............................13
3.1.19. ipv4Address .......................................13
3.1.20. ipv6Address .......................................13
3.2. Data Type Semantics .......................................13
3.2.1. quantity ...........................................13
3.2.2. totalCounter .......................................13
3.2.3. deltaCounter .......................................14
3.2.4. identifier .........................................14
3.2.5. flags ..............................................14
4. Information Element Identifiers ................................14
5. Information Elements ...........................................18
5.1. Identifiers ...............................................19
5.1.1. lineCardId .........................................20
5.1.2. portId .............................................20
5.1.3. ingressInterface ...................................20
5.1.4. egressInterface ....................................21
5.1.5. meteringProcessId ..................................21
5.1.6. exportingProcessId .................................21
5.1.7. flowId .............................................22
5.1.8. templateId .........................................22
5.1.9. observationDomainId ................................22
5.1.10. observationPointId ................................23
5.1.11. commonPropertiesId ................................23
5.2. Metering and Exporting Process Configuration ..............23
5.2.1. exporterIPv4Address ................................24
5.2.2. exporterIPv6Address ................................24
5.2.3. exporterTransportPort ..............................24
5.2.4. collectorIPv4Address ...............................25
5.2.5. collectorIPv6Address ...............................25
5.2.6. exportInterface ....................................25
5.2.7. exportProtocolVersion ..............................26
5.2.8. exportTransportProtocol ............................26
5.2.9. collectorTransportPort .............................27
5.2.10. flowKeyIndicator ..................................27
5.3. Metering and Exporting Process Statistics .................28
5.3.1. exportedMessageTotalCount ..........................28
5.3.2. exportedOctetTotalCount ............................28
5.3.3. exportedFlowRecordTotalCount .......................29
5.3.4. observedFlowTotalCount .............................29
5.3.5. ignoredPacketTotalCount ............................29
5.3.6. ignoredOctetTotalCount .............................30
5.3.7. notSentFlowTotalCount ..............................30
5.3.8. notSentPacketTotalCount ............................30
5.3.9. notSentOctetTotalCount .............................31
5.4. IP Header Fields ..........................................31
5.4.1. ipVersion ..........................................31
5.4.2. sourceIPv4Address ..................................32
5.4.3. sourceIPv6Address ..................................32
5.4.4. sourceIPv4PrefixLength .............................32
5.4.5. sourceIPv6PrefixLength .............................33
5.4.6. sourceIPv4Prefix ...................................33
5.4.7. sourceIPv6Prefix ...................................33
5.4.8. destinationIPv4Address .............................33
5.4.9. destinationIPv6Address .............................34
5.4.10. destinationIPv4PrefixLength .......................34
5.4.11. destinationIPv6PrefixLength .......................34
5.4.12. destinationIPv4Prefix .............................34
5.4.13. destinationIPv6Prefix .............................35
5.4.14. ipTTL .............................................35
5.4.15. protocolIdentifier ................................35
5.4.16. nextHeaderIPv6 ....................................36
5.4.17. ipDiffServCodePoint ...............................36
5.4.18. ipPrecedence ......................................36
5.4.19. ipClassOfService ..................................37
5.4.20. postIpClassOfService ..............................37
5.4.21. flowLabelIPv6 .....................................38
5.4.22. isMulticast .......................................38
5.4.23. fragmentIdentification ............................39
5.4.24. fragmentOffset ....................................39
5.4.25. fragmentFlags .....................................39
5.4.26. ipHeaderLength ....................................40
5.4.27. ipv4IHL ...........................................40
5.4.28. totalLengthIPv4 ...................................41
5.4.29. ipTotalLength .....................................41
5.4.30. payloadLengthIPv6 .................................41
5.5. Transport Header Fields ...................................42
5.5.1. sourceTransportPort ................................42
5.5.2. destinationTransportPort ...........................42
5.5.3. udpSourcePort ......................................43
5.5.4. udpDestinationPort .................................43
5.5.5. udpMessageLength ...................................43
5.5.6. tcpSourcePort ......................................44
5.5.7. tcpDestinationPort .................................44
5.5.8. tcpSequenceNumber ..................................44
5.5.9. tcpAcknowledgementNumber ...........................44
5.5.10. tcpWindowSize .....................................45
5.5.11. tcpWindowScale ....................................45
5.5.12. tcpUrgentPointer ..................................45
5.5.13. tcpHeaderLength ...................................45
5.5.14. icmpTypeCodeIPv4 ..................................46
5.5.15. icmpTypeIPv4 ......................................46
5.5.16. icmpCodeIPv4 ......................................46
5.5.17. icmpTypeCodeIPv6 ..................................46
5.5.18. icmpTypeIPv6 ......................................47
5.5.19. icmpCodeIPv6 ......................................47
5.5.20. igmpType ..........................................47
5.6. Sub-IP Header Fields ......................................48
5.6.1. sourceMacAddress ...................................48
5.6.2. postSourceMacAddress ...............................48
5.6.3. vlanId .............................................49
5.6.4. postVlanId .........................................49
5.6.5. destinationMacAddress ..............................49
5.6.6. postDestinationMacAddress ..........................49
5.6.7. wlanChannelId ......................................50
5.6.8. wlanSSID ...........................................50
5.6.9. mplsTopLabelTTL ....................................50
5.6.10. mplsTopLabelExp ...................................51
5.6.11. postMplsTopLabelExp ...............................51
5.6.12. mplsLabelStackDepth ...............................51
5.6.13. mplsLabelStackLength ..............................52
5.6.14. mplsPayloadLength .................................52
5.6.15. mplsTopLabelStackSection ..........................52
5.6.16. mplsLabelStackSection2 ............................53
5.6.17. mplsLabelStackSection3 ............................53
5.6.18. mplsLabelStackSection4 ............................53
5.6.19. mplsLabelStackSection5 ............................54
5.6.20. mplsLabelStackSection6 ............................54
5.6.21. mplsLabelStackSection7 ............................54
5.6.22. mplsLabelStackSection8 ............................55
5.6.23. mplsLabelStackSection9 ............................55
5.6.24. mplsLabelStackSection10 ...........................55
5.7. Derived Packet Properties .................................56
5.7.1. ipPayloadLength ....................................56
5.7.2. ipNextHopIPv4Address ...............................56
5.7.3. ipNextHopIPv6Address ...............................57
5.7.4. bgpSourceAsNumber ..................................57
5.7.5. bgpDestinationAsNumber .............................57
5.7.6. bgpNextAdjacentAsNumber ............................57
5.7.7. bgpPrevAdjacentAsNumber ............................58
5.7.8. bgpNextHopIPv4Address ..............................58
5.7.9. bgpNextHopIPv6Address ..............................58
5.7.10. mplsTopLabelType ..................................59
5.7.11. mplsTopLabelIPv4Address ...........................59
5.7.12. mplsTopLabelIPv6Address ...........................60
5.7.13. mplsVpnRouteDistinguisher .........................60
5.8. Min/Max Flow Properties ...................................61
5.8.1. minimumIpTotalLength ...............................61
5.8.2. maximumIpTotalLength ...............................61
5.8.3. minimumTTL .........................................61
5.8.4. maximumTTL .........................................62
5.8.5. ipv4Options ........................................62
5.8.6. ipv6ExtensionHeaders ...............................64
5.8.7. tcpControlBits .....................................65
5.8.8. tcpOptions .........................................66
5.9. Flow Timestamps ...........................................67
5.9.1. flowStartSeconds ...................................67
5.9.2. flowEndSeconds .....................................68
5.9.3. flowStartMilliseconds ..............................68
5.9.4. flowEndMilliseconds ................................68
5.9.5. flowStartMicroseconds ..............................68
5.9.6. flowEndMicroseconds ................................68
5.9.7. flowStartNanoseconds ...............................69
5.9.8. flowEndNanoseconds .................................69
5.9.9. flowStartDeltaMicroseconds .........................69
5.9.10. flowEndDeltaMicroseconds ..........................69
5.9.11. systemInitTimeMilliseconds ........................70
5.9.12. flowStartSysUpTime ................................70
5.9.13. flowEndSysUpTime ..................................70
5.10. Per-Flow Counters ........................................70
5.10.1. octetDeltaCount ...................................71
5.10.2. postOctetDeltaCount ...............................71
5.10.3. octetDeltaSumOfSquares ............................72
5.10.4. octetTotalCount ...................................72
5.10.5. postOctetTotalCount ...............................72
5.10.6. octetTotalSumOfSquares ............................72
5.10.7. packetDeltaCount ..................................73
5.10.8. postPacketDeltaCount ..............................73
5.10.9. packetTotalCount ..................................73
5.10.10. postPacketTotalCount .............................74
5.10.11. droppedOctetDeltaCount ...........................74
5.10.12. droppedPacketDeltaCount ..........................74
5.10.13. droppedOctetTotalCount ...........................74
5.10.14. droppedPacketTotalCount ..........................75
5.10.15. postMCastPacketDeltaCount ........................75
5.10.16. postMCastOctetDeltaCount .........................75
5.10.17. postMCastPacketTotalCount ........................76
5.10.18. postMCastOctetTotalCount .........................76
5.10.19. tcpSynTotalCount .................................76
5.10.20. tcpFinTotalCount .................................77
5.10.21. tcpRstTotalCount .................................77
5.10.22. tcpPshTotalCount .................................77
5.10.23. tcpAckTotalCount .................................78
5.10.24. tcpUrgTotalCount .................................78
5.11. Miscellaneous Flow Properties ............................78
5.11.1. flowActiveTimeout .................................79
5.11.2. flowIdleTimeout ...................................79
5.11.3. flowEndReason .....................................79
5.11.4. flowDurationMilliseconds ..........................80
5.11.5. flowDurationMicroseconds ..........................80
5.11.6. flowDirection .....................................80
5.12. Padding ..................................................80
5.12.1. paddingOctets .....................................81
6. Extending the Information Model ................................81
7. IANA Considerations ............................................82
7.1. IPFIX Information Elements ................................82
7.2. MPLS Label Type Identifier ................................82
7.3. XML Namespace and Schema ..................................83
8. Security Considerations ........................................83
9. Acknowledgements ...............................................84
10. References ....................................................84
10.1. Normative References .....................................84
10.2. Informative References ...................................84
Appendix A. XML Specification of IPFIX Information Elements .......89
Appendix B. XML Specification of Abstract Data Types .............158
1. Introduction
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].
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.
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.
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.
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.
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.
Note that although partially generated from the attached XML
documents, the main body of this document is normative while the
appendices are informational.
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].
2. Properties of IPFIX Protocol Information Elements
2.1. Information Elements Specification Template
Information in messages of the IPFIX protocol is modeled in terms of
Information Elements of the IPFIX information model. IPFIX
Information Elements are specified in Section 5. For specifying
these Information Elements, a template is used that is described
below.
All Information Elements specified for the IPFIX protocol either in
this document or by any future extension MUST have the following
properties defined:
name - A unique and meaningful name for the Information Element.
elementId - A numeric identifier of the Information Element. If this
identifier is used without an enterprise identifier (see [RFC5101]
and enterpriseId below), then it is globally unique and the list
of allowed values is administered by IANA. It is used for compact
identification of an Information Element when encoding Templates
in the protocol.
description - The semantics of this Information Element. Describes
how this Information Element is derived from the Flow or other
information available to the observer.
dataType - One of the types listed in Section 3.1 of this document or
in a future extension of the information model. The type space
for attributes is constrained to facilitate implementation. The
existing type space does however encompass most basic types used
in modern programming languages, as well as some derived types
(such as ipv4Address) that are common to this domain and useful to
distinguish.
status - The status of the specification of this Information Element.
Allowed values are 'current', 'deprecated', and 'obsolete'.
Enterprise-specific Information Elements MUST have the following
property defined:
enterpriseId - Enterprises may wish to define Information Elements
without registering them with IANA, for example, for
enterprise-internal purposes. For such Information Elements, the
Information Element identifier described above is not sufficient
when the Information Element is used outside the enterprise. If
specifications of enterprise-specific Information Elements are
made public and/or if enterprise-specific identifiers are used by
the IPFIX protocol outside the enterprise, then the
enterprise-specific identifier MUST be made globally unique by
combining it with an enterprise identifier. Valid values for the
enterpriseId are defined by IANA as Structure of Management
Information (SMI) network management private enterprise codes.
They are defined at http://www.iana.org/assignments/enterprise-
numbers.
All Information Elements specified for the IPFIX protocol either in
this document or by any future extension MAY have the following
properties defined:
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.
units - If the Information Element is a measure of some kind, the
units identify what the measure is.
range - Some Information Elements may only be able to take on a
restricted set of values that can be expressed as a range (e.g., 0
through 511 inclusive). If this is the case, the valid inclusive
range should be specified.
reference - Identifies additional specifications that more precisely
define this item or provide additional context for its use.
2.2. Scope of Information Elements
By default, most Information Elements have a scope specified in their
definitions.
o The Information Elements defined in Sections 5.2 and 5.3 have a
default of "a specific Metering Process" or of "a specific
Exporting Process", respectively.
o The Information Elements defined in Sections 5.4-5.11 have a scope
of "a specific 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].
2.3. Naming Conventions for Information Elements
The following naming conventions were used for naming Information
Elements in this document. It is recommended that extensions of the
model use the same conventions.
o Names of Information Elements should be descriptive.
o 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 Names of Information Elements start with non-capitalized letters.
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 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.
3. Type Space
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.
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'.
3.1. Abstract Data Types
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.
3.1.1. unsigned8
The type "unsigned8" represents a non-negative integer value in the
range of 0 to 255.
3.1.2. unsigned16
The type "unsigned16" represents a non-negative integer value in the
range of 0 to 65535.
3.1.3. unsigned32
The type "unsigned32" represents a non-negative integer value in the
range of 0 to 4294967295.
3.1.4. unsigned64
The type "unsigned64" represents a non-negative integer value in the
range of 0 to 18446744073709551615.
3.1.5. signed8
The type "signed8" represents an integer value in the range of -128
to 127.
3.1.6. signed16
The type "signed16" represents an integer value in the range of
-32768 to 32767.
3.1.7. signed32
The type "signed32" represents an integer value in the range of
-2147483648 to 2147483647.
3.1.8. signed64
The type "signed64" represents an integer value in the range of
-9223372036854775808 to 9223372036854775807.
3.1.9. float32
The type "float32" corresponds to an IEEE single-precision 32-bit
floating point type as defined in [IEEE.754.1985].
3.1.10. float64
The type "float64" corresponds to an IEEE double-precision 64-bit
floating point type as defined in [IEEE.754.1985].
3.1.11. boolean
The type "boolean" represents a binary value. The only allowed
values are "true" and "false".
3.1.12. macAddress
The type "macAddress" represents a string of 6 octets.
3.1.13. octetArray
The type "octetArray" represents a finite-length string of octets.
3.1.14. string
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.
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.
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.
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
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.
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.
3.1.19. ipv4Address
The type "ipv4Address" represents a value of an IPv4 address.
3.1.20. ipv6Address
The type "ipv6Address" represents a value of an IPv6 address.
3.2. Data Type Semantics
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.
3.2.1. quantity
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.
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
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.
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.
3.2.4. identifier
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.
3.2.5. flags
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.
4. Information Element Identifiers
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.
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].
+---------------------------------+---------------------------------+
| Range of IANA-assigned | Description |
| Information Element identifiers | |
+---------------------------------+---------------------------------+
| 0 | Reserved. |
| 1-127 | Information Element identifiers |
| | compatible with NetFlow version |
| | 9 field types [RFC3954]. |
| 128-32767 | Further Information Element |
| | identifiers. |
+---------------------------------+---------------------------------+
Enterprise-specific Information Element identifiers have the same
range of 1-32767, but they are coupled with an additional enterprise
identifier. For enterprise-specific Information Elements,
Information Element identifier 0 is also reserved.
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.
Still, Collecting Processes can distinguish these Information
Elements because the Information Element identifier is coupled with
an enterprise identifier.
Enterprise identifiers MUST be registered as SMI network management
private enterprise code numbers with IANA. The registry can be found
at http://www.iana.org/assignments/enterprise-numbers.
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].
+----+----------------------------+-------+-------------------------+
| ID | Name | ID | Name |
+----+----------------------------+-------+-------------------------+
| 1 | octetDeltaCount | 43 | RESERVED |
| 2 | packetDeltaCount | 44 | sourceIPv4Prefix |
| 3 | RESERVED | 45 | destinationIPv4Prefix |
| 4 | protocolIdentifier | 46 | mplsTopLabelType |
| 5 | ipClassOfService | 47 | mplsTopLabelIPv4Address |
| 6 | tcpControlBits | 48-51 | RESERVED |
| 7 | sourceTransportPort | 52 | minimumTTL |
| 8 | sourceIPv4Address | 53 | maximumTTL |
| 9 | sourceIPv4PrefixLength | 54 | fragmentIdentification |
| 10 | ingressInterface | 55 | postIpClassOfService |
| 11 | destinationTransportPort | 56 | sourceMacAddress |
| 12 | destinationIPv4Address | 57 |postDestinationMacAddress|
| 13 | destinationIPv4PrefixLength| 58 | vlanId |
| 14 | egressInterface | 59 | postVlanId |
| 15 | ipNextHopIPv4Address | 60 | ipVersion |
| 16 | bgpSourceAsNumber | 61 | flowDirection |
| 17 | bgpDestinationAsNumber | 62 | ipNextHopIPv6Address |
| 18 | bgpNexthopIPv4Address | 63 | bgpNexthopIPv6Address |
| 19 | postMCastPacketDeltaCount | 64 | ipv6ExtensionHeaders |
| 20 | postMCastOctetDeltaCount | 65-69 | RESERVED |
| 21 | flowEndSysUpTime | 70 | mplsTopLabelStackSection|
| 22 | flowStartSysUpTime | 71 | mplsLabelStackSection2 |
| 23 | postOctetDeltaCount | 72 | mplsLabelStackSection3 |
| 24 | postPacketDeltaCount | 73 | mplsLabelStackSection4 |
| 25 | minimumIpTotalLength | 74 | mplsLabelStackSection5 |
| 26 | maximumIpTotalLength | 75 | mplsLabelStackSection6 |
| 27 | sourceIPv6Address | 76 | mplsLabelStackSection7 |
| 28 | destinationIPv6Address | 77 | mplsLabelStackSection8 |
| 29 | sourceIPv6PrefixLength | 78 | mplsLabelStackSection9 |
| 30 | destinationIPv6PrefixLength| 79 | mplsLabelStackSection10 |
| 31 | flowLabelIPv6 | 80 | destinationMacAddress |
| 32 | icmpTypeCodeIPv4 | 81 | postSourceMacAddress |
| 33 | igmpType | 82-84 | RESERVED |
| 34 | RESERVED | 85 | octetTotalCount |
| 35 | RESERVED | 86 | packetTotalCount |
| 36 | flowActiveTimeout | 87 | RESERVED |
| 37 | flowIdleTimeout | 88 | fragmentOffset |
| 38 | RESERVED | 89 | RESERVED |
| 39 | RESERVED | 90 |mplsVpnRouteDistinguisher|
| 40 | exportedOctetTotalCount |91-127 | RESERVED |
| 41 | exportedMessageTotalCount | | |
| 42 |exportedFlowRecordTotalCount| | |
+----+----------------------------+-------+-------------------------+
The following list gives an overview of the Information Element
identifiers that are specified in Section 5 and extends the list of
Information Element identifiers specified already in [RFC3954].
+-----+---------------------------+-----+---------------------------+
| ID | Name | ID | Name |
+-----+---------------------------+-----+---------------------------+
| 128 | bgpNextAdjacentAsNumber | 169 | destinationIPv6Prefix |
| 129 | bgpPrevAdjacentAsNumber | 170 | sourceIPv6Prefix |
| 130 | exporterIPv4Address | 171 | postOctetTotalCount |
| 131 | exporterIPv6Address | 172 | postPacketTotalCount |
| 132 | droppedOctetDeltaCount | 173 | flowKeyIndicator |
| 133 | droppedPacketDeltaCount | 174 | postMCastPacketTotalCount |
| 134 | droppedOctetTotalCount | 175 | postMCastOctetTotalCount |
| 135 | droppedPacketTotalCount | 176 | icmpTypeIPv4 |
| 136 | flowEndReason | 177 | icmpCodeIPv4 |
| 137 | commonPropertiesId | 178 | icmpTypeIPv6 |
| 138 | observationPointId | 179 | icmpCodeIPv6 |
| 139 | icmpTypeCodeIPv6 | 180 | udpSourcePort |
| 140 | mplsTopLabelIPv6Address | 181 | udpDestinationPort |
| 141 | lineCardId | 182 | tcpSourcePort |
| 142 | portId | 183 | tcpDestinationPort |
| 143 | meteringProcessId | 184 | tcpSequenceNumber |
| 144 | exportingProcessId | 185 | tcpAcknowledgementNumber |
| 145 | templateId | 186 | tcpWindowSize |
| 146 | wlanChannelId | 187 | tcpUrgentPointer |
| 147 | wlanSSID | 188 | tcpHeaderLength |
| 148 | flowId | 189 | ipHeaderLength |
| 149 | observationDomainId | 190 | totalLengthIPv4 |
| 150 | flowStartSeconds | 191 | payloadLengthIPv6 |
| 151 | flowEndSeconds | 192 | ipTTL |
| 152 | flowStartMilliseconds | 193 | nextHeaderIPv6 |
| 153 | flowEndMilliseconds | 194 | mplsPayloadLength |
| 154 | flowStartMicroseconds | 195 | ipDiffServCodePoint |
| 155 | flowEndMicroseconds | 196 | ipPrecedence |
| 156 | flowStartNanoseconds | 197 | fragmentFlags |
| 157 | flowEndNanoseconds | 198 | octetDeltaSumOfSquares |
| 158 | flowStartDeltaMicroseconds| 199 | octetTotalSumOfSquares |
| 159 | flowEndDeltaMicroseconds | 200 | mplsTopLabelTTL |
| 160 | systemInitTimeMilliseconds| 201 | mplsLabelStackLength |
| 161 | flowDurationMilliseconds | 202 | mplsLabelStackDepth |
| 162 | flowDurationMicroseconds | 203 | mplsTopLabelExp |
| 163 | observedFlowTotalCount | 204 | ipPayloadLength |
| 164 | ignoredPacketTotalCount | 205 | udpMessageLength |
| 165 | ignoredOctetTotalCount | 206 | isMulticast |
| 166 | notSentFlowTotalCount | 207 | ipv4IHL |
| 167 | notSentPacketTotalCount | 208 | ipv4Options |
| 168 | notSentOctetTotalCount | 209 | tcpOptions |
+-----+---------------------------+-----+---------------------------+
| ID | Name | ID | Name |
+-----+---------------------------+-----+---------------------------+
| 210 | paddingOctets | 218 | tcpSynTotalCount |
| 211 | collectorIPv4Address | 219 | tcpFinTotalCount |
| 212 | collectorIPv6Address | 220 | tcpRstTotalCount |
| 213 | exportInterface | 221 | tcpPshTotalCount |
| 214 | exportProtocolVersion | 222 | tcpAckTotalCount |
| 215 | exportTransportProtocol | 223 | tcpUrgTotalCount |
| 216 | collectorTransportPort | 224 | ipTotalLength |
| 217 | exporterTransportPort | 237 | postMplsTopLabelExp |
| | | 238 | tcpWindowScale |
+-----+---------------------------+-----+---------------------------+
5. Information Elements
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:
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
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.
If they do not serve as Flow Keys, their value may change from packet
to packet within a single Flow. For Information Elements with values
that are derived from fields of packets or from packet treatment and
for which the value may change from packet to packet within a single
Flow, the IPFIX information model defines that their value is
determined by the first packet observed for the corresponding Flow,
unless the description of the Information Element explicitly
specifies a different semantics. This simple rule allows writing all
Information Elements related to header fields once when the first
packet of the Flow is observed. For further observed packets of the
same Flow, only Flow properties that depend on more than one packet,
such as the Information Elements in groups 8-11, need to be updated.
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.
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
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.
Typically, some of them are used for limiting scopes of other
Information Elements. However, other Information Elements MAY be
used for limiting scopes. Note also that all Information Elements
listed below MAY be used for other purposes than limiting scopes.
+-----+---------------------------+-----+---------------------------+
| ID | Name | ID | Name |
+-----+---------------------------+-----+---------------------------+
| 141 | lineCardId | 148 | flowId |
| 142 | portId | 145 | templateId |
| 10 | ingressInterface | 149 | observationDomainId |
| 14 | egressInterface | 138 | observationPointId |
| 143 | meteringProcessId | 137 | commonPropertiesId |
| 144 | exportingProcessId | | |
+-----+---------------------------+-----+---------------------------+
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
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
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.
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.
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
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
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
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
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
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
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
5.2. Metering and Exporting Process Configuration
Information Elements in this section describe the configuration of
the Metering Process or the Exporting Process. The set of these
Information Elements is listed in the table below.
+-----+--------------------------+-----+----------------------------+
| ID | Name | ID | Name |
+-----+--------------------------+-----+----------------------------+
| 130 | exporterIPv4Address | 213 | exportInterface |
| 131 | exporterIPv6Address | 214 | exportProtocolVersion |
| 217 | exporterTransportPort | 215 | exportTransportProtocol |
| 211 | collectorIPv4Address | 216 | collectorTransportPort |
| 212 | collectorIPv6Address | 173 | flowKeyIndicator |
+-----+--------------------------+-----+----------------------------+
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
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
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.
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
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
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.
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.
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.
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.
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
5.3. Metering and Exporting Process Statistics
Information Elements in this section describe statistics of the
Metering Process and/or the Exporting Process. The set of these
Information Elements is listed in the table below.
+-----+-----------------------------+-----+-------------------------+
| ID | Name | ID | Name |
+-----+-----------------------------+-----+-------------------------+
| 41 | exportedMessageTotalCount | 165 | ignoredOctetTotalCount |
| 40 | exportedOctetTotalCount | 166 | notSentFlowTotalCount |
| 42 | exportedFlowRecordTotalCount| 167 | notSentPacketTotalCount |
| 163 | observedFlowTotalCount | 168 | notSentOctetTotalCount |
| 164 | ignoredPacketTotalCount | | |
+-----+-----------------------------+-----+-------------------------+
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
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
Units: octets
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
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
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
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
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
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
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
5.4. IP Header Fields
Information Elements in this section indicate values of IP header
fields or are derived from IP header field values in combination with
further information.
+-----+----------------------------+-----+--------------------------+
| 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 |
+-----+----------------------------+-----+--------------------------+
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
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.
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.
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.
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.
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.
5.4.6. sourceIPv4Prefix
Description:
IPv4 source address prefix.
Abstract Data Type: ipv4Address
ElementId: 44
Status: current
5.4.7. sourceIPv6Prefix
Description:
IPv6 source address prefix.
Abstract Data Type: ipv6Address
ElementId: 170
Status: current
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.
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.
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.
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.
5.4.12. destinationIPv4Prefix
Description:
IPv4 destination address prefix.
Abstract Data Type: ipv4Address
ElementId: 45
Status: current
5.4.13. destinationIPv6Prefix
Description:
IPv6 destination address prefix.
Abstract Data Type: ipv6Address
ElementId: 169
Status: current
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
0 1 2 3 4 5 6 7
+------+------+------+------+------+------+------+------+
| MCv4 | RES. | RES. | T | IPv6 multicast scope |
+------+------+------+------+------+------+------+------+
Bit 0: set to 1 if IPv4 multicast
Bits 1-2: reserved for future use
Bit 4: set to value of T flag, if IPv6 multicast
Bits 4-7: set to value of multicast scope if IPv6 multicast
Abstract Data Type: unsigned8
Data Type Semantics: flags
ElementId: 206
Status: current
Reference:
See RFC 1112 for the specification of reserved IPv4 multicast
addresses. See RFC 4291 for the specification of reserved IPv6
multicast addresses and the definition of the T flag and the IPv6
multicast scope.
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.
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.
5.4.25. fragmentFlags
Description:
Fragmentation properties indicated by flags in the IPv4 packet
header or the IPv6 Fragment header, respectively.
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 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.
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.
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.
Abstract Data Type: unsigned8
ElementId: 207
Status: current
Units: 4 octets
Reference:
See RFC 791 for the specification of the IPv4 header.
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.
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.
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.
5.5. Transport Header Fields
The set of Information Elements related to transport header fields
and length includes the Information Elements listed in the table
below.
+-----+---------------------------+-----+---------------------------+
| ID | Name | ID | Name |
+-----+---------------------------+-----+---------------------------+
| 7 | sourceTransportPort | 238 | tcpWindowScale |
| 11 | destinationTransportPort | 187 | tcpUrgentPointer |
| 180 | udpSourcePort | 188 | tcpHeaderLength |
| 181 | udpDestinationPort | 32 | icmpTypeCodeIPv4 |
| 205 | udpMessageLength | 176 | icmpTypeIPv4 |
| 182 | tcpSourcePort | 177 | icmpCodeIPv4 |
| 183 | tcpDestinationPort | 139 | icmpTypeCodeIPv6 |
| 184 | tcpSequenceNumber | 178 | icmpTypeIPv6 |
| 185 | tcpAcknowledgementNumber | 179 | icmpCodeIPv6 |
| 186 | tcpWindowSize | 33 | igmpType |
+-----+---------------------------+-----+---------------------------+
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
5.6. Sub-IP Header Fields
The set of Information Elements related to Sub-IP header fields
includes the Information Elements listed in the table below.
+-----+---------------------------+-----+---------------------------+
| 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 |
+-----+---------------------------+-----+---------------------------+
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.
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.
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.
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.
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.
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
Reference:
See IEEE.802-3.2002.
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.
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.
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.
5.6.10. mplsTopLabelExp
Description:
The Exp field from the top MPLS label stack entry, i.e., the last
label that was pushed.
Bits 0-4: Don't Care, value is irrelevant.
Bits 5-7: MPLS Exp field.
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| don't care | Exp |
+---+---+---+---+---+---+---+---+
Abstract Data Type: unsigned8
Data Type Semantics: flags
ElementId: 203
Status: current
Reference:
See RFC 3032 for the specification of the Exp field. See RFC 3270
for usage of the Exp field.
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.
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.
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.
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.
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.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | Exp |S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label: Label Value, 20 bits
Exp: Experimental Use, 3 bits
S: Bottom of Stack, 1 bit
Abstract Data Type: octetArray
Data Type Semantics: identifier
ElementId: 70
Status: current
Reference:
See RFC 3032.
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.
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.
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.
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.
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.
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.
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.
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.
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.
5.7. Derived Packet Properties
The set of Information Elements derived from packet properties (for
example, values of header fields) includes the Information Elements
listed in the table below.
+-----+---------------------------+-----+---------------------------+
| ID | Name | ID | Name |
+-----+---------------------------+-----+---------------------------+
| 204 | ipPayloadLength | 18 | bgpNextHopIPv4Address |
| 15 | ipNextHopIPv4Address | 63 | bgpNextHopIPv6Address |
| 62 | ipNextHopIPv6Address | 46 | mplsTopLabelType |
| 16 | bgpSourceAsNumber | 47 | mplsTopLabelIPv4Address |
| 17 | bgpDestinationAsNumber | 140 | mplsTopLabelIPv6Address |
| 128 | bgpNextAdjacentAsNumber | 90 | mplsVpnRouteDistinguisher |
| 129 | bgpPrevAdjacentAsNumber | | |
+-----+---------------------------+-----+---------------------------+
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.
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
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
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.
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.
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.
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.
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.
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.
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.
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.
- 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
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.
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.
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.
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.
5.8. Min/Max Flow Properties
Information Elements in this section are results of minimum or
maximum operations over all packets of a Flow.
+-----+---------------------------+-----+---------------------------+
| ID | Name | ID | Name |
+-----+---------------------------+-----+---------------------------+
| 25 | minimumIpTotalLength | 208 | ipv4Options |
| 26 | maximumIpTotalLength | 64 | ipv6ExtensionHeaders |
| 52 | minimumTTL | 6 | tcpControlBits |
| 53 | maximumTTL | 209 | tcpOptions |
+-----+---------------------------+-----+---------------------------+
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.
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.
5.8.3. minimumTTL
Description:
Minimum TTL value observed for any packet in this Flow.
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.
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.
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.
0 1 2 3 4 5 6 7
+------+------+------+------+------+------+------+------+
| EOOL | NOP | SEC | LSR | TS |E-SEC |CIPSO | RR | ...
+------+------+------+------+------+------+------+------+
8 9 10 11 12 13 14 15
+------+------+------+------+------+------+------+------+
... | SID | SSR | ZSU | MTUP | MTUR | FINN | VISA |ENCODE| ...
+------+------+------+------+------+------+------+------+
16 17 18 19 20 21 22 23
+------+------+------+------+------+------+------+------+
... |IMITD | EIP | TR |ADDEXT|RTRALT| SDB |NSAPA | DPS | ...
+------+------+------+------+------+------+------+------+
24 25 26 27 28 29 30 31
+------+------+------+------+------+------+------+------+
... | UMP | QS | to be assigned by IANA | EXP | |
+------+------+------+------+------+------+------+------+
Type Option
Bit Value Name Reference
---+-----+-------+------------------------------------
0 0 EOOL End of Options List, RFC 791
1 1 NOP No Operation, RFC 791
2 130 SEC Security, RFC 1108
3 131 LSR Loose Source Route, RFC 791
4 68 TS Time Stamp, RFC 791
5 133 E-SEC Extended Security, RFC 1108
6 134 CIPSO Commercial Security
7 7 RR Record Route, RFC 791
8 136 SID Stream ID, RFC 791
9 137 SSR Strict Source Route, RFC 791
10 10 ZSU Experimental Measurement
11 11 MTUP (obsoleted) MTU Probe, RFC 1191
12 12 MTUR (obsoleted) MTU Reply, RFC 1191
13 205 FINN Experimental Flow Control
14 142 VISA Experimental Access Control
15 15 ENCODE
16 144 IMITD IMI Traffic Descriptor
17 145 EIP Extended Internet Protocol, RFC 1385
18 82 TR Traceroute, RFC 3193
19 147 ADDEXT Address Extension
20 148 RTRALT Router Alert, RFC 2113
21 149 SDB Selective Directed Broadcast
22 150 NSAPA NSAP Address
23 151 DPS Dynamic Packet State
24 152 UMP Upstream Multicast Pkt.
25 25 QS Quick-Start
30 30 EXP RFC3692-style Experiment
30 94 EXP RFC3692-style Experiment
30 158 EXP RFC3692-style Experiment
30 222 EXP RFC3692-style Experiment
... ... ... Further options numbers
may be assigned by IANA
Abstract Data Type: unsigned32
Data Type Semantics: flags
ElementId: 208
Status: current
Reference:
See RFC 791 for the definition of IPv4 options. See the list of
IPv4 option numbers assigned by IANA at
http://www.iana.org/assignments/ip-parameters.
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.
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| Res | FRA1| RH | FRA0| UNK | Res | HOP | DST | ...
+-----+-----+-----+-----+-----+-----+-----+-----+
8 9 10 11 12 13 14 15
+-----+-----+-----+-----+-----+-----+-----+-----+
... | PAY | AH | ESP | Reserved | ...
+-----+-----+-----+-----+-----+-----+-----+-----+
16 17 18 19 20 21 22 23
+-----+-----+-----+-----+-----+-----+-----+-----+
... | Reserved | ...
+-----+-----+-----+-----+-----+-----+-----+-----+
24 25 26 27 28 29 30 31
+-----+-----+-----+-----+-----+-----+-----+-----+
... | Reserved |
+-----+-----+-----+-----+-----+-----+-----+-----+
Bit IPv6 Option Description
0, Res Reserved
1, FRA1 44 Fragmentation header - not first fragment
2, RH 43 Routing header
3, FRA0 44 Fragment header - first fragment
4, UNK Unknown Layer 4 header
(compressed, encrypted, not supported)
5, Res Reserved
6, HOP 0 Hop-by-hop option header
7, DST 60 Destination option header
8, PAY 108 Payload compression header
9, AH 51 Authentication Header
10, ESP 50 Encrypted security payload
11 to 31 Reserved
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.
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.
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| Reserved | URG | ACK | PSH | RST | SYN | FIN |
+-----+-----+-----+-----+-----+-----+-----+-----+
Reserved: Reserved for future use by TCP. Must be zero.
URG: Urgent Pointer field significant
ACK: Acknowledgment field significant
PSH: Push Function
RST: Reset the connection
SYN: Synchronize sequence numbers
FIN: No more data from sender
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.
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.
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+
8 9 10 11 12 13 14 15
+-----+-----+-----+-----+-----+-----+-----+-----+
... | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 |...
+-----+-----+-----+-----+-----+-----+-----+-----+
16 17 18 19 20 21 22 23
+-----+-----+-----+-----+-----+-----+-----+-----+
... | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 |...
+-----+-----+-----+-----+-----+-----+-----+-----+
. . .
56 57 58 59 60 61 62 63
+-----+-----+-----+-----+-----+-----+-----+-----+
... | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 |
+-----+-----+-----+-----+-----+-----+-----+-----+
Abstract Data Type: unsigned64
Data Type Semantics: flags
ElementId: 209
Status: current
Reference:
See RFC 793 for the definition of TCP options. See the list of
TCP option numbers assigned by IANA at
http://www.iana.org/assignments/tcp-parameters.
5.9. Flow Timestamps
Information Elements in this section are timestamps of events.
Timestamps flowStartSeconds, flowEndSeconds, flowStartMilliseconds,
flowEndMilliseconds, flowStartMicroseconds, flowEndMicroseconds,
flowStartNanoseconds, flowEndNanoseconds, and
systemInitTimeMilliseconds are absolute and have a well-defined fixed
time base, such as, for example, the number of seconds since 0000 UTC
Jan 1st 1970.
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.
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.
+-----+---------------------------+-----+---------------------------+
| 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 |
+-----+---------------------------+-----+---------------------------+
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
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
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
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
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
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
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
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
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.
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.
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
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
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
5.10. Per-Flow Counters
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, pot