tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5102


Pages: 171
Top     in Index     Prev     Next
 

Information Model for IP Flow Information Export

Part 1 of 7, p. 1 to 14
None       Next RFC Part

Obsoleted by:    7012
Updated by:    6313


Top       ToC       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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 RFC Part