Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5102

Information Model for IP Flow Information Export

Pages: 171
Obsoleted by:  7012
Updated by:  6313
Part 1 of 7 – Pages 1 to 14
None   None   Next

ToP   noToC   RFC5102 - Page 1
Network Working Group                                         J. Quittek
Request for Comments: 5102                                           NEC
Category: Standards Track                                      S. Bryant
                                                               B. Claise
                                                               P. Aitken
                                                     Cisco Systems, Inc.
                                                                J. Meyer
                                                                  PayPal
                                                            January 2008


            Information Model for IP Flow Information Export

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

This memo defines an information model for the IP Flow Information eXport (IPFIX) protocol. It is used by the IPFIX protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic Metering Process, and the Exporting Process. Although developed for the IPFIX protocol, the model is defined in an open way that easily allows using it in other protocols, interfaces, and applications.

Table of Contents

1. Introduction ....................................................6 2. Properties of IPFIX Protocol Information Elements ...............7 2.1. Information Elements Specification Template ................7 2.2. Scope of Information Elements ..............................9 2.3. Naming Conventions for Information Elements ................9 3. Type Space .....................................................10 3.1. Abstract Data Types .......................................10 3.1.1. unsigned8 ..........................................10 3.1.2. unsigned16 .........................................11 3.1.3. unsigned32 .........................................11 3.1.4. unsigned64 .........................................11 3.1.5. signed8 ............................................11 3.1.6. signed16 ...........................................11 3.1.7. signed32 ...........................................11 3.1.8. signed64 ...........................................11
ToP   noToC   RFC5102 - Page 2
           3.1.9. float32 ............................................11
           3.1.10. float64 ...........................................11
           3.1.11. boolean ...........................................12
           3.1.12. macAddress ........................................12
           3.1.13. octetArray ........................................12
           3.1.14. string ............................................12
           3.1.15. dateTimeSeconds ...................................12
           3.1.16. dateTimeMilliseconds ..............................12
           3.1.17. dateTimeMicroseconds ..............................12
           3.1.18. dateTimeNanoseconds ...............................13
           3.1.19. ipv4Address .......................................13
           3.1.20. ipv6Address .......................................13
      3.2. Data Type Semantics .......................................13
           3.2.1. quantity ...........................................13
           3.2.2. totalCounter .......................................13
           3.2.3. deltaCounter .......................................14
           3.2.4. identifier .........................................14
           3.2.5. flags ..............................................14
   4. Information Element Identifiers ................................14
   5. Information Elements ...........................................18
      5.1. Identifiers ...............................................19
           5.1.1. lineCardId .........................................20
           5.1.2. portId .............................................20
           5.1.3. ingressInterface ...................................20
           5.1.4. egressInterface ....................................21
           5.1.5. meteringProcessId ..................................21
           5.1.6. exportingProcessId .................................21
           5.1.7. flowId .............................................22
           5.1.8. templateId .........................................22
           5.1.9. observationDomainId ................................22
           5.1.10. observationPointId ................................23
           5.1.11. commonPropertiesId ................................23
      5.2. Metering and Exporting Process Configuration ..............23
           5.2.1. exporterIPv4Address ................................24
           5.2.2. exporterIPv6Address ................................24
           5.2.3. exporterTransportPort ..............................24
           5.2.4. collectorIPv4Address ...............................25
           5.2.5. collectorIPv6Address ...............................25
           5.2.6. exportInterface ....................................25
           5.2.7. exportProtocolVersion ..............................26
           5.2.8. exportTransportProtocol ............................26
           5.2.9. collectorTransportPort .............................27
           5.2.10. flowKeyIndicator ..................................27
      5.3. Metering and Exporting Process Statistics .................28
           5.3.1. exportedMessageTotalCount ..........................28
           5.3.2. exportedOctetTotalCount ............................28
           5.3.3. exportedFlowRecordTotalCount .......................29
           5.3.4. observedFlowTotalCount .............................29
ToP   noToC   RFC5102 - Page 3
           5.3.5. ignoredPacketTotalCount ............................29
           5.3.6. ignoredOctetTotalCount .............................30
           5.3.7. notSentFlowTotalCount ..............................30
           5.3.8. notSentPacketTotalCount ............................30
           5.3.9. notSentOctetTotalCount .............................31
      5.4. IP Header Fields ..........................................31
           5.4.1. ipVersion ..........................................31
           5.4.2. sourceIPv4Address ..................................32
           5.4.3. sourceIPv6Address ..................................32
           5.4.4. sourceIPv4PrefixLength .............................32
           5.4.5. sourceIPv6PrefixLength .............................33
           5.4.6. sourceIPv4Prefix ...................................33
           5.4.7. sourceIPv6Prefix ...................................33
           5.4.8. destinationIPv4Address .............................33
           5.4.9. destinationIPv6Address .............................34
           5.4.10. destinationIPv4PrefixLength .......................34
           5.4.11. destinationIPv6PrefixLength .......................34
           5.4.12. destinationIPv4Prefix .............................34
           5.4.13. destinationIPv6Prefix .............................35
           5.4.14. ipTTL .............................................35
           5.4.15. protocolIdentifier ................................35
           5.4.16. nextHeaderIPv6 ....................................36
           5.4.17. ipDiffServCodePoint ...............................36
           5.4.18. ipPrecedence ......................................36
           5.4.19. ipClassOfService ..................................37
           5.4.20. postIpClassOfService ..............................37
           5.4.21. flowLabelIPv6 .....................................38
           5.4.22. isMulticast .......................................38
           5.4.23. fragmentIdentification ............................39
           5.4.24. fragmentOffset ....................................39
           5.4.25. fragmentFlags .....................................39
           5.4.26. ipHeaderLength ....................................40
           5.4.27. ipv4IHL ...........................................40
           5.4.28. totalLengthIPv4 ...................................41
           5.4.29. ipTotalLength .....................................41
           5.4.30. payloadLengthIPv6 .................................41
      5.5. Transport Header Fields ...................................42
           5.5.1. sourceTransportPort ................................42
           5.5.2. destinationTransportPort ...........................42
           5.5.3. udpSourcePort ......................................43
           5.5.4. udpDestinationPort .................................43
           5.5.5. udpMessageLength ...................................43
           5.5.6. tcpSourcePort ......................................44
           5.5.7. tcpDestinationPort .................................44
           5.5.8. tcpSequenceNumber ..................................44
           5.5.9. tcpAcknowledgementNumber ...........................44
           5.5.10. tcpWindowSize .....................................45
           5.5.11. tcpWindowScale ....................................45
ToP   noToC   RFC5102 - Page 4
           5.5.12. tcpUrgentPointer ..................................45
           5.5.13. tcpHeaderLength ...................................45
           5.5.14. icmpTypeCodeIPv4 ..................................46
           5.5.15. icmpTypeIPv4 ......................................46
           5.5.16. icmpCodeIPv4 ......................................46
           5.5.17. icmpTypeCodeIPv6 ..................................46
           5.5.18. icmpTypeIPv6 ......................................47
           5.5.19. icmpCodeIPv6 ......................................47
           5.5.20. igmpType ..........................................47
      5.6. Sub-IP Header Fields ......................................48
           5.6.1. sourceMacAddress ...................................48
           5.6.2. postSourceMacAddress ...............................48
           5.6.3. vlanId .............................................49
           5.6.4. postVlanId .........................................49
           5.6.5. destinationMacAddress ..............................49
           5.6.6. postDestinationMacAddress ..........................49
           5.6.7. wlanChannelId ......................................50
           5.6.8. wlanSSID ...........................................50
           5.6.9. mplsTopLabelTTL ....................................50
           5.6.10. mplsTopLabelExp ...................................51
           5.6.11. postMplsTopLabelExp ...............................51
           5.6.12. mplsLabelStackDepth ...............................51
           5.6.13. mplsLabelStackLength ..............................52
           5.6.14. mplsPayloadLength .................................52
           5.6.15. mplsTopLabelStackSection ..........................52
           5.6.16. mplsLabelStackSection2 ............................53
           5.6.17. mplsLabelStackSection3 ............................53
           5.6.18. mplsLabelStackSection4 ............................53
           5.6.19. mplsLabelStackSection5 ............................54
           5.6.20. mplsLabelStackSection6 ............................54
           5.6.21. mplsLabelStackSection7 ............................54
           5.6.22. mplsLabelStackSection8 ............................55
           5.6.23. mplsLabelStackSection9 ............................55
           5.6.24. mplsLabelStackSection10 ...........................55
      5.7. Derived Packet Properties .................................56
           5.7.1. ipPayloadLength ....................................56
           5.7.2. ipNextHopIPv4Address ...............................56
           5.7.3. ipNextHopIPv6Address ...............................57
           5.7.4. bgpSourceAsNumber ..................................57
           5.7.5. bgpDestinationAsNumber .............................57
           5.7.6. bgpNextAdjacentAsNumber ............................57
           5.7.7. bgpPrevAdjacentAsNumber ............................58
           5.7.8. bgpNextHopIPv4Address ..............................58
           5.7.9. bgpNextHopIPv6Address ..............................58
           5.7.10. mplsTopLabelType ..................................59
           5.7.11. mplsTopLabelIPv4Address ...........................59
           5.7.12. mplsTopLabelIPv6Address ...........................60
           5.7.13. mplsVpnRouteDistinguisher .........................60
ToP   noToC   RFC5102 - Page 5
      5.8. Min/Max Flow Properties ...................................61
           5.8.1. minimumIpTotalLength ...............................61
           5.8.2. maximumIpTotalLength ...............................61
           5.8.3. minimumTTL .........................................61
           5.8.4. maximumTTL .........................................62
           5.8.5. ipv4Options ........................................62
           5.8.6. ipv6ExtensionHeaders ...............................64
           5.8.7. tcpControlBits .....................................65
           5.8.8. tcpOptions .........................................66
      5.9. Flow Timestamps ...........................................67
           5.9.1. flowStartSeconds ...................................67
           5.9.2. flowEndSeconds .....................................68
           5.9.3. flowStartMilliseconds ..............................68
           5.9.4. flowEndMilliseconds ................................68
           5.9.5. flowStartMicroseconds ..............................68
           5.9.6. flowEndMicroseconds ................................68
           5.9.7. flowStartNanoseconds ...............................69
           5.9.8. flowEndNanoseconds .................................69
           5.9.9. flowStartDeltaMicroseconds .........................69
           5.9.10. flowEndDeltaMicroseconds ..........................69
           5.9.11. systemInitTimeMilliseconds ........................70
           5.9.12. flowStartSysUpTime ................................70
           5.9.13. flowEndSysUpTime ..................................70
      5.10. Per-Flow Counters ........................................70
           5.10.1. octetDeltaCount ...................................71
           5.10.2. postOctetDeltaCount ...............................71
           5.10.3. octetDeltaSumOfSquares ............................72
           5.10.4. octetTotalCount ...................................72
           5.10.5. postOctetTotalCount ...............................72
           5.10.6. octetTotalSumOfSquares ............................72
           5.10.7. packetDeltaCount ..................................73
           5.10.8. postPacketDeltaCount ..............................73
           5.10.9. packetTotalCount ..................................73
           5.10.10. postPacketTotalCount .............................74
           5.10.11. droppedOctetDeltaCount ...........................74
           5.10.12. droppedPacketDeltaCount ..........................74
           5.10.13. droppedOctetTotalCount ...........................74
           5.10.14. droppedPacketTotalCount ..........................75
           5.10.15. postMCastPacketDeltaCount ........................75
           5.10.16. postMCastOctetDeltaCount .........................75
           5.10.17. postMCastPacketTotalCount ........................76
           5.10.18. postMCastOctetTotalCount .........................76
           5.10.19. tcpSynTotalCount .................................76
           5.10.20. tcpFinTotalCount .................................77
           5.10.21. tcpRstTotalCount .................................77
           5.10.22. tcpPshTotalCount .................................77
           5.10.23. tcpAckTotalCount .................................78
           5.10.24. tcpUrgTotalCount .................................78
ToP   noToC   RFC5102 - Page 6
      5.11. Miscellaneous Flow Properties ............................78
           5.11.1. flowActiveTimeout .................................79
           5.11.2. flowIdleTimeout ...................................79
           5.11.3. flowEndReason .....................................79
           5.11.4. flowDurationMilliseconds ..........................80
           5.11.5. flowDurationMicroseconds ..........................80
           5.11.6. flowDirection .....................................80
      5.12. Padding ..................................................80
           5.12.1. paddingOctets .....................................81
   6. Extending the Information Model ................................81
   7. IANA Considerations ............................................82
      7.1. IPFIX Information Elements ................................82
      7.2. MPLS Label Type Identifier ................................82
      7.3. XML Namespace and Schema ..................................83
   8. Security Considerations ........................................83
   9. Acknowledgements ...............................................84
   10. References ....................................................84
      10.1. Normative References .....................................84
      10.2. Informative References ...................................84
   Appendix A. XML Specification of IPFIX Information Elements .......88
   Appendix B. XML Specification of Abstract Data Types .............157

1. Introduction

The IP Flow Information eXport (IPFIX) protocol serves for transmitting information related to measured IP traffic over the Internet. The protocol specification in [RFC5101] defines how Information Elements are transmitted. For Information Elements, it specifies the encoding of a set of basic data types. However, the list of Information Elements that can be transmitted by the protocol, such as Flow attributes (source IP address, number of packets, etc.) and information about the Metering and Exporting Process (packet Observation Point, sampling rate, Flow timeout interval, etc.), is not specified in [RFC5101]. This document complements the IPFIX protocol specification by providing the IPFIX information model. IPFIX-specific terminology used in this document is defined in Section 2 of [RFC5101]. As in [RFC5101], these IPFIX-specific terms have the first letter of a word capitalized when used in this document. The use of the term 'information model' is not fully in line with the definition of this term in [RFC3444]. The IPFIX information model does not specify relationships between Information Elements, but also it does not specify a concrete encoding of Information Elements. Besides the encoding used by the IPFIX protocol, other encodings of IPFIX Information Elements can be applied, for example, XML-based encodings.
ToP   noToC   RFC5102 - Page 7
   The main part of this document is Section 5, which defines the
   (extensible) list of Information Elements to be transmitted by the
   IPFIX protocol.  Section 2 defines a template for specifying IPFIX
   Information Elements in Section 5.  Section 3 defines the set of
   abstract data types that are available for IPFIX Information
   Elements.  Section 6 discusses extensibility of the IPFIX information
   model.

   The main bodies of Sections 2, 3, and 5 were generated from XML
   documents.  The XML-based specification of template, abstract data
   types, and IPFIX Information Elements can be used for automatically
   checking syntactical correctness of the specification of IPFIX
   Information Elements.  It can further be used for generating IPFIX
   protocol implementation code that deals with processing IPFIX
   Information Elements.  Also, code for applications that further
   process traffic information transmitted via the IPFIX protocol can be
   generated with the XML specification of IPFIX Information Elements.

   For that reason, the XML document that served as a source for Section
   5 and the XML schema that served as source for Sections 2 and 3 are
   attached to this document in Appendices A and B.

   Note that although partially generated from the attached XML
   documents, the main body of this document is normative while the
   appendices are informational.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2. Properties of IPFIX Protocol Information Elements

2.1. Information Elements Specification Template

Information in messages of the IPFIX protocol is modeled in terms of Information Elements of the IPFIX information model. IPFIX Information Elements are specified in Section 5. For specifying these Information Elements, a template is used that is described below. All Information Elements specified for the IPFIX protocol either in this document or by any future extension MUST have the following properties defined: name - A unique and meaningful name for the Information Element.
ToP   noToC   RFC5102 - Page 8
   elementId - A numeric identifier of the Information Element.  If this
      identifier is used without an enterprise identifier (see [RFC5101]
      and enterpriseId below), then it is globally unique and the list
      of allowed values is administered by IANA.  It is used for compact
      identification of an Information Element when encoding Templates
      in the protocol.

   description - The semantics of this Information Element.  Describes
      how this Information Element is derived from the Flow or other
      information available to the observer.

   dataType - One of the types listed in Section 3.1 of this document or
      in a future extension of the information model.  The type space
      for attributes is constrained to facilitate implementation.  The
      existing type space does however encompass most basic types used
      in modern programming languages, as well as some derived types
      (such as ipv4Address) that are common to this domain and useful to
      distinguish.

   status - The status of the specification of this Information Element.
      Allowed values are 'current', 'deprecated', and 'obsolete'.

   Enterprise-specific Information Elements MUST have the following
   property defined:

   enterpriseId - Enterprises may wish to define Information Elements
      without registering them with IANA, for example, for
      enterprise-internal purposes.  For such Information Elements, the
      Information Element identifier described above is not sufficient
      when the Information Element is used outside the enterprise.  If
      specifications of enterprise-specific Information Elements are
      made public and/or if enterprise-specific identifiers are used by
      the IPFIX protocol outside the enterprise, then the
      enterprise-specific identifier MUST be made globally unique by
      combining it with an enterprise identifier.  Valid values for the
      enterpriseId are defined by IANA as Structure of Management
      Information (SMI) network management private enterprise codes.
      They are defined at http://www.iana.org/assignments/enterprise-
      numbers.

   All Information Elements specified for the IPFIX protocol either in
   this document or by any future extension MAY have the following
   properties defined:

   dataTypeSemantics - The integral types may be qualified by additional
      semantic details.  Valid values for the data type semantics are
      specified in Section 3.2 of this document or in a future extension
      of the information model.
