Network Working Group J. Quittek Internet-Draft NEC Expires: August 21, 2005 S. Bryant Cisco Systems Ltd J. Meyer PayPal February 20, 2005 Information Model for IP Flow Information Export draft-ietf-ipfix-info-06 Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 21, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This memo defines and 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 Quittek, et al. Expires August 21, 2005 [Page 1] Internet-Draft IPFIX Information Model February 2005 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 . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Properties of IPFIX Protocol Information Elements . . . . . 6 3. Type Space . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1 Data Types . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1.1 octet . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1.2 unsigned16 . . . . . . . . . . . . . . . . . . . . . . 8 3.1.3 unsigned32 . . . . . . . . . . . . . . . . . . . . . . 8 3.1.4 unsigned64 . . . . . . . . . . . . . . . . . . . . . . 8 3.1.5 float32 . . . . . . . . . . . . . . . . . . . . . . . 8 3.1.6 boolean . . . . . . . . . . . . . . . . . . . . . . . 8 3.1.7 octetArray . . . . . . . . . . . . . . . . . . . . . . 8 3.1.8 string . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1.9 dateTimeSeconds . . . . . . . . . . . . . . . . . . . 9 3.1.10 dateTimeMicroSeconds . . . . . . . . . . . . . . . . 9 3.1.11 ipv4Address . . . . . . . . . . . . . . . . . . . . 9 3.1.12 ipv6Address . . . . . . . . . . . . . . . . . . . . 9 3.2 Data Type Semantics . . . . . . . . . . . . . . . . . . . 9 3.2.1 quantity . . . . . . . . . . . . . . . . . . . . . . . 9 3.2.2 totalCounter . . . . . . . . . . . . . . . . . . . . . 9 3.2.3 deltaCounter . . . . . . . . . . . . . . . . . . . . . 10 3.2.4 identifier . . . . . . . . . . . . . . . . . . . . . . 10 3.2.5 flags . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Information Element Identifiers . . . . . . . . . . . . . . 11 5. Information Elements . . . . . . . . . . . . . . . . . . . . 13 5.1 IP Header Fields . . . . . . . . . . . . . . . . . . . . . 13 5.1.1 ipVersion . . . . . . . . . . . . . . . . . . . . . . 13 5.1.2 sourceIPv4Address . . . . . . . . . . . . . . . . . . 14 5.1.3 sourceIPv6Address . . . . . . . . . . . . . . . . . . 14 5.1.4 sourceIPv4Mask . . . . . . . . . . . . . . . . . . . . 15 5.1.5 sourceIPv6Mask . . . . . . . . . . . . . . . . . . . . 15 5.1.6 sourceIPv4Prefix . . . . . . . . . . . . . . . . . . . 15 5.1.7 destinationIPv4Address . . . . . . . . . . . . . . . . 16 5.1.8 destinationIPv6Address . . . . . . . . . . . . . . . . 16 5.1.9 destinationIPv4Mask . . . . . . . . . . . . . . . . . 16 5.1.10 destinationIPv6Mask . . . . . . . . . . . . . . . . 16 5.1.11 destinationIPv4Prefix . . . . . . . . . . . . . . . 17 5.1.12 classOfServiceIPv4 . . . . . . . . . . . . . . . . . 17 5.1.13 classOfServiceV6 . . . . . . . . . . . . . . . . . . 18 5.1.14 flowLabelV6 . . . . . . . . . . . . . . . . . . . . 18 5.1.15 identificationV4 . . . . . . . . . . . . . . . . . . 18 5.1.16 protocolIdentifier . . . . . . . . . . . . . . . . . 19 5.2 Trandport Header Fields . . . . . . . . . . . . . . . . . 19 Quittek, et al. Expires August 21, 2005 [Page 2] Internet-Draft IPFIX Information Model February 2005 5.2.1 sourceTransportPort . . . . . . . . . . . . . . . . . 19 5.2.2 destinationtransportPort . . . . . . . . . . . . . . . 20 5.2.3 icmpTypeCode . . . . . . . . . . . . . . . . . . . . . 20 5.2.4 igmpType . . . . . . . . . . . . . . . . . . . . . . . 21 5.3 Sub-IP Header Fields . . . . . . . . . . . . . . . . . . . 21 5.3.1 sourceMacAddress . . . . . . . . . . . . . . . . . . . 21 5.3.2 mplsLabelStackEntry1 . . . . . . . . . . . . . . . . . 22 5.3.3 mplsLabelStackEntry2 . . . . . . . . . . . . . . . . . 22 5.3.4 mplsLabelStackEntry3 . . . . . . . . . . . . . . . . . 22 5.3.5 mplsLabelStackEntry4 . . . . . . . . . . . . . . . . . 23 5.3.6 mplsLabelStackEntry5 . . . . . . . . . . . . . . . . . 23 5.3.7 mplsLabelStackEntry6 . . . . . . . . . . . . . . . . . 23 5.3.8 mplsLabelStackEntry7 . . . . . . . . . . . . . . . . . 24 5.3.9 mplsLabelStackEntry8 . . . . . . . . . . . . . . . . . 24 5.3.10 mplsLabelStackEntry9 . . . . . . . . . . . . . . . . 24 5.3.11 mplsLabelStackEntry10 . . . . . . . . . . . . . . . 25 5.4 Derived Packet Properties . . . . . . . . . . . . . . . . 25 5.4.1 ipNextHopIPv4Address . . . . . . . . . . . . . . . . . 25 5.4.2 ipNextHopIPv6Address . . . . . . . . . . . . . . . . . 26 5.4.3 ingressInterface . . . . . . . . . . . . . . . . . . . 26 5.4.4 egressInterface . . . . . . . . . . . . . . . . . . . 26 5.4.5 ipNextHopAsNumber . . . . . . . . . . . . . . . . . . 27 5.4.6 bgpSourceAsNumber . . . . . . . . . . . . . . . . . . 27 5.4.7 bgpDestinationAsNumber . . . . . . . . . . . . . . . . 27 5.4.8 bgpNextHopAsNumber . . . . . . . . . . . . . . . . . . 28 5.4.9 bgpNextHopIPv4Address . . . . . . . . . . . . . . . . 28 5.4.10 bgpNextHopIPv6Address . . . . . . . . . . . . . . . 28 5.4.11 mplsTopLabelType . . . . . . . . . . . . . . . . . . 29 5.4.12 mplsTopLabelIPv4Address . . . . . . . . . . . . . . 29 5.4.13 mplsTopLabelIPv6Address . . . . . . . . . . . . . . 29 5.5 Properties of Metering/Exporting Process . . . . . . . . . 30 5.5.1 exporterIPv4Address . . . . . . . . . . . . . . . . . 30 5.5.2 exporterIPv6Address . . . . . . . . . . . . . . . . . 30 5.6 Min/Max Flow Properties . . . . . . . . . . . . . . . . . 30 5.6.1 minimumPacketLength . . . . . . . . . . . . . . . . . 31 5.6.2 maximumPacketLength . . . . . . . . . . . . . . . . . 31 5.6.3 minimumTTL . . . . . . . . . . . . . . . . . . . . . . 32 5.6.4 maximumTTL . . . . . . . . . . . . . . . . . . . . . . 32 5.6.5 ipv6OptionHeaders . . . . . . . . . . . . . . . . . . 32 5.6.6 tcpControlBits . . . . . . . . . . . . . . . . . . . . 33 5.6.7 flowCreationTime . . . . . . . . . . . . . . . . . . . 33 5.6.8 flowEndTime . . . . . . . . . . . . . . . . . . . . . 34 5.6.9 flowActiveTimeOut . . . . . . . . . . . . . . . . . . 34 5.6.10 flowInactiveTimeout . . . . . . . . . . . . . . . . 34 5.6.11 flowEndReason . . . . . . . . . . . . . . . . . . . 34 5.7 Per-Flow Counters . . . . . . . . . . . . . . . . . . . . 35 5.7.1 inOctetDeltaCount . . . . . . . . . . . . . . . . . . 36 5.7.2 outOctetDeltaCount . . . . . . . . . . . . . . . . . . 36 Quittek, et al. Expires August 21, 2005 [Page 3] Internet-Draft IPFIX Information Model February 2005 5.7.3 octetDeltaCount . . . . . . . . . . . . . . . . . . . 36 5.7.4 inOctetTotalCount . . . . . . . . . . . . . . . . . . 37 5.7.5 inPacketDeltaCount . . . . . . . . . . . . . . . . . . 37 5.7.6 outPacketDeltaCount . . . . . . . . . . . . . . . . . 37 5.7.7 packetDeltaCount . . . . . . . . . . . . . . . . . . . 38 5.7.8 inPacketTotalCount . . . . . . . . . . . . . . . . . . 38 5.7.9 droppedOctetDeltaCount . . . . . . . . . . . . . . . . 38 5.7.10 droppedOctetTotalCount . . . . . . . . . . . . . . . 39 5.7.11 droppedPacketDeltaCount . . . . . . . . . . . . . . 39 5.7.12 droppedPacketTotalCount . . . . . . . . . . . . . . 40 5.7.13 outMulticastPacketCount . . . . . . . . . . . . . . 40 5.7.14 outMulticastOctetCount . . . . . . . . . . . . . . . 40 5.8 Process Counters . . . . . . . . . . . . . . . . . . . . . 41 5.8.1 observedFlowTotalCount . . . . . . . . . . . . . . . . 41 5.8.2 exportedOctetTotalCount . . . . . . . . . . . . . . . 41 5.8.3 exportedPacketTotalCount . . . . . . . . . . . . . . . 42 5.8.4 exportedFlowTotalCount . . . . . . . . . . . . . . . . 42 6. Extending the Information Model . . . . . . . . . . . . . . 43 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 44 8. Security Considerations . . . . . . . . . . . . . . . . . . 45 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 46 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 10.1 Normative Reference . . . . . . . . . . . . . . . . . . . 47 10.2 Informative Reference . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 48 A. Formal Specification of IPFIX Fields . . . . . . . . . . . . 50 B. Formal Specification of Abstract Data Types . . . . . . . . 74 Intellectual Property and Copyright Statements . . . . . . . 85 Quittek, et al. Expires August 21, 2005 [Page 4] Internet-Draft IPFIX Information Model February 2005 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 [IPFIX-PROTO] defines how information elements are transmitted. For information elements, it specifies the encoding of a set of basic data types. However, the list of fields 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, smapling rate, flow timeout interval, etc.), is not specified in [IPFIX-PROTO]. This document complements the IPFIX protocol specification by providing the IPFIX information model. IPFIX-specific terminology used in this document including terms such as 'IP Traffic Flow', 'Observation Point', 'Metering Process', 'Exporting Process', and 'Collecting Process' is defined in [IPFIX-PROTO]. The main part of this document is Section 5 defining the (extensible) list of fields to be transmitted by the IPFIX protcol. Section 2 defines a template for specifying IPFIX fields that is used in Section 4. Section 3 defines the set of abstract data types that are available for IPFIX fields. Section 5 discusses extensibility of the IPFIX information model. The main bodies of Sections 2, 3 and 4 were generated from XML documents. The XML-based specification of template, abstract data types and IPFIX fields can be used for automatically checking syntactical correctness of the specification of IPFIX fields. It can further be used for generating IPFIX protocol implementation code that deals with processing IPFIX fields. Also code for applications that further process traffic information transmitted via the IPFIX protocol can be generated with the XML specification of IPFIX fields. For that reason, the XML document that served as source for Section 4 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. Quittek, et al. Expires August 21, 2005 [Page 5] Internet-Draft IPFIX Information Model February 2005 2. Properties of IPFIX Protocol Information Elements Fields in messages of the IPFIX protocol carrying information about traffic measurement are modeled as elements of the IPFIX information model and specified in Section 4. For defining these information elements, a template is used that is specified 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. The preferred spelling for the name is to use mixed case if the name is compound, with an initial lower case letter, e.g., "sourceIpAddress". fieldId - A numeric identifier administered by IANA. This is used for compact identification of an information item when encoding templates in the protocol. description - The semantics of this information element. Describes how this field 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 an 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 IPAddress) which are common to this domain and useful to distinguish. applicability - This propoerty of an information element indicates in which kind of records the element can be used. Allowed values for this property are 'data', 'option', and 'all'. status - The status of the specification of this information element. Allowed values are 'current', 'deprecated', and 'obsolete'. All information elements specified for the IPFIX protocol either in this document or by any future extension MAY have the following properties defined: enterpriseId - When extension is done outside of the scope of the IANA IPFIX fieldId range, a enterpriseId MUST be provided. Valid values for the enterpriseId are defined by IANA as SMI network management private enterprise code. They are defined at http://www.iana.org/assignments/enterprise-numbers. 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 an extension of the information model. Quittek, et al. Expires August 21, 2005 [Page 6] Internet-Draft IPFIX Information Model February 2005 units - If the field is a measure of some kind, the units identify what the measure is. enumeratedRange - Some items may have a specific set of numeric identifiers associated with a set of discrete values this element may take. The meaning of each discrete value and a human readable name should be assigned. range - Some elements may only be able to take on a restricted set of values which 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 which more precisely define this item or provide additional context for its use. Quittek, et al. Expires August 21, 2005 [Page 7] Internet-Draft IPFIX Information Model February 2005 3. Type Space This section describes the abstract data types that can be used for the specification of IPFIX fields in Section 4. Section 3.1 describes the set of data types. For the integral data types octet, unsigned16, unsigned32, and unsigned64 also data type semantics can be specified, such as, for example, 'counter', 'identifier' or 'flags'. Data type semantics are specified in section 3.2. 3.1 Data Types This section describes the set of valid data types of the IPFIX information model. Note that further data types may be specified by protocol extensions. 3.1.1 octet The type "octet" 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 float32 The type "float32" corresponds to an IEEE single-precision 32-bit floating point type. 3.1.6 boolean The type "boolean" represents a binary value. 3.1.7 octetArray The type "octetArray" represents a finite length string of octets. Quittek, et al. Expires August 21, 2005 [Page 8] Internet-Draft IPFIX Information Model February 2005 3.1.8 string The type "string" represents a finite length string of valid characters from the Unicode character encoding set. Unicode allows for ASCII and many other international character sets to be used. It is expected that strings will be encoded in UTF-8 format, which is identical in encoding for USASCII characters, but also accomodates other Unicode multibyte characters. 3.1.9 dateTimeSeconds The type "dateTimeSeconds" represents a time value having a precision of seconds and normalized to the GMT timezone. Such types are in common use on many operating systems and have the advantage that they can be stored in 32-bit integers. 3.1.10 dateTimeMicroSeconds The type "dateTimeSeconds" represents a time value having a precision of microseconds and normalized to the GMT timezone. 3.1.11 ipv4Address The type "ipv4Addr" represents a value of an IPv4 address. These addresses are typically stored as 32-bit integers. 3.1.12 ipv6Address The type "ipv6Addr" 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 protocol extensions. 3.2.1 quantity A quantity value represents a discrete measured value pertaining to the record. This is distinguished from counters which represent an ongoing measured value whose "odometer" reading is captured as part of a given record. If no semantic qualifier is given, the integral fields should behave as a quantity. 3.2.2 totalCounter A measurement which is ongoing from the perspective of the Exporter. Quittek, et al. Expires August 21, 2005 [Page 9] Internet-Draft IPFIX Information Model February 2005 Basically the same semantics as counters in SNMP. 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. A running counter counts independent of the export of its value. 3.2.3 deltaCounter A measurement which is ongoing from the perspective of the Exporter. Basically the same semantics as counters in SNMP. 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. A delta counter is reset to zero each time its value is exported. 3.2.4 identifier An integral value which 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 which 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. Quittek, et al. Expires August 21, 2005 [Page 10] Internet-Draft IPFIX Information Model February 2005 4. Information Element Identifiers The elements of this information model are identified by the combination of a field identifier and an optional enterprise identifier. Standardized information elements defined in section 5 of this document or in extensions of the IPFIX information model have their values assigned by IANA. These values are in the range of 1 - 32767. In this range, the value of the most significant bit in a 16-bit-representation always equals 0. Enterprise-specific field IDs are in the range of 32768 - 65535. In this range, the value of the most significant bit in a 16-bit-representation always equals 1. This choice of ranges allows a Collecting Process to clearly and easily distinguished standardized fields from enterprise-specific fields by just checking a single bit. +---------------------------------+---------------------------------+ | Field ID Range | Description | +---------------------------------+---------------------------------+ | 0 | reserved | | | | | 1 - 127 | standardized field IDs | | | compatible to NetFlow version 9 | | | | | 128 - 32767 | standardized field IDs assigned | | | by IANA | | | | | 32768 - 65535 | enterprise-defined field IDs | +---------------------------------+---------------------------------+ Enterprise-specific IDs can be chosen by an enterprise arbitrarily within the given range. The same ID may be assigned by different enterprises for different purposes. In order to ensure that Collecting Processes can always identify information elements uniquely, enterprise-specific information elements are identified by the combination of a field ID and an enterprise ID. Valid valuse for enterprise IDs are also assigned by IANA. The IPFIX information model uses the SMI network management private enterprise code defined at http://www.iana.org/assignments/enterprise-numbers as the set of valid numbers for enterprise IDs. Enterprise IDs used for identifying IPFIX information elements MUST be registered as SMI network management private enterprise code numbers at IANA. The following list gives an overview of field IDs used as identifiers of the information elements specified in section 5. Quittek, et al. Expires August 21, 2005 [Page 11] Internet-Draft IPFIX Information Model February 2005 +-------+-------------------------+-------+-------------------------+ | ID | Field Name | ID | Field Name | +-------+-------------------------+-------+-------------------------+ | 1 | inOctetDeltaCount | 44 | sourceIPv4Prefix | | 2 | inPacketDeltaCount | 45 | destinationIPv4Prefix | | 3 | totalFlowCount | 46 | mplsTopLabelType | | 4 | protocolIdentifier | 47 | mplsTopLabelIPv4Address | | 5 | classOfServiceIPv4 | 48-51 | RESERVED | | 6 | tcpControlBits | 52 | minimumTTL | | 7 | sourceTransportPort | 53 | maximumTTL | | 8 | sourceIPv4Address | 54 | identificationIPv4 | | 9 | sourceIPv4Mask | 55 | RESERVED | | 10 | ingressInterface | 56 | sourceMacAddress | | 11 | destinationTransportPort| 57-59 | RESERVED | | 12 | destinationIPv4Address | 60 | ipVersion | | 13 | destinationIPv4Mask | 61 | RESERVED | | 14 | egressInterface | 62 | ipNextHopIPv6Address | | 15 | ipNextHopIPv4Address | 63 | bgpNextHopIPv6Address | | 16 | bgpSourceAsNumber | 64 | ipv6OptionHeaders | | 17 | bgpDestinationAsNumber | 65-69 | RESERVED | | 18 | bgpNextHopIPv4Address | 70 | mplsLabelStackEntry1 | | 19 | OutMulticastPacketCount | 71 | mplsLabelStackEntry2 | | 20 | OutMulticastOctetCount | 72 | mplsLabelStackEntry3 | | 21 | flowEndTime | 73 | mplsLabelStackEntry4 | | 22 | flowCreationTime | 74 | mplsLabelStackEntry5 | | 23 | outOctetDeltaCount | 75 | mplsLabelStackEntry6 | | 24 | outPacketDeltaCount | 76 | mplsLabelStackEntry7 | | 25 | minimumPacketLength | 77 | mplsLabelStackEntry8 | | 26 | maximumPacketLength | 78 | mplsLabelStackEntry9 | | 27 | sourceIPv6Address | 79 | mplsLabelStackEntry10 | | 28 | destinationIPv6Address | 80-84 | RESERVED | | 29 | sourceIPv6Mask | 85 | inOctetTotalCount | | 30 | destinationIPv6Mask | 86 | inPacketTotalCount | | 31 | flowLabelIPv6 |87-127 | RESERVED | | 32 | icmpTypeCode | 128 | bgpNextHopAsNumber | | 33 | igmpType | 129 | ipNextHopAsNumber | | 34-35 | RESERVED | 130 | exporterIPv4Address | | 36 | flowActiveTimeOut | 131 | exporterIPv6Address | | 37 | flowInactiveTimeout | 132 | droppedOctetDeltaCount | | 38-39 | RESERVED | 133 | droppedPacketDeltaCount | | 40 | exportedOctetCount | 134 | droppedOctetTotalCount | | 41 | exportedPacketCount | 135 | droppedPacketTotalCount | | 42 | exportedFlowCount | 136 | flowEndReason | | 43 | RESERVED | 137 | classOfServiceIPv6 | | | | 138 | octetDeltaCount | | | | 139 | packetDeltaCount | | | | 140 | mplsTopLabelIPv6Address | +-------+-------------------------+-------+-------------------------+ Quittek, et al. Expires August 21, 2005 [Page 12] Internet-Draft IPFIX Information Model February 2005 5. Information Elements This section describes the flow attributes of the IPFIX information model. The elements are grouped into 8 groups according to their semantics and their applicability. 5.1 IP Header Fields Information elements in this section indicate values of header fields or are derived from IP header field values in combination with further information. These information elements can serve as part of a flow key used for mapping packets to flows. But also they may contain values related to header fields that are not constant for a single flow. For example a flow using a certain source IPv4 address as flow key has sourceAddressV4 as constant property but may have destinationAddressV4 as a property that changes from packet to packet. For information elements that are not constant for a flow, the value MUST be the value of the first packet observed for this flow. 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 the counters need to be increased. The set of information elements related to IP header fields includes the information elements listed in the table below. +-------+-------------------------+-------+-------------------------+ | ID | Field Name | ID | Field Name | +-------+-------------------------+-------+-------------------------+ | 60 | ipVersion | 5 | classOfServiceIPv4 | | 8 | sourceIPv4Address | 137 | classOfServiceIPv6 | | 27 | sourceIPv6Address | 31 | flowLabelIPv6 | | 9 | sourceIPv4Mask | 54 | identificationIPv4 | | 29 | sourceIPv6Mask | 4 | protocolIdentifier | | 44 | sourceIPv4Prefix | | | | 12 | destinationIPv4Address | | | | 28 | destinationIPv6Address | | | | 13 | destinationIPv4Mask | | | | 30 | destinationIPv6Mask | | | | 45 | destinationIPv4Prefix | | | +-------+-------------------------+-------+-------------------------+ 5.1.1 ipVersion Quittek, et al. Expires August 21, 2005 [Page 13] Internet-Draft IPFIX Information Model February 2005 Description: The IP version field given in the IP header. Abstract Data Type: octet FieldId: 60 Applicability: all Status: current Units: flows Reference: See RFC 791 for a definition of the version field in the IPv6 packet header. See RFC 2460 for a 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.1.2 sourceIPv4Address Description: IPv4 source address taken from the IP packet header of a packet of this flow. Abstract Data Type: ipv4Address FieldId: 8 Applicability: all Status: current Reference: See RFC 791 for the definition of the IPv4 source address field. 5.1.3 sourceIPv6Address Description: IPv6 source address taken from the IP packet header of a packet of this flow. Abstract Data Type: ipv6Address FieldId: 27 Applicability: all Status: current Quittek, et al. Expires August 21, 2005 [Page 14] Internet-Draft IPFIX Information Model February 2005 5.1.4 sourceIPv4Mask Description: The number of contiguous bits that are relevant in the sourceAddressV4 field. Abstract Data Type: octet FieldId: 9 Applicability: option Status: current Units: bits Range: The valid range is 0-32. 5.1.5 sourceIPv6Mask Description: The number of contiguous bits that are relevant in the sourceAddressV6 field. Abstract Data Type: octet FieldId: 29 Applicability: option Status: current Units: bits Range: The valid range is 0-128. 5.1.6 sourceIPv4Prefix Description: IPv4 source address prefix. EDITOR'S NOTE: to be discussed on ipfix mailing list Abstract Data Type: ipV4Address FieldId: 44 Applicability: data Status: current Units: flows Quittek, et al. Expires August 21, 2005 [Page 15] Internet-Draft IPFIX Information Model February 2005 5.1.7 destinationIPv4Address Description: IPv4 destination address taken from the IP packet header of a packet of this flow. Abstract Data Type: ipv4Address FieldId: 12 Applicability: all Status: current Reference: See RFC 791 for the definition of the IPv4 destination address field. 5.1.8 destinationIPv6Address Description: IPv6 destination address taken from the IP packet header of a packet of this flow. Abstract Data Type: ipv6Address FieldId: 28 Applicability: all Status: current 5.1.9 destinationIPv4Mask Description: The number of contiguous bits that are relevant in the destinationAddressV4 field. Abstract Data Type: octet FieldId: 13 Applicability: option Status: current Units: bits Range: The valid range is 0-32. 5.1.10 destinationIPv6Mask Quittek, et al. Expires August 21, 2005 [Page 16] Internet-Draft IPFIX Information Model February 2005 Description: The number of contiguous bits that are relevant in the destinationAddressV6 field. Abstract Data Type: octet FieldId: 30 Applicability: option Status: current Units: bits Range: The valid range is 0-128. 5.1.11 destinationIPv4Prefix Description: IPv4 destination address prefix. EDITOR'S NOTE: to be discussed on ipfix mailing list Abstract Data Type: ipV4Address FieldId: 45 Applicability: data Status: current Units: flows 5.1.12 classOfServiceIPv4 Description: The value of the IPv4 TOS field observed for packets of this flow. Abstract Data Type: octet Data Type Semantics: identifier FieldId: 5 Applicability: all Status: current Reference: See RFC 791 for the definition of the IPv4 TOS field. Quittek, et al. Expires August 21, 2005 [Page 17] Internet-Draft IPFIX Information Model February 2005 5.1.13 classOfServiceV6 Description: The value of the IPv6 traffic class field observed for packets of this flow. Abstract Data Type: octet FieldId: 137 Applicability: data Status: current Reference: See RFC 2460 for the definition of the IPv6 traffic class field. 5.1.14 flowLabelV6 Description: The Flow Label of the IPv6 packet header observed in the first packet of this flow. Abstract Data Type: unsigned32 FieldId: 31 Applicability: all Status: current Reference: See RFC 2460 for a definition of the flow label field in the IPv6 packet header. 5.1.15 identificationV4 Description: The IPv4 packet identification field from the first packet of this flow. Abstract Data Type: unsigned16 Data Type Semantics: identifier FieldId: 54 Applicability: data Status: current Reference: See RFC 791 for the definition of the IPv4 identification field. Quittek, et al. Expires August 21, 2005 [Page 18] Internet-Draft IPFIX Information Model February 2005 5.1.16 protocolIdentifier Description: The protocol number observed for packets of this flow. The protocol number identifies the IP packet payload. 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: octet Data Type Semantics: identifier FieldId: 4 Applicability: all 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 list of protocol numbers assigned by IANA at http://www.iana.org/assignments/protocol-numbers. 5.2 Trandport Header Fields The set of information elements related to transport header fields includes the information elements listed in the table below. +-------+-------------------------+-------+-------------------------+ | ID | Field Name | ID | Field Name | +-------+-------------------------+-------+-------------------------+ | 7 | sourceTransportPort | 32 | icmpTypeCode | | 11 | destinationTransportPort| 33 | igmpType | +-------+-------------------------+-------+-------------------------+ 5.2.1 sourceTransportPort Description: A source port identifier in the transport header. For 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 Quittek, et al. Expires August 21, 2005 [Page 19] Internet-Draft IPFIX Information Model February 2005 FieldId: 7 Applicability: all 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 2960 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.2 destinationtransportPort Description: A destination port identifier in the transport header. For 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 FieldId: 11 Applicability: all 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 2960 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.3 icmpTypeCode Description: Type and Code of the ICMP message. The combination of both values is reported as (ICMP type * 256) + ICMP code. Abstract Data Type: unsigned16 FieldId: 32 Applicability: all Status: current Quittek, et al. Expires August 21, 2005 [Page 20] Internet-Draft IPFIX Information Model February 2005 Reference: See RFC 792 for a definition of the ICMP type and code fields. 5.2.4 igmpType Description: The type field of the IGMP message. Abstract Data Type: octet FieldId: 33 Applicability: all Status: current Reference: See RFC 2236 for a definition of the IGMP type field. 5.3 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 | Field Name | ID | Field Name | +-------+-------------------------+-------+-------------------------+ | 56 | sourceMacAddress | 75 | mplsLabelStackEntry6 | | 70 | mplsLabelStackEntry1 | 76 | mplsLabelStackEntry7 | | 71 | mplsLabelStackEntry2 | 77 | mplsLabelStackEntry8 | | 72 | mplsLabelStackEntry3 | 78 | mplsLabelStackEntry9 | | 73 | mplsLabelStackEntry4 | 79 | mplsLabelStackEntry10 | | 74 | mplsLabelStackEntry5 | | | +-------+-------------------------+-------+-------------------------+ 5.3.1 sourceMacAddress Description: Packet identification field from the first IP packet of this flow. Abstract Data Type: octetArray FieldId: 56 Applicability: data Status: current Reference: See RFC 791 for the definition of the IPv4 identification field. Quittek, et al. Expires August 21, 2005 [Page 21] Internet-Draft IPFIX Information Model February 2005 5.3.2 mplsLabelStackEntry1 Description: The label, exp and s fields from the outermost MPLS label stack entry e.g. the last label that was pushed last. 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: unsigned32 FieldId: 70 Applicability: all Status: current Reference: See RFC 3032. 5.3.3 mplsLabelStackEntry2 Description: The label, exp and s fields from the LSE that was pushed immediately before the LSE that would be reported by mplsLabelStackEntry1. See the definition of mplsLabelStackEntry1 for further details. Abstract Data Type: unsigned32 FieldId: 71 Applicability: all Status: current Reference: See RFC 3032. 5.3.4 mplsLabelStackEntry3 Description: The label, exp and s fields from the LSE that was pushed immediately before the LSE that would be reported by mplsLabelStackEntry2. See the definition of mplsLabelStackEntry1 for further details. Abstract Data Type: unsigned32 Quittek, et al. Expires August 21, 2005 [Page 22] Internet-Draft IPFIX Information Model February 2005 FieldId: 72 Applicability: all Status: current Reference: See RFC 3032. 5.3.5 mplsLabelStackEntry4 Description: The label, exp and s fields from the LSE that was pushed immediately before the LSE that would be reported by mplsLabelStackEntry3. See the definition of mplsLabelStackEntry1 for further details. Abstract Data Type: unsigned32 FieldId: 73 Applicability: all Status: current Reference: See RFC 3032. 5.3.6 mplsLabelStackEntry5 Description: The label, exp and s fields from the LSE that was pushed immediately before the LSE that would be reported by mplsLabelStackEntry4. See the definition of mplsLabelStackEntry1 for further details. Abstract Data Type: unsigned32 FieldId: 74 Applicability: all Status: current Reference: See RFC 3032. 5.3.7 mplsLabelStackEntry6 Description: The label, exp and s fields from the LSE that was pushed immediately before the LSE that would be reported by mplsLabelStackEntry5. See the definition of mplsLabelStackEntry1 for further details. Abstract Data Type: unsigned32 Quittek, et al. Expires August 21, 2005 [Page 23] Internet-Draft IPFIX Information Model February 2005 FieldId: 75 Applicability: all Status: current Reference: See RFC 3032. 5.3.8 mplsLabelStackEntry7 Description: The label, exp and s fields from the LSE that was pushed immediately before the LSE that would be reported by mplsLabelStackEntry6. See the definition of mplsLabelStackEntry1 for further details. Abstract Data Type: unsigned32 FieldId: 76 Applicability: all Status: current Reference: See RFC 3032. 5.3.9 mplsLabelStackEntry8 Description: The label, exp and s fields from the LSE that was pushed immediately before the LSE that would be reported by mplsLabelStackEntry7. See the definition of mplsLabelStackEntry1 for further details. Abstract Data Type: unsigned32 FieldId: 77 Applicability: all Status: current Reference: See RFC 3032. 5.3.10 mplsLabelStackEntry9 Description: The label, exp and s fields from the LSE that was pushed immediately before the LSE that would be reported by mplsLabelStackEntry8. See the definition of mplsLabelStackEntry1 for further details. Abstract Data Type: unsigned32 Quittek, et al. Expires August 21, 2005 [Page 24] Internet-Draft IPFIX Information Model February 2005 FieldId: 78 Applicability: all Status: current Reference: See RFC 3032. 5.3.11 mplsLabelStackEntry10 Description: The label, exp and s fields from the LSE that was pushed immediately before the LSE that would be reported by mplsLabelStackEntry9. See the definition of mplsLabelStackEntry1 for further details. Abstract Data Type: unsigned32 FieldId: 79 Applicability: all Status: current Reference: See RFC 3032. 5.4 Derived Packet Properties The set of information elements derived from values of header fields and further information includes the information elements listed in the table below. +-------+-------------------------+-------+-------------------------+ | ID | Field Name | ID | Field Name | +-------+-------------------------+-------+-------------------------+ | 15 | ipNextHopIPv4Address | 128 | bgpNextHopAsNumber | | 62 | ipNextHopIPv6Address | 18 | bgpNextHopIPv4Address | | 10 | ingressInterface | 63 | bgpNextHopIPv6Address | | 14 | egressInterface | 46 | mplsTopLabelType | | 129 | ipNextHopAsNumber | 47 | mplsTopLabelIPv4Address | | 16 | bgpSourceAsNumber | 140 | mplsTopLabelIPv6Address | | 17 | bgpDestinationAsNumber | | | +-------+-------------------------+-------+-------------------------+ 5.4.1 ipNextHopIPv4Address Description: The IPv4 address of the next IP hop to which packets of this flow are forwarded. Abstract Data Type: ipv4Address Quittek, et al. Expires August 21, 2005 [Page 25] Internet-Draft IPFIX Information Model February 2005 FieldId: 15 Applicability: data Status: current 5.4.2 ipNextHopIPv6Address Description: The IPv6 address of the next BGP hop to which packets of this flow are forwarded. Abstract Data Type: ipv6Address FieldId: 62 Applicability: data Status: current 5.4.3 ingressInterface Description: The index of the IP interface (ifIndex) where packets of this flow are being received. Abstract Data Type: unsigned32 Data Type Semantics: identifier FieldId: 10 Applicability: all Status: current Reference: See RFC 2863 for the definition of the ifIndex object. 5.4.4 egressInterface Description: The index of the IP interface (ifIndex) where packets of this flow are being sent. Abstract Data Type: unsigned32 Data Type Semantics: identifier FieldId: 14 Applicability: all Quittek, et al. Expires August 21, 2005 [Page 26] Internet-Draft IPFIX Information Model February 2005 Status: current Reference: See RFC 2863 for the definition of the ifIndex object. 5.4.5 ipNextHopAsNumber Description: The autonomous system (AS) number of the next IP hop to which packets of this flow are forwarded. Abstract Data Type: unsigned16 Data Type Semantics: identifier FieldId: 129 Applicability: all Status: current Reference: See RFC 1771 for a description of BGB-4 and see RFC 1930 a definition of the AS number. 5.4.6 bgpSourceAsNumber Description: The autonomous system (AS) number of the source address in the IP packet header in a packet of this flow. Abstract Data Type: unsigned16 Data Type Semantics: identifier FieldId: 16 Applicability: all Status: current Reference: See RFC 1771 for a description of BGB-4 and see RFC 1930 a definition of the AS number. 5.4.7 bgpDestinationAsNumber Description: The autonomous system (AS) number of the destination address in the IP packet header in a packet of this flow. Abstract Data Type: unsigned16 Data Type Semantics: identifier FieldId: 17 Quittek, et al. Expires August 21, 2005 [Page 27] Internet-Draft IPFIX Information Model February 2005 Applicability: all Status: current Reference: See RFC 1771 for a description of BGB-4 and see RFC 1930 a definition of the AS number. 5.4.8 bgpNextHopAsNumber Description: The autonomous system (AS) number of the next BGP hop to which packets of this flow are forwarded. Abstract Data Type: unsigned16 Data Type Semantics: identifier FieldId: 128 Applicability: all Status: current Reference: See RFC 1771 for a description of BGB-4 and see RFC 1930 a definition of the AS number. 5.4.9 bgpNextHopIPv4Address Description: The IPv4 address of the next BGP hop to which packets of this flow are forwarded. Abstract Data Type: ipv4Address FieldId: 18 Applicability: all Status: current Reference: See RFC 1771 for a description of BGB-4 and see RFC 1930 a definition of the AS number. 5.4.10 bgpNextHopIPv6Address Description: The IPv6 address of the next BGP hop to which packets of this flow are forwarded. Abstract Data Type: ipv6Address Data Type Semantics: identifier FieldId: 63 Quittek, et al. Expires August 21, 2005 [Page 28] Internet-Draft IPFIX Information Model February 2005 Applicability: all Status: current Reference: See RFC 1771 for a description of BGB-4. See RFC 1930 a definition of the AS number. 5.4.11 mplsTopLabelType Description: MPLS top label type: This field identifies the control protocol that allocated the top of stack label. Abstract Data Type: octet Data Type Semantics: identifier FieldId: 46 Applicability: data Status: current 5.4.12 mplsTopLabelIPv4Address Description: The IPv4 address of the system that the MPLS top label will cause this packet to be forwarded to. Abstract Data Type: ipV4Address FieldId: 47 Applicability: data Status: current 5.4.13 mplsTopLabelIPv6Address Description: The IPv4 address of the system that the MPLS top label will cause this packet to be forwarded to. Abstract Data Type: ipV6Address FieldId: 140 Applicability: data Status: current Quittek, et al. Expires August 21, 2005 [Page 29] Internet-Draft IPFIX Information Model February 2005 5.5 Properties of Metering/Exporting Process Information elements in this section describe static properties of the Metering Process and/or the Exporting Process. The set of these information elements is listed in the table below +-------+-------------------------+-------+-------------------------+ | ID | Field Name | ID | Field Name | +-------+-------------------------+-------+-------------------------+ | 130 | exporterIPv4Address | 131 | exporterIPv6Address | +-------+-------------------------+-------+-------------------------+ 5.5.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 FieldId: 130 Applicability: all Status: current 5.5.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 FieldId: 131 Applicability: all Status: current 5.6 Min/Max Flow Properties Information elements in this section are results of minimum or Quittek, et al. Expires August 21, 2005 [Page 30] Internet-Draft IPFIX Information Model February 2005 maximum operations over multiple or all packets of a flow. They cannot serve as flow keys, but their value can be used as trigger for selecting and/or exporting flows. The set of information elements resulting from minimum or maximum operations over all packets of a flow includes the information elements listed in the table below. +-------+-------------------------+-------+-------------------------+ | ID | Field Name | ID | Field Name | +-------+-------------------------+-------+-------------------------+ | 25 | minimumPacketLength | 22 | flowCreationTime | | 26 | maximumPacketLength | 21 | flowEndTime | | 52 | minimumTTL | 36 | flowActiveTimeOut | | 53 | maximumTTL | 37 | flowInactiveTimeOut | | 64 | ipv6OptionHeaders | 136 | flowEndReason | | 6 | tcpControlBits | | | +-------+-------------------------+-------+-------------------------+ 5.6.1 minimumPacketLength Description: Length of the smallest packet observed for this flow. Abstract Data Type: unsigned16 FieldId: 25 Applicability: all Status: current Units: octets 5.6.2 maximumPacketLength Description: Length of the largest packet observed for this flow. Abstract Data Type: unsigned16 FieldId: 26 Applicability: all Status: current Units: octets Quittek, et al. Expires August 21, 2005 [Page 31] Internet-Draft IPFIX Information Model February 2005 5.6.3 minimumTTL Description: Minimum TTL value observed for any packet in this flow. Abstract Data Type: octet FieldId: 52 Applicability: data Status: current 5.6.4 maximumTTL Description: Maximum TTL value observed for any packet in this flow. Abstract Data Type: octet FieldId: 53 Applicability: data Status: current 5.6.5 ipv6OptionHeaders Description: IPv6 options in the IP packet headers of this flow. This is encoded as a bit field. bit IPv6 Option Definition 0 Reserved 1 44 Fragmentation header - not first fragment 2 43 Routing header 3 44 Fragmentation header - first fragment 4 Unknown Layer 4 header (compressed, encrypted, not supported) 5 Reserved 6 0 Hop-by-hop option header 7 60 Destination option header 8 108 Payload compression header 9 51 Authentication Header 10 50 Encrypted security payload 11 to 31 Reserved Abstract Data Type: unsigned32 Data Type Semantics: flags Quittek, et al. Expires August 21, 2005 [Page 32] Internet-Draft IPFIX Information Model February 2005 FieldId: 64 Applicability: all Status: current Reference: To be done. 5.6.6 tcpControlBits Description: TCP control bits observed for packets of this flow. The value of this field is the result of a logical OR operation over the flags observed in all packets of the flow. This implies that a 0 value for a bit indicates that the respective 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: octet Data Type Semantics: flags FieldId: 6 Applicability: all Status: current Reference: See RFC 793 for a definition of the TCP control bits in the TCP header. 5.6.7 flowCreationTime Description: The timestamp of the first packet of this flow. Abstract Data Type: dateTimeSeconds FieldId: 22 Applicability: data Quittek, et al. Expires August 21, 2005 [Page 33] Internet-Draft IPFIX Information Model February 2005 Status: current 5.6.8 flowEndTime Description: The timestamp of the last packet of this flow. Abstract Data Type: dateTimeSeconds FieldId: 21 Applicability: data Status: current 5.6.9 flowActiveTimeOut Description: The number of seconds after which an active flow is timed out anyway, even if there is still a continuous flow of packets. Abstract Data Type: unsigned16 FieldId: 36 Applicability: all Status: current Units: seconds 5.6.10 flowInactiveTimeout Description: A flow is considered to be timed out if no packets belonging to the flow have been observed for the number of seconds specified by this field. Abstract Data Type: unsigned16 FieldId: 37 Applicability: all Status: current Units: seconds 5.6.11 flowEndReason Quittek, et al. Expires August 21, 2005 [Page 34] Internet-Draft IPFIX Information Model February 2005 Description: The reason for flow termination. EDITORS' NOTE: This needs to be defined as an enumerated range. Abstract Data Type: octet FieldId: 136 Applicability: data Status: current 5.7 Per-Flow Counters Information elements in this section are counters all having integral values. Their values may change for every report they are used in. They cannot serve as part of a flow key used for mapping packets to flows. However, potentially they can be used for selecting exported flow, for example by only exporting flows with more than a thresholh number of observed octets. There are running counters and delta counters. Delta counters are reset to zero for each time their values are exported. Running counters continue counting independent of the Exporting Process. There are per-flow counters and counters related to the Metering Process and/or the Exporting Process. Per-flow counters are flow properites that potentially change each time a packets belonging to the flow is observed. Per-flow counters are flow properites that potentially change each time a packet belonging to the flow is observed. The set of per-flow counters includes the information elements listed in the table below. +-------+-------------------------+-------+-------------------------+ | ID | Field Name | ID | Field Name | +-------+-------------------------+-------+-------------------------+ | 1 | inOctetDeltaCount | 132 | droppedOctetDeltaCount | | 23 | outOctetDeltaCount | 133 | droppedOctetTotalCount | | 138 | octetDeltaCount | 134 | droppedPacketDeltaCount | | 85 | inOctetTotalCount | 135 | droppedPacketTotalCount | | 2 | inPacketDeltaCount | 19 | outMulticastPacketCount | | 24 | outPacketDeltaCount | 20 | outMulticastOctetCount | | 139 | packetDeltaCount | | | | 86 | inPacketTotalCount | | | +-------+-------------------------+-------+-------------------------+ Quittek, et al. Expires August 21, 2005 [Page 35] Internet-Draft IPFIX Information Model February 2005 5.7.1 inOctetDeltaCount Description: The number of octets in incoming packets observed for this flow at the Observation Point since the previous report (if any). The number of octets include IP header(s) and IP payload. Abstract Data Type: unsigned64 Data Type Semantics: deltaCounter FieldId: 1 Applicability: data Status: current Units: octets 5.7.2 outOctetDeltaCount Description: The number of octets in outgoing packets observed for this flow at the Observation Point since the previous report (if any). The number of octets include IP header(s) and IP payload. Abstract Data Type: unsigned64 Data Type Semantics: deltaCounter FieldId: 23 Applicability: data Status: current Units: octets 5.7.3 octetDeltaCount Description: The number of octets in all packets observed for this flow at the Observation Point since the previous report (if any). The number of octets include IP header(s) and IP payload. Abstract Data Type: unsigned64 Data Type Semantics: deltaCounter FieldId: 138 Quittek, et al. Expires August 21, 2005 [Page 36] Internet-Draft IPFIX Information Model February 2005 Applicability: data Status: current Units: octets 5.7.4 inOctetTotalCount Description: The running counter for the number of octets in incoming packets observed for this flow at the Observation Point since the Metering Process initialization for this Observation Point. The number of octets include IP header(s) and IP payload. Abstract Data Type: unsigned64 Data Type Semantics: totalCounter FieldId: 85 Applicability: all Status: current Units: octets 5.7.5 inPacketDeltaCount Description: The number of incoming packets observed for this flow at the Observation Point since the previous report (if any). Abstract Data Type: unsigned64 Data Type Semantics: deltaCounter FieldId: 2 Applicability: data Status: current Units: packets 5.7.6 outPacketDeltaCount Description: The number of outgoing packets observed for this flow at the Observation Point since the previous report (if any). Abstract Data Type: unsigned64 Quittek, et al. Expires August 21, 2005 [Page 37] Internet-Draft IPFIX Information Model February 2005 Data Type Semantics: deltaCounter FieldId: 24 Applicability: data Status: current Units: packets 5.7.7 packetDeltaCount Description: The number of all packets observed for this flow at the Observation Point since the previous report (if any). Abstract Data Type: unsigned64 Data Type Semantics: deltaCounter FieldId: 139 Applicability: data Status: current Units: packets 5.7.8 inPacketTotalCount Description: The running counter for the number of incoming packets observed for this flow at the Observation Point since the Metering Process initialization for this Observation Point. Abstract Data Type: unsigned64 Data Type Semantics: totalCounter FieldId: 86 Applicability: all Status: current Units: packets 5.7.9 droppedOctetDeltaCount Quittek, et al. Expires August 21, 2005 [Page 38] Internet-Draft IPFIX Information Model February 2005 Description: The number of octets in packets of this flow dropped by packet treatment. Abstract Data Type: unsigned64 Data Type Semantics: deltaCounter FieldId: 132 Applicability: data Status: current Units: octets 5.7.10 droppedOctetTotalCount Description: The number of octets in packets of this flow dropped by packet treatment. Abstract Data Type: unsigned64 Data Type Semantics: totalCounter FieldId: 133 Applicability: data Status: current Units: octets 5.7.11 droppedPacketDeltaCount Description: The number of packets of this flow dropped by packet treatment. Abstract Data Type: unsigned64 Data Type Semantics: deltaCounter FieldId: 134 Applicability: data Status: current Units: packets Quittek, et al. Expires August 21, 2005 [Page 39] Internet-Draft IPFIX Information Model February 2005 5.7.12 droppedPacketTotalCount Description: The number of packets of this flow dropped by packet treatment. Abstract Data Type: unsigned64 Data Type Semantics: totalCounter FieldId: 135 Applicability: data Status: current Units: packets 5.7.13 outMulticastPacketCount Description: The number of outgoing multicast packets created for packets of this flow by an adjacent multicast daemon. Note that typically not all of the created packets can be observed at the Observation Point of this flow. Abstract Data Type: unsigned64 FieldId: 19 Applicability: data Status: current Units: packets 5.7.14 outMulticastOctetCount Description: The number of octets in outgoing multicast packets created for packets of this flow by an adjacent multicast daemon. Note that typically not all of the created packets can be observed at the Observation Point of this flow. Abstract Data Type: unsigned64 FieldId: 20 Applicability: data Status: current Quittek, et al. Expires August 21, 2005 [Page 40] Internet-Draft IPFIX Information Model February 2005 Units: octets 5.8 Process Counters The set of counters related to the Metering Process and/or the Exporting Process exported includes the information elements listed in the table below. +-------+-------------------------+-------+-------------------------+ | ID | Field Name | ID | Field Name | +-------+-------------------------+-------+-------------------------+ | 3 | observedFlowTotalCount | 41 | exportedPacketTotalCount| | 40 | exportedOctetToalCount | 42 | exportedFlowTotalCount | +-------+-------------------------+-------+-------------------------+ 5.8.1 observedFlowTotalCount Description: The number of flows observed so far in the Observation Domain. Abstract Data Type: unsigned64 Data Type Semantics: totalCounter FieldId: 3 Applicability: data Status: current Units: flows 5.8.2 exportedOctetTotalCount Description: The number of all octets reported by the Exporting Process to this Collecting Process. Abstract Data Type: unsigned64 Data Type Semantics: totalCounter FieldId: 40 Applicability: data Status: current Units: octets Quittek, et al. Expires August 21, 2005 [Page 41] Internet-Draft IPFIX Information Model February 2005 5.8.3 exportedPacketTotalCount Description: The number of all packets reported by the Exporting Process to this Collecting Process. Abstract Data Type: unsigned64 Data Type Semantics: totalCounter FieldId: 41 Applicability: data Status: current Units: packets 5.8.4 exportedFlowTotalCount Description: The number of all flows records reported by the Exporting Process to this Collecting Process. Abstract Data Type: unsigned64 FieldId: 42 Applicability: data Status: current Units: flows Quittek, et al. Expires August 21, 2005 [Page 42] Internet-Draft IPFIX Information Model February 2005 6. Extending the Information Model A key requirement for IPFIX is to allow for extending the set of information items which are reported for flows. This section defines the mechanism for extending this set. The IPFIX protocol carries flow records defined by a template. Multiple templates may be defined for a dialog between an Exporter and a Collector. A given template identifies the information items and their order. The means of identification of information items in a template is via a field ID. Field Id's are unique identifiers administered by IANA. Extension is done by defining new Information elements, including the set of necessary information and possibly additional optional information for each element. Each new information item MUST be assigned a unique fieldId as part of its definition. These unique field ids are the connection between the record structure communicated by the protocol using templates and a consuming application. Enterprise-specific extensions may be made by enterprises with an SMI network management private enterprise code defined by IANA at http://www.iana.org/assignments/enterprise-numbers. Enterprise-specific field IDs do not need to be registered by IANA. The definition of a enterprise-specific information element MUST specify the enterprise ID as well as the enterprise-specified field ID and other mandatory field properties. Before creating enterprise-specific fields, the general applicability of such information elements should be considered. For generally applicable fields using IETF and IANA mechanisms for extending the information model is recommended. Quittek, et al. Expires August 21, 2005 [Page 43] Internet-Draft IPFIX Information Model February 2005 7. IANA Considerations IANA has to create a new registry for IPFIX field ID's. Appendix B defines an XML schema which may be used to create consistent machine readable extensions to the IPFIX information model. This schema introduces a new namespace, which will be assigned by IANA according to RFC 3688. Currently the name space for this schema is identified as http://www.ietf.org/ipfix. Quittek, et al. Expires August 21, 2005 [Page 44] Internet-Draft IPFIX Information Model February 2005 8. Security Considerations The IPFIX information model itself does not directly introduce security issues. Rather it defines a set of attributes which may for privacy or business issues be considered sensitive information. The underlying protocol used to exchange the information described here must therefore apply appropriate procedures to guarantee the integrity and confidentiality of the exported information. Such protocols are defined in separate documents, specifically the IPFIX Protocol document [IPFIX-PROTO]. Quittek, et al. Expires August 21, 2005 [Page 45] Internet-Draft IPFIX Information Model February 2005 9. Acknowledgements The editors thank Benoit Claise for a lot of useful input on the field definitions. Also many thanks to Thomas Dietz for developing the XSLT scripts that generate large portions of the text part of this document from the XML appendices. Quittek, et al. Expires August 21, 2005 [Page 46] Internet-Draft IPFIX Information Model February 2005 10. References 10.1 Normative Reference [1] Claise, B., Fullmer, M., Calato, P. and R. Penno, "IPFIX Protocol Specification", IETF draft work in progress, January 2004, . 10.2 Informative Reference [2] Quittek, J., Zseby, T., Claise, B. and S. Zander, "Requirements for IP Flow Information Export", IETF draft work in progress, January 2004, . [3] Sadasivan, G. and N. Brownlee, "Architecture Model for IP Flow Information Export", IETF draft work in progress, October 2003, . [4] Zseby, T., Penno, R., Claise, B. and N. Brownlee, "IPFIX Applicability", IETF draft work in progress, October 2003, . [5] Claise, B., "Cisco Systems NetFlow Services Export Version 9", RFC 3954, October 2004, . [6] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0", W3C XML, February 1998, . [7] World Wide Web Consortium, "XML Schema Part 1: Structures", W3C XML, May 2001, . [8] World Wide Web Consortium, "XML Schema Part 2: Datatypes", W3C XML, May 2001, . [9] Internet Protocol Detail Record Organization, "Network Data Management - Usage (NDM-U) For IP-Based Services Version 3.1.1", October 2002, . Quittek, et al. Expires August 21, 2005 [Page 47] Internet-Draft IPFIX Information Model February 2005 [10] Brownlee, N. and A. Blount, "Accounting Attributes and Record Formats", RFC 2924, Sept. 2000, . [11] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999, . [12] Hollenbeck, S., Rose, M. and L. Masinter, "Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols", RFC 3470, January 2003, . [13] Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, January 2003, . [14] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004, . Authors' Addresses Juergen Quittek NEC Kurfuersten-Anlage 36 Heidelberg 69115 Germany Phone: +49 6221 90511-15 EMail: quittek@netlab.nec.de URI: http://www.netlab.nec.de/ Stewart Bryant Cisco Systems Ltd 250, Longwater, Green Park Reading RG2 6GB United Kingdom EMail: stbryant@cisco.com Quittek, et al. Expires August 21, 2005 [Page 48] Internet-Draft IPFIX Information Model February 2005 Jeff Meyer PayPal 2211 N. First St. San Jose, CA 95131-2021 US Phone: +1 408 976-9149 EMail: jemeyer@paypal.com URI: http://www.paypal.com Quittek, et al. Expires August 21, 2005 [Page 49] Internet-Draft IPFIX Information Model February 2005 Appendix A. Formal Specification of IPFIX Fields This appendix contains a formal description of the IPFIX information model XML document. Note that this appendix is of informational nature, while the text in section 4 generated from this appendix is normative. Using a formal and machine readable syntax for the Information model enables the creation of IPFIX aware tools which can automatically adapt to extensions to the information model, by simply reading updated information model specifications. The wide availability of XML aware tools and libraries for client devices is a primary consideration for this choice. In particular libraries for parsing XML documents are readily available. Also mechanisms such as the Extensible Stylesheet Language (XSL) allow for transforming a source XML document into other documents. This draft was authored in XML and transformed according to RFC2629. It should be noted that the use of XML in Exporters, Collectors or other tools is not mandatory for the deployment of IPFIX. In particular Exporting Processes do not produce or consume XML as part of their operation. It is expected that IPFIX Collectors MAY take advantage of the machine readability of the Information Model vs. hardcoding their behavior or inventing proprietary means for accomodating extensions. The IP version field given in the IP header. flows See RFC 791 for a definition of the version field in the IPv6 packet header. See RFC 2460 for a 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. Quittek, et al. Expires August 21, 2005 [Page 50] Internet-Draft IPFIX Information Model February 2005 IPv4 source address taken from the IP packet header of a packet of this flow. See RFC 791 for the definition of the IPv4 source address field. IPv6 source address taken from the IP packet header of a packet of this flow. The number of contiguous bits that are relevant in the sourceAddressV4 field. bits 0-32 The number of contiguous bits that are relevant in the Quittek, et al. Expires August 21, 2005 [Page 51] Internet-Draft IPFIX Information Model February 2005 sourceAddressV6 field. bits 0-128 IPv4 source address prefix. EDITOR'S NOTE: to be discussed on ipfix mailing list flows IPv4 destination address taken from the IP packet header of a packet of this flow. See RFC 791 for the definition of the IPv4 destination address field. IPv6 destination address taken from the IP packet header of a packet of this flow. Quittek, et al. Expires August 21, 2005 [Page 52] Internet-Draft IPFIX Information Model February 2005 The number of contiguous bits that are relevant in the destinationAddressV4 field. bits 0-32 The number of contiguous bits that are relevant in the destinationAddressV6 field. bits 0-128 IPv4 destination address prefix. EDITOR'S NOTE: to be discussed on ipfix mailing list flows The value of the IPv4 TOS field observed for packets of this flow. See RFC 791 for the definition of the IPv4 TOS field. Quittek, et al. Expires August 21, 2005 [Page 53] Internet-Draft IPFIX Information Model February 2005 The value of the IPv6 traffic class field observed for packets of this flow. See RFC 2460 for the definition of the IPv6 traffic class field. The Flow Label of the IPv6 packet header observed in the first packet of this flow. See RFC 2460 for a definition of the flow label field in the IPv6 packet header. The IPv4 packet identification field from the first packet of this flow. See RFC 791 for the definition of the IPv4 identification field. Quittek, et al. Expires August 21, 2005 [Page 54] Internet-Draft IPFIX Information Model February 2005 The protocol number observed for packets of this flow. The protocol number identifies the IP packet payload. 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. See RFC 791 for the specification of the IPv4 protocol field. See RFC 2460 for the specification of the IPv6 protocol field. See list of protocol numbers assigned by IANA at http://www.iana.org/assignments/protocol-numbers. A source port identifier in the transport header. For 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. 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 2960 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. Quittek, et al. Expires August 21, 2005 [Page 55] Internet-Draft IPFIX Information Model February 2005 A destination port identifier in the transport header. For 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. 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 2960 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. Type and Code of the ICMP message. The combination of both values is reported as (ICMP type * 256) + ICMP code. See RFC 792 for a definition of the ICMP type and code fields. The type field of the IGMP message. See RFC 2236 for a definition of the IGMP type field. Quittek, et al. Expires August 21, 2005 [Page 56] Internet-Draft IPFIX Information Model February 2005 Packet identification field from the first IP packet of this flow. See RFC 791 for the definition of the IPv4 identification field. The label, exp and s fields from the outermost MPLS label stack entry e.g. the last label that was pushed last. 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 See RFC 3032. The label, exp and s fields from the LSE that was pushed immediately before the LSE that would be reported by Quittek, et al. Expires August 21, 2005 [Page 57] Internet-Draft IPFIX Information Model February 2005 mplsLabelStackEntry1. See the definition of mplsLabelStackEntry1 for further details. See RFC 3032. The label, exp and s fields from the LSE that was pushed immediately before the LSE that would be reported by mplsLabelStackEntry2. See the definition of mplsLabelStackEntry1 for further details. See RFC 3032. The label, exp and s fields from the LSE that was pushed immediately before the LSE that would be reported by mplsLabelStackEntry3. See the definition of mplsLabelStackEntry1 for further details. See RFC 3032. The label, exp and s fields from the LSE that was pushed immediately before the LSE that would be reported by Quittek, et al. Expires August 21, 2005 [Page 58] Internet-Draft IPFIX Information Model February 2005 mplsLabelStackEntry4. See the definition of mplsLabelStackEntry1 for further details. See RFC 3032. The label, exp and s fields from the LSE that was pushed immediately before the LSE that would be reported by mplsLabelStackEntry5. See the definition of mplsLabelStackEntry1 for further details. See RFC 3032. The label, exp and s fields from the LSE that was pushed immediately before the LSE that would be reported by mplsLabelStackEntry6. See the definition of mplsLabelStackEntry1 for further details. See RFC 3032. The label, exp and s fields from the LSE that was pushed immediately before the LSE that would be reported by Quittek, et al. Expires August 21, 2005 [Page 59] Internet-Draft IPFIX Information Model February 2005 mplsLabelStackEntry7. See the definition of mplsLabelStackEntry1 for further details. See RFC 3032. The label, exp and s fields from the LSE that was pushed immediately before the LSE that would be reported by mplsLabelStackEntry8. See the definition of mplsLabelStackEntry1 for further details. See RFC 3032. The label, exp and s fields from the LSE that was pushed immediately before the LSE that would be reported by mplsLabelStackEntry9. See the definition of mplsLabelStackEntry1 for further details. See RFC 3032. The IPv4 address of the next IP hop to which packets of this flow are forwarded. Quittek, et al. Expires August 21, 2005 [Page 60] Internet-Draft IPFIX Information Model February 2005 The IPv6 address of the next BGP hop to which packets of this flow are forwarded. The index of the IP interface (ifIndex) where packets of this flow are being received. See RFC 2863 for the definition of the ifIndex object. The index of the IP interface (ifIndex) where packets of this flow are being sent. See RFC 2863 for the definition of the ifIndex object. The autonomous system (AS) number of the next IP hop to which packets of this flow are forwarded. See RFC 1771 for a description of BGB-4 and see RFC 1930 a definition of the AS number. The autonomous system (AS) number of the source address in the IP packet header in a packet of this flow. See RFC 1771 for a description of BGB-4 and see RFC 1930 a definition of the AS number. The autonomous system (AS) number of the destination address in the IP packet header in a packet of this flow. See RFC 1771 for a description of BGB-4 and see RFC 1930 a definition of the AS number. The autonomous system (AS) number of the next BGP hop to which packets of this flow are forwarded. See RFC 1771 for a description of BGB-4 and see RFC 1930 a definition of the AS number. The IPv4 address of the next BGP hop to which packets of this flow are forwarded. See RFC 1771 for a description of BGB-4 and see RFC 1930 a definition of the AS number. The IPv6 address of the next BGP hop to which packets of this flow are forwarded. See RFC 1771 for a description of BGB-4. See RFC 1930 a definition of the AS number. Quittek, et al. Expires August 21, 2005 [Page 63] Internet-Draft IPFIX Information Model February 2005 MPLS top label type: 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 This field identifies the control protocol that allocated the top of stack label. The IPv4 address of the system that the MPLS top label will cause this packet to be forwarded to. The IPv4 address of the system that the MPLS top label will cause this packet to be forwarded to. 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 Quittek, et al. Expires August 21, 2005 [Page 64] Internet-Draft IPFIX Information Model February 2005 obscured by the use of a proxy. 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. Length of the smallest packet observed for this flow. octets Length of the largest packet observed for this flow. octets Minimum TTL value observed for any packet in this flow. Quittek, et al. Expires August 21, 2005 [Page 65] Internet-Draft IPFIX Information Model February 2005 Maximum TTL value observed for any packet in this flow. IPv6 options in the IP packet headers of this flow. This is encoded as a bit field. bit IPv6 Option Definition 0 Reserved 1 44 Fragmentation header - not first fragment 2 43 Routing header 3 44 Fragmentation header - first fragment 4 Unknown Layer 4 header (compressed, encrypted, not supported) 5 Reserved 6 0 Hop-by-hop option header 7 60 Destination option header 8 108 Payload compression header 9 51 Authentication Header 10 50 Encrypted security payload 11 to 31 Reserved To be done. TCP control bits observed for packets of this flow. The value of this field is the result of a logical OR operation over the flags observed in all packets of the flow. This implies that a 0 value for a bit indicates that the respective 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 See RFC 793 for a definition of the TCP control bits in the TCP header. The timestamp of the first packet of this flow. The timestamp of the last packet of this flow. Quittek, et al. Expires August 21, 2005 [Page 67] Internet-Draft IPFIX Information Model February 2005 The number of seconds after which an active flow is timed out anyway, even if there is still a continuous flow of packets. seconds A flow is considered to be timed out if no packets belonging to the flow have been observed for the number of seconds specified by this field. seconds The reason for flow termination. idle timeout end of flow detected (e.g. TCP FIN) forced end cache full EDITORS' NOTE: This needs to be defined as an enumerated range. The number of octets in incoming packets observed for this flow at the Observation Point since the previous report (if any). Quittek, et al. Expires August 21, 2005 [Page 68] Internet-Draft IPFIX Information Model February 2005 The number of octets include IP header(s) and IP payload. octets The number of octets in outgoing packets observed for this flow at the Observation Point since the previous report (if any). The number of octets include IP header(s) and IP payload. octets The number of octets in all packets observed for this flow at the Observation Point since the previous report (if any). The number of octets include IP header(s) and IP payload. octets The running counter for the number of octets in incoming packets observed for this flow at the Observation Point since the Metering Process initialization for this Observation Point. The number of octets include IP header(s) and IP payload. octets Quittek, et al. Expires August 21, 2005 [Page 69] Internet-Draft IPFIX Information Model February 2005 The number of incoming packets observed for this flow at the Observation Point since the previous report (if any). packets The number of outgoing packets observed for this flow at the Observation Point since the previous report (if any). packets The number of all packets observed for this flow at the Observation Point since the previous report (if any). packets The running counter for the number of incoming packets observed for this flow at the Observation Point since the Metering Process initialization for this Observation Point. Quittek, et al. Expires August 21, 2005 [Page 70] Internet-Draft IPFIX Information Model February 2005 packets The number of octets in packets of this flow dropped by packet treatment. octets The number of octets in packets of this flow dropped by packet treatment. octets The number of packets of this flow dropped by packet treatment. packets The number of packets of this flow dropped by packet treatment. Quittek, et al. Expires August 21, 2005 [Page 71] Internet-Draft IPFIX Information Model February 2005 packets The number of outgoing multicast packets created for packets of this flow by an adjacent multicast daemon. Note that typically not all of the created packets can be observed at the Observation Point of this flow. packets The number of octets in outgoing multicast packets created for packets of this flow by an adjacent multicast daemon. Note that typically not all of the created packets can be observed at the Observation Point of this flow. octets The number of flows observed so far in the Observation Domain. flows The number of all octets reported by the Exporting Process to this Collecting Process. octets The number of all packets reported by the Exporting Process to this Collecting Process. packets The number of all flows records reported by the Exporting Process to this Collecting Process. flows Quittek, et al. Expires August 21, 2005 [Page 73] Internet-Draft IPFIX Information Model February 2005 Appendix B. Formal Specification of Abstract Data Types This appendix containfs a formal description of the abstract data types to be used for IPFIX fields and a formal description of the template used for defining IPFIX fields. Note that this appendix is of informational nature, while the text in sections 2 and 3 generated from this appendix is normative. The type "octet" represents a non-negative integer value in the range of 0 to 255. The type "unsigned16" represents a non-negative integer value in the range of 0 to 65535. The type "unsigned32" represents a non-negative integer value in the range of 0 to 4294967295. The type "unsigned64" represents a non-negative integer value in the range of 0 to 18446744073709551615. Quittek, et al. Expires August 21, 2005 [Page 74] Internet-Draft IPFIX Information Model February 2005 The type "float32" corresponds to an IEEE single-precision 32-bit floating point type. The type "boolean" represents a binary value. The type "octetArray" represents a finite length string of octets. The type "string" represents a finite length string of valid characters from the Unicode character encoding set. Unicode allows for ASCII and many other international character sets to be used. It is expected that strings will be encoded in UTF-8 format, which is identical in encoding for USASCII characters, but also accomodates other Unicode multibyte characters. The type "dateTimeSeconds" represents a time value having a precision of seconds and normalized to the Quittek, et al. Expires August 21, 2005 [Page 75] Internet-Draft IPFIX Information Model February 2005 GMT timezone. Such types are in common use on many operating systems and have the advantage that they can be stored in 32-bit integers. The type "dateTimeSeconds" represents a time value having a precision of microseconds and normalized to the GMT timezone. The type "ipv4Addr" represents a value of an IPv4 address. These addresses are typically stored as 32-bit integers. The type "ipv6Addr" represents a value of an IPv6 address. A quantity value represents a discrete measured value pertaining to the record. This is distinguished from counters which represent an ongoing measured value whose "odometer" reading is captured as part of a given record. If no semantic qualifier is given, the integral fields should behave as a quantity. Quittek, et al. Expires August 21, 2005 [Page 76] Internet-Draft IPFIX Information Model February 2005 A measurement which is ongoing from the perspective of the Exporter. Basically the same semantics as counters in SNMP. 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. A running counter counts independent of the export of its value. A measurement which is ongoing from the perspective of the Exporter. Basically the same semantics as counters in SNMP. 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. A delta counter is reset to zero each time its value is exported. An integral value which 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. Quittek, et al. Expires August 21, 2005 [Page 77] Internet-Draft IPFIX Information Model February 2005 An integral value which 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. Used for fields that are applicable to flow records only. Used for fields that are applicable to option records only. Used for fields that are applicable to flow records as well as to option records. Quittek, et al. Expires August 21, 2005 [Page 78] Internet-Draft IPFIX Information Model February 2005 Indicates that the field definition is that the definition is current and valid. Indicates that the field definition is obsolete, but it permits new/continued implementation in order to foster interoperability with older/existing implementations. Indicates that the field definition is obsolete and should not be implemented and/or can be removed if previously implemented. to be done ... Quittek, et al. Expires August 21, 2005 [Page 79] Internet-Draft IPFIX Information Model February 2005 to be done ... to be done ... The semantics of this information element. Describes how this field is derived from the flow or other information available to the observer. If the field is a measure of some kind, the units identify what the measure is. Quittek, et al. Expires August 21, 2005 [Page 80] Internet-Draft IPFIX Information Model February 2005 Identifies additional specifications which more precisely define this item or provide additional context for its use. Some items may have a specific set of numeric identifiers associated with a set of discrete values this element may take. The meaning of each discrete value and a human readable name should be assigned. Some elements may only be able to take on a restricted set of values which can be expressed as a range (e.g. 0 through 511 inclusive). If this is the case, the valid inclusive range should be specified. A unique and meaningful name for the information element. The preferred spelling for the name is to use mixed case if the name is compound, with an initial Quittek, et al. Expires August 21, 2005 [Page 81] Internet-Draft IPFIX Information Model February 2005 lower case letter, e.g., "sourceIpAddress". One of the types listed in section 3.1 of this document or in an 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 IPAddress) which are common to this domain and useful to distinguish. 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 an extension of the information model. A numeric identifier administered by IANA. This is used for compact identification of an information item when encoding templates in the protocol. Quittek, et al. Expires August 21, 2005 [Page 82] Internet-Draft IPFIX Information Model February 2005 When extension is done outside of the scope of the IANA IPFIX fieldId range, a enterpriseId MUST be provided. Valid values for the enterpriseId are defined by IANA as SMI network management private enterprise code. They are defined at http://www.iana.org/assignments/enterprise-numbers. This propoerty of an information element indicates in which kind of records the element can be used. Allowed values for this property are 'data', 'option', and 'all'. The status of the specification of this information element. Allowed values are 'current', 'deprecated', and 'obsolete'. to be done ... Quittek, et al. Expires August 21, 2005 [Page 83] Internet-Draft IPFIX Information Model February 2005 Quittek, et al. Expires August 21, 2005 [Page 84] Internet-Draft IPFIX Information Model February 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Quittek, et al. Expires August 21, 2005 [Page 85]