Network Working Group J. Quittek Request for Comments: 5102 NEC Category: Standards Track S. Bryant B. Claise P. Aitken Cisco Systems, Inc. J. Meyer PayPal January 2008 Information Model for IP Flow Information Export 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 .......88
Appendix B. XML Specification of Abstract Data Types .............157
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.
(page 14 continued on part 2)