ToP   noToC   RFC5102 - Page 9
   units - If the Information Element is a measure of some kind, the
      units identify what the measure is.

   range - Some Information Elements may only be able to take on a
      restricted set of values that can be expressed as a range (e.g., 0
      through 511 inclusive).  If this is the case, the valid inclusive
      range should be specified.

   reference - Identifies additional specifications that more precisely
      define this item or provide additional context for its use.

2.2. Scope of Information Elements

By default, most Information Elements have a scope specified in their definitions. o The Information Elements defined in Sections 5.2 and 5.3 have a default of "a specific Metering Process" or of "a specific Exporting Process", respectively. o The Information Elements defined in Sections 5.4-5.11 have a scope of "a specific Flow". Within Data Records defined by Option Templates, the IPFIX protocol allows further limiting of the Information Element scope. The new scope is specified by one or more scope fields and defined as the combination of all specified scope values; see Section 3.4.2.1 on IPFIX scopes in [RFC5101].

2.3. Naming Conventions for Information Elements

The following naming conventions were used for naming Information Elements in this document. It is recommended that extensions of the model use the same conventions. o Names of Information Elements should be descriptive. o Names of Information Elements that are not enterprise-specific MUST be unique within the IPFIX information model. Enterprise-specific Information Elements SHOULD be prefixed with a vendor name. o Names of Information Elements start with non-capitalized letters.
ToP   noToC   RFC5102 - Page 10
   o  Composed names use capital letters for the first letter of each
      component (except for the first one).  All other letters are
      non-capitalized, even for acronyms.  Exceptions are made for
      acronyms containing non-capitalized letter, such as 'IPv4' and
      'IPv6'.  Examples are sourceMacAddress and destinationIPv4Address.

   o  Middleboxes [RFC3234] may change Flow properties, such as the
      Differentiated Service Code Point (DSCP) value or the source IP
      address.  If an IPFIX Observation Point is located in the path of
      a Flow before one or more middleboxes that potentially modify
      packets of the Flow, then it may be desirable to also report Flow
      properties after the modification performed by the middleboxes.
      An example is an Observation Point before a packet marker changing
      a packet's IPv4 Type of Service (TOS) field that is encoded in
      Information Element classOfServiceIPv4.  Then the value observed
      and reported by Information Element classOfServiceIPv4 is valid at
      the Observation Point, but not after the packet passed the packet
      marker.  For reporting the change value of the TOS field, the
      IPFIX information model uses Information Elements that have a name
      prefix "post", for example, "postClassOfServiceIPv4".  Information
      Elements with prefix "post" report on Flow properties that are not
      necessarily observed at the Observation Point, but which are
      obtained within the Flow's Observation Domain by other means
      considered to be sufficiently reliable, for example, by analyzing
      the packet marker's marking tables.

3. Type Space

This section describes the abstract data types that can be used for the specification of IPFIX Information Elements in Section 4. Section 3.1 describes the set of abstract data types. Abstract data types unsigned8, unsigned16, unsigned32, unsigned64, signed8, signed16, signed32, and signed64 are integral data types. As described in Section 3.2, their data type semantics can be further specified, for example, by 'totalCounter', 'deltaCounter', 'identifier', or 'flags'.

3.1. Abstract Data Types

This section describes the set of valid abstract data types of the IPFIX information model. Note that further abstract data types may be specified by future extensions of the IPFIX information model.

3.1.1. unsigned8

The type "unsigned8" represents a non-negative integer value in the range of 0 to 255.
ToP   noToC   RFC5102 - Page 11

3.1.2. unsigned16

The type "unsigned16" represents a non-negative integer value in the range of 0 to 65535.

3.1.3. unsigned32

The type "unsigned32" represents a non-negative integer value in the range of 0 to 4294967295.

3.1.4. unsigned64

The type "unsigned64" represents a non-negative integer value in the range of 0 to 18446744073709551615.

3.1.5. signed8

The type "signed8" represents an integer value in the range of -128 to 127.

3.1.6. signed16

The type "signed16" represents an integer value in the range of -32768 to 32767.

3.1.7. signed32

The type "signed32" represents an integer value in the range of -2147483648 to 2147483647.

3.1.8. signed64

The type "signed64" represents an integer value in the range of -9223372036854775808 to 9223372036854775807.

3.1.9. float32

The type "float32" corresponds to an IEEE single-precision 32-bit floating point type as defined in [IEEE.754.1985].

3.1.10. float64

The type "float64" corresponds to an IEEE double-precision 64-bit floating point type as defined in [IEEE.754.1985].
ToP   noToC   RFC5102 - Page 12

3.1.11. boolean

The type "boolean" represents a binary value. The only allowed values are "true" and "false".

3.1.12. macAddress

The type "macAddress" represents a string of 6 octets.

3.1.13. octetArray

The type "octetArray" represents a finite-length string of octets.

3.1.14. string

The type "string" represents a finite-length string of valid characters from the Unicode character encoding set [ISO.10646- 1.1993]. Unicode allows for ASCII [ISO.646.1991] and many other international character sets to be used.

3.1.15. dateTimeSeconds

The type "dateTimeSeconds" represents a time value in units of seconds based on coordinated universal time (UTC). The choice of an epoch, for example, 00:00 UTC, January 1, 1970, is left to corresponding encoding specifications for this type, for example, the IPFIX protocol specification. Leap seconds are excluded. Note that transformation of values might be required between different encodings if different epoch values are used.

3.1.16. dateTimeMilliseconds

The type "dateTimeMilliseconds" represents a time value in units of milliseconds based on coordinated universal time (UTC). The choice of an epoch, for example, 00:00 UTC, January 1, 1970, is left to corresponding encoding specifications for this type, for example, the IPFIX protocol specification. Leap seconds are excluded. Note that transformation of values might be required between different encodings if different epoch values are used.

3.1.17. dateTimeMicroseconds

The type "dateTimeMicroseconds" represents a time value in units of microseconds based on coordinated universal time (UTC). The choice of an epoch, for example, 00:00 UTC, January 1, 1970, is left to
ToP   noToC   RFC5102 - Page 13
   corresponding encoding specifications for this type, for example, the
   IPFIX protocol specification.  Leap seconds are excluded.  Note that
   transformation of values might be required between different
   encodings if different epoch values are used.

3.1.18. dateTimeNanoseconds

The type "dateTimeNanoseconds" represents a time value in units of nanoseconds based on coordinated universal time (UTC). The choice of an epoch, for example, 00:00 UTC, January 1, 1970, is left to corresponding encoding specifications for this type, for example, the IPFIX protocol specification. Leap seconds are excluded. Note that transformation of values might be required between different encodings if different epoch values are used.

3.1.19. ipv4Address

The type "ipv4Address" represents a value of an IPv4 address.

3.1.20. ipv6Address

The type "ipv6Address" represents a value of an IPv6 address.

3.2. Data Type Semantics

This section describes the set of valid data type semantics of the IPFIX information model. Note that further data type semantics may be specified by future extensions of the IPFIX information model.

3.2.1. quantity

A quantity value represents a discrete measured value pertaining to the record. This is distinguished from counters that represent an ongoing measured value whose "odometer" reading is captured as part of a given record. If no semantic qualifier is given, the Information Elements that have an integral data type should behave as a quantity.

3.2.2. totalCounter

An integral value reporting the value of a counter. Counters are unsigned and wrap back to zero after reaching the limit of the type. For example, an unsigned64 with counter semantics will continue to increment until reaching the value of 2**64 - 1. At this point, the next increment will wrap its value to zero and continue counting from zero. The semantics of a total counter is similar to the semantics of counters used in SNMP, such as Counter32 defined in RFC 2578 [RFC2578]. The only difference between total counters and counters
ToP   noToC   RFC5102 - Page 14
   used in SNMP is that the total counters have an initial value of 0.
   A total counter counts independently of the export of its value.

3.2.3. deltaCounter

An integral value reporting the value of a counter. Counters are unsigned and wrap back to zero after reaching the limit of the type. For example, an unsigned64 with counter semantics will continue to increment until reaching the value of 2**64 - 1. At this point, the next increment will wrap its value to zero and continue counting from zero. The semantics of a delta counter is similar to the semantics of counters used in SNMP, such as Counter32 defined in RFC 2578 [RFC2578]. The only difference between delta counters and counters used in SNMP is that the delta counters have an initial value of 0. A delta counter is reset to 0 each time its value is exported.

3.2.4. identifier

An integral value that serves as an identifier. Specifically, mathematical operations on two identifiers (aside from the equality operation) are meaningless. For example, Autonomous System ID 1 * Autonomous System ID 2 is meaningless.

3.2.5. flags

An integral value that actually represents a set of bit fields. Logical operations are appropriate on such values, but not other mathematical operations. Flags should always be of an unsigned type.


(page 14 continued on part 2)

Next Section