Network Working Group B. Claise, Ed. Internet Draft Cisco Systems, Inc. Obsoletes: 5102 B. Trammell, Ed. Category: Standards Track ETH Zurich Expires: January 14, 2013 July 13, 2012 Information Model for IP Flow Information eXport (IPFIX) draft-ietf-ipfix-information-model-rfc5102bis-03.txt Abstract This document provides an overview of the information model for the IP Flow Information eXport (IPFIX) protocol, as defined in the IANA IPFIX Information Element Registry. 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. This document obsoletes RFC 5102. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 23, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of Claise, Trammell Standards Track [Page 1]
Internet-Draft IPFIX Information Model July 13, 2012 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Changes since RFC 5102 . . . . . . . . . . . . . . . . . . 4 1.2. IPFIX Documents Overview . . . . . . . . . . . . . . . . . 4 2. Properties of IPFIX Protocol Information Elements . . . . . . 5 2.1. Information Element Specification Template . . . . . . . . 5 2.2. Scope of Information Elements . . . . . . . . . . . . . . 7 2.3. Naming Conventions for Information Elements . . . . . . . 8 3. Type Space . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Abstract Data Types . . . . . . . . . . . . . . . . . . . 9 3.1.1. unsigned8 . . . . . . . . . . . . . . . . . . . . . . 9 3.1.2. unsigned16 . . . . . . . . . . . . . . . . . . . . . . 9 3.1.3. unsigned32 . . . . . . . . . . . . . . . . . . . . . . 9 3.1.4. unsigned64 . . . . . . . . . . . . . . . . . . . . . . 9 3.1.5. signed8 . . . . . . . . . . . . . . . . . . . . . . . 9 3.1.6. signed16 . . . . . . . . . . . . . . . . . . . . . . . 10 3.1.7. signed32 . . . . . . . . . . . . . . . . . . . . . . . 10 3.1.8. signed64 . . . . . . . . . . . . . . . . . . . . . . . 10 3.1.9. float32 . . . . . . . . . . . . . . . . . . . . . . . 10 3.1.10. float64 . . . . . . . . . . . . . . . . . . . . . . . 10 3.1.11. boolean . . . . . . . . . . . . . . . . . . . . . . . 10 3.1.12. macAddress . . . . . . . . . . . . . . . . . . . . . 10 3.1.13. octetArray . . . . . . . . . . . . . . . . . . . . . 10 3.1.14. string . . . . . . . . . . . . . . . . . . . . . . . 10 3.1.15. dateTimeSeconds . . . . . . . . . . . . . . . . . . . 11 3.1.16. dateTimeMilliseconds . . . . . . . . . . . . . . . . 11 3.1.17. dateTimeMicroseconds . . . . . . . . . . . . . . . . 11 3.1.18. dateTimeNanoseconds . . . . . . . . . . . . . . . . . 11 3.1.19. ipv4Address . . . . . . . . . . . . . . . . . . . . . 11 3.1.20. ipv6Address . . . . . . . . . . . . . . . . . . . . . 11 3.2. Data Type Semantics . . . . . . . . . . . . . . . . . . . 11 3.2.1. quantity . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.2. totalCounter . . . . . . . . . . . . . . . . . . . . . 12 3.2.3. deltaCounter . . . . . . . . . . . . . . . . . . . . . 12 3.2.4. identifier . . . . . . . . . . . . . . . . . . . . . . 12 3.2.5. flags . . . . . . . . . . . . . . . . . . . . . . . . 12 4. Information Element Identifiers . . . . . . . . . . . . . . . 12 4.1. NetFlow version 9 compatible Information Element Identifiers . . . . . . . . . . . . . . . . . . . . . . . 13 Claise, Trammell Standards Track [Page 2]
Internet-Draft IPFIX Information Model July 13, 2012 5. Information Element Categories . . . . . . . . . . . . . . . . 15 5.1. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 16 5.3. Metering and Exporting Process Statistics . . . . . . . . 17 5.4. IP Header Fields . . . . . . . . . . . . . . . . . . . . . 17 5.5. Transport Header Fields . . . . . . . . . . . . . . . . . 18 5.6. Sub-IP Header Fields . . . . . . . . . . . . . . . . . . . 19 5.7. Derived Packet Properties . . . . . . . . . . . . . . . . 19 5.9. Flow Timestamps . . . . . . . . . . . . . . . . . . . . . 20 5.10. Per-Flow Counters . . . . . . . . . . . . . . . . . . . . 20 5.11. Miscellaneous Flow Properties . . . . . . . . . . . . . . 21 5.12. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 22 6. Extending the Information Model . . . . . . . . . . . . . . . 22 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 7.1. IPFIX Information Elements . . . . . . . . . . . . . . . . 23 7.2. MPLS Label Type Identifier . . . . . . . . . . . . . . . . 23 7.3. XML Namespace and Schema . . . . . . . . . . . . . . . . . 23 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 10.1. Normative References . . . . . . . . . . . . . . . . . . 25 10.2. Informative References . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 OPEN ISSUES: review the NetFlow V9-compatible Information Elements table in Section 4 to ensure that it includes V9 IEs recently made compatible/non-proprietary: 82, 83, 91, 98, 99. What about deltaFlowCount (3)? On second thought, consider removing these tables, they add nothing and ignore the last five years. 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 [RFC5101bis] 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 [RFC5101bis]. The canonical reference for IPFIX Information Elements the IANA IPFIX Information Element registry [IPFIX-IANA]; the initial values for Claise, Trammell Standards Track [Page 3]
Internet-Draft IPFIX Information Model July 13, 2012 this registry were provided by [RFC5102]. This document complements the IPFIX protocol specification by providing an overview of the IPFIX information model and specifying data types for it. IPFIX-specific terminology used in this document is defined in Section 2 of [RFC5101bis]. As in [RFC5101bis], 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 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]. 1.1. Changes since RFC 5102 This document obsoletes the Proposed Standard revision of the IPFIX Protocol Specification [RFC5102]. The following changes have been made to this document with respect to the previous document: - EDITOR'S NOTE: not sure if we need to this information Errata ID: 1307 (technical) Errata ID: 1492 (technical) Errata ID: 1736 (technical) Errata ID: 2879 (editorial) Errata ID: 2944, which updates 1737 (technical) Errata ID: 2945, which updates 1738 (technical) Errata ID: 2946, which updates 1739 (technical) Updated the reference to RFC5101bis Clarified the time-related IEs - Since this document is based on the IPFIX Draft Standard [RFC5101bis], all improvements have been taken into account. For example, the timestamps.- Instead of repeating every Information Elements from [RFC5102], a reference to the IPFIX IANA registry [IPFIX-IANA] is introduced. However the category in section 5 have been kept.- The appendix A and B have been removed- Introduced [IPFIX-IE-DOCTORS] 1.2. IPFIX Documents Overview Claise, Trammell Standards Track [Page 4]
Internet-Draft IPFIX Information Model July 13, 2012 The IPFIX protocol provides network administrators with access to IP flow information. The architecture for the export of measured IP flow information out of an IPFIX Exporting Process to a Collecting Process is defined in [RFC5470], per the requirements defined in [RFC3917]. The IPFIX specifications [RFC5101bis] document specifies how IPFIX data records and templates are carried via a number of transport protocols from IPFIX Exporting Processes to IPFIX Collecting Processes. Four IPFIX optimizations/extensions are currently specified: a bandwidth saving method for the IPFIX protocol in [RFC5473], an efficient method for exporting bidirectional flow in [RFC5103], a method for the definition and export of complex data structures in [RFC6313], and the specification of the Protocol for IPFIX Mediations [IPFIX-MED-PROTO] based on the IPIFX Mediation Framework [RFC6183]. IPFIX has a formal description of IPFIX Information Elements, their name, type and additional semantic information, as specified in this document, with the export of the Information Element types specified in [RFC5610]. [IPFIX-CONF] specifies a data model for configuring and monitoring IPFIX and PSAMP compliant devices using the NETCONF protocol, while the [RFC5815bis] specifies a MIB module for monitoring. In terms of development, [RFC5153] provides guidelines for the implementation and use of the IPFIX protocol, while [RFC5471] provides guidelines for testing. Finally, [RFC5472] describes what type of applications can use the IPFIX protocol and how they can use the information provided. It furthermore shows how the IPFIX framework relates to other architectures and frameworks. 2. Properties of IPFIX Protocol Information Elements 2.1. Information Element Specification Template Information in messages of the IPFIX protocol is modeled in terms of Information Elements of the IPFIX information model. The IPFIX Information Elements mentioned in Section 5 are specified in [IPFIX- IANA]. For specifying these Information Elements, a template is used that is described below. All Information Elements specified for the IPFIX protocol MUST have the following properties defined: name - A unique and meaningful name for the Information Element. Claise, Trammell Standards Track [Page 5]
Internet-Draft IPFIX Information Model July 13, 2012 elementId - A numeric identifier of the Information Element. If this identifier is used without an enterprise identifier (see [RFC5101bis] 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. Information Elements of dataType string or octetArray which have a length constraints (fixed length, minimum and/or maximum length) MUST note these constraints in their description. dataType - One of the types listed in Section 3.1 of this document or registered in the IANA IPFIX Information Element Data Types registry. 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'. All newly-defined Information Elements have 'current' status. The process for moving Information Elements to the 'deprecated' or 'obsolete' status is defined in Section 5.2 of [IPFIX-IE-DOCTORS]. 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 Claise, Trammell Standards Track [Page 6]
Internet-Draft IPFIX Information Model July 13, 2012 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. Information Elements replacing an enterprise-specific Information Element used for experimental or pre-standardization purposes SHOULD define the following property, as outlined in Section 4.9 of [IPFIX- IE-DOCTORS]. enterpriseSpecificReference - The enterpriseId and elementId of the enterprise-specific Information Element(s) replaced by this Information Element. The following two Information Element properties are defined to allow the management of an Information Element registry with Information Element definitions that may be updated over time, per the process defined in Section 5.2 of [IPFIX-IE-DOCTORS]. revision - The revision number of an Information Element, starting at 0 for Information Elements at time of definition, and incremented by one for each revision. date - The date of the entry of this revision of the Information Element into the registry. For Information Elements of the string or octetArray data types which have size limits (minimum and/or maximum size, or fixed length), the limits MUST be defined within the description of the Information Element. 2.2. Scope of Information Elements By default, most Information Elements have a scope specified in their definitions. Claise, Trammell Standards Track [Page 7]
Internet-Draft IPFIX Information Model July 13, 2012 o The Information Elements listed in Sections 5.2 and 5.3, and similar Information Elements in [IPFIX-IANA], have a default of "a specific Metering Process" or of "a specific Exporting Process", respectively. o The Information Elements listed in Sections 5.4-5.11, and similar Information Elements in [IPFIX-IANA], 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 [RFC5101bis]. 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 MUST be unique within the IANA registry. Enterprise-specific Information Elements SHOULD be prefixed with a vendor name. o Names of Information Elements MUST start with non-capitalized letters. o Composed names MUST 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 letters, 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 ipClassOfService. Then the value observed and reported by Information Element ipClassOfService 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 Claise, Trammell Standards Track [Page 8]
Internet-Draft IPFIX Information Model July 13, 2012 IPFIX information model uses Information Elements that have a name prefix "post", for example, "postIpClassOfService". 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 Claise, Trammell Standards Track [Page 9]
Internet-Draft IPFIX Information Model July 13, 2012 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. Claise, Trammell Standards Track [Page 10]
Internet-Draft IPFIX Information Model July 13, 2012 3.1.15. dateTimeSeconds The data type dateTimeSeconds is an unsigned 32-bit integer representing the number of seconds since the UNIX epoch, 1 January 1970 at 00:00 UTC, as defined in [POSIX.1]. 3.1.16. dateTimeMilliseconds The data type dateTimeMilliseconds is an unsigned 64-bit integer containing the number of milliseconds since the UNIX epoch, 1 January 1970 at 00:00 UTC, as defined in [POSIX.1]. 3.1.17. dateTimeMicroseconds The type "dateTimeMicroseconds" represents a time value with microsecond precision according to the NTP Timestamp format as defined in section 6 of [RFC5905]. 3.1.18. dateTimeNanoseconds The type "dateTimeNanoseconds" represents a time value with nanosecond precision according to the NTP Timestamp format as defined in section 6 of [RFC5905]. 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. A registry of data type semantics is established in [RFC5610]; the restrictions specified in section 3.10 of that document are followed here. Note that further data type semantics may be specified by future extensions of the IPFIX information model. These semantics apply only to numeric types, as noted in the description of each semantic below. 3.2.1. quantity A numeric (integral or floating point) value representing a 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. This is the default semantic type Claise, Trammell Standards Track [Page 11]
Internet-Draft IPFIX Information Model July 13, 2012 of all numeric data types. 3.2.2. totalCounter An numeric 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 [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 numeric 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. Identifiers MUST be one of the signed or unsigned data types. 3.2.5. flags An integral value that represents a set of bit fields. Logical operations are appropriate on such values, but not other mathematical operations. Flags MUST always be of an unsigned data type. 4. Information Element Identifiers All Information Elements defined in the IANA IPFIX Information Element registry [IPFIX-IANA] have their identifiers assigned by IANA. Claise, Trammell Standards Track [Page 12]
Internet-Draft IPFIX Information Model July 13, 2012 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]; Information Element identifiers in this range MUST NOT be assigned unless the Information Element is compatible with the NetFlow version 9 protocol. Such Information Elements may ONLY be requested by a NetFlow v9 expert, to be designated by the IESG. In general, IANA will add newly registered Information Elements to the registry, assigning the lowest available Information Element identifier in the range 128-32767. Enterprise-specific Information Element identifiers have the same range of 1-32767, but they are coupled with an additional enterprise identifier. For enterprise-specific Information Elements, Information Element identifier 0 is also reserved. 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; these Information Elements are distinct 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. 4.1. NetFlow version 9 compatible Information Element Identifiers The following list gives an overview of the Information Element identifiers that are compatible with field types used by NetFlow version 9 [RFC3954]. Claise, Trammell Standards Track [Page 13]
Internet-Draft IPFIX Information Model July 13, 2012 +----+----------------------------+-------+-------------------------+ | 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| | | +----+----------------------------+-------+-------------------------+ Claise, Trammell Standards Track [Page 14]
Internet-Draft IPFIX Information Model July 13, 2012 5. Information Element Categories This section describes the Information Element category for the IPFIX information model at the time that [RFC5102] was published. Since this category field is not part of the IANA process for assigning new Information Element (even though it has been reused, for example, in [RFC5103]), the newest Information Elements in IANA [IPFIX-IANA] don't have this classification. 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, "postIpClassOfService", 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. Claise, Trammell Standards Track [Page 15]
Internet-Draft IPFIX Information Model July 13, 2012 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 | | | +-----+---------------------------+-----+---------------------------+ See [