GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5102

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

Quittek, et al. Standards Track [Page 1] RFC 5102 IPFIX Information Model January 2008

         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

Quittek, et al. Standards Track [Page 2] RFC 5102 IPFIX Information Model January 2008

         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

Quittek, et al. Standards Track [Page 3] RFC 5102 IPFIX Information Model January 2008

         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

Quittek, et al. Standards Track [Page 4] RFC 5102 IPFIX Information Model January 2008

    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

Quittek, et al. Standards Track [Page 5] RFC 5102 IPFIX Information Model January 2008

    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.

Quittek, et al. Standards Track [Page 6] RFC 5102 IPFIX Information Model January 2008

 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.

Quittek, et al. Standards Track [Page 7] RFC 5102 IPFIX Information Model January 2008

 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.

Quittek, et al. Standards Track [Page 8] RFC 5102 IPFIX Information Model January 2008

 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.

Quittek, et al. Standards Track [Page 9] RFC 5102 IPFIX Information Model January 2008

 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.

Quittek, et al. Standards Track [Page 10] RFC 5102 IPFIX Information Model January 2008

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].

Quittek, et al. Standards Track [Page 11] RFC 5102 IPFIX Information Model January 2008

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

Quittek, et al. Standards Track [Page 12] RFC 5102 IPFIX Information Model January 2008

 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

Quittek, et al. Standards Track [Page 13] RFC 5102 IPFIX Information Model January 2008

 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.

4. Information Element Identifiers

 All Information Elements defined in Section 5 of this document or in
 future extensions of the IPFIX information model have their
 identifiers assigned by IANA.  Their identifiers can be retrieved at
 http://www.iana.org/assignments/ipfix.
 The value of these identifiers is in the range of 1-32767.  Within
 this range, Information Element identifier values in the sub-range of
 1-127 are compatible with field types used by NetFlow version 9
 [RFC3954].

Quittek, et al. Standards Track [Page 14] RFC 5102 IPFIX Information Model January 2008

 +---------------------------------+---------------------------------+
 | Range of IANA-assigned          | Description                     |
 | Information Element identifiers |                                 |
 +---------------------------------+---------------------------------+
 | 0                               | Reserved.                       |
 | 1-127                           | Information Element identifiers |
 |                                 | compatible with NetFlow version |
 |                                 | 9 field types [RFC3954].        |
 | 128-32767                       | Further Information Element     |
 |                                 | identifiers.                    |
 +---------------------------------+---------------------------------+
 Enterprise-specific Information Element identifiers have the same
 range of 1-32767, but they are coupled with an additional enterprise
 identifier.  For enterprise-specific Information Elements,
 Information Element identifier 0 is also reserved.
 Enterprise-specific Information Element identifiers can be chosen by
 an enterprise arbitrarily within the range of 1-32767.  The same
 identifier may be assigned by other enterprises for different
 purposes.
 Still, Collecting Processes can distinguish these Information
 Elements because the Information Element identifier is coupled with
 an enterprise identifier.
 Enterprise identifiers MUST be registered as SMI network management
 private enterprise code numbers with IANA.  The registry can be found
 at http://www.iana.org/assignments/enterprise-numbers.
 The following list gives an overview of the Information Element
 identifiers that are specified in Section 5 and are compatible with
 field types used by NetFlow version 9 [RFC3954].

Quittek, et al. Standards Track [Page 15] RFC 5102 IPFIX Information Model January 2008

 +----+----------------------------+-------+-------------------------+
 | ID | Name                       |    ID | Name                    |
 +----+----------------------------+-------+-------------------------+
 |  1 | octetDeltaCount            |    43 | RESERVED                |
 |  2 | packetDeltaCount           |    44 | sourceIPv4Prefix        |
 |  3 | RESERVED                   |    45 | destinationIPv4Prefix   |
 |  4 | protocolIdentifier         |    46 | mplsTopLabelType        |
 |  5 | ipClassOfService           |    47 | mplsTopLabelIPv4Address |
 |  6 | tcpControlBits             | 48-51 | RESERVED                |
 |  7 | sourceTransportPort        |    52 | minimumTTL              |
 |  8 | sourceIPv4Address          |    53 | maximumTTL              |
 |  9 | sourceIPv4PrefixLength     |    54 | fragmentIdentification  |
 | 10 | ingressInterface           |    55 | postIpClassOfService    |
 | 11 | destinationTransportPort   |    56 | sourceMacAddress        |
 | 12 | destinationIPv4Address     |    57 |postDestinationMacAddress|
 | 13 | destinationIPv4PrefixLength|    58 | vlanId                  |
 | 14 | egressInterface            |    59 | postVlanId              |
 | 15 | ipNextHopIPv4Address       |    60 | ipVersion               |
 | 16 | bgpSourceAsNumber          |    61 | flowDirection           |
 | 17 | bgpDestinationAsNumber     |    62 | ipNextHopIPv6Address    |
 | 18 | bgpNexthopIPv4Address      |    63 | bgpNexthopIPv6Address   |
 | 19 | postMCastPacketDeltaCount  |    64 | ipv6ExtensionHeaders    |
 | 20 | postMCastOctetDeltaCount   | 65-69 | RESERVED                |
 | 21 | flowEndSysUpTime           |    70 | mplsTopLabelStackSection|
 | 22 | flowStartSysUpTime         |    71 | mplsLabelStackSection2  |
 | 23 | postOctetDeltaCount        |    72 | mplsLabelStackSection3  |
 | 24 | postPacketDeltaCount       |    73 | mplsLabelStackSection4  |
 | 25 | minimumIpTotalLength       |    74 | mplsLabelStackSection5  |
 | 26 | maximumIpTotalLength       |    75 | mplsLabelStackSection6  |
 | 27 | sourceIPv6Address          |    76 | mplsLabelStackSection7  |
 | 28 | destinationIPv6Address     |    77 | mplsLabelStackSection8  |
 | 29 | sourceIPv6PrefixLength     |    78 | mplsLabelStackSection9  |
 | 30 | destinationIPv6PrefixLength|    79 | mplsLabelStackSection10 |
 | 31 | flowLabelIPv6              |    80 | destinationMacAddress   |
 | 32 | icmpTypeCodeIPv4           |    81 | postSourceMacAddress    |
 | 33 | igmpType                   | 82-84 | RESERVED                |
 | 34 | RESERVED                   |    85 | octetTotalCount         |
 | 35 | RESERVED                   |    86 | packetTotalCount        |
 | 36 | flowActiveTimeout          |    87 | RESERVED                |
 | 37 | flowIdleTimeout            |    88 | fragmentOffset          |
 | 38 | RESERVED                   |    89 | RESERVED                |
 | 39 | RESERVED                   |    90 |mplsVpnRouteDistinguisher|
 | 40 | exportedOctetTotalCount    |91-127 | RESERVED                |
 | 41 | exportedMessageTotalCount  |       |                         |
 | 42 |exportedFlowRecordTotalCount|       |                         |
 +----+----------------------------+-------+-------------------------+

Quittek, et al. Standards Track [Page 16] RFC 5102 IPFIX Information Model January 2008

 The following list gives an overview of the Information Element
 identifiers that are specified in Section 5 and extends the list of
 Information Element identifiers specified already in [RFC3954].
 +-----+---------------------------+-----+---------------------------+
 |  ID | Name                      |  ID | Name                      |
 +-----+---------------------------+-----+---------------------------+
 | 128 | bgpNextAdjacentAsNumber   | 169 | destinationIPv6Prefix     |
 | 129 | bgpPrevAdjacentAsNumber   | 170 | sourceIPv6Prefix          |
 | 130 | exporterIPv4Address       | 171 | postOctetTotalCount       |
 | 131 | exporterIPv6Address       | 172 | postPacketTotalCount      |
 | 132 | droppedOctetDeltaCount    | 173 | flowKeyIndicator          |
 | 133 | droppedPacketDeltaCount   | 174 | postMCastPacketTotalCount |
 | 134 | droppedOctetTotalCount    | 175 | postMCastOctetTotalCount  |
 | 135 | droppedPacketTotalCount   | 176 | icmpTypeIPv4              |
 | 136 | flowEndReason             | 177 | icmpCodeIPv4              |
 | 137 | commonPropertiesId        | 178 | icmpTypeIPv6              |
 | 138 | observationPointId        | 179 | icmpCodeIPv6              |
 | 139 | icmpTypeCodeIPv6          | 180 | udpSourcePort             |
 | 140 | mplsTopLabelIPv6Address   | 181 | udpDestinationPort        |
 | 141 | lineCardId                | 182 | tcpSourcePort             |
 | 142 | portId                    | 183 | tcpDestinationPort        |
 | 143 | meteringProcessId         | 184 | tcpSequenceNumber         |
 | 144 | exportingProcessId        | 185 | tcpAcknowledgementNumber  |
 | 145 | templateId                | 186 | tcpWindowSize             |
 | 146 | wlanChannelId             | 187 | tcpUrgentPointer          |
 | 147 | wlanSSID                  | 188 | tcpHeaderLength           |
 | 148 | flowId                    | 189 | ipHeaderLength            |
 | 149 | observationDomainId       | 190 | totalLengthIPv4           |
 | 150 | flowStartSeconds          | 191 | payloadLengthIPv6         |
 | 151 | flowEndSeconds            | 192 | ipTTL                     |
 | 152 | flowStartMilliseconds     | 193 | nextHeaderIPv6            |
 | 153 | flowEndMilliseconds       | 194 | mplsPayloadLength         |
 | 154 | flowStartMicroseconds     | 195 | ipDiffServCodePoint       |
 | 155 | flowEndMicroseconds       | 196 | ipPrecedence              |
 | 156 | flowStartNanoseconds      | 197 | fragmentFlags             |
 | 157 | flowEndNanoseconds        | 198 | octetDeltaSumOfSquares    |
 | 158 | flowStartDeltaMicroseconds| 199 | octetTotalSumOfSquares    |
 | 159 | flowEndDeltaMicroseconds  | 200 | mplsTopLabelTTL           |
 | 160 | systemInitTimeMilliseconds| 201 | mplsLabelStackLength      |
 | 161 | flowDurationMilliseconds  | 202 | mplsLabelStackDepth       |
 | 162 | flowDurationMicroseconds  | 203 | mplsTopLabelExp           |
 | 163 | observedFlowTotalCount    | 204 | ipPayloadLength           |
 | 164 | ignoredPacketTotalCount   | 205 | udpMessageLength          |
 | 165 | ignoredOctetTotalCount    | 206 | isMulticast               |
 | 166 | notSentFlowTotalCount     | 207 | ipv4IHL                   |
 | 167 | notSentPacketTotalCount   | 208 | ipv4Options               |
 | 168 | notSentOctetTotalCount    | 209 | tcpOptions                |

Quittek, et al. Standards Track [Page 17] RFC 5102 IPFIX Information Model January 2008

 +-----+---------------------------+-----+---------------------------+
 |  ID | Name                      |  ID | Name                      |
 +-----+---------------------------+-----+---------------------------+
 | 210 | paddingOctets             | 218 | tcpSynTotalCount          |
 | 211 | collectorIPv4Address      | 219 | tcpFinTotalCount          |
 | 212 | collectorIPv6Address      | 220 | tcpRstTotalCount          |
 | 213 | exportInterface           | 221 | tcpPshTotalCount          |
 | 214 | exportProtocolVersion     | 222 | tcpAckTotalCount          |
 | 215 | exportTransportProtocol   | 223 | tcpUrgTotalCount          |
 | 216 | collectorTransportPort    | 224 | ipTotalLength             |
 | 217 | exporterTransportPort     | 237 | postMplsTopLabelExp       |
 |     |                           | 238 | tcpWindowScale            |
 +-----+---------------------------+-----+---------------------------+

5. Information Elements

 This section describes the Information Elements of the IPFIX
 information model.  The elements are grouped into 12 groups according
 to their semantics and their applicability:
 1.   Identifiers
 2.   Metering and Exporting Process Configuration
 3.   Metering and Exporting Process Statistics
 4.   IP Header Fields
 5.   Transport Header Fields
 6.   Sub-IP Header Fields
 7.   Derived Packet Properties
 8.   Min/Max Flow Properties
 9.   Flow Timestamps
 10.  Per-Flow Counters
 11.  Miscellaneous Flow Properties
 12.  Padding
 The Information Elements that are derived from fields of packets or
 from packet treatment, such as the Information Elements in groups
 4-7, can typically serve as Flow Keys used for mapping packets to
 Flows.
 If they do not serve as Flow Keys, their value may change from packet
 to packet within a single Flow.  For Information Elements with values
 that are derived from fields of packets or from packet treatment and
 for which the value may change from packet to packet within a single
 Flow, the IPFIX information model defines that their value is
 determined by the first packet observed for the corresponding Flow,
 unless the description of the Information Element explicitly
 specifies a different semantics.  This simple rule allows writing all

Quittek, et al. Standards Track [Page 18] RFC 5102 IPFIX Information Model January 2008

 Information Elements related to header fields once when the first
 packet of the Flow is observed.  For further observed packets of the
 same Flow, only Flow properties that depend on more than one packet,
 such as the Information Elements in groups 8-11, need to be updated.
 Information Elements with a name having the "post" prefix, for
 example, "postClassOfServiceIPv4", do not report properties that were
 actually observed at the Observation Point, but retrieved by other
 means within the Observation Domain.  These Information Elements can
 be used if there are middlebox functions within the Observation
 Domain changing Flow properties after packets passed the Observation
 Point.
 Information Elements in this section use the reference property to
 reference [RFC0768], [RFC0791], [RFC0792], [RFC0793], [RFC1108],
 [RFC1112], [RFC1191], [RFC1323], [RFC1385], [RFC1812], [RFC1930],
 [RFC2113], [RFC2119], [RFC2460], [RFC2675], [RFC2863], [RFC3031],
 [RFC3032], [RFC3193], [RFC3234], [RFC3260], [RFC3270], [RFC3376],
 [RFC3954], [RFC4271], [RFC4291], [RFC4302], [RFC4303], [RFC4364],
 [RFC4382], [RFC4443], [RFC4960], [RFC5036], [IEEE.802-11.1999],
 [IEEE.802-1Q.2003], and [IEEE.802-3.2002].

5.1. Identifiers

 Information Elements grouped in the table below are identifying
 components of the IPFIX architecture, of an IPFIX Device, or of the
 IPFIX protocol.  All of them have an integral abstract data type and
 data type semantics "identifier" as described in Section 3.2.4.
 Typically, some of them are used for limiting scopes of other
 Information Elements.  However, other Information Elements MAY be
 used for limiting scopes.  Note also that all Information Elements
 listed below MAY be used for other purposes than limiting scopes.
 +-----+---------------------------+-----+---------------------------+
 |  ID | Name                      |  ID | Name                      |
 +-----+---------------------------+-----+---------------------------+
 | 141 | lineCardId                | 148 | flowId                    |
 | 142 | portId                    | 145 | templateId                |
 |  10 | ingressInterface          | 149 | observationDomainId       |
 |  14 | egressInterface           | 138 | observationPointId        |
 | 143 | meteringProcessId         | 137 | commonPropertiesId        |
 | 144 | exportingProcessId        |     |                           |
 +-----+---------------------------+-----+---------------------------+

Quittek, et al. Standards Track [Page 19] RFC 5102 IPFIX Information Model January 2008

5.1.1. lineCardId

 Description:
    An identifier of a line card that is unique per IPFIX Device
    hosting an Observation Point.  Typically, this Information Element
    is used for limiting the scope of other Information Elements.
 Abstract Data Type: unsigned32
 Data Type Semantics: identifier
 ElementId: 141
 Status: current

5.1.2. portId

 Description:
    An identifier of a line port that is unique per IPFIX Device
    hosting an Observation Point.  Typically, this Information Element
    is used for limiting the scope of other Information Elements.
 Abstract Data Type: unsigned32
 Data Type Semantics: identifier
 ElementId: 142
 Status: current

5.1.3. ingressInterface

 Description:
    The index of the IP interface where packets of this Flow are being
    received.  The value matches the value of managed object 'ifIndex'
    as defined in RFC 2863.  Note that ifIndex values are not assigned
    statically to an interface and that the interfaces may be
    renumbered every time the device's management system is
    re-initialized, as specified in RFC 2863.
 Abstract Data Type: unsigned32
 Data Type Semantics: identifier
 ElementId: 10
 Status: current
 Reference:
    See RFC 2863 for the definition of the ifIndex object.

Quittek, et al. Standards Track [Page 20] RFC 5102 IPFIX Information Model January 2008

5.1.4. egressInterface

 Description:
    The index of the IP interface where packets of this Flow are being
    sent.  The value matches the value of managed object 'ifIndex' as
    defined in RFC 2863.  Note that ifIndex values are not assigned
    statically to an interface and that the interfaces may be
    renumbered every time the device's management system is
    re-initialized, as specified in RFC 2863.
 Abstract Data Type: unsigned32
 Data Type Semantics: identifier
 ElementId: 14
 Status: current
 Reference:
    See RFC 2863 for the definition of the ifIndex object.

5.1.5. meteringProcessId

 Description:
    An identifier of a Metering Process that is unique per IPFIX
    Device.  Typically, this Information Element is used for limiting
    the scope of other Information Elements.  Note that process
    identifiers are typically assigned dynamically.  The Metering
    Process may be re-started with a different ID.
 Abstract Data Type: unsigned32
 Data Type Semantics: identifier
 ElementId: 143
 Status: current

5.1.6. exportingProcessId

 Description:
    An identifier of an Exporting Process that is unique per IPFIX
    Device.  Typically, this Information Element is used for limiting
    the scope of other Information Elements.  Note that process
    identifiers are typically assigned dynamically.  The Exporting
    Process may be re-started with a different ID.
 Abstract Data Type: unsigned32
 Data Type Semantics: identifier
 ElementId: 144
 Status: current

Quittek, et al. Standards Track [Page 21] RFC 5102 IPFIX Information Model January 2008

5.1.7. flowId

 Description:
    An identifier of a Flow that is unique within an Observation
    Domain.  This Information Element can be used to distinguish
    between different Flows if Flow Keys such as IP addresses and port
    numbers are not reported or are reported in separate records.
 Abstract Data Type: unsigned64
 Data Type Semantics: identifier
 ElementId: 148
 Status: current

5.1.8. templateId

 Description:
    An identifier of a Template that is locally unique within a
    combination of a Transport session and an Observation Domain.
    Template IDs 0-255 are reserved for Template Sets, Options
    Template Sets, and other reserved Sets yet to be created.
    Template IDs of Data Sets are numbered from 256 to 65535.
    Typically, this Information Element is used for limiting the scope
    of other Information Elements.  Note that after a re-start of the
    Exporting Process Template identifiers may be re-assigned.
 Abstract Data Type: unsigned16
 Data Type Semantics: identifier
 ElementId: 145
 Status: current

5.1.9. observationDomainId

 Description:
    An identifier of an Observation Domain that is locally unique to
    an Exporting Process.  The Exporting Process uses the Observation
    Domain ID to uniquely identify to the Collecting Process the
    Observation Domain where Flows were metered.  It is RECOMMENDED
    that this identifier is also unique per IPFIX Device.  A value of
    0 indicates that no specific Observation Domain is identified by
    this Information Element.  Typically, this Information Element is
    used for limiting the scope of other Information Elements.
 Abstract Data Type: unsigned32
 Data Type Semantics: identifier
 ElementId: 149
 Status: current

Quittek, et al. Standards Track [Page 22] RFC 5102 IPFIX Information Model January 2008

5.1.10. observationPointId

 Description:
    An identifier of an Observation Point that is unique per
    Observation Domain.  It is RECOMMENDED that this identifier is
    also unique per IPFIX Device.  Typically, this Information Element
    is used for limiting the scope of other Information Elements.
 Abstract Data Type: unsigned32
 Data Type Semantics: identifier
 ElementId: 138
 Status: current

5.1.11. commonPropertiesId

 Description:
    An identifier of a set of common properties that is unique per
    Observation Domain and Transport Session.  Typically, this
    Information Element is used to link to information reported in
    separate Data Records.
 Abstract Data Type: unsigned64
 Data Type Semantics: identifier
 ElementId: 137
 Status: current

5.2. Metering and Exporting Process Configuration

 Information Elements in this section describe the configuration of
 the Metering Process or the Exporting Process.  The set of these
 Information Elements is listed in the table below.
 +-----+--------------------------+-----+----------------------------+
 |  ID | Name                     |  ID | Name                       |
 +-----+--------------------------+-----+----------------------------+
 | 130 | exporterIPv4Address      | 213 | exportInterface            |
 | 131 | exporterIPv6Address      | 214 | exportProtocolVersion      |
 | 217 | exporterTransportPort    | 215 | exportTransportProtocol    |
 | 211 | collectorIPv4Address     | 216 | collectorTransportPort     |
 | 212 | collectorIPv6Address     | 173 | flowKeyIndicator           |
 +-----+--------------------------+-----+----------------------------+

Quittek, et al. Standards Track [Page 23] RFC 5102 IPFIX Information Model January 2008

5.2.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
 ElementId: 130
 Status: current

5.2.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
 ElementId: 131
 Status: current

5.2.3. exporterTransportPort

 Description:
    The source port identifier from which the Exporting Process sends
    Flow information.  For the transport protocols UDP, TCP, and SCTP,
    this is the source port number.  This field MAY also be used for
    future transport protocols that have 16-bit source port
    identifiers.  This field may be useful for distinguishing multiple
    Exporting Processes that use the same IP address.
 Abstract Data Type: unsigned16
 Data Type Semantics: identifier
 ElementId: 217
 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
    4960 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. Standards Track [Page 24] RFC 5102 IPFIX Information Model January 2008

5.2.4. collectorIPv4Address

 Description:
    An IPv4 address to which the Exporting Process sends Flow
    information.
 Abstract Data Type: ipv4Address
 Data Type Semantics: identifier
 ElementId: 211
 Status: current

5.2.5. collectorIPv6Address

 Description:
    An IPv6 address to which the Exporting Process sends Flow
    information.
 Abstract Data Type: ipv6Address
 Data Type Semantics: identifier
 ElementId: 212
 Status: current

5.2.6. exportInterface

 Description:
    The index of the interface from which IPFIX Messages sent by the
    Exporting Process to a Collector leave the IPFIX Device.  The
    value matches the value of managed object 'ifIndex' as defined in
    RFC 2863.  Note that ifIndex values are not assigned statically to
    an interface and that the interfaces may be renumbered every time
    the device's management system is re-initialized, as specified in
    RFC 2863.
 Abstract Data Type: unsigned32
 Data Type Semantics: identifier
 ElementId: 213
 Status: current
 Reference:
    See RFC 2863 for the definition of the ifIndex object.

Quittek, et al. Standards Track [Page 25] RFC 5102 IPFIX Information Model January 2008

5.2.7. exportProtocolVersion

 Description:
    The protocol version used by the Exporting Process for sending
    Flow information.  The protocol version is given by the value of
    the Version Number field in the Message Header.  The protocol
    version is 10 for IPFIX and 9 for NetFlow version 9.  A value of 0
    indicates that no export protocol is in use.
 Abstract Data Type: unsigned8
 Data Type Semantics: identifier
 ElementId: 214
 Status: current
 Reference:
    See the IPFIX protocol specification [RFC5101] for the definition
    of the IPFIX Message Header.
    See RFC 3954 for the definition of the NetFlow version 9 message
    header.

5.2.8. exportTransportProtocol

 Description:
    The value of the protocol number used by the Exporting Process for
    sending Flow information.  The protocol number identifies the IP
    packet payload type.  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: unsigned8
 Data Type Semantics: identifier
 ElementId: 215
 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
    the list of protocol numbers assigned by IANA at
    http://www.iana.org/assignments/protocol-numbers.

Quittek, et al. Standards Track [Page 26] RFC 5102 IPFIX Information Model January 2008

5.2.9. collectorTransportPort

 Description:
    The destination port identifier to which the Exporting Process
    sends Flow information.  For the transport protocols UDP, TCP, and
    SCTP, this is the destination port number.  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
 ElementId: 216
 Status: current
 Reference:
    See RFC 768 for the definition of the UDP destination port field.
    See RFC 793 for the definition of the TCP destination port field.
    See RFC 4960 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.10. flowKeyIndicator

 Description:
    This set of bit fields is used for marking the Information
    Elements of a Data Record that serve as Flow Key.  Each bit
    represents an Information Element in the Data Record with the n-th
    bit representing the n-th Information Element.  A bit set to value
    1 indicates that the corresponding Information Element is a Flow
    Key of the reported Flow.  A bit set to value 0 indicates that
    this is not the case.
    If the Data Record contains more than 64 Information Elements, the
    corresponding Template SHOULD be designed such that all Flow Keys
    are among the first 64 Information Elements, because the
    flowKeyIndicator only contains 64 bits.  If the Data Record
    contains less than 64 Information Elements, then the bits in the
    flowKeyIndicator for which no corresponding Information Element
    exists MUST have the value 0.
 Abstract Data Type: unsigned64
 Data Type Semantics: flags
 ElementId: 173
 Status: current

Quittek, et al. Standards Track [Page 27] RFC 5102 IPFIX Information Model January 2008

5.3. Metering and Exporting Process Statistics

 Information Elements in this section describe statistics of the
 Metering Process and/or the Exporting Process.  The set of these
 Information Elements is listed in the table below.
 +-----+-----------------------------+-----+-------------------------+
 |  ID | Name                        |  ID | Name                    |
 +-----+-----------------------------+-----+-------------------------+
 |  41 | exportedMessageTotalCount   | 165 | ignoredOctetTotalCount  |
 |  40 | exportedOctetTotalCount     | 166 | notSentFlowTotalCount   |
 |  42 | exportedFlowRecordTotalCount| 167 | notSentPacketTotalCount |
 | 163 | observedFlowTotalCount      | 168 | notSentOctetTotalCount  |
 | 164 | ignoredPacketTotalCount     |     |                         |
 +-----+-----------------------------+-----+-------------------------+

5.3.1. exportedMessageTotalCount

 Description:
    The total number of IPFIX Messages that the Exporting Process has
    sent since the Exporting Process (re-)initialization to a
    particular Collecting Process.  The reported number excludes the
    IPFIX Message that carries the counter value.  If this Information
    Element is sent to a particular Collecting Process, then by
    default it specifies the number of IPFIX Messages sent to this
    Collecting Process.
 Abstract Data Type: unsigned64
 Data Type Semantics: totalCounter
 ElementId: 41
 Status: current
 Units: messages

5.3.2. exportedOctetTotalCount

 Description:
    The total number of octets that the Exporting Process has sent
    since the Exporting Process (re-)initialization to a particular
    Collecting Process.  The value of this Information Element is
    calculated by summing up the IPFIX Message Header length values of
    all IPFIX Messages that were successfully sent to the Collecting
    Process.  The reported number excludes octets in the IPFIX Message
    that carries the counter value.  If this Information Element is
    sent to a particular Collecting Process, then by default it
    specifies the number of octets sent to this Collecting Process.
 Abstract Data Type: unsigned64
 Data Type Semantics: totalCounter
 ElementId: 40
 Status: current

Quittek, et al. Standards Track [Page 28] RFC 5102 IPFIX Information Model January 2008

 Units: octets

5.3.3. exportedFlowRecordTotalCount

 Description:
    The total number of Flow Records that the Exporting Process has
    sent as Data Records since the Exporting Process
    (re-)initialization to a particular Collecting Process.  The
    reported number excludes Flow Records in the IPFIX Message that
    carries the counter value.  If this Information Element is sent to
    a particular Collecting Process, then by default it specifies the
    number of Flow Records sent to this process.
 Abstract Data Type: unsigned64
 Data Type Semantics: totalCounter
 ElementId: 42
 Status: current
 Units: flows

5.3.4. observedFlowTotalCount

 Description:
    The total number of Flows observed in the Observation Domain since
    the Metering Process (re-)initialization for this Observation
    Point.
 Abstract Data Type: unsigned64
 Data Type Semantics: totalCounter
 ElementId: 163
 Status: current
 Units: flows

5.3.5. ignoredPacketTotalCount

 Description:
    The total number of observed IP packets that the Metering Process
    did not process since the (re-)initialization of the Metering
    Process.
 Abstract Data Type: unsigned64
 Data Type Semantics: totalCounter
 ElementId: 164
 Status: current
 Units: packets

Quittek, et al. Standards Track [Page 29] RFC 5102 IPFIX Information Model January 2008

5.3.6. ignoredOctetTotalCount

 Description:
    The total number of octets in observed IP packets (including the
    IP header) that the Metering Process did not process since the
    (re-)initialization of the Metering Process.
 Abstract Data Type: unsigned64
 Data Type Semantics: totalCounter
 ElementId: 165
 Status: current
 Units: octets

5.3.7. notSentFlowTotalCount

 Description:
    The total number of Flow Records that were generated by the
    Metering Process and dropped by the Metering Process or by the
    Exporting Process instead of being sent to the Collecting Process.
    There are several potential reasons for this including resource
    shortage and special Flow export policies.
 Abstract Data Type: unsigned64
 Data Type Semantics: totalCounter
 ElementId: 166
 Status: current
 Units: flows

5.3.8. notSentPacketTotalCount

 Description:
    The total number of packets in Flow Records that were generated by
    the Metering Process and dropped by the Metering Process or by the
    Exporting Process instead of being sent to the Collecting Process.
    There are several potential reasons for this including resource
    shortage and special Flow export policies.
 Abstract Data Type: unsigned64
 Data Type Semantics: totalCounter
 ElementId: 167
 Status: current
 Units: packets

Quittek, et al. Standards Track [Page 30] RFC 5102 IPFIX Information Model January 2008

5.3.9. notSentOctetTotalCount

 Description:
    The total number of octets in packets in Flow Records that were
    generated by the Metering Process and dropped by the Metering
    Process or by the Exporting Process instead of being sent to the
    Collecting Process.  There are several potential reasons for this
    including resource shortage and special Flow export policies.
 Abstract Data Type: unsigned64
 Data Type Semantics: totalCounter
 ElementId: 168
 Status: current
 Units: octets

5.4. IP Header Fields

 Information Elements in this section indicate values of IP header
 fields or are derived from IP header field values in combination with
 further information.
 +-----+----------------------------+-----+--------------------------+
 |  ID | Name                       |  ID | Name                     |
 +-----+----------------------------+-----+--------------------------+
 |  60 | ipVersion                  | 193 | nextHeaderIPv6           |
 |   8 | sourceIPv4Address          | 195 | ipDiffServCodePoint      |
 |  27 | sourceIPv6Address          | 196 | ipPrecedence             |
 |   9 | sourceIPv4PrefixLength     |   5 | ipClassOfService         |
 |  29 | sourceIPv6PrefixLength     |  55 | postIpClassOfService     |
 |  44 | sourceIPv4Prefix           |  31 | flowLabelIPv6            |
 | 170 | sourceIPv6Prefix           | 206 | isMulticast              |
 |  12 | destinationIPv4Address     |  54 | fragmentIdentification   |
 |  28 | destinationIPv6Address     |  88 | fragmentOffset           |
 |  13 | destinationIPv4PrefixLength| 197 | fragmentFlags            |
 |  30 | destinationIPv6PrefixLength| 189 | ipHeaderLength           |
 |  45 | destinationIPv4Prefix      | 207 | ipv4IHL                  |
 | 169 | destinationIPv6Prefix      | 190 | totalLengthIPv4          |
 | 192 | ipTTL                      | 224 | ipTotalLength            |
 |   4 | protocolIdentifier         | 191 | payloadLengthIPv6        |
 +-----+----------------------------+-----+--------------------------+

5.4.1. ipVersion

 Description:
    The IP version field in the IP packet header.
 Abstract Data Type: unsigned8
 Data Type Semantics: identifier
 ElementId: 60
 Status: current

Quittek, et al. Standards Track [Page 31] RFC 5102 IPFIX Information Model January 2008

 Reference:
    See RFC 791 for the definition of the version field in the IPv4
    packet header.  See RFC 2460 for the 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.4.2. sourceIPv4Address

 Description:
    The IPv4 source address in the IP packet header.
 Abstract Data Type: ipv4Address
 Data Type Semantics: identifier
 ElementId: 8
 Status: current
 Reference:
    See RFC 791 for the definition of the IPv4 source address field.

5.4.3. sourceIPv6Address

 Description:
    The IPv6 source address in the IP packet header.
 Abstract Data Type: ipv6Address
 Data Type Semantics: identifier
 ElementId: 27
 Status: current
 Reference:
    See RFC 2460 for the definition of the Source Address field in the
    IPv6 header.

5.4.4. sourceIPv4PrefixLength

 Description:
    The number of contiguous bits that are relevant in the
    sourceIPv4Prefix Information Element.
 Abstract Data Type: unsigned8
 ElementId: 9
 Status: current
 Units: bits
 Range: The valid range is 0-32.

Quittek, et al. Standards Track [Page 32] RFC 5102 IPFIX Information Model January 2008

5.4.5. sourceIPv6PrefixLength

 Description:
    The number of contiguous bits that are relevant in the
    sourceIPv6Prefix Information Element.
 Abstract Data Type: unsigned8
 ElementId: 29
 Status: current
 Units: bits
 Range: The valid range is 0-128.

5.4.6. sourceIPv4Prefix

 Description:
    IPv4 source address prefix.
 Abstract Data Type: ipv4Address
 ElementId: 44
 Status: current

5.4.7. sourceIPv6Prefix

 Description:
    IPv6 source address prefix.
 Abstract Data Type: ipv6Address
 ElementId: 170
 Status: current

5.4.8. destinationIPv4Address

 Description:
    The IPv4 destination address in the IP packet header.
 Abstract Data Type: ipv4Address
 Data Type Semantics: identifier
 ElementId: 12
 Status: current
 Reference:
    See RFC 791 for the definition of the IPv4 destination address
    field.

Quittek, et al. Standards Track [Page 33] RFC 5102 IPFIX Information Model January 2008

5.4.9. destinationIPv6Address

 Description:
    The IPv6 destination address in the IP packet header.
 Abstract Data Type: ipv6Address
 Data Type Semantics: identifier
 ElementId: 28
 Status: current
 Reference:
    See RFC 2460 for the definition of the Destination Address field
    in the IPv6 header.

5.4.10. destinationIPv4PrefixLength

 Description:
    The number of contiguous bits that are relevant in the
    destinationIPv4Prefix Information Element.
 Abstract Data Type: unsigned8
 ElementId: 13
 Status: current
 Units: bits
 Range: The valid range is 0-32.

5.4.11. destinationIPv6PrefixLength

 Description:
    The number of contiguous bits that are relevant in the
    destinationIPv6Prefix Information Element.
 Abstract Data Type: unsigned8
 ElementId: 30
 Status: current
 Units: bits
 Range: The valid range is 0-128.

5.4.12. destinationIPv4Prefix

 Description:
    IPv4 destination address prefix.
 Abstract Data Type: ipv4Address
 ElementId: 45
 Status: current

Quittek, et al. Standards Track [Page 34] RFC 5102 IPFIX Information Model January 2008

5.4.13. destinationIPv6Prefix

 Description:
    IPv6 destination address prefix.
 Abstract Data Type: ipv6Address
 ElementId: 169
 Status: current

5.4.14. ipTTL

 Description:
    For IPv4, the value of the Information Element matches the value
    of the Time to Live (TTL) field in the IPv4 packet header.  For
    IPv6, the value of the Information Element matches the value of
    the Hop Limit field in the IPv6 packet header.
 Abstract Data Type: unsigned8
 ElementId: 192
 Status: current
 Units: hops
 Reference:
    See RFC 791 for the definition of the IPv4 Time to Live field.
    See RFC 2460 for the definition of the IPv6 Hop Limit field.

5.4.15. protocolIdentifier

 Description:
    The value of the protocol number in the IP packet header.  The
    protocol number identifies the IP packet payload type.  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: unsigned8
 Data Type Semantics: identifier
 ElementId: 4
 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
    the list of protocol numbers assigned by IANA at
    http://www.iana.org/assignments/protocol-numbers.

Quittek, et al. Standards Track [Page 35] RFC 5102 IPFIX Information Model January 2008

5.4.16. nextHeaderIPv6

 Description:
    The value of the Next Header field of the IPv6 header.  The value
    identifies the type of the following IPv6 extension header or of
    the following IP payload.  Valid values are defined in the IANA
    Protocol Numbers registry.
 Abstract Data Type: unsigned8
 ElementId: 193
 Status: current
 Reference:
    See RFC 2460 for the definition of the IPv6 Next Header field.
    See the list of protocol numbers assigned by IANA at
    http://www.iana.org/assignments/protocol-numbers.

5.4.17. ipDiffServCodePoint

 Description:
    The value of a Differentiated Services Code Point (DSCP) encoded
    in the Differentiated Services field.  The Differentiated Services
    field spans the most significant 6 bits of the IPv4 TOS field or
    the IPv6 Traffic Class field, respectively.
    This Information Element encodes only the 6 bits of the
    Differentiated Services field.  Therefore, its value may range
    from 0 to 63.
 Abstract Data Type: unsigned8
 Data Type Semantics: identifier
 ElementId: 195
 Status: current
 Range: The valid range is 0-63.
 Reference:
    See RFC 3260 for the definition of the Differentiated Services
    field.  See RFC 1812 (Section 5.3.2) and RFC 791 for the
    definition of the IPv4 TOS field.  See RFC 2460 for the definition
    of the IPv6 Traffic Class field.

5.4.18. ipPrecedence

 Description:
    The value of the IP Precedence.  The IP Precedence value is
    encoded in the first 3 bits of the IPv4 TOS field or the IPv6
    Traffic Class field, respectively.  This Information Element
    encodes only these 3 bits.  Therefore, its value may range from 0
    to 7.
 Abstract Data Type: unsigned8
 Data Type Semantics: identifier
 ElementId: 196
 Status: current

Quittek, et al. Standards Track [Page 36] RFC 5102 IPFIX Information Model January 2008

 Range: The valid range is 0-7.
 Reference:
    See RFC 1812 (Section 5.3.3) and RFC 791 for the definition of the
    IP Precedence.  See RFC 1812 (Section 5.3.2) and RFC 791 for the
    definition of the IPv4 TOS field.  See RFC 2460 for the definition
    of the IPv6 Traffic Class field.

5.4.19. ipClassOfService

 Description:
    For IPv4 packets, this is the value of the TOS field in the IPv4
    packet header.  For IPv6 packets, this is the value of the Traffic
    Class field in the IPv6 packet header.
 Abstract Data Type: unsigned8
 Data Type Semantics: identifier
 ElementId: 5
 Status: current
 Reference:
    See RFC 1812 (Section 5.3.2) and RFC 791 for the definition of the
    IPv4 TOS field.  See RFC 2460 for the definition of the IPv6
    Traffic Class field.

5.4.20. postIpClassOfService

 Description:
    The definition of this Information Element is identical to the
    definition of Information Element 'ipClassOfService', except that
    it reports a potentially modified value caused by a middlebox
    function after the packet passed the Observation Point.
 Abstract Data Type: unsigned8
 Data Type Semantics: identifier
 ElementId: 55
 Status: current
 Reference:
    See RFC 791 for the definition of the IPv4 TOS field.  See RFC
    2460 for the definition of the IPv6 Traffic Class field.  See RFC
    3234 for the definition of middleboxes.

Quittek, et al. Standards Track [Page 37] RFC 5102 IPFIX Information Model January 2008

5.4.21. flowLabelIPv6

 Description:
    The value of the IPv6 Flow Label field in the IP packet header.
 Abstract Data Type: unsigned32
 Data Type Semantics: identifier
 ElementId: 31
 Status: current
 Reference:
    See RFC 2460 for the definition of the Flow Label field in the
    IPv6 packet header.

5.4.22. isMulticast

 Description:
    If the IP destination address is not a reserved multicast address,
    then the value of all bits of the octet (including the reserved
    ones) is zero.
    The first bit of this octet is set to 1 if the Version field of
    the IP header has the value 4 and if the Destination Address field
    contains a reserved multicast address in the range from 224.0.0.0
    to 239.255.255.255.  Otherwise, this bit is set to 0.  The second
    and third bits of this octet are reserved for future use.
    The remaining bits of the octet are only set to values other than
    zero if the IP Destination Address is a reserved IPv6 multicast
    address.  Then the fourth bit of the octet is set to the value of
    the T flag in the IPv6 multicast address and the remaining four
    bits are set to the value of the scope field in the IPv6 multicast
    address.
          0      1      2      3      4      5      6      7
       +------+------+------+------+------+------+------+------+
       | MCv4 | RES. | RES. |  T   |   IPv6 multicast scope    |
       +------+------+------+------+------+------+------+------+
       Bit  0:    set to 1 if IPv4 multicast
       Bits 1-2:  reserved for future use
       Bit  4:    set to value of T flag, if IPv6 multicast
       Bits 4-7:  set to value of multicast scope if IPv6 multicast
 Abstract Data Type: unsigned8
 Data Type Semantics: flags
 ElementId: 206
 Status: current

Quittek, et al. Standards Track [Page 38] RFC 5102 IPFIX Information Model January 2008

 Reference:
    See RFC 1112 for the specification of reserved IPv4 multicast
    addresses.  See RFC 4291 for the specification of reserved IPv6
    multicast addresses and the definition of the T flag and the IPv6
    multicast scope.

5.4.23. fragmentIdentification

 Description:
    The value of the Identification field in the IPv4 packet header or
    in the IPv6 Fragment header, respectively.  The value is 0 for
    IPv6 if there is no fragment header.
 Abstract Data Type: unsigned32
 Data Type Semantics: identifier
 ElementId: 54
 Status: current
 Reference:
    See RFC 791 for the definition of the IPv4 Identification field.
    See RFC 2460 for the definition of the Identification field in the
    IPv6 Fragment header.

5.4.24. fragmentOffset

 Description:
    The value of the IP fragment offset field in the IPv4 packet
    header or the IPv6 Fragment header, respectively.  The value is 0
    for IPv6 if there is no fragment header.
 Abstract Data Type: unsigned16
 Data Type Semantics: identifier
 ElementId: 88
 Status: current
 Reference:
    See RFC 791 for the specification of the fragment offset in the
    IPv4 header.  See RFC 2460 for the specification of the fragment
    offset in the IPv6 Fragment header.

5.4.25. fragmentFlags

 Description:
    Fragmentation properties indicated by flags in the IPv4 packet
    header or the IPv6 Fragment header, respectively.
    Bit 0:    (RS) Reserved.
              The value of this bit MUST be 0 until specified
              otherwise.

Quittek, et al. Standards Track [Page 39] RFC 5102 IPFIX Information Model January 2008

    Bit 1:    (DF) 0 = May Fragment,  1 = Don't Fragment.
              Corresponds to the value of the DF flag in the
              IPv4 header.  Will always be 0 for IPv6 unless
              a "don't fragment" feature is introduced to IPv6.
    Bit 2:    (MF) 0 = Last Fragment, 1 = More Fragments.
              Corresponds to the MF flag in the IPv4 header
              or to the M flag in the IPv6 Fragment header,
              respectively.  The value is 0 for IPv6 if there
              is no fragment header.
    Bits 3-7: (DC) Don't Care.
              The values of these bits are irrelevant.
         0   1   2   3   4   5   6   7
       +---+---+---+---+---+---+---+---+
       | R | D | M | D | D | D | D | D |
       | S | F | F | C | C | C | C | C |
       +---+---+---+---+---+---+---+---+
 Abstract Data Type: unsigned8
 Data Type Semantics: flags
 ElementId: 197
 Status: current
 Reference:
    See RFC 791 for the specification of the IPv4 fragment flags.  See
    RFC 2460 for the specification of the IPv6 Fragment header.

5.4.26. ipHeaderLength

 Description:
    The length of the IP header.  For IPv6, the value of this
    Information Element is 40.
 Abstract Data Type: unsigned8
 ElementId: 189
 Status: current
 Units: octets
 Reference:
    See RFC 791 for the specification of the IPv4 header.  See RFC
    2460 for the specification of the IPv6 header.

5.4.27. ipv4IHL

 Description:
    The value of the Internet Header Length (IHL) field in the IPv4
    header.  It specifies the length of the header in units of 4
    octets.  Please note that its unit is different from most of the
    other Information Elements reporting length values.

Quittek, et al. Standards Track [Page 40] RFC 5102 IPFIX Information Model January 2008

 Abstract Data Type: unsigned8
 ElementId: 207
 Status: current
 Units: 4 octets
 Reference:
    See RFC 791 for the specification of the IPv4 header.

5.4.28. totalLengthIPv4

 Description:
    The total length of the IPv4 packet.
 Abstract Data Type: unsigned16
 ElementId: 190
 Status: current
 Units: octets
 Reference:
    See RFC 791 for the specification of the IPv4 total length.

5.4.29. ipTotalLength

 Description:
    The total length of the IP packet.
 Abstract Data Type: unsigned64
 ElementId: 224
 Status: current
 Units: octets
 Reference:
    See RFC 791 for the specification of the IPv4 total length.  See
    RFC 2460 for the specification of the IPv6 payload length.  See
    RFC 2675 for the specification of the IPv6 jumbo payload length.

5.4.30. payloadLengthIPv6

 Description:
    This Information Element reports the value of the Payload Length
    field in the IPv6 header.  Note that IPv6 extension headers belong
    to the payload.  Also note that in case of a jumbo payload option
    the value of the Payload Length field in the IPv6 header is zero
    and so will be the value reported by this Information Element.
 Abstract Data Type: unsigned16
 ElementId: 191
 Status: current
 Units: octets
 Reference:
    See RFC 2460 for the specification of the IPv6 payload length.
    See RFC 2675 for the specification of the IPv6 jumbo payload
    option.

Quittek, et al. Standards Track [Page 41] RFC 5102 IPFIX Information Model January 2008

5.5. Transport Header Fields

 The set of Information Elements related to transport header fields
 and length includes the Information Elements listed in the table
 below.
 +-----+---------------------------+-----+---------------------------+
 |  ID | Name                      |  ID | Name                      |
 +-----+---------------------------+-----+---------------------------+
 |   7 | sourceTransportPort       | 238 | tcpWindowScale            |
 |  11 | destinationTransportPort  | 187 | tcpUrgentPointer          |
 | 180 | udpSourcePort             | 188 | tcpHeaderLength           |
 | 181 | udpDestinationPort        |  32 | icmpTypeCodeIPv4          |
 | 205 | udpMessageLength          | 176 | icmpTypeIPv4              |
 | 182 | tcpSourcePort             | 177 | icmpCodeIPv4              |
 | 183 | tcpDestinationPort        | 139 | icmpTypeCodeIPv6          |
 | 184 | tcpSequenceNumber         | 178 | icmpTypeIPv6              |
 | 185 | tcpAcknowledgementNumber  | 179 | icmpCodeIPv6              |
 | 186 | tcpWindowSize             |  33 | igmpType                  |
 +-----+---------------------------+-----+---------------------------+

5.5.1. sourceTransportPort

 Description:
    The source port identifier in the transport header.  For the
    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
 ElementId: 7
 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
    4960 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.5.2. destinationTransportPort

 Description:
    The destination port identifier in the transport header.  For the
    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.

Quittek, et al. Standards Track [Page 42] RFC 5102 IPFIX Information Model January 2008

 Abstract Data Type: unsigned16
 Data Type Semantics: identifier
 ElementId: 11
 Status: current
 Reference:
    See RFC 768 for the definition of the UDP destination port field.
    See RFC 793 for the definition of the TCP destination port field.
    See RFC 4960 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.5.3. udpSourcePort

 Description:
    The source port identifier in the UDP header.
 Abstract Data Type: unsigned16
 Data Type Semantics: identifier
 ElementId: 180
 Status: current
 Reference:
    See RFC 768 for the definition of the UDP source port field.
    Additional information on defined UDP port numbers can be found at
    http://www.iana.org/assignments/port-numbers.

5.5.4. udpDestinationPort

 Description:
    The destination port identifier in the UDP header.
 Abstract Data Type: unsigned16
 Data Type Semantics: identifier
 ElementId: 181
 Status: current
 Reference:
    See RFC 768 for the definition of the UDP destination port field.
    Additional information on defined UDP port numbers can be found at
    http://www.iana.org/assignments/port-numbers.

5.5.5. udpMessageLength

 Description:
    The value of the Length field in the UDP header.
 Abstract Data Type: unsigned16
 ElementId: 205
 Status: current
 Units: octets
 Reference:
    See RFC 768 for the specification of the UDP header.

Quittek, et al. Standards Track [Page 43] RFC 5102 IPFIX Information Model January 2008

5.5.6. tcpSourcePort

 Description:
    The source port identifier in the TCP header.
 Abstract Data Type: unsigned16
 Data Type Semantics: identifier
 ElementId: 182
 Status: current
 Reference:
    See RFC 793 for the definition of the TCP source port field.
    Additional information on defined TCP port numbers can be found at
    http://www.iana.org/assignments/port-numbers.

5.5.7. tcpDestinationPort

 Description:
    The destination port identifier in the TCP header.
 Abstract Data Type: unsigned16
 Data Type Semantics: identifier
 ElementId: 183
 Status: current
 Reference:
    See RFC 793 for the definition of the TCP source port field.
    Additional information on defined TCP port numbers can be found at
    http://www.iana.org/assignments/port-numbers.

5.5.8. tcpSequenceNumber

 Description:
    The sequence number in the TCP header.
 Abstract Data Type: unsigned32
 ElementId: 184
 Status: current
 Reference:
    See RFC 793 for the definition of the TCP sequence number.

5.5.9. tcpAcknowledgementNumber

 Description:
    The acknowledgement number in the TCP header.
 Abstract Data Type: unsigned32
 ElementId: 185
 Status: current
 Reference:
    See RFC 793 for the definition of the TCP acknowledgement number.

Quittek, et al. Standards Track [Page 44] RFC 5102 IPFIX Information Model January 2008

5.5.10. tcpWindowSize

 Description:
    The window field in the TCP header.  If the TCP window scale is
    supported, then TCP window scale must be known to fully interpret
    the value of this information.
 Abstract Data Type: unsigned16
 ElementId: 186
 Status: current
 Reference:
    See RFC 793 for the definition of the TCP window field.  See RFC
    1323 for the definition of the TCP window scale.

5.5.11. tcpWindowScale

 Description:
    The scale of the window field in the TCP header.
 Abstract Data Type: unsigned16
 ElementId: 238
 Status: current
 Reference:
    See RFC 1323 for the definition of the TCP window scale.

5.5.12. tcpUrgentPointer

 Description:
    The urgent pointer in the TCP header.
 Abstract Data Type: unsigned16
 ElementId: 187
 Status: current
 Reference:
    See RFC 793 for the definition of the TCP urgent pointer.

5.5.13. tcpHeaderLength

 Description:
    The length of the TCP header.  Note that the value of this
    Information Element is different from the value of the Data Offset
    field in the TCP header.  The Data Offset field indicates the
    length of the TCP header in units of 4 octets.  This Information
    Elements specifies the length of the TCP header in units of
    octets.
 Abstract Data Type: unsigned8
 ElementId: 188
 Status: current
 Units: octets
 Reference:
    See RFC 793 for the definition of the TCP header.

Quittek, et al. Standards Track [Page 45] RFC 5102 IPFIX Information Model January 2008

5.5.14. icmpTypeCodeIPv4

 Description:
    Type and Code of the IPv4 ICMP message.  The combination of both
    values is reported as (ICMP type * 256) + ICMP code.
 Abstract Data Type: unsigned16
 Data Type Semantics: identifier
 ElementId: 32
 Status: current
 Reference:
    See RFC 792 for the definition of the IPv4 ICMP type and code
    fields.

5.5.15. icmpTypeIPv4

 Description:
    Type of the IPv4 ICMP message.
 Abstract Data Type: unsigned8
 Data Type Semantics: identifier
 ElementId: 176
 Status: current
 Reference:
    See RFC 792 for the definition of the IPv4 ICMP type field.

5.5.16. icmpCodeIPv4

 Description:
    Code of the IPv4 ICMP message.
 Abstract Data Type: unsigned8
 Data Type Semantics: identifier
 ElementId: 177
 Status: current
 Reference:
    See RFC 792 for the definition of the IPv4 ICMP code field.

5.5.17. icmpTypeCodeIPv6

 Description:
    Type and Code of the IPv6 ICMP message.  The combination of both
    values is reported as (ICMP type * 256) + ICMP code.
 Abstract Data Type: unsigned16
 Data Type Semantics: identifier
 ElementId: 139
 Status: current
 Reference:
    See RFC 4443 for the definition of the IPv6 ICMP type and code
    fields.

Quittek, et al. Standards Track [Page 46] RFC 5102 IPFIX Information Model January 2008

5.5.18. icmpTypeIPv6

 Description:
    Type of the IPv6 ICMP message.
 Abstract Data Type: unsigned8
 Data Type Semantics: identifier
 ElementId: 178
 Status: current
 Reference:
    See RFC 4443 for the definition of the IPv6 ICMP type field.

5.5.19. icmpCodeIPv6

 Description:
    Code of the IPv6 ICMP message.
 Abstract Data Type: unsigned8
 Data Type Semantics: identifier
 ElementId: 179
 Status: current
 Reference:
    See RFC 4443 for the definition of the IPv6 ICMP code field.

5.5.20. igmpType

 Description:
    The type field of the IGMP message.
 Abstract Data Type: unsigned8
 Data Type Semantics: identifier
 ElementId: 33
 Status: current
 Reference:
    See RFC 3376 for the definition of the IGMP type field.

Quittek, et al. Standards Track [Page 47] RFC 5102 IPFIX Information Model January 2008

5.6. 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 | Name                      |  ID | Name                      |
 +-----+---------------------------+-----+---------------------------+
 |  56 | sourceMacAddress          | 201 | mplsLabelStackLength      |
 |  81 | postSourceMacAddress      | 194 | mplsPayloadLength         |
 |  58 | vlanId                    |  70 | mplsTopLabelStackSection  |
 |  59 | postVlanId                |  71 | mplsLabelStackSection2    |
 |  80 | destinationMacAddress     |  72 | mplsLabelStackSection3    |
 |  57 | postDestinationMacAddress |  73 | mplsLabelStackSection4    |
 | 146 | wlanChannelId             |  74 | mplsLabelStackSection5    |
 | 147 | wlanSSID                  |  75 | mplsLabelStackSection6    |
 | 200 | mplsTopLabelTTL           |  76 | mplsLabelStackSection7    |
 | 203 | mplsTopLabelExp           |  77 | mplsLabelStackSection8    |
 | 237 | postMplsTopLabelExp       |  78 | mplsLabelStackSection9    |
 | 202 | mplsLabelStackDepth       |  79 | mplsLabelStackSection10   |
 +-----+---------------------------+-----+---------------------------+

5.6.1. sourceMacAddress

 Description:
    The IEEE 802 source MAC address field.
 Abstract Data Type: macAddress
 Data Type Semantics: identifier
 ElementId: 56
 Status: current
 Reference:
    See IEEE.802-3.2002.

5.6.2. postSourceMacAddress

 Description:
    The definition of this Information Element is identical to the
    definition of Information Element 'sourceMacAddress', except that
    it reports a potentially modified value caused by a middlebox
    function after the packet passed the Observation Point.
 Abstract Data Type: macAddress
 Data Type Semantics: identifier
 ElementId: 81
 Status: current
 Reference:
    See IEEE.802-3.2002.

Quittek, et al. Standards Track [Page 48] RFC 5102 IPFIX Information Model January 2008

5.6.3. vlanId

 Description:
    The IEEE 802.1Q VLAN identifier (VID) extracted from the Tag
    Control Information field that was attached to the IP packet.
 Abstract Data Type: unsigned16
 Data Type Semantics: identifier
 ElementId: 58
 Status: current
 Reference:
    See IEEE.802-1Q.2003.

5.6.4. postVlanId

 Description:
    The definition of this Information Element is identical to the
    definition of Information Element 'vlanId', except that it reports
    a potentially modified value caused by a middlebox function after
    the packet passed the Observation Point.
 Abstract Data Type: unsigned16
 Data Type Semantics: identifier
 ElementId: 59
 Status: current
 Reference:
    See IEEE.802-1Q.2003.

5.6.5. destinationMacAddress

 Description:
    The IEEE 802 destination MAC address field.
 Abstract Data Type: macAddress
 Data Type Semantics: identifier
 ElementId: 80
 Status: current
 Reference:
    See IEEE.802-3.2002.

5.6.6. postDestinationMacAddress

 Description:
    The definition of this Information Element is identical to the
    definition of Information Element 'destinationMacAddress', except
    that it reports a potentially modified value caused by a middlebox
    function after the packet passed the Observation Point.
 Abstract Data Type: macAddress
 Data Type Semantics: identifier
 ElementId: 57
 Status: current

Quittek, et al. Standards Track [Page 49] RFC 5102 IPFIX Information Model January 2008

 Reference:
    See IEEE.802-3.2002.

5.6.7. wlanChannelId

 Description:
    The identifier of the 802.11 (Wi-Fi) channel used.
 Abstract Data Type: unsigned8
 Data Type Semantics: identifier
 ElementId: 146
 Status: current
 Reference:
    See IEEE.802-11.1999.

5.6.8. wlanSSID

 Description:
    The Service Set IDentifier (SSID) identifying an 802.11 (Wi-Fi)
    network used.  According to IEEE.802-11.1999, the SSID is encoded
    into a string of up to 32 characters.
 Abstract Data Type: string
 ElementId: 147
 Status: current
 Reference:
    See IEEE.802-11.1999.

5.6.9. mplsTopLabelTTL

 Description:
    The TTL field from the top MPLS label stack entry, i.e., the last
    label that was pushed.
 Abstract Data Type: unsigned8
 ElementId: 200
 Status: current
 Units: hops
 Reference:
    See RFC 3032 for the specification of the TTL field.

Quittek, et al. Standards Track [Page 50] RFC 5102 IPFIX Information Model January 2008

5.6.10. mplsTopLabelExp

 Description:
    The Exp field from the top MPLS label stack entry, i.e., the last
    label that was pushed.
    Bits 0-4:  Don't Care, value is irrelevant.
    Bits 5-7:  MPLS Exp field.
        0   1   2   3   4   5   6   7
      +---+---+---+---+---+---+---+---+
      |     don't care    |    Exp    |
      +---+---+---+---+---+---+---+---+
 Abstract Data Type: unsigned8
 Data Type Semantics: flags
 ElementId: 203
 Status: current
 Reference:
    See RFC 3032 for the specification of the Exp field.  See RFC 3270
    for usage of the Exp field.

5.6.11. postMplsTopLabelExp

 Description:
    The definition of this Information Element is identical to the
    definition of Information Element 'mplsTopLabelExp', except that
    it reports a potentially modified value caused by a middlebox
    function after the packet passed the Observation Point.
 Abstract Data Type: unsigned8
 Data Type Semantics: flags
 ElementId: 237
 Status: current
 Reference:
    See RFC 3032 for the specification of the Exp field.  See RFC 3270
    for usage of the Exp field.

5.6.12. mplsLabelStackDepth

 Description:
    The number of labels in the MPLS label stack.
 Abstract Data Type: unsigned32
 ElementId: 202
 Status: current
 Units: label stack entries
 Reference:
    See RFC 3032 for the specification of the MPLS label stack.

Quittek, et al. Standards Track [Page 51] RFC 5102 IPFIX Information Model January 2008

5.6.13. mplsLabelStackLength

 Description:
    The length of the MPLS label stack in units of octets.
 Abstract Data Type: unsigned32
 ElementId: 201
 Status: current
 Units: octets
 Reference:
    See RFC 3032 for the specification of the MPLS label stack.

5.6.14. mplsPayloadLength

 Description:
    The size of the MPLS packet without the label stack.
 Abstract Data Type: unsigned32
 ElementId: 194
 Status: current
 Units: octets
 Reference:
    See RFC 3031 for the specification of MPLS packets.  See RFC 3032
    for the specification of the MPLS label stack.

5.6.15. mplsTopLabelStackSection

 Description:
    The Label, Exp, and S fields from the top MPLS label stack entry,
    i.e., from the last label that was pushed.  The size of this
    Information Element is 3 octets.
     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: octetArray
 Data Type Semantics: identifier
 ElementId: 70
 Status: current
 Reference:
    See RFC 3032.

Quittek, et al. Standards Track [Page 52] RFC 5102 IPFIX Information Model January 2008

5.6.16. mplsLabelStackSection2

 Description:
    The Label, Exp, and S fields from the label stack entry that was
    pushed immediately before the label stack entry that would be
    reported by mplsTopLabelStackSection.  See the definition of
    mplsTopLabelStackSection for further details.  The size of this
    Information Element is 3 octets.
 Abstract Data Type: octetArray
 Data Type Semantics: identifier
 ElementId: 71
 Status: current
 Reference:
    See RFC 3032.

5.6.17. mplsLabelStackSection3

 Description:
    The Label, Exp, and S fields from the label stack entry that was
    pushed immediately before the label stack entry that would be
    reported by mplsLabelStackSection2.  See the definition of
    mplsTopLabelStackSection for further details.  The size of this
    Information Element is 3 octets.
 Abstract Data Type: octetArray
 Data Type Semantics: identifier
 ElementId: 72
 Status: current
 Reference:
    See RFC 3032.

5.6.18. mplsLabelStackSection4

 Description:
    The Label, Exp, and S fields from the label stack entry that was
    pushed immediately before the label stack entry that would be
    reported by mplsLabelStackSection3.  See the definition of
    mplsTopLabelStackSection for further details.  The size of this
    Information Element is 3 octets.
 Abstract Data Type: octetArray
 Data Type Semantics: identifier
 ElementId: 73
 Status: current
 Reference:
    See RFC 3032.

Quittek, et al. Standards Track [Page 53] RFC 5102 IPFIX Information Model January 2008

5.6.19. mplsLabelStackSection5

 Description:
    The Label, Exp, and S fields from the label stack entry that was
    pushed immediately before the label stack entry that would be
    reported by mplsLabelStackSection4.  See the definition of
    mplsTopLabelStackSection for further details.  The size of this
    Information Element is 3 octets.
 Abstract Data Type: octetArray
 Data Type Semantics: identifier
 ElementId: 74
 Status: current
 Reference:
    See RFC 3032.

5.6.20. mplsLabelStackSection6

 Description:
    The Label, Exp, and S fields from the label stack entry that was
    pushed immediately before the label stack entry that would be
    reported by mplsLabelStackSection5.  See the definition of
    mplsTopLabelStackSection for further details.  The size of this
    Information Element is 3 octets.
 Abstract Data Type: octetArray
 Data Type Semantics: identifier
 ElementId: 75
 Status: current
 Reference:
    See RFC 3032.

5.6.21. mplsLabelStackSection7

 Description:
    The Label, Exp, and S fields from the label stack entry that was
    pushed immediately before the label stack entry that would be
    reported by mplsLabelStackSection6.  See the definition of
    mplsTopLabelStackSection for further details.  The size of this
    Information Element is 3 octets.
 Abstract Data Type: octetArray
 Data Type Semantics: identifier
 ElementId: 76
 Status: current
 Reference:
    See RFC 3032.

Quittek, et al. Standards Track [Page 54] RFC 5102 IPFIX Information Model January 2008

5.6.22. mplsLabelStackSection8

 Description:
    The Label, Exp, and S fields from the label stack entry that was
    pushed immediately before the label stack entry that would be
    reported by mplsLabelStackSection7.  See the definition of
    mplsTopLabelStackSection for further details.  The size of this
    Information Element is 3 octets.
 Abstract Data Type: octetArray
 Data Type Semantics: identifier
 ElementId: 77
 Status: current
 Reference:
    See RFC 3032.

5.6.23. mplsLabelStackSection9

 Description:
    The Label, Exp, and S fields from the label stack entry that was
    pushed immediately before the label stack entry that would be
    reported by mplsLabelStackSection8.  See the definition of
    mplsTopLabelStackSection for further details.  The size of this
    Information Element is 3 octets.
 Abstract Data Type: octetArray
 Data Type Semantics: identifier
 ElementId: 78
 Status: current
 Reference:
    See RFC 3032.

5.6.24. mplsLabelStackSection10

 Description:
    The Label, Exp, and S fields from the label stack entry that was
    pushed immediately before the label stack entry that would be
    reported by mplsLabelStackSection9.  See the definition of
    mplsTopLabelStackSection for further details.  The size of this
    Information Element is 3 octets.
 Abstract Data Type: octetArray
 Data Type Semantics: identifier
 ElementId: 79
 Status: current
 Reference:
    See RFC 3032.

Quittek, et al. Standards Track [Page 55] RFC 5102 IPFIX Information Model January 2008

5.7. Derived Packet Properties

 The set of Information Elements derived from packet properties (for
 example, values of header fields) includes the Information Elements
 listed in the table below.
 +-----+---------------------------+-----+---------------------------+
 |  ID | Name                      |  ID | Name                      |
 +-----+---------------------------+-----+---------------------------+
 | 204 | ipPayloadLength           |  18 | bgpNextHopIPv4Address     |
 |  15 | ipNextHopIPv4Address      |  63 | bgpNextHopIPv6Address     |
 |  62 | ipNextHopIPv6Address      |  46 | mplsTopLabelType          |
 |  16 | bgpSourceAsNumber         |  47 | mplsTopLabelIPv4Address   |
 |  17 | bgpDestinationAsNumber    | 140 | mplsTopLabelIPv6Address   |
 | 128 | bgpNextAdjacentAsNumber   |  90 | mplsVpnRouteDistinguisher |
 | 129 | bgpPrevAdjacentAsNumber   |     |                           |
 +-----+---------------------------+-----+---------------------------+

5.7.1. ipPayloadLength

 Description:
    The effective length of the IP payload.  For IPv4 packets, the
    value of this Information Element is the difference between the
    total length of the IPv4 packet (as reported by Information
    Element totalLengthIPv4) and the length of the IPv4 header (as
    reported by Information Element headerLengthIPv4).  For IPv6, the
    value of the Payload Length field in the IPv6 header is reported
    except in the case that the value of this field is zero and that
    there is a valid jumbo payload option.  In this case, the value of
    the Jumbo Payload Length field in the jumbo payload option is
    reported.
 Abstract Data Type: unsigned32
 ElementId: 204
 Status: current
 Units: octets
 Reference:
    See RFC 791 for the specification of IPv4 packets.  See RFC 2460
    for the specification of the IPv6 payload length.  See RFC 2675
    for the specification of the IPv6 jumbo payload length.

5.7.2. ipNextHopIPv4Address

 Description:
    The IPv4 address of the next IPv4 hop.
 Abstract Data Type: ipv4Address
 Data Type Semantics: identifier
 ElementId: 15
 Status: current

Quittek, et al. Standards Track [Page 56] RFC 5102 IPFIX Information Model January 2008

5.7.3. ipNextHopIPv6Address

 Description:
    The IPv6 address of the next IPv6 hop.
 Abstract Data Type: ipv6Address
 Data Type Semantics: identifier
 ElementId: 62
 Status: current

5.7.4. bgpSourceAsNumber

 Description:
    The autonomous system (AS) number of the source IP address.  If AS
    path information for this Flow is only available as an unordered
    AS set (and not as an ordered AS sequence), then the value of this
    Information Element is 0.
 Abstract Data Type: unsigned32
 Data Type Semantics: identifier
 ElementId: 16
 Status: current
 Reference:
    See RFC 4271 for a description of BGP-4, and see RFC 1930 for the
    definition of the AS number.

5.7.5. bgpDestinationAsNumber

 Description:
    The autonomous system (AS) number of the destination IP address.
    If AS path information for this Flow is only available as an
    unordered AS set (and not as an ordered AS sequence), then the
    value of this Information Element is 0.
 Abstract Data Type: unsigned32
 Data Type Semantics: identifier
 ElementId: 17
 Status: current
 Reference:
    See RFC 4271 for a description of BGP-4, and see RFC 1930 for the
    definition of the AS number.

5.7.6. bgpNextAdjacentAsNumber

 Description:
    The autonomous system (AS) number of the first AS in the AS path
    to the destination IP address.  The path is deduced by looking up
    the destination IP address of the Flow in the BGP routing
    information base.  If AS path information for this Flow is only
    available as an unordered AS set (and not as an ordered AS
    sequence), then the value of this Information Element is 0.

Quittek, et al. Standards Track [Page 57] RFC 5102 IPFIX Information Model January 2008

 Abstract Data Type: unsigned32
 Data Type Semantics: identifier
 ElementId: 128
 Status: current
 Reference:
    See RFC 4271 for a description of BGP-4, and see RFC 1930 for the
    definition of the AS number.

5.7.7. bgpPrevAdjacentAsNumber

 Description:
    The autonomous system (AS) number of the last AS in the AS path
    from the source IP address.  The path is deduced by looking up the
    source IP address of the Flow in the BGP routing information base.
    If AS path information for this Flow is only available as an
    unordered AS set (and not as an ordered AS sequence), then the
    value of this Information Element is 0.  In case of BGP asymmetry,
    the bgpPrevAdjacentAsNumber might not be able to report the
    correct value.
 Abstract Data Type: unsigned32
 Data Type Semantics: identifier
 ElementId: 129
 Status: current
 Reference:
    See RFC 4271 for a description of BGP-4, and see RFC 1930 for the
    definition of the AS number.

5.7.8. bgpNextHopIPv4Address

 Description:
    The IPv4 address of the next (adjacent) BGP hop.
 Abstract Data Type: ipv4Address
 Data Type Semantics: identifier
 ElementId: 18
 Status: current
 Reference:
    See RFC 4271 for a description of BGP-4.

5.7.9. bgpNextHopIPv6Address

 Description:
    The IPv6 address of the next (adjacent) BGP hop.
 Abstract Data Type: ipv6Address
 Data Type Semantics: identifier
 ElementId: 63
 Status: current
 Reference:
    See RFC 4271 for a description of BGP-4.

Quittek, et al. Standards Track [Page 58] RFC 5102 IPFIX Information Model January 2008

5.7.10. mplsTopLabelType

 Description:
    This field identifies the control protocol that
    allocated the top-of-stack label.  Initial values for this field
    are listed below.  Further values may be assigned by IANA in the
    MPLS label type registry.
  1. 0x01 TE-MIDPT: Any TE tunnel mid-point or tail label
  2. 0x02 Pseudowire: Any PWE3 or Cisco AToM based label
  3. 0x03 VPN: Any label associated with VPN
  4. 0x04 BGP: Any label associated with BGP or BGP routing
  5. 0x05 LDP: Any label associated with dynamically assigned

labels using LDP

 Abstract Data Type: unsigned8
 Data Type Semantics: identifier
 ElementId: 46
 Status: current
 Reference:
    See RFC 3031 for the MPLS label structure.  See RFC 4364 for the
    association of MPLS labels with Virtual Private Networks (VPNs).
    See RFC 4271 for BGP and BGP routing.  See RFC 5036 for Label
    Distribution Protocol (LDP).  See the list of MPLS label types
    assigned by IANA at
    http://www.iana.org/assignments/mpls-label-values.

5.7.11. mplsTopLabelIPv4Address

 Description:
    The IPv4 address of the system that the MPLS top label will cause
    this Flow to be forwarded to.
 Abstract Data Type: ipv4Address
 Data Type Semantics: identifier
 ElementId: 47
 Status: current
 Reference:
    See RFC 3031 for the association between MPLS labels and IP
    addresses.

Quittek, et al. Standards Track [Page 59] RFC 5102 IPFIX Information Model January 2008

5.7.12. mplsTopLabelIPv6Address

 Description:
    The IPv6 address of the system that the MPLS top label will cause
    this Flow to be forwarded to.
 Abstract Data Type: ipv6Address
 Data Type Semantics: identifier
 ElementId: 140
 Status: current
 Reference:
    See RFC 3031 for the association between MPLS labels and IP
    addresses.

5.7.13. mplsVpnRouteDistinguisher

 Description:
    The value of the VPN route distinguisher of a corresponding entry
    in a VPN routing and forwarding table.  Route distinguisher
    ensures that the same address can be used in several different
    MPLS VPNs and that it is possible for BGP to carry several
    completely different routes to that address, one for each VPN.
    According to RFC 4364, the size of mplsVpnRouteDistinguisher is 8
    octets.  However, in RFC 4382 an octet string with flexible length
    was chosen for representing a VPN route distinguisher by object
    MplsL3VpnRouteDistinguisher.  This choice was made in order to be
    open to future changes of the size.  This idea was adopted when
    choosing octetArray as abstract data type for this Information
    Element.  The maximum length of this Information Element is 256
    octets.
 Abstract Data Type: octetArray
 Data Type Semantics: identifier
 ElementId: 90
 Status: current
 Reference:
    See RFC 4364 for the specification of the route distinguisher.
    See RFC 4382 for the specification of the MPLS/BGP Layer 3 Virtual
    Private Network (VPN) Management Information Base.

Quittek, et al. Standards Track [Page 60] RFC 5102 IPFIX Information Model January 2008

5.8. Min/Max Flow Properties

 Information Elements in this section are results of minimum or
 maximum operations over all packets of a Flow.
 +-----+---------------------------+-----+---------------------------+
 |  ID | Name                      |  ID | Name                      |
 +-----+---------------------------+-----+---------------------------+
 |  25 | minimumIpTotalLength      | 208 | ipv4Options               |
 |  26 | maximumIpTotalLength      |  64 | ipv6ExtensionHeaders      |
 |  52 | minimumTTL                |   6 | tcpControlBits            |
 |  53 | maximumTTL                | 209 | tcpOptions                |
 +-----+---------------------------+-----+---------------------------+

5.8.1. minimumIpTotalLength

 Description:
    Length of the smallest packet observed for this Flow.  The packet
    length includes the IP header(s) length and the IP payload length.
 Abstract Data Type: unsigned64
 ElementId: 25
 Status: current
 Units: octets
 Reference:
    See RFC 791 for the specification of the IPv4 total length.  See
    RFC 2460 for the specification of the IPv6 payload length.  See
    RFC 2675 for the specification of the IPv6 jumbo payload length.

5.8.2. maximumIpTotalLength

 Description:
    Length of the largest packet observed for this Flow.  The packet
    length includes the IP header(s) length and the IP payload length.
 Abstract Data Type: unsigned64
 ElementId: 26
 Status: current
 Units: octets
 Reference:
    See RFC 791 for the specification of the IPv4 total length.  See
    RFC 2460 for the specification of the IPv6 payload length.  See
    RFC 2675 for the specification of the IPv6 jumbo payload length.

5.8.3. minimumTTL

 Description:
    Minimum TTL value observed for any packet in this Flow.

Quittek, et al. Standards Track [Page 61] RFC 5102 IPFIX Information Model January 2008

 Abstract Data Type: unsigned8
 ElementId: 52
 Status: current
 Units: hops
 Reference:
    See RFC 791 for the definition of the IPv4 Time to Live field.
    See RFC 2460 for the definition of the IPv6 Hop Limit field.

5.8.4. maximumTTL

 Description:
    Maximum TTL value observed for any packet in this Flow.
 Abstract Data Type: unsigned8
 ElementId: 53
 Status: current
 Units: hops
 Reference:
    See RFC 791 for the definition of the IPv4 Time to Live field.
    See RFC 2460 for the definition of the IPv6 Hop Limit field.

5.8.5. ipv4Options

 Description:
    IPv4 options in packets of this Flow.  The information is encoded
    in a set of bit fields.  For each valid IPv4 option type, there is
    a bit in this set.  The bit is set to 1 if any observed packet of
    this Flow contains the corresponding IPv4 option type.  Otherwise,
    if no observed packet of this Flow contained the respective IPv4
    option type, the value of the corresponding bit is 0.  The list of
    valid IPv4 options is maintained by IANA.  Note that for
    identifying an option not just the 5-bit Option Number, but all 8
    bits of the Option Type need to match one of the IPv4 options
    specified at http://www.iana.org/assignments/ip-parameters.
    Options are mapped to bits according to their option numbers.
    Option number X is mapped to bit X.  The mapping is illustrated by
    the figure below.
         0      1      2      3      4      5      6      7
     +------+------+------+------+------+------+------+------+
     | EOOL | NOP  | SEC  | LSR  |  TS  |E-SEC |CIPSO |  RR  | ...
     +------+------+------+------+------+------+------+------+
         8      9     10     11     12     13     14     15
     +------+------+------+------+------+------+------+------+
 ... | SID  | SSR  | ZSU  | MTUP | MTUR | FINN | VISA |ENCODE| ...
     +------+------+------+------+------+------+------+------+
        16     17     18     19     20     21     22     23

Quittek, et al. Standards Track [Page 62] RFC 5102 IPFIX Information Model January 2008

     +------+------+------+------+------+------+------+------+
 ... |IMITD | EIP  |  TR  |ADDEXT|RTRALT| SDB  |NSAPA | DPS  | ...
     +------+------+------+------+------+------+------+------+
        24     25     26     27     28     29     30     31
     +------+------+------+------+------+------+------+------+
 ... | UMP  |  QS  |   to be assigned by IANA  |  EXP |      |
     +------+------+------+------+------+------+------+------+
        Type   Option
    Bit Value  Name    Reference
    ---+-----+-------+------------------------------------
     0     0   EOOL    End of Options List, RFC 791
     1     1   NOP     No Operation, RFC 791
     2   130   SEC     Security, RFC 1108
     3   131   LSR     Loose Source Route, RFC 791
     4    68   TS      Time Stamp, RFC 791
     5   133   E-SEC   Extended Security, RFC 1108
     6   134   CIPSO   Commercial Security
     7     7   RR      Record Route, RFC 791
     8   136   SID     Stream ID, RFC 791
     9   137   SSR     Strict Source Route, RFC 791
    10    10   ZSU     Experimental Measurement
    11    11   MTUP    (obsoleted) MTU Probe, RFC 1191
    12    12   MTUR    (obsoleted) MTU Reply, RFC 1191
    13   205   FINN    Experimental Flow Control
    14   142   VISA    Experimental Access Control
    15    15   ENCODE
    16   144   IMITD   IMI Traffic Descriptor
    17   145   EIP     Extended Internet Protocol, RFC 1385
    18    82   TR      Traceroute, RFC 3193
    19   147   ADDEXT  Address Extension
    20   148   RTRALT  Router Alert, RFC 2113
    21   149   SDB     Selective Directed Broadcast
    22   150   NSAPA   NSAP Address
    23   151   DPS     Dynamic Packet State
    24   152   UMP     Upstream Multicast Pkt.
    25    25   QS      Quick-Start
    30    30   EXP     RFC3692-style Experiment
    30    94   EXP     RFC3692-style Experiment
    30   158   EXP     RFC3692-style Experiment
    30   222   EXP     RFC3692-style Experiment
    ...  ...   ...     Further options numbers
                       may be assigned by IANA
 Abstract Data Type: unsigned32
 Data Type Semantics: flags
 ElementId: 208

Quittek, et al. Standards Track [Page 63] RFC 5102 IPFIX Information Model January 2008

 Status: current
 Reference:
    See RFC 791 for the definition of IPv4 options.  See the list of
    IPv4 option numbers assigned by IANA at
    http://www.iana.org/assignments/ip-parameters.

5.8.6. ipv6ExtensionHeaders

 Description:
    IPv6 extension headers observed in packets of this Flow.  The
    information is encoded in a set of bit fields.  For each IPv6
    option header, there is a bit in this set.  The bit is set to 1 if
    any observed packet of this Flow contains the corresponding IPv6
    extension header.  Otherwise, if no observed packet of this Flow
    contained the respective IPv6 extension header, the value of the
    corresponding bit is 0.
            0     1     2     3     4     5     6     7
        +-----+-----+-----+-----+-----+-----+-----+-----+
        | Res | FRA1| RH  | FRA0| UNK | Res | HOP | DST |  ...
        +-----+-----+-----+-----+-----+-----+-----+-----+
            8     9    10    11    12    13    14    15
        +-----+-----+-----+-----+-----+-----+-----+-----+
    ... | PAY | AH  | ESP |         Reserved            | ...
        +-----+-----+-----+-----+-----+-----+-----+-----+
           16    17    18    19    20    21    22    23
        +-----+-----+-----+-----+-----+-----+-----+-----+
    ... |                  Reserved                     | ...
        +-----+-----+-----+-----+-----+-----+-----+-----+
           24    25    26    27    28    29    30    31
        +-----+-----+-----+-----+-----+-----+-----+-----+
    ... |                  Reserved                     |
        +-----+-----+-----+-----+-----+-----+-----+-----+
      Bit    IPv6 Option   Description
     0, Res               Reserved
     1, FRA1     44       Fragmentation header - not first fragment
     2, RH       43       Routing header
     3, FRA0     44       Fragment header - first fragment
     4, UNK               Unknown Layer 4 header
                          (compressed, encrypted, not supported)
     5, Res               Reserved
     6, HOP       0       Hop-by-hop option header
     7, DST      60       Destination option header

Quittek, et al. Standards Track [Page 64] RFC 5102 IPFIX Information Model January 2008

     8, PAY     108       Payload compression header
     9, AH       51       Authentication Header
    10, ESP      50       Encrypted security payload
    11 to 31              Reserved
 Abstract Data Type: unsigned32
 Data Type Semantics: flags
 ElementId: 64
 Status: current
 Reference:
    See RFC 2460 for the general definition of IPv6 extension headers
    and for the specification of the hop-by-hop options header, the
    routing header, the fragment header, and the destination options
    header.  See RFC 4302 for the specification of the authentication
    header.  See RFC 4303 for the specification of the encapsulating
    security payload.

5.8.7. tcpControlBits

 Description:
    TCP control bits observed for packets of this Flow.  The
    information is encoded in a set of bit fields.  For each TCP
    control bit, there is a bit in this set.  A bit is set to 1 if any
    observed packet of this Flow has the corresponding TCP control bit
    set to 1.  A value of 0 for a bit indicates that the corresponding
    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: unsigned8
 Data Type Semantics: flags
 ElementId: 6
 Status: current
 Reference:
    See RFC 793 for the definition of the TCP control bits in the TCP
    header.

Quittek, et al. Standards Track [Page 65] RFC 5102 IPFIX Information Model January 2008

5.8.8. tcpOptions

 Description:
    TCP options in packets of this Flow.  The information is encoded
    in a set of bit fields.  For each TCP option, there is a bit in
    this set.  The bit is set to 1 if any observed packet of this Flow
    contains the corresponding TCP option.  Otherwise, if no observed
    packet of this Flow contained the respective TCP option, the value
    of the corresponding bit is 0.
    Options are mapped to bits according to their option numbers.
    Option number X is mapped to bit X.  TCP option numbers are
    maintained by IANA.
            0     1     2     3     4     5     6     7
        +-----+-----+-----+-----+-----+-----+-----+-----+
        |   0 |   1 |   2 |   3 |   4 |   5 |   6 |   7 |  ...
        +-----+-----+-----+-----+-----+-----+-----+-----+
            8     9    10    11    12    13    14    15
        +-----+-----+-----+-----+-----+-----+-----+-----+
    ... |   8 |   9 |  10 |  11 |  12 |  13 |  14 |  15 |...
        +-----+-----+-----+-----+-----+-----+-----+-----+
           16    17    18    19    20    21    22    23
        +-----+-----+-----+-----+-----+-----+-----+-----+
    ... |  16 |  17 |  18 |  19 |  20 |  21 |  22 |  23 |...
        +-----+-----+-----+-----+-----+-----+-----+-----+
                              . . .
           56    57    58    59    60    61    62    63
        +-----+-----+-----+-----+-----+-----+-----+-----+
    ... |  56 |  57 |  58 |  59 |  60 |  61 |  62 |  63 |
        +-----+-----+-----+-----+-----+-----+-----+-----+
 Abstract Data Type: unsigned64
 Data Type Semantics: flags
 ElementId: 209
 Status: current
 Reference:
    See RFC 793 for the definition of TCP options.  See the list of
    TCP option numbers assigned by IANA at
    http://www.iana.org/assignments/tcp-parameters.

Quittek, et al. Standards Track [Page 66] RFC 5102 IPFIX Information Model January 2008

5.9. Flow Timestamps

 Information Elements in this section are timestamps of events.
 Timestamps flowStartSeconds, flowEndSeconds, flowStartMilliseconds,
 flowEndMilliseconds, flowStartMicroseconds, flowEndMicroseconds,
 flowStartNanoseconds, flowEndNanoseconds, and
 systemInitTimeMilliseconds are absolute and have a well-defined fixed
 time base, such as, for example, the number of seconds since 0000 UTC
 Jan 1st 1970.
 Timestamps flowStartDeltaMicroseconds and flowEndDeltaMicroseconds
 are relative timestamps only valid within the scope of a single IPFIX
 Message.  They contain the negative time offsets relative to the
 export time specified in the IPFIX Message Header.  The maximum time
 offset that can be encoded by these delta counters is 1 hour, 11
 minutes, and 34.967295 seconds.
 Timestamps flowStartSysUpTime and flowEndSysUpTime are relative
 timestamps indicating the time relative to the last (re-
 )initialization of the IPFIX Device.  For reporting the time of the
 last (re-)initialization, systemInitTimeMilliseconds can be reported,
 for example, in Data Records defined by Option Templates.
 +-----+---------------------------+-----+---------------------------+
 |  ID | Name                      |  ID | Name                      |
 +-----+---------------------------+-----+---------------------------+
 | 150 | flowStartSeconds          | 156 | flowStartNanoseconds      |
 | 151 | flowEndSeconds            | 157 | flowEndNanoseconds        |
 | 152 | flowStartMilliseconds     | 158 | flowStartDeltaMicroseconds|
 | 153 | flowEndMilliseconds       | 159 | flowEndDeltaMicroseconds  |
 | 154 | flowStartMicroseconds     | 160 | systemInitTimeMilliseconds|
 | 155 | flowEndMicroseconds       |  22 | flowStartSysUpTime        |
 |     |                           |  21 | flowEndSysUpTime          |
 +-----+---------------------------+-----+---------------------------+

5.9.1. flowStartSeconds

 Description:
    The absolute timestamp of the first packet of this Flow.
 Abstract Data Type: dateTimeSeconds
 ElementId: 150
 Status: current
 Units: seconds

Quittek, et al. Standards Track [Page 67] RFC 5102 IPFIX Information Model January 2008

5.9.2. flowEndSeconds

 Description:
    The absolute timestamp of the last packet of this Flow.
 Abstract Data Type: dateTimeSeconds
 ElementId: 151
 Status: current
 Units: seconds

5.9.3. flowStartMilliseconds

 Description:
    The absolute timestamp of the first packet of this Flow.
 Abstract Data Type: dateTimeMilliseconds
 ElementId: 152
 Status: current
 Units: milliseconds

5.9.4. flowEndMilliseconds

 Description:
    The absolute timestamp of the last packet of this Flow.
 Abstract Data Type: dateTimeMilliseconds
 ElementId: 153
 Status: current
 Units: milliseconds

5.9.5. flowStartMicroseconds

 Description:
    The absolute timestamp of the first packet of this Flow.
 Abstract Data Type: dateTimeMicroseconds
 ElementId: 154
 Status: current
 Units: microseconds

5.9.6. flowEndMicroseconds

 Description:
    The absolute timestamp of the last packet of this Flow.
 Abstract Data Type: dateTimeMicroseconds
 ElementId: 155
 Status: current
 Units: microseconds

Quittek, et al. Standards Track [Page 68] RFC 5102 IPFIX Information Model January 2008

5.9.7. flowStartNanoseconds

 Description:
    The absolute timestamp of the first packet of this Flow.
 Abstract Data Type: dateTimeNanoseconds
 ElementId: 156
 Status: current
 Units: nanoseconds

5.9.8. flowEndNanoseconds

 Description:
    The absolute timestamp of the last packet of this Flow.
 Abstract Data Type: dateTimeNanoseconds
 ElementId: 157
 Status: current
 Units: nanoseconds

5.9.9. flowStartDeltaMicroseconds

 Description:
    This is a relative timestamp only valid within the scope of a
    single IPFIX Message.  It contains the negative time offset of the
    first observed packet of this Flow relative to the export time
    specified in the IPFIX Message Header.
 Abstract Data Type: unsigned32
 ElementId: 158
 Status: current
 Units: microseconds
 Reference:
    See the IPFIX protocol specification [RFC5101] for the definition
    of the IPFIX Message Header.

5.9.10. flowEndDeltaMicroseconds

 Description:
    This is a relative timestamp only valid within the scope of a
    single IPFIX Message.  It contains the negative time offset of the
    last observed packet of this Flow relative to the export time
    specified in the IPFIX Message Header.
 Abstract Data Type: unsigned32
 ElementId: 159
 Status: current
 Units: microseconds
 Reference:
    See the IPFIX protocol specification [RFC5101] for the
    definition of the IPFIX Message Header.

Quittek, et al. Standards Track [Page 69] RFC 5102 IPFIX Information Model January 2008

5.9.11. systemInitTimeMilliseconds

 Description:
    The absolute timestamp of the last (re-)initialization of the
    IPFIX Device.
 Abstract Data Type: dateTimeMilliseconds
 ElementId: 160
 Status: current
 Units: milliseconds

5.9.12. flowStartSysUpTime

 Description:
    The relative timestamp of the first packet of this Flow.  It
    indicates the number of milliseconds since the last
    (re-)initialization of the IPFIX Device (sysUpTime).
 Abstract Data Type: unsigned32
 ElementId: 22
 Status: current
 Units: milliseconds

5.9.13. flowEndSysUpTime

 Description:
    The relative timestamp of the last packet of this Flow.  It
    indicates the number of milliseconds since the last
    (re-)initialization of the IPFIX Device (sysUpTime).
 Abstract Data Type: unsigned32
 ElementId: 21
 Status: current
 Units: milliseconds

5.10. Per-Flow Counters

 Information Elements in this section are counters all having integer
 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
 Flows, for example, by only exporting Flows with more than a
 threshold number of observed octets.
 There are running counters and delta counters.  Delta counters are
 reset to zero each time their values are exported.  Running counters
 continue counting independently 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
 properties that potentially change each time a packet belonging to

Quittek, et al. Standards Track [Page 70] RFC 5102 IPFIX Information Model January 2008

 the Flow is observed.  The set of per-Flow counters includes the
 Information Elements listed in the table below.  Counters related to
 the Metering Process and/or the Exporting Process are described in
 Section 5.3.
 +-----+---------------------------+-----+---------------------------+
 |  ID | Name                      |  ID | Name                      |
 +-----+---------------------------+-----+---------------------------+
 |   1 | octetDeltaCount           | 134 | droppedOctetTotalCount    |
 |  23 | postOctetDeltaCount       | 135 | droppedPacketTotalCount   |
 | 198 | octetDeltaSumOfSquares    |  19 | postMCastPacketDeltaCount |
 |  85 | octetTotalCount           |  20 | postMCastOctetDeltaCount  |
 | 171 | postOctetTotalCount       | 174 | postMCastPacketTotalCount |
 | 199 | octetTotalSumOfSquares    | 175 | postMCastOctetTotalCount  |
 |   2 | packetDeltaCount          | 218 | tcpSynTotalCount          |
 |  24 | postPacketDeltaCount      | 219 | tcpFinTotalCount          |
 |  86 | packetTotalCount          | 220 | tcpRstTotalCount          |
 | 172 | postPacketTotalCount      | 221 | tcpPshTotalCount          |
 | 132 | droppedOctetDeltaCount    | 222 | tcpAckTotalCount          |
 | 133 | droppedPacketDeltaCount   | 223 | tcpUrgTotalCount          |
 +-----+---------------------------+-----+---------------------------+

5.10.1. octetDeltaCount

 Description:
    The number of octets since the previous report (if any) in
    incoming packets for this Flow at the Observation Point.  The
    number of octets includes IP header(s) and IP payload.
 Abstract Data Type: unsigned64
 Data Type Semantics: deltaCounter
 ElementId: 1
 Status: current
 Units: octets

5.10.2. postOctetDeltaCount

 Description:
    The definition of this Information Element is identical to the
    definition of Information Element 'octetDeltaCount', except that
    it reports a potentially modified value caused by a middlebox
    function after the packet passed the Observation Point.
 Abstract Data Type: unsigned64
 Data Type Semantics: deltaCounter
 ElementId: 23
 Status: current
 Units: octets

Quittek, et al. Standards Track [Page 71] RFC 5102 IPFIX Information Model January 2008

5.10.3. octetDeltaSumOfSquares

 Description:
    The sum of the squared numbers of octets per incoming packet since
    the previous report (if any) for this Flow at the Observation
    Point.  The number of octets includes IP header(s) and IP payload.
 Abstract Data Type: unsigned64
 ElementId: 198
 Status: current

5.10.4. octetTotalCount

 Description:
    The total number of octets in incoming packets for this Flow at
    the Observation Point since the Metering Process
    (re-)initialization for this Observation Point.  The number
    of octets includes IP header(s) and IP payload.
 Abstract Data Type: unsigned64
 Data Type Semantics: totalCounter
 ElementId: 85
 Status: current
 Units: octets

5.10.5. postOctetTotalCount

 Description:
    The definition of this Information Element is identical to the
    definition of Information Element 'octetTotalCount', except that
    it reports a potentially modified value caused by a middlebox
    function after the packet passed the Observation Point.
 Abstract Data Type: unsigned64
 Data Type Semantics: totalCounter
 ElementId: 171
 Status: current
 Units: octets

5.10.6. octetTotalSumOfSquares

 Description:
    The total sum of the squared numbers of octets in incoming packets
    for this Flow at the Observation Point since the Metering Process
    (re-)initialization for this Observation Point.  The number of
    octets includes IP header(s) and IP payload.
 Abstract Data Type: unsigned64
 ElementId: 199
 Status: current
 Units: octets

Quittek, et al. Standards Track [Page 72] RFC 5102 IPFIX Information Model January 2008

5.10.7. packetDeltaCount

 Description:
    The number of incoming packets since the previous report (if any)
    for this Flow at the Observation Point.
 Abstract Data Type: unsigned64
 Data Type Semantics: deltaCounter
 ElementId: 2
 Status: current
 Units: packets

5.10.8. postPacketDeltaCount

 Description:
    The definition of this Information Element is identical to the
    definition of Information Element 'packetDeltaCount', except that
    it reports a potentially modified value caused by a middlebox
    function after the packet passed the Observation Point.
 Abstract Data Type: unsigned64
 Data Type Semantics: deltaCounter
 ElementId: 24
 Status: current
 Units: packets

5.10.9. packetTotalCount

 Description:
    The total number of incoming packets for this Flow at the
    Observation Point since the Metering Process (re-)initialization
    for this Observation Point.
 Abstract Data Type: unsigned64
 Data Type Semantics: totalCounter
 ElementId: 86
 Status: current
 Units: packets

Quittek, et al. Standards Track [Page 73] RFC 5102 IPFIX Information Model January 2008

5.10.10. postPacketTotalCount

 Description:
    The definition of this Information Element is identical to the
    definition of Information Element 'packetTotalCount', except that
    it reports a potentially modified value caused by a middlebox
    function after the packet passed the Observation Point.
 Abstract Data Type: unsigned64
 Data Type Semantics: totalCounter
 ElementId: 172
 Status: current
 Units: packets

5.10.11. droppedOctetDeltaCount

 Description:
    The number of octets since the previous report (if any) in packets
    of this Flow dropped by packet treatment.  The number of octets
    includes IP header(s) and IP payload.
 Abstract Data Type: unsigned64
 Data Type Semantics: deltaCounter
 ElementId: 132
 Status: current
 Units: octets

5.10.12. droppedPacketDeltaCount

 Description:
    The number of packets since the previous report (if any) of this
    Flow dropped by packet treatment.
 Abstract Data Type: unsigned64
 Data Type Semantics: deltaCounter
 ElementId: 133
 Status: current
 Units: packets

5.10.13. droppedOctetTotalCount

 Description:
    The total number of octets in packets of this Flow dropped by
    packet treatment since the Metering Process (re-)initialization
    for this Observation Point.  The number of octets includes IP
    header(s) and IP payload.
 Abstract Data Type: unsigned64
 Data Type Semantics: totalCounter
 ElementId: 134
 Status: current
 Units: octets

Quittek, et al. Standards Track [Page 74] RFC 5102 IPFIX Information Model January 2008

5.10.14. droppedPacketTotalCount

 Description:
    The number of packets of this Flow dropped by packet treatment
    since the Metering Process (re-)initialization for this
    Observation Point.
 Abstract Data Type: unsigned64
 Data Type Semantics: totalCounter
 ElementId: 135
 Status: current
 Units: packets

5.10.15. postMCastPacketDeltaCount

 Description:
    The number of outgoing multicast packets since the previous report
    (if any) sent for packets of this Flow by a multicast daemon
    within the Observation Domain.  This property cannot necessarily
    be observed at the Observation Point, but may be retrieved by
    other means.
 Abstract Data Type: unsigned64
 Data Type Semantics: deltaCounter
 ElementId: 19
 Status: current
 Units: packets

5.10.16. postMCastOctetDeltaCount

 Description:
    The number of octets since the previous report (if any) in
    outgoing multicast packets sent for packets of this Flow by a
    multicast daemon within the Observation Domain.  This property
    cannot necessarily be observed at the Observation Point, but may
    be retrieved by other means.  The number of octets includes IP
    header(s) and IP payload.
 Abstract Data Type: unsigned64
 Data Type Semantics: deltaCounter
 ElementId: 20
 Status: current
 Units: octets

Quittek, et al. Standards Track [Page 75] RFC 5102 IPFIX Information Model January 2008

5.10.17. postMCastPacketTotalCount

 Description:
    The total number of outgoing multicast packets sent for packets of
    this Flow by a multicast daemon within the Observation Domain
    since the Metering Process (re-)initialization.  This property
    cannot necessarily be observed at the Observation Point, but may
    be retrieved by other means.
 Abstract Data Type: unsigned64
 Data Type Semantics: totalCounter
 ElementId: 174
 Status: current
 Units: packets

5.10.18. postMCastOctetTotalCount

 Description:
    The total number of octets in outgoing multicast packets sent for
    packets of this Flow by a multicast daemon in the Observation
    Domain since the Metering Process (re-)initialization.  This
    property cannot necessarily be observed at the Observation Point,
    but may be retrieved by other means.  The number of octets
    includes IP header(s) and IP payload.
 Abstract Data Type: unsigned64
 Data Type Semantics: totalCounter
 ElementId: 175
 Status: current
 Units: octets

5.10.19. tcpSynTotalCount

 Description:
    The total number of packets of this Flow with TCP "Synchronize
    sequence numbers" (SYN) flag set.
 Abstract Data Type: unsigned64
 Data Type Semantics: totalCounter
 ElementId: 218
 Status: current
 Units: packets
 Reference:
    See RFC 793 for the definition of the TCP SYN flag.

Quittek, et al. Standards Track [Page 76] RFC 5102 IPFIX Information Model January 2008

5.10.20. tcpFinTotalCount

 Description:
    The total number of packets of this Flow with TCP "No more data
    from sender" (FIN) flag set.
 Abstract Data Type: unsigned64
 Data Type Semantics: totalCounter
 ElementId: 219
 Status: current
 Units: packets
 Reference:
    See RFC 793 for the definition of the TCP FIN flag.

5.10.21. tcpRstTotalCount

 Description:
    The total number of packets of this Flow with TCP "Reset the
    connection" (RST) flag set.
 Abstract Data Type: unsigned64
 Data Type Semantics: totalCounter
 ElementId: 220
 Status: current
 Units: packets
 Reference:
    See RFC 793 for the definition of the TCP RST flag.

5.10.22. tcpPshTotalCount

 Description:
    The total number of packets of this Flow with TCP "Push Function"
    (PSH) flag set.
 Abstract Data Type: unsigned64
 Data Type Semantics: totalCounter
 ElementId: 221
 Status: current
 Units: packets
 Reference:
    See RFC 793 for the definition of the TCP PSH flag.

Quittek, et al. Standards Track [Page 77] RFC 5102 IPFIX Information Model January 2008

5.10.23. tcpAckTotalCount

 Description:
    The total number of packets of this Flow with TCP "Acknowledgment
    field significant" (ACK) flag set.
 Abstract Data Type: unsigned64
 Data Type Semantics: totalCounter
 ElementId: 222
 Status: current
 Units: packets
 Reference:
    See RFC 793 for the definition of the TCP ACK flag.

5.10.24. tcpUrgTotalCount

 Description:
    The total number of packets of this Flow with TCP "Urgent Pointer
    field significant" (URG) flag set.
 Abstract Data Type: unsigned64
 Data Type Semantics: totalCounter
 ElementId: 223
 Status: current
 Units: packets
 Reference:
    See RFC 793 for the definition of the TCP URG flag.

5.11. Miscellaneous Flow Properties

 Information Elements in this section describe properties of Flows
 that are related to Flow start, Flow duration, and Flow termination,
 but they are not timestamps as the Information Elements in Section
 5.9 are.
 +-----+---------------------------+-----+---------------------------+
 |  ID | Name                      |  ID | Name                      |
 +-----+---------------------------+-----+---------------------------+
 |  36 | flowActiveTimeout         | 161 | flowDurationMilliseconds  |
 |  37 | flowIdleTimeout           | 162 | flowDurationMicroseconds  |
 | 136 | flowEndReason             |  61 | flowDirection             |
 +-----+---------------------------+-----+---------------------------+

Quittek, et al. Standards Track [Page 78] RFC 5102 IPFIX Information Model January 2008

5.11.1. 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
 ElementId: 36
 Status: current
 Units: seconds

5.11.2. flowIdleTimeout

 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
 ElementId: 37
 Status: current
 Units: seconds

5.11.3. flowEndReason

 Description:
    The reason for Flow termination.  The range of values includes the
    following:
    0x01: idle timeout
          The Flow was terminated because it was considered to be
          idle.
    0x02: active timeout
          The Flow was terminated for reporting purposes while it was
          still active, for example, after the maximum lifetime of
          unreported Flows was reached.
    0x03: end of Flow detected
          The Flow was terminated because the Metering Process
          detected signals indicating the end of the Flow, for
          example, the TCP FIN flag.
    0x04: forced end
          The Flow was terminated because of some external event, for
          example, a shutdown of the Metering Process initiated by a
          network management application.

Quittek, et al. Standards Track [Page 79] RFC 5102 IPFIX Information Model January 2008

    0x05: lack of resources
          The Flow was terminated because of lack of resources
          available to the Metering Process and/or the Exporting
          Process.
 Abstract Data Type: unsigned8
 Data Type Semantics: identifier
 ElementId: 136
 Status: current

5.11.4. flowDurationMilliseconds

 Description:
    The difference in time between the first observed packet of this
    Flow and the last observed packet of this Flow.
 Abstract Data Type: unsigned32
 ElementId: 161
 Status: current
 Units: milliseconds

5.11.5. flowDurationMicroseconds

 Description:
    The difference in time between the first observed packet of this
    Flow and the last observed packet of this Flow.
 Abstract Data Type: unsigned32
 ElementId: 162
 Status: current
 Units: microseconds

5.11.6. flowDirection

 Description:
    The direction of the Flow observed at the Observation Point.
    There are only two values defined.
    0x00: ingress flow
    0x01: egress flow
 Abstract Data Type: unsigned8
 Data Type Semantics: identifier
 ElementId: 61
 Status: current

5.12. Padding

 This section contains a single Information Element that can be used
 for padding of Flow Records.

Quittek, et al. Standards Track [Page 80] RFC 5102 IPFIX Information Model January 2008

 IPFIX implementations may wish to align Information Elements within
 Data Records or to align entire Data Records to 4-octet or 8-octet
 boundaries.  This can be achieved by including one or more
 paddingOctets Information Elements in a Data Record.
 +-----+---------------------------+-----+---------------------------+
 |  ID | Name                      |  ID | Name                      |
 +-----+---------------------------+-----+---------------------------+
 | 210 | paddingOctets             |     |                           |
 +-----+---------------------------+-----+---------------------------+

5.12.1. paddingOctets

 Description:
    The value of this Information Element is always a sequence of 0x00
    values.
 Abstract Data Type: octetArray
 ElementId: 210
 Status: current

6. Extending the Information Model

 A key requirement for IPFIX is to allow for extending the set of
 Information Elements that are reported.  This section defines the
 mechanism for extending this set.
 Extension can be done by defining new Information Elements.  Each new
 Information Element MUST be assigned a unique Information Element
 identifier as part of its definition.  These unique Information
 Element identifiers are the connection between the record structure
 communicated by the protocol using Templates and a consuming
 application.  For generally applicable Information Elements, using
 IETF and IANA mechanisms to extend the information model is
 RECOMMENDED.
 Names of new Information Elements SHOULD be chosen according to the
 naming conventions given in Section 2.3.
 For extensions, the type space defined in Section 3 can be used.  If
 required, new abstract data types can be added.  New abstract data
 types MUST be defined in IETF Standards Track documents.
 Enterprises may wish to define Information Elements without
 registering them with IANA.  IPFIX explicitly supports
 enterprise-specific Information Elements.  Enterprise-specific
 Information Elements are described in Sections 2.1 and 4.

Quittek, et al. Standards Track [Page 81] RFC 5102 IPFIX Information Model January 2008

 However, before creating enterprise-specific Information Elements,
 the general applicability of such Information Elements should be
 considered.  IPFIX does not support enterprise-specific abstract data
 types.

7. IANA Considerations

7.1. IPFIX Information Elements

 This document specifies an initial set of IPFIX Information Elements.
 The list of these Information Elements with their identifiers is
 given in Section 4.  The Internet Assigned Numbers Authority (IANA)
 has created a new registry for IPFIX Information Element identifiers
 and filled it with the initial list in Section 4.
 New assignments for IPFIX Information Elements will be administered
 by IANA through Expert Review [RFC2434], i.e., review by one of a
 group of experts designated by an IETF Area Director.  The group of
 experts MUST check the requested Information Element for completeness
 and accuracy of the description and for correct naming according to
 the naming conventions in Section 2.3.  Requests for Information
 Elements that duplicate the functionality of existing Information
 Elements SHOULD be declined.  The smallest available identifier
 SHOULD be assigned to a new Information Element.
 The specification of new IPFIX Information Elements MUST use the
 template specified in Section 2.1 and MUST be published using a
 well-established and persistent publication medium.  The experts will
 initially be drawn from the Working Group Chairs and document editors
 of the IPFIX and PSAMP Working Groups.

7.2. MPLS Label Type Identifier

 Information Element #46, named mplsTopLabelType, carries MPLS label
 types.  Values for 5 different types have initially been defined.
 For ensuring extensibility of this information, IANA has created a
 new registry for MPLS label types and filled it with the initial list
 from the description Information Element #46, mplsTopLabelType.
 New assignments for MPLS label types will be administered by IANA
 through Expert Review [RFC2434], i.e., review by one of a group of
 experts designated by an IETF Area Director.  The group of experts
 must double check the label type definitions with already defined
 label types for completeness, accuracy, and redundancy.  The
 specification of new MPLS label types MUST be published using a
 well-established and persistent publication medium.

Quittek, et al. Standards Track [Page 82] RFC 5102 IPFIX Information Model January 2008

7.3. XML Namespace and Schema

 Appendix B defines an XML schema for IPFIX Information Element
 definitions.  All Information Elements specified in this document are
 defined by the XML specification in Appendix A that is a valid XML
 record according to the schema in Appendix B.  This schema may also
 be used for specifying further Information Elements in future
 extensions of the IPFIX information model in a machine-readable way.
 Appendix B uses URNs to describe an XML namespace and an XML schema
 for IPFIX Information Elements conforming to a registry mechanism
 described in [RFC3688].  Two URI assignments have been made.
 1.  Registration for the IPFIX information model namespace
     *  URI: urn:ietf:params:xml:ns:ipfix-info-15
     *  Registrant Contact: IETF IPFIX Working Group <ipfix@ietf.org>,
        as designated by the IESG <iesg@ietf.org>.
     *  XML: None.  Namespace URIs do not represent an XML.
 2.  Registration for the IPFIX information model schema
     *  URI: urn:ietf:params:xml:schema:ipfix-info-15
     *  Registrant Contact: IETF IPFIX Working Group <ipfix@ietf.org>,
        as designated by the IESG <iesg@ietf.org>.
     *  XML: See Appendix B of this document.

8. Security Considerations

 The IPFIX information model itself does not directly introduce
 security issues.  Rather, it defines a set of attributes that may for
 privacy or business issues be considered sensitive information.
 For example, exporting values of header fields may make attacks
 possible for the receiver of this information, which would otherwise
 only be possible for direct observers of the reported Flows along the
 data path.
 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 [RFC5101].
 This document does not specify any Information Element carrying
 keying material.  If future extensions will do so, then appropriate
 precautions need to be taken for properly protecting such sensitive
 information.

Quittek, et al. Standards Track [Page 83] RFC 5102 IPFIX Information Model January 2008

9. Acknowledgements

 The editors thank Paul Callato for creating the initial version of
 this document, and Thomas Dietz for developing the XSLT scripts that
 generate large portions of the text part of this document from the
 XML appendices.

10. References

10.1. Normative References

 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC5101]  Claise, B., "Specification of the IPFIX Protocol for the
            Exchange", RFC 5101, January 2008.

10.2. Informative References

 [IEEE.754.1985]
            Institute of Electrical and Electronics Engineers,
            "Standard for Binary Floating-Point Arithmetic", IEEE
            Standard 754, August 1985.
 [IEEE.802-11.1999]
            "Information technology - Telecommunications and
            information exchange between systems - Local and
            metropolitan area networks - Specific requirements - Part
            11: Wireless LAN Medium Access Control (MAC) and Physical
            Layer (PHY) specifications", IEEE Standard 802.11, 1999,
            <http://standards.ieee.org/getieee802/download/802.11-
            1999.pdF>.
 [IEEE.802-1Q.2003]
            Institute of Electrical and Electronics Engineers, "Local
            and Metropolitan Area Networks: Virtual Bridged Local Area
            Networks", IEEE Standard 802.1Q, March 2003.
 [IEEE.802-3.2002]
            "Information technology - Telecommunications and
            information exchange between systems - Local and
            metropolitan area networks - Specific requirements - Part
            3: Carrier sense multiple access with collision detection
            (CSMA/CD) access method and physical layer
            specifications", IEEE Standard 802.3, September 2002.

Quittek, et al. Standards Track [Page 84] RFC 5102 IPFIX Information Model January 2008

 [ISO.10646-1.1993]
            International Organization for Standardization,
            "Information Technology - Universal Multiple-octet coded
            Character Set (UCS) - Part 1: Architecture and Basic
            Multilingual Plane", ISO Standard 10646-1, May 1993.
 [ISO.646.1991]
            International Organization for Standardization,
            "Information technology - ISO 7-bit coded character set
            for information interchange", ISO Standard 646, 1991.
 [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
            August 1980.
 [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791, September
            1981.
 [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
            RFC 792, September 1981.
 [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7, RFC
            793, September 1981.
 [RFC1108]  Kent, S., "U.S. Department of Defense Security Options for
            the Internet Protocol", RFC 1108, November 1991.
 [RFC1112]  Deering, S., "Host extensions for IP multicasting", STD 5,
            RFC 1112, August 1989.
 [RFC1191]  Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
            November 1990.
 [RFC1323]  Jacobson, V., Braden, R., and D. Borman, "TCP Extensions
            for High Performance", RFC 1323, May 1992.
 [RFC1385]  Wang, Z., "EIP: The Extended Internet Protocol", RFC 1385,
            November 1992.
 [RFC1812]  Baker, F., Ed., "Requirements for IP Version 4 Routers",
            RFC 1812, June 1995.
 [RFC1930]  Hawkinson, J. and T. Bates, "Guidelines for creation,
            selection, and registration of an Autonomous System (AS)",
            BCP 6, RFC 1930, March 1996.
 [RFC2113]  Katz, D., "IP Router Alert Option", RFC 2113, February
            1997.

Quittek, et al. Standards Track [Page 85] RFC 5102 IPFIX Information Model January 2008

 [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
            IANA Considerations Section in RFCs", BCP 26, RFC 2434,
            October 1998.
 [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
            (IPv6) Specification", RFC 2460, December 1998.
 [RFC2578]  McCloghrie, K., Perkins, D., and J. Schoenwaelder,
            "Structure of Management Information Version 2 (SMIv2)",
            STD 58, RFC 2578, April 1999.
 [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
            June 1999.
 [RFC2675]  Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms",
            RFC 2675, August 1999.
 [RFC2863]  McCloghrie, K. and F. Kastenholz, "The Interfaces Group
            MIB", RFC 2863, June 2000.
 [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
            Label Switching Architecture", RFC 3031, January 2001.
 [RFC3032]  Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
            Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
            Encoding", RFC 3032, January 2001.
 [RFC3193]  Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth,
            "Securing L2TP using IPsec", RFC 3193, November 2001.
 [RFC3234]  Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
            Issues", RFC 3234, February 2002.
 [RFC3260]  Grossman, D., "New Terminology and Clarifications for
            Diffserv", RFC 3260, April 2002.
 [RFC3270]  Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
            P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-
            Protocol Label Switching (MPLS) Support of Differentiated
            Services", RFC 3270, May 2002.
 [RFC3376]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
            Thyagarajan, "Internet Group Management Protocol, Version
            3", RFC 3376, October 2002.
 [RFC3444]  Pras, A. and J. Schoenwaelder, "On the Difference between
            Information Models and Data Models", RFC 3444, January
            2003.

Quittek, et al. Standards Track [Page 86] RFC 5102 IPFIX Information Model January 2008

 [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
            January 2004.
 [RFC3954]  Claise, B., Ed., "Cisco Systems NetFlow Services Export
            Version 9", RFC 3954, October 2004.
 [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
            Border Gateway Protocol 4 (BGP-4)", RFC 4271, January
            2006.
 [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
            Architecture", RFC 4291, February 2006.
 [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302, December
            2005.
 [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
            4303, December 2005.
 [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
            Networks (VPNs)", RFC 4364, February 2006.
 [RFC4382]  Nadeau, T., Ed., and H. van der Linde, Ed., "MPLS/BGP
            Layer 3 Virtual Private Network (VPN) Management
            Information Base", RFC 4382, February 2006.
 [RFC4443]  Conta, A., Deering, S., and M. Gupta, Ed., "Internet
            Control Message Protocol (ICMPv6) for the Internet
            Protocol Version 6 (IPv6) Specification", RFC 4443, March
            2006.
 [RFC4960]  Stewart, R., Ed., "Stream Control Transmission Protocol",
            RFC 4960, September 2007.
 [RFC5036]  Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
            "LDP Specification", RFC 5036, October 2007.

Quittek, et al. Standards Track [Page 87] RFC 5102 IPFIX Information Model January 2008

Appendix A. XML Specification of IPFIX Information Elements

 This appendix contains a machine-readable description of the IPFIX
 information model coded in XML.  Note that this appendix is of
 informational nature, while the text in Section 4 (generated from
 this appendix) is normative.
 Using a machine-readable syntax for the information model enables the
 creation of IPFIX-aware tools that 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
 document 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.
 hard coding their behavior or inventing proprietary means for
 accommodating extensions.
 <?xml version="1.0" encoding="UTF-8"?>
 <fieldDefinitions xmlns="urn:ietf:params:xml:ns:ipfix-info"
              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
              xsi:schemaLocation="urn:ietf:params:xml:ns:ipfix-info
              ipfix-info.xsd">
   <field name="lineCardId" dataType="unsigned32"
          group="scope"
          dataTypeSemantics="identifier"
          elementId="141" applicability="option" status="current">
     <description>
       <paragraph>
         An identifier of a line card that is unique per IPFIX
         Device hosting an Observation Point.  Typically, this
         Information Element is used for limiting the scope
         of other Information Elements.
       </paragraph>
     </description>
   </field>
   <field name="portId" dataType="unsigned32"

Quittek, et al. Standards Track [Page 88] RFC 5102 IPFIX Information Model January 2008

          group="scope"
          dataTypeSemantics="identifier"
          elementId="142" applicability="option" status="current">
     <description>
       <paragraph>
         An identifier of a line port that is unique per IPFIX
         Device hosting an Observation Point.  Typically, this
         Information Element is used for limiting the scope
         of other Information Elements.
       </paragraph>
     </description>
   </field>
   <field name="ingressInterface" dataType="unsigned32"
          group="scope"
          dataTypeSemantics="identifier"
          elementId="10" applicability="all" status="current">
     <description>
       <paragraph>
         The index of the IP interface where packets of this Flow
         are being received.  The value matches the value of managed
         object 'ifIndex' as defined in RFC 2863.
         Note that ifIndex values are not assigned statically to an
         interface and that the interfaces may be renumbered every
         time the device's management system is re-initialized, as
         specified in RFC 2863.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 2863 for the definition of the ifIndex object.
       </paragraph>
     </reference>
   </field>
   <field name="egressInterface" dataType="unsigned32"
          group="scope"
          dataTypeSemantics="identifier"
          elementId="14" applicability="all" status="current">
     <description>
       <paragraph>
         The index of the IP interface where packets of
         this Flow are being sent.  The value matches the value of
         managed object 'ifIndex' as defined in RFC 2863.
         Note that ifIndex values are not assigned statically to an
         interface and that the interfaces may be renumbered every
         time the device's management system is re-initialized, as
         specified in RFC 2863.

Quittek, et al. Standards Track [Page 89] RFC 5102 IPFIX Information Model January 2008

       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 2863 for the definition of the ifIndex object.
       </paragraph>
     </reference>
   </field>
   <field name="meteringProcessId" dataType="unsigned32"
          group="scope"
          dataTypeSemantics="identifier"
          elementId="143" applicability="option" status="current">
     <description>
       <paragraph>
         An identifier of a Metering Process that is unique per
         IPFIX Device.  Typically, this Information Element is used
         for limiting the scope of other Information Elements.
         Note that process identifiers are typically assigned
         dynamically.
         The Metering Process may be re-started with a different ID.
       </paragraph>
     </description>
   </field>
   <field name="exportingProcessId" dataType="unsigned32"
          group="scope"
          dataTypeSemantics="identifier"
          elementId="144" applicability="option" status="current">
     <description>
       <paragraph>
         An identifier of an Exporting Process that is unique per
         IPFIX Device.  Typically, this Information Element is used
         for limiting the scope of other Information Elements.
         Note that process identifiers are typically assigned
         dynamically.  The Exporting Process may be re-started
         with a different ID.
       </paragraph>
     </description>
   </field>
   <field name="flowId" dataType="unsigned64"
          group="scope"
          dataTypeSemantics="identifier"
          elementId="148" applicability="option" status="current">
     <description>
       <paragraph>
         An identifier of a Flow that is unique within an Observation

Quittek, et al. Standards Track [Page 90] RFC 5102 IPFIX Information Model January 2008

         Domain.  This Information Element can be used to distinguish
         between different Flows if Flow Keys such as IP addresses and
         port numbers are not reported or are reported in separate
         records.
       </paragraph>
     </description>
   </field>
   <field name="templateId" dataType="unsigned16"
          group="scope"
          dataTypeSemantics="identifier"
          elementId="145" applicability="option" status="current">
     <description>
       <paragraph>
         An identifier of a Template that is locally unique within a
         combination of a Transport session and an Observation Domain.
       </paragraph>
       <paragraph>
         Template IDs 0-255 are reserved for Template Sets, Options
         Template Sets, and other reserved Sets yet to be created.
         Template IDs of Data Sets are numbered from 256 to 65535.
       </paragraph>
       <paragraph>
         Typically, this Information Element is used for limiting
         the scope of other Information Elements.
         Note that after a re-start of the Exporting Process Template
         identifiers may be re-assigned.
       </paragraph>
     </description>
   </field>
   <field name="observationDomainId" dataType="unsigned32"
          group="scope"
          dataTypeSemantics="identifier"
          elementId="149" applicability="option" status="current">
     <description>
       <paragraph>
         An identifier of an Observation Domain that is locally
         unique to an Exporting Process.  The Exporting Process uses
         the Observation Domain ID to uniquely identify to the
         Collecting Process the Observation Domain where Flows
         were metered.  It is RECOMMENDED that this identifier is
         also unique per IPFIX Device.
       </paragraph>
       <paragraph>
         A value of 0 indicates that no specific Observation Domain
         is identified by this Information Element.
       </paragraph>

Quittek, et al. Standards Track [Page 91] RFC 5102 IPFIX Information Model January 2008

       <paragraph>
         Typically, this Information Element is used for limiting
         the scope of other Information Elements.
       </paragraph>
     </description>
   </field>
   <field name="observationPointId" dataType="unsigned32"
          group="scope"
          dataTypeSemantics="identifier"
          elementId="138" applicability="option" status="current">
     <description>
       <paragraph>
       An identifier of an Observation Point that is unique per
       Observation Domain.  It is RECOMMENDED that this identifier is
       also unique per IPFIX Device.  Typically, this Information
       Element is used for limiting the scope of other Information
       Elements.
       </paragraph>
     </description>
   </field>
   <field name="commonPropertiesId" dataType="unsigned64"
          group="scope"
          dataTypeSemantics="identifier"
          elementId="137" applicability="option" status="current">
     <description>
       <paragraph>
         An identifier of a set of common properties that is
         unique per Observation Domain and Transport Session.
         Typically, this Information Element is used to link to
         information reported in separate Data Records.
       </paragraph>
     </description>
   </field>
   <field name="exporterIPv4Address" dataType="ipv4Address"
          dataTypeSemantics="identifier"
          group="config"
          elementId="130" applicability="all" status="current">
     <description>
       <paragraph>
       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.
       </paragraph>
     </description>
   </field>

Quittek, et al. Standards Track [Page 92] RFC 5102 IPFIX Information Model January 2008

   <field name="exporterIPv6Address" dataType="ipv6Address"
          dataTypeSemantics="identifier"
          group="config"
          elementId="131" applicability="all" status="current">
     <description>
       <paragraph>
       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.
       </paragraph>
     </description>
   </field>
   <field name="exporterTransportPort" dataType="unsigned16"
          group="config"
          dataTypeSemantics="identifier"
          elementId="217" applicability="all" status="current">
     <description>
       <paragraph>
       The source port identifier from which the Exporting
       Process sends Flow information.  For the transport protocols
       UDP, TCP, and SCTP, this is the source port number.
       This field MAY also be used for future transport protocols
       that have 16-bit source port identifiers.  This field may
       be useful for distinguishing multiple Exporting Processes
       that use the same IP address.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       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 4960 for the definition of SCTP.
       </paragraph>
       <paragraph>
       Additional information on defined UDP and TCP port numbers can
       be found at http://www.iana.org/assignments/port-numbers.
       </paragraph>
     </reference>
   </field>
   <field name="collectorIPv4Address" dataType="ipv4Address"
          dataTypeSemantics="identifier"
          group="config"
          elementId="211" applicability="all" status="current">

Quittek, et al. Standards Track [Page 93] RFC 5102 IPFIX Information Model January 2008

     <description>
       <paragraph>
       An IPv4 address to which the Exporting Process sends Flow
       information.
       </paragraph>
     </description>
   </field>
   <field name="collectorIPv6Address" dataType="ipv6Address"
          dataTypeSemantics="identifier"
          group="config"
          elementId="212" applicability="all" status="current">
     <description>
       <paragraph>
       An IPv6 address to which the Exporting Process sends Flow
       information.
       </paragraph>
     </description>
   </field>
   <field name="exportInterface" dataType="unsigned32"
          group="config"
          dataTypeSemantics="identifier"
          elementId="213" applicability="all" status="current">
     <description>
       <paragraph>
         The index of the interface from which IPFIX Messages sent
         by the Exporting Process to a Collector leave the IPFIX
         Device.  The value matches the value of
         managed object 'ifIndex' as defined in RFC 2863.
         Note that ifIndex values are not assigned statically to an
         interface and that the interfaces may be renumbered every
         time the device's management system is re-initialized, as
         specified in RFC 2863.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 2863 for the definition of the ifIndex object.
       </paragraph>
     </reference>
   </field>
   <field name="exportProtocolVersion" dataType="unsigned8"
          dataTypeSemantics="identifier"
          group="config"
          elementId="214" applicability="all" status="current">
     <description>

Quittek, et al. Standards Track [Page 94] RFC 5102 IPFIX Information Model January 2008

       <paragraph>
         The protocol version used by the Exporting Process for
         sending Flow information.  The protocol version is given
         by the value of the Version Number field in the Message
         Header.
       </paragraph>
       <paragraph>
         The protocol version is 10 for IPFIX and 9 for NetFlow
         version 9.
         A value of 0 indicates that no export protocol is in use.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See the IPFIX protocol specification [RFC5101] for the
       definition of the IPFIX Message Header.
       </paragraph>
       <paragraph>
       See RFC 3954 for the definition of the NetFlow
       version 9 message header.
       </paragraph>
     </reference>
   </field>
   <field name="exportTransportProtocol" dataType="unsigned8"
          group="config"
          dataTypeSemantics="identifier"
          elementId="215" applicability="all" status="current">
     <description>
       <paragraph>
       The value of the protocol number used by the Exporting Process
       for sending Flow information.
       The protocol number identifies the IP packet payload type.
       Protocol numbers are defined in the IANA Protocol Numbers
       registry.
       </paragraph>
       <paragraph>
       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.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 791 for the specification of the IPv4
       protocol field.

Quittek, et al. Standards Track [Page 95] RFC 5102 IPFIX Information Model January 2008

       See RFC 2460 for the specification of the IPv6
       protocol field.
       See the list of protocol numbers assigned by IANA at
       http://www.iana.org/assignments/protocol-numbers.
       </paragraph>
     </reference>
   </field>
   <field name="collectorTransportPort" dataType="unsigned16"
          group="config"
          dataTypeSemantics="identifier"
          elementId="216" applicability="all" status="current">
     <description>
       <paragraph>
       The destination port identifier to which the Exporting
       Process sends Flow information.  For the transport protocols
       UDP, TCP, and SCTP, this is the destination port number.
       This field MAY also be used for future transport protocols
       that have 16-bit source port identifiers.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 768 for the definition of the UDP
       destination port field.
       See RFC 793 for the definition of the TCP
       destination port field.
       See RFC 4960 for the definition of SCTP.
       </paragraph>
       <paragraph>
       Additional information on defined UDP and TCP port numbers can
       be found at http://www.iana.org/assignments/port-numbers.
       </paragraph>
     </reference>
   </field>
   <field name="flowKeyIndicator" dataType="unsigned64"
          dataTypeSemantics="flags"
          group="config"
          elementId="173" applicability="all" status="current">
     <description>
       <paragraph>
       This set of bit fields is used for marking the Information
       Elements of a Data Record that serve as Flow Key.  Each bit
       represents an Information Element in the Data Record with
       the n-th bit representing the n-th Information Element.
       A bit set to value 1 indicates that the corresponding
       Information Element is a Flow Key of the reported Flow.

Quittek, et al. Standards Track [Page 96] RFC 5102 IPFIX Information Model January 2008

       A bit set to value 0 indicates that this is not the case.
       </paragraph>
       <paragraph>
       If the Data Record contains more than 64 Information Elements,
       the corresponding Template SHOULD be designed such that all
       Flow Keys are among the first 64 Information Elements, because
       the flowKeyIndicator only contains 64 bits.  If the Data Record
       contains less than 64 Information Elements, then the bits in
       the flowKeyIndicator for which no corresponding Information
       Element exists MUST have the value 0.
       </paragraph>
     </description>
   </field>
   <field name="exportedMessageTotalCount" dataType="unsigned64"
          dataTypeSemantics="totalCounter"
          group="processCounter"
          elementId="41" applicability="data" status="current">
     <description>
       <paragraph>
         The total number of IPFIX Messages that the Exporting Process
         has sent since the Exporting Process (re-)initialization to
         a particular Collecting Process.
         The reported number excludes the IPFIX Message that carries
         the counter value.
         If this Information Element is sent to a particular
         Collecting Process, then by default it specifies the number
         of IPFIX Messages sent to this Collecting Process.
       </paragraph>
     </description>
     <units>messages</units>
   </field>
   <field name="exportedOctetTotalCount" dataType="unsigned64"
          dataTypeSemantics="totalCounter"
          group="processCounter"
          elementId="40" applicability="data" status="current">
     <description>
       <paragraph>
         The total number of octets that the Exporting Process
         has sent since the Exporting Process (re-)initialization
         to a particular Collecting Process.
         The value of this Information Element is calculated by
         summing up the IPFIX Message Header length values of all
         IPFIX Messages that were successfully sent to the Collecting
         Process.  The reported number excludes octets in the IPFIX
         Message that carries the counter value.
         If this Information Element is sent to a particular

Quittek, et al. Standards Track [Page 97] RFC 5102 IPFIX Information Model January 2008

         Collecting Process, then by default it specifies the number
         of octets sent to this Collecting Process.
       </paragraph>
     </description>
     <units>octets</units>
   </field>
   <field name="exportedFlowRecordTotalCount" dataType="unsigned64"
          group="processCounter"
          dataTypeSemantics="totalCounter"
          elementId="42" applicability="data" status="current">
     <description>
       <paragraph>
         The total number of Flow Records that the Exporting
         Process has sent as Data Records since the Exporting
         Process (re-)initialization to a particular Collecting
         Process.  The reported number excludes Flow Records in
         the IPFIX Message that carries the counter value.
         If this Information Element is sent to a particular
         Collecting Process, then by default it specifies the number
         of Flow Records sent to this process.
       </paragraph>
     </description>
     <units>flows</units>
   </field>
   <field name="observedFlowTotalCount" dataType="unsigned64"
          dataTypeSemantics="totalCounter"
          group="processCounter"
          elementId="163" applicability="data" status="current">
     <description>
       <paragraph>
       The total number of Flows observed in the Observation Domain
       since the Metering Process (re-)initialization for this
       Observation Point.
       </paragraph>
     </description>
     <units>flows</units>
   </field>
   <field name="ignoredPacketTotalCount" dataType="unsigned64"
          dataTypeSemantics="totalCounter"
          group="processCounter"
          elementId="164" applicability="data" status="current">
     <description>
       <paragraph>
          The total number of observed IP packets that the
          Metering Process did not process since the

Quittek, et al. Standards Track [Page 98] RFC 5102 IPFIX Information Model January 2008

          (re-)initialization of the Metering Process.
       </paragraph>
     </description>
     <units>packets</units>
   </field>
   <field name="ignoredOctetTotalCount" dataType="unsigned64"
          dataTypeSemantics="totalCounter"
          group="processCounter"
          elementId="165" applicability="data" status="current">
     <description>
       <paragraph>
          The total number of octets in observed IP packets
          (including the IP header) that the Metering Process
          did not process since the (re-)initialization of the
          Metering Process.
       </paragraph>
     </description>
     <units>octets</units>
   </field>
   <field name="notSentFlowTotalCount" dataType="unsigned64"
          dataTypeSemantics="totalCounter"
          group="processCounter"
          elementId="166" applicability="data" status="current">
     <description>
       <paragraph>
          The total number of Flow Records that were generated by the
          Metering Process and dropped by the Metering Process or
          by the Exporting Process instead of being sent to the
          Collecting Process.  There are several potential reasons for
          this including resource shortage and special Flow export
          policies.
       </paragraph>
     </description>
     <units>flows</units>
   </field>
   <field name="notSentPacketTotalCount" dataType="unsigned64"
          dataTypeSemantics="totalCounter"
          group="processCounter"
          elementId="167" applicability="data" status="current">
     <description>
       <paragraph>
          The total number of packets in Flow Records that were
          generated by the Metering Process and dropped
          by the Metering Process or by the Exporting Process
          instead of being sent to the Collecting Process.

Quittek, et al. Standards Track [Page 99] RFC 5102 IPFIX Information Model January 2008

          There are several potential reasons for this including
          resource shortage and special Flow export policies.
       </paragraph>
     </description>
     <units>packets</units>
   </field>
   <field name="notSentOctetTotalCount" dataType="unsigned64"
          dataTypeSemantics="totalCounter"
          group="processCounter"
          elementId="168" applicability="data" status="current">
     <description>
       <paragraph>
          The total number of octets in packets in Flow Records
          that were generated by the Metering Process and
          dropped by the Metering Process or by the Exporting
          Process instead of being sent to the Collecting Process.
          There are several potential reasons for this including
          resource shortage and special Flow export policies.
       </paragraph>
     </description>
     <units>octets</units>
   </field>
   <field name="ipVersion" dataType="unsigned8"
          group="ipHeader"
          dataTypeSemantics="identifier"
          elementId="60" applicability="all" status="current">
     <description>
       <paragraph>
       The IP version field in the IP packet header.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 791 for the definition of the version field
       in the IPv4 packet header.
       See RFC 2460 for the 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.
       </paragraph>
     </reference>
   </field>
   <field name="sourceIPv4Address" dataType="ipv4Address"
          group="ipHeader"

Quittek, et al. Standards Track [Page 100] RFC 5102 IPFIX Information Model January 2008

          dataTypeSemantics="identifier"
          elementId="8" applicability="all" status="current">
     <description>
       <paragraph>
       The IPv4 source address in the IP packet header.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 791 for the definition of the IPv4 source
       address field.
       </paragraph>
     </reference>
   </field>
   <field name="sourceIPv6Address" dataType="ipv6Address"
          group="ipHeader"
          dataTypeSemantics="identifier"
          elementId="27" applicability="all" status="current">
     <description>
       <paragraph>
       The IPv6 source address in the IP packet header.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 2460 for the definition of the
       Source Address field in the IPv6 header.
       </paragraph>
     </reference>
   </field>
   <field name="sourceIPv4PrefixLength" dataType="unsigned8"
          group="ipHeader"
          elementId="9" applicability="option" status="current">
     <description>
       <paragraph>
       The number of contiguous bits that are relevant in the
       sourceIPv4Prefix Information Element.
       </paragraph>
     </description>
     <units>bits</units>
     <range>0-32</range>
   </field>
   <field name="sourceIPv6PrefixLength" dataType="unsigned8"
          group="ipHeader"
          elementId="29" applicability="option" status="current">

Quittek, et al. Standards Track [Page 101] RFC 5102 IPFIX Information Model January 2008

     <description>
       <paragraph>
       The number of contiguous bits that are relevant in the
       sourceIPv6Prefix Information Element.
       </paragraph>
     </description>
     <units>bits</units>
     <range>0-128</range>
   </field>
   <field name="sourceIPv4Prefix" dataType="ipv4Address"
          group="ipHeader"
          elementId="44" applicability="data" status="current">
     <description>
       <paragraph>
       IPv4 source address prefix.
       </paragraph>
     </description>
   </field>
   <field name="sourceIPv6Prefix" dataType="ipv6Address"
          group="ipHeader"
          elementId="170" applicability="data" status="current">
     <description>
       <paragraph>
       IPv6 source address prefix.
       </paragraph>
     </description>
   </field>
   <field name="destinationIPv4Address" dataType="ipv4Address"
          group="ipHeader"
          dataTypeSemantics="identifier"
          elementId="12" applicability="all" status="current">
     <description>
       <paragraph>
       The IPv4 destination address in the IP packet header.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 791 for the definition of the IPv4
       destination address field.
       </paragraph>
     </reference>
   </field>
   <field name="destinationIPv6Address" dataType="ipv6Address"

Quittek, et al. Standards Track [Page 102] RFC 5102 IPFIX Information Model January 2008

          group="ipHeader"
          dataTypeSemantics="identifier"
          elementId="28" applicability="all" status="current">
     <description>
       <paragraph>
       The IPv6 destination address in the IP packet header.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 2460 for the definition of the
       Destination Address field in the IPv6 header.
       </paragraph>
     </reference>
   </field>
   <field name="destinationIPv4PrefixLength" dataType="unsigned8"
          group="ipHeader"
          elementId="13" applicability="option" status="current">
     <description>
       <paragraph>
       The number of contiguous bits that are relevant in the
       destinationIPv4Prefix Information Element.
       </paragraph>
     </description>
     <units>bits</units>
     <range>0-32</range>
   </field>
   <field name="destinationIPv6PrefixLength" dataType="unsigned8"
          group="ipHeader"
          elementId="30" applicability="option" status="current">
     <description>
       <paragraph>
       The number of contiguous bits that are relevant in the
       destinationIPv6Prefix Information Element.
       </paragraph>
     </description>
     <units>bits</units>
     <range>0-128</range>
   </field>
   <field name="destinationIPv4Prefix" dataType="ipv4Address"
          group="ipHeader"
          elementId="45" applicability="data" status="current">
     <description>
       <paragraph> IPv4 destination address prefix. </paragraph>
     </description>

Quittek, et al. Standards Track [Page 103] RFC 5102 IPFIX Information Model January 2008

   </field>
   <field name="destinationIPv6Prefix" dataType="ipv6Address"
          group="ipHeader"
          elementId="169" applicability="data" status="current">
     <description>
       <paragraph> IPv6 destination address prefix. </paragraph>
     </description>
   </field>
   <field name="ipTTL" dataType="unsigned8"
          group="ipHeader"
          elementId="192" applicability="all" status="current">
     <description>
       <paragraph>
       For IPv4, the value of the Information Element matches
       the value of the Time to Live (TTL) field in the IPv4 packet
       header.  For IPv6, the value of the Information Element
       matches the value of the Hop Limit field in the IPv6
       packet header.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 791 for the definition of the IPv4
       Time to Live field.
       See RFC 2460 for the definition of the IPv6
       Hop Limit field.
       </paragraph>
     </reference>
     <units>hops</units>
   </field>
   <field name="protocolIdentifier" dataType="unsigned8"
          group="ipHeader"
          dataTypeSemantics="identifier"
          elementId="4" applicability="all" status="current">
     <description>
       <paragraph>
       The value of the protocol number in the IP packet header.
       The protocol number identifies the IP packet payload type.
       Protocol numbers are defined in the IANA Protocol Numbers
       registry.
          </paragraph>
       <paragraph>
       In Internet Protocol version 4 (IPv4), this is carried in the
       Protocol field.  In Internet Protocol version 6 (IPv6), this

Quittek, et al. Standards Track [Page 104] RFC 5102 IPFIX Information Model January 2008

       is carried in the Next Header field in the last extension
       header of the packet.
          </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 791 for the specification of the IPv4
       protocol field.
       See RFC 2460 for the specification of the IPv6
       protocol field.
       See the list of protocol numbers assigned by IANA at
       http://www.iana.org/assignments/protocol-numbers.
       </paragraph>
     </reference>
   </field>
   <field name="nextHeaderIPv6" dataType="unsigned8"
          group="ipHeader"
          elementId="193" applicability="all" status="current">
     <description>
       <paragraph>
       The value of the Next Header field of the IPv6 header.
       The value identifies the type of the following IPv6
       extension header or of the following IP payload.
       Valid values are defined in the IANA
       Protocol Numbers registry.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 2460 for the definition of the IPv6
       Next Header field.
       See the list of protocol numbers assigned by IANA at
       http://www.iana.org/assignments/protocol-numbers.
       </paragraph>
     </reference>
   </field>
   <field name="ipDiffServCodePoint" dataType="unsigned8"
          group="ipHeader"
          dataTypeSemantics="identifier"
          elementId="195" applicability="all" status="current">
     <description>
       <paragraph>
       The value of a Differentiated Services Code Point (DSCP)
       encoded in the Differentiated Services field.  The
       Differentiated Services field spans the most significant
       6 bits of the IPv4 TOS field or the IPv6 Traffic Class

Quittek, et al. Standards Track [Page 105] RFC 5102 IPFIX Information Model January 2008

       field, respectively.
       </paragraph>
       <paragraph>
       This Information Element encodes only the 6 bits of the
       Differentiated Services field.  Therefore, its value may
       range from 0 to 63.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 3260 for the definition of the
       Differentiated Services field.
       See RFC 1812 (Section 5.3.2) and RFC 791 for the definition
       of the IPv4 TOS field.  See RFC 2460 for the definition of
       the IPv6 Traffic Class field.
       </paragraph>
     </reference>
     <range>0-63</range>
   </field>
   <field name="ipPrecedence" dataType="unsigned8"
          group="ipHeader"
          dataTypeSemantics="identifier"
          elementId="196" applicability="all" status="current">
     <description>
       <paragraph>
       The value of the IP Precedence.  The IP Precedence value
       is encoded in the first 3 bits of the IPv4 TOS field
       or the IPv6 Traffic Class field, respectively.
       </paragraph>
       <paragraph>
       This Information Element encodes only these 3 bits.
       Therefore, its value may range from 0 to 7.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 1812 (Section 5.3.3) and RFC 791
       for the definition of the IP Precedence.
       See RFC 1812 (Section 5.3.2) and RFC 791
       for the definition of the IPv4 TOS field.
       See RFC 2460 for the definition of the IPv6
       Traffic Class field.
       </paragraph>
     </reference>
     <range>0-7</range>
   </field>

Quittek, et al. Standards Track [Page 106] RFC 5102 IPFIX Information Model January 2008

   <field name="ipClassOfService" dataType="unsigned8"
          group="ipHeader"
          dataTypeSemantics="identifier"
          elementId="5" applicability="all" status="current">
     <description>
       <paragraph>
       For IPv4 packets, this is the value of the TOS field in
       the IPv4 packet header.  For IPv6 packets, this is the
       value of the Traffic Class field in the IPv6 packet header.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 1812 (Section 5.3.2) and RFC 791
       for the definition of the IPv4 TOS field.
       See RFC 2460 for the definition of the IPv6
       Traffic Class field.
       </paragraph>
     </reference>
   </field>
   <field name="postIpClassOfService" dataType="unsigned8"
          group="ipHeader"
          dataTypeSemantics="identifier"
          elementId="55" applicability="all" status="current">
     <description>
       <paragraph>
       The definition of this Information Element is identical
       to the definition of Information Element
       'ipClassOfService', except that it reports a
       potentially modified value caused by a middlebox
       function after the packet passed the Observation Point.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 791 for the definition of the IPv4
       TOS field.
       See RFC 2460 for the definition of the IPv6
       Traffic Class field.
       See RFC 3234 for the definition of middleboxes.
       </paragraph>
     </reference>
   </field>
   <field name="flowLabelIPv6" dataType="unsigned32"
          group="ipHeader"
          dataTypeSemantics="identifier"

Quittek, et al. Standards Track [Page 107] RFC 5102 IPFIX Information Model January 2008

          elementId="31" applicability="all" status="current">
     <description>
       <paragraph>
       The value of the IPv6 Flow Label field in the IP packet header.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 2460 for the definition of the
       Flow Label field in the IPv6 packet header.
       </paragraph>
     </reference>
   </field>
   <field name="isMulticast" dataType="unsigned8"
          group="ipHeader"
          dataTypeSemantics="flags"
          elementId="206" applicability="data" status="current">
     <description>
       <paragraph>
         If the IP destination address is not a reserved multicast
         address, then the value of all bits of the octet (including
         the reserved ones) is zero.
       </paragraph>
       <paragraph>
         The first bit of this octet is set to 1 if the Version
         field of the IP header has the value 4 and if the
         Destination Address field contains a reserved multicast
         address in the range from 224.0.0.0 to 239.255.255.255.
         Otherwise, this bit is set to 0.
       </paragraph>
       <paragraph>
         The second and third bits of this octet are reserved for
         future use.
       </paragraph>
       <paragraph>
         The remaining bits of the octet are only set to values
         other than zero if the IP Destination Address is a
         reserved IPv6 multicast address.  Then the fourth bit
         of the octet is set to the value of the T flag in the
         IPv6 multicast address and the remaining four bits are
         set to the value of the scope field in the IPv6
         multicast address.
       </paragraph>
       <artwork>
           0      1      2      3      4      5      6      7
        +------+------+------+------+------+------+------+------+
        | MCv4 | RES. | RES. |  T   |   IPv6 multicast scope    |

Quittek, et al. Standards Track [Page 108] RFC 5102 IPFIX Information Model January 2008

        +------+------+------+------+------+------+------+------+
        Bit  0:    set to 1 if IPv4 multicast
        Bits 1-2:  reserved for future use
        Bit  4:    set to value of T flag, if IPv6 multicast
        Bits 4-7:  set to value of multicast scope if IPv6 multicast
       </artwork>
     </description>
     <reference>
       <paragraph>
       See RFC 1112 for the specification of reserved
       IPv4 multicast addresses.
       See RFC 4291 for the specification of reserved
       IPv6 multicast addresses and the definition of the T flag
       and the IPv6 multicast scope.
       </paragraph>
     </reference>
   </field>
   <field name="fragmentIdentification" dataType="unsigned32"
          group="ipHeader"
          dataTypeSemantics="identifier"
          elementId="54" applicability="data" status="current">
     <description>
       <paragraph>
       The value of the Identification field
       in the IPv4 packet header or in the IPv6 Fragment header,
       respectively.  The value is 0 for IPv6 if there is
       no fragment header.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 791 for the definition of the IPv4
       Identification field.
       See RFC 2460 for the definition of the
       Identification field in the IPv6 Fragment header.
       </paragraph>
     </reference>
   </field>
   <field name="fragmentOffset" dataType="unsigned16"
          group="ipHeader"
          dataTypeSemantics="identifier"
          elementId="88" applicability="all" status="current">
     <description>
       <paragraph>
       The value of the IP fragment offset field in the

Quittek, et al. Standards Track [Page 109] RFC 5102 IPFIX Information Model January 2008

       IPv4 packet header or the IPv6 Fragment header,
       respectively.  The value is 0 for IPv6 if there is
       no fragment header.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 791 for the specification of the
       fragment offset in the IPv4 header.
       See RFC 2460 for the specification of the
       fragment offset in the IPv6 Fragment header.
       </paragraph>
     </reference>
   </field>
   <field name="fragmentFlags" dataType="unsigned8"
          group="ipHeader"
          dataTypeSemantics="flags"
          elementId="197" applicability="all" status="current">
     <description>
       <paragraph>
         Fragmentation properties indicated by flags in the IPv4
         packet header or the IPv6 Fragment header, respectively.
       </paragraph>
       <artwork>
       Bit 0:    (RS) Reserved.
                 The value of this bit MUST be 0 until specified
                 otherwise.
       Bit 1:    (DF) 0 = May Fragment,  1 = Don't Fragment.
                 Corresponds to the value of the DF flag in the
                 IPv4 header.  Will always be 0 for IPv6 unless
                 a "don't fragment" feature is introduced to IPv6.
       Bit 2:    (MF) 0 = Last Fragment, 1 = More Fragments.
                 Corresponds to the MF flag in the IPv4 header
                 or to the M flag in the IPv6 Fragment header,
                 respectively.  The value is 0 for IPv6 if there
                 is no fragment header.
       Bits 3-7: (DC) Don't Care.
                 The values of these bits are irrelevant.
           0   1   2   3   4   5   6   7
         +---+---+---+---+---+---+---+---+
         | R | D | M | D | D | D | D | D |
         | S | F | F | C | C | C | C | C |
         +---+---+---+---+---+---+---+---+
       </artwork>
     </description>

Quittek, et al. Standards Track [Page 110] RFC 5102 IPFIX Information Model January 2008

     <reference>
       <paragraph>
       See RFC 791 for the specification of the IPv4
       fragment flags.
       See RFC 2460 for the specification of the IPv6
       Fragment header.
       </paragraph>
     </reference>
   </field>
   <field name="ipHeaderLength" dataType="unsigned8"
          group="ipHeader"
          elementId="189" applicability="all" status="current">
     <description>
       <paragraph>
       The length of the IP header.  For IPv6, the value of this
       Information Element is 40.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 791 for the specification of the
       IPv4 header.
       See RFC 2460 for the specification of the
       IPv6 header.
       </paragraph>
     </reference>
     <units>octets</units>
   </field>
   <field name="ipv4IHL" dataType="unsigned8"
          group="ipHeader"
          elementId="207" applicability="all" status="current">
     <description>
       <paragraph>
       The value of the Internet Header Length (IHL) field in
       the IPv4 header.  It specifies the length of the header
       in units of 4 octets.  Please note that its unit is
       different from most of the other Information Elements
       reporting length values.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 791 for the specification of the
       IPv4 header.
       </paragraph>
     </reference>

Quittek, et al. Standards Track [Page 111] RFC 5102 IPFIX Information Model January 2008

     <units>4 octets</units>
   </field>
   <field name="totalLengthIPv4" dataType="unsigned16"
          group="ipHeader"
          elementId="190" applicability="all" status="current">
     <description>
       <paragraph>
       The total length of the IPv4 packet.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 791 for the specification of the
       IPv4 total length.
       </paragraph>
     </reference>
     <units>octets</units>
   </field>
   <field name="ipTotalLength" dataType="unsigned64"
          group="ipHeader"
          elementId="224" applicability="all" status="current">
     <description>
       <paragraph>
       The total length of the IP packet.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 791 for the specification of the
       IPv4 total length.
       See RFC 2460 for the specification of the
       IPv6 payload length.
       See RFC 2675 for the specification of the
       IPv6 jumbo payload length.
       </paragraph>
     </reference>
     <units>octets</units>
   </field>
   <field name="payloadLengthIPv6" dataType="unsigned16"
          group="ipHeader"
          elementId="191" applicability="all" status="current">
     <description>
       <paragraph>
       This Information Element reports the value of the Payload
       Length field in the IPv6 header.  Note that IPv6 extension

Quittek, et al. Standards Track [Page 112] RFC 5102 IPFIX Information Model January 2008

       headers belong to the payload.  Also note that in case of a
       jumbo payload option the value of the Payload Length field in
       the IPv6 header is zero and so will be the value reported
       by this Information Element.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 2460 for the specification of the
       IPv6 payload length.
       See RFC 2675 for the specification of the
       IPv6 jumbo payload option.
       </paragraph>
     </reference>
     <units>octets</units>
   </field>
   <field name="sourceTransportPort" dataType="unsigned16"
          group="transportHeader"
          dataTypeSemantics="identifier"
          elementId="7" applicability="all" status="current">
     <description>
       <paragraph>
       The source port identifier in the transport header.
       For the 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.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       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 4960 for the definition of SCTP.
       </paragraph>
       <paragraph>
       Additional information on defined UDP and TCP port numbers can
       be found at http://www.iana.org/assignments/port-numbers.
       </paragraph>
     </reference>
   </field>
   <field name="destinationTransportPort" dataType="unsigned16"
          group="transportHeader"
          dataTypeSemantics="identifier"

Quittek, et al. Standards Track [Page 113] RFC 5102 IPFIX Information Model January 2008

          elementId="11" applicability="all" status="current">
     <description>
       <paragraph>
       The destination port identifier in the transport header.
       For the 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.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 768 for the definition of the UDP
       destination port field.
       See RFC 793 for the definition of the TCP
       destination port field.
       See RFC 4960 for the definition of SCTP.
       </paragraph>
       <paragraph>
       Additional information on defined UDP and TCP port numbers can
       be found at http://www.iana.org/assignments/port-numbers.
       </paragraph>
     </reference>
   </field>
   <field name="udpSourcePort" dataType="unsigned16"
          group="transportHeader"
          dataTypeSemantics="identifier"
          elementId="180" applicability="all" status="current">
     <description>
       <paragraph>
       The source port identifier in the UDP header.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 768 for the definition of the
       UDP source port field.
       Additional information on defined UDP port numbers can
       be found at http://www.iana.org/assignments/port-numbers.
       </paragraph>
     </reference>
   </field>
   <field name="udpDestinationPort" dataType="unsigned16"
          group="transportHeader"
          dataTypeSemantics="identifier"
          elementId="181" applicability="all" status="current">

Quittek, et al. Standards Track [Page 114] RFC 5102 IPFIX Information Model January 2008

     <description>
       <paragraph>
       The destination port identifier in the UDP header.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 768 for the definition of the
       UDP destination port field.
       Additional information on defined UDP port numbers can
       be found at http://www.iana.org/assignments/port-numbers.
       </paragraph>
     </reference>
   </field>
   <field name="udpMessageLength" dataType="unsigned16"
          group="transportHeader"
          elementId="205" applicability="all" status="current">
     <description>
       <paragraph>
       The value of the Length field in the UDP header.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 768 for the specification of the
       UDP header.
       </paragraph>
     </reference>
     <units>octets</units>
   </field>
   <field name="tcpSourcePort" dataType="unsigned16"
          group="transportHeader"
          dataTypeSemantics="identifier"
          elementId="182" applicability="all" status="current">
     <description>
       <paragraph>
       The source port identifier in the TCP header.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 793 for the definition of the TCP
       source port field.
       Additional information on defined TCP port numbers can
       be found at http://www.iana.org/assignments/port-numbers.
       </paragraph>

Quittek, et al. Standards Track [Page 115] RFC 5102 IPFIX Information Model January 2008

     </reference>
   </field>
   <field name="tcpDestinationPort" dataType="unsigned16"
          group="transportHeader"
          dataTypeSemantics="identifier"
          elementId="183" applicability="all" status="current">
     <description>
       <paragraph>
       The destination port identifier in the TCP header.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 793 for the definition of the TCP
       source port field.
       Additional information on defined TCP port numbers can
       be found at http://www.iana.org/assignments/port-numbers.
       </paragraph>
     </reference>
   </field>
   <field name="tcpSequenceNumber" dataType="unsigned32"
          group="transportHeader"
          elementId="184" applicability="all" status="current">
     <description>
       <paragraph>
       The sequence number in the TCP header.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 793 for the definition of the TCP
       sequence number.
       </paragraph>
     </reference>
   </field>
   <field name="tcpAcknowledgementNumber" dataType="unsigned32"
          group="transportHeader"
          elementId="185" applicability="all" status="current">
     <description>
       <paragraph>
       The acknowledgement number in the TCP header.
       </paragraph>
     </description>
     <reference>
       <paragraph>

Quittek, et al. Standards Track [Page 116] RFC 5102 IPFIX Information Model January 2008

       See RFC 793 for the definition of the TCP
       acknowledgement number.
       </paragraph>
     </reference>
   </field>
   <field name="tcpWindowSize" dataType="unsigned16"
          group="transportHeader"
          elementId="186" applicability="all" status="current">
     <description>
       <paragraph>
       The window field in the TCP header.
       If the TCP window scale is supported,
       then TCP window scale must be known
       to fully interpret the value of this information.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 793 for the definition of the TCP window field.
       See RFC 1323 for the definition of the TCP window scale.
       </paragraph>
     </reference>
   </field>
   <field name="tcpWindowScale" dataType="unsigned16"
          group="transportHeader"
          elementId="238" applicability="all" status="current">
     <description>
       <paragraph>
       The scale of the window field in the TCP header.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 1323 for the definition of the TCP window scale.
       </paragraph>
     </reference>
   </field>
   <field name="tcpUrgentPointer" dataType="unsigned16"
          group="transportHeader"
          elementId="187" applicability="all" status="current">
     <description>
       <paragraph>
       The urgent pointer in the TCP header.
       </paragraph>
     </description>

Quittek, et al. Standards Track [Page 117] RFC 5102 IPFIX Information Model January 2008

     <reference>
       <paragraph>
       See RFC 793 for the definition of the TCP
       urgent pointer.
       </paragraph>
     </reference>
   </field>
   <field name="tcpHeaderLength" dataType="unsigned8"
          group="transportHeader"
          elementId="188" applicability="all" status="current">
     <description>
       <paragraph>
       The length of the TCP header.  Note that the value of this
       Information Element is different from the value of the Data
       Offset field in the TCP header.  The Data Offset field
       indicates the length of the TCP header in units of 4 octets.
       This Information Elements specifies the length of the TCP
       header in units of octets.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 793 for the definition of the
       TCP header.
       </paragraph>
     </reference>
     <units>octets</units>
   </field>
   <field name="icmpTypeCodeIPv4" dataType="unsigned16"
          group="transportHeader"
          dataTypeSemantics="identifier"
          elementId="32" applicability="all" status="current">
     <description>
       <paragraph>
       Type and Code of the IPv4 ICMP message.  The combination of
       both values is reported as (ICMP type * 256) + ICMP code.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 792 for the definition of the IPv4 ICMP
          type and code fields.
       </paragraph>
     </reference>
   </field>

Quittek, et al. Standards Track [Page 118] RFC 5102 IPFIX Information Model January 2008

   <field name="icmpTypeIPv4" dataType="unsigned8"
          group="transportHeader"
          dataTypeSemantics="identifier"
          elementId="176" applicability="all" status="current">
     <description>
       <paragraph>
       Type of the IPv4 ICMP message.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 792 for the definition of the IPv4 ICMP
       type field.
       </paragraph>
     </reference>
   </field>
   <field name="icmpCodeIPv4" dataType="unsigned8"
          group="transportHeader"
          dataTypeSemantics="identifier"
          elementId="177" applicability="all" status="current">
     <description>
       <paragraph>
       Code of the IPv4 ICMP message.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 792 for the definition of the IPv4
       ICMP code field.
       </paragraph>
     </reference>
   </field>
   <field name="icmpTypeCodeIPv6" dataType="unsigned16"
          group="transportHeader"
          dataTypeSemantics="identifier"
          elementId="139" applicability="all" status="current">
     <description>
       <paragraph>
       Type and Code of the IPv6 ICMP message.  The combination of
       both values is reported as (ICMP type * 256) + ICMP code.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 4443 for the definition of the IPv6
       ICMP type and code fields.

Quittek, et al. Standards Track [Page 119] RFC 5102 IPFIX Information Model January 2008

       </paragraph>
     </reference>
   </field>
   <field name="icmpTypeIPv6" dataType="unsigned8"
          group="transportHeader"
          dataTypeSemantics="identifier"
          elementId="178" applicability="all" status="current">
     <description>
       <paragraph>
       Type of the IPv6 ICMP message.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 4443 for the definition of the IPv6
       ICMP type field.
       </paragraph>
     </reference>
   </field>
   <field name="icmpCodeIPv6" dataType="unsigned8"
          group="transportHeader"
          dataTypeSemantics="identifier"
          elementId="179" applicability="all" status="current">
     <description>
       <paragraph>
       Code of the IPv6 ICMP message.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 4443 for the definition of the IPv6
       ICMP code field.
       </paragraph>
     </reference>
   </field>
   <field name="igmpType" dataType="unsigned8"
          group="transportHeader"
          dataTypeSemantics="identifier"
          elementId="33" applicability="all" status="current">
     <description>
       <paragraph>
       The type field of the IGMP message.
       </paragraph>
     </description>
     <reference>

Quittek, et al. Standards Track [Page 120] RFC 5102 IPFIX Information Model January 2008

       <paragraph>
       See RFC 3376 for the definition of the IGMP
       type field.
       </paragraph>
     </reference>
   </field>
   <field name="sourceMacAddress" dataType="macAddress"
          group="subIpHeader"
          dataTypeSemantics="identifier"
          elementId="56" applicability="data" status="current">
     <description>
       <paragraph>
         The IEEE 802 source MAC address field.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See IEEE.802-3.2002.
       </paragraph>
     </reference>
   </field>
   <field name="postSourceMacAddress" dataType="macAddress"
          group="subIpHeader"
          dataTypeSemantics="identifier"
          elementId="81" applicability="data" status="current">
     <description>
       <paragraph>
       The definition of this Information Element is identical
       to the definition of Information Element
       'sourceMacAddress', except that it reports a
       potentially modified value caused by a middlebox
       function after the packet passed the Observation Point.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See IEEE.802-3.2002.
       </paragraph>
     </reference>
   </field>
   <field name="vlanId" dataType="unsigned16"
          group="subIpHeader"
          dataTypeSemantics="identifier"
          elementId="58" applicability="data" status="current">
     <description>

Quittek, et al. Standards Track [Page 121] RFC 5102 IPFIX Information Model January 2008

       <paragraph>
         The IEEE 802.1Q VLAN identifier (VID) extracted from the Tag
         Control Information field that was attached to the IP packet.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See IEEE.802-1Q.2003.
       </paragraph>
     </reference>
   </field>
   <field name="postVlanId" dataType="unsigned16"
          group="subIpHeader"
          dataTypeSemantics="identifier"
          elementId="59" applicability="data" status="current">
     <description>
       <paragraph>
       The definition of this Information Element is identical
       to the definition of Information Element
       'vlanId', except that it reports a
       potentially modified value caused by a middlebox
       function after the packet passed the Observation Point.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See IEEE.802-1Q.2003.
       </paragraph>
     </reference>
   </field>
   <field name="destinationMacAddress" dataType="macAddress"
          group="subIpHeader"
          dataTypeSemantics="identifier"
          elementId="80" applicability="data" status="current">
     <description>
       <paragraph>
         The IEEE 802 destination MAC address field.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See IEEE.802-3.2002.
       </paragraph>
     </reference>
   </field>

Quittek, et al. Standards Track [Page 122] RFC 5102 IPFIX Information Model January 2008

   <field name="postDestinationMacAddress" dataType="macAddress"
          group="subIpHeader"
          dataTypeSemantics="identifier"
          elementId="57" applicability="data" status="current">
     <description>
       <paragraph>
       The definition of this Information Element is identical
       to the definition of Information Element
       'destinationMacAddress', except that it reports a
       potentially modified value caused by a middlebox
       function after the packet passed the Observation Point.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See IEEE.802-3.2002.
       </paragraph>
     </reference>
   </field>
   <field name="wlanChannelId" dataType="unsigned8"
          group="subIpHeader"
          dataTypeSemantics="identifier"
          elementId="146" applicability="data" status="current">
     <description>
       <paragraph>
         The identifier of the 802.11 (Wi-Fi) channel used.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See IEEE.802-11.1999.
       </paragraph>
     </reference>
   </field>
   <field name="wlanSSID" dataType="string"
          group="subIpHeader"
          elementId="147" applicability="data" status="current">
     <description>
       <paragraph>
         The Service Set IDentifier (SSID) identifying an 802.11
         (Wi-Fi) network used.  According to IEEE.802-11.1999, the
         SSID is encoded into a string of up to 32 characters.
       </paragraph>
     </description>
     <reference>
       <paragraph>

Quittek, et al. Standards Track [Page 123] RFC 5102 IPFIX Information Model January 2008

       See IEEE.802-11.1999.
       </paragraph>
     </reference>
   </field>
   <field name="mplsTopLabelTTL" dataType="unsigned8"
          group="subIpHeader"
          elementId="200" applicability="all" status="current">
     <description>
       <paragraph>
       The TTL field from the top MPLS label stack entry,
       i.e., the last label that was pushed.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 3032 for the specification of the
       TTL field.
       </paragraph>
     </reference>
     <units>hops</units>
   </field>
   <field name="mplsTopLabelExp" dataType="unsigned8"
          group="subIpHeader"
          dataTypeSemantics="flags"
          elementId="203" applicability="all" status="current">
     <description>
       <paragraph>
       The Exp field from the top MPLS label stack entry,
       i.e., the last label that was pushed.
       </paragraph>
       <artwork>
       Bits 0-4:  Don't Care, value is irrelevant.
       Bits 5-7:  MPLS Exp field.
           0   1   2   3   4   5   6   7
         +---+---+---+---+---+---+---+---+
         |     don't care    |    Exp    |
         +---+---+---+---+---+---+---+---+
       </artwork>
     </description>
     <reference>
       <paragraph>
       See RFC 3032 for the specification of the Exp field.
       See RFC 3270 for usage of the Exp field.
       </paragraph>
     </reference>

Quittek, et al. Standards Track [Page 124] RFC 5102 IPFIX Information Model January 2008

   </field>
   <field name="postMplsTopLabelExp" dataType="unsigned8"
          group="subIpHeader"
          dataTypeSemantics="flags"
          elementId="237" applicability="all" status="current">
     <description>
       <paragraph>
       The definition of this Information Element is identical to the
       definition of Information Element 'mplsTopLabelExp', except
       that it reports a potentially modified value caused by a
       middlebox function after the packet passed the Observation
       Point.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 3032 for the specification of the Exp field.
       See RFC 3270 for usage of the Exp field.
       </paragraph>
     </reference>
   </field>
   <field name="mplsLabelStackDepth" dataType="unsigned32"
          group="subIpHeader"
          elementId="202" applicability="all" status="current">
     <description>
       <paragraph>
       The number of labels in the MPLS label stack.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 3032 for the specification of
       the MPLS label stack.
       </paragraph>
     </reference>
     <units>label stack entries</units>
   </field>
   <field name="mplsLabelStackLength" dataType="unsigned32"
          group="subIpHeader"
          elementId="201" applicability="all" status="current">
     <description>
       <paragraph>
       The length of the MPLS label stack in units of octets.
       </paragraph>
     </description>

Quittek, et al. Standards Track [Page 125] RFC 5102 IPFIX Information Model January 2008

     <reference>
       <paragraph>
       See RFC 3032 for the specification of
       the MPLS label stack.
       </paragraph>
     </reference>
     <units>octets</units>
   </field>
   <field name="mplsPayloadLength" dataType="unsigned32"
          group="subIpHeader"
          elementId="194" applicability="all" status="current">
     <description>
       <paragraph>
       The size of the MPLS packet without the label stack.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 3031 for the specification of
       MPLS packets.
       See RFC 3032 for the specification of
       the MPLS label stack.
       </paragraph>
     </reference>
     <units>octets</units>
   </field>
   <field name="mplsTopLabelStackSection" dataType="octetArray"
          group="subIpHeader"
          dataTypeSemantics="identifier"
          elementId="70" applicability="all" status="current">
     <description>
       <paragraph>
       The Label, Exp, and S fields from the top MPLS label
       stack entry, i.e., from the last label that was pushed.
       </paragraph>
       <paragraph>
       The size of this Information Element is 3 octets.
       </paragraph>
       <artwork>
     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

Quittek, et al. Standards Track [Page 126] RFC 5102 IPFIX Information Model January 2008

    Exp:    Experimental Use, 3 bits
    S:      Bottom of Stack, 1 bit
       </artwork>
     </description>
     <reference>
       <paragraph>
       See RFC 3032.
       </paragraph>
     </reference>
   </field>
   <field name="mplsLabelStackSection2" dataType="octetArray"
          group="subIpHeader"
          dataTypeSemantics="identifier"
          elementId="71" applicability="all" status="current">
     <description>
       <paragraph>
       The Label, Exp, and S fields from the label stack entry that
       was pushed immediately before the label stack entry that would
       be reported by mplsTopLabelStackSection.  See the definition of
       mplsTopLabelStackSection for further details.
       </paragraph>
       <paragraph>
       The size of this Information Element is 3 octets.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 3032.
       </paragraph>
     </reference>
   </field>
   <field name="mplsLabelStackSection3" dataType="octetArray"
          group="subIpHeader"
          dataTypeSemantics="identifier"
          elementId="72" applicability="all" status="current">
     <description>
       <paragraph>
       The Label, Exp, and S fields from the label stack entry that
       was pushed immediately before the label stack entry that would
       be reported by mplsLabelStackSection2.  See the definition of
       mplsTopLabelStackSection for further details.
       </paragraph>
       <paragraph>
       The size of this Information Element is 3 octets.
       </paragraph>
     </description>

Quittek, et al. Standards Track [Page 127] RFC 5102 IPFIX Information Model January 2008

     <reference>
       <paragraph>
       See RFC 3032.
       </paragraph>
     </reference>
   </field>
   <field name="mplsLabelStackSection4" dataType="octetArray"
          group="subIpHeader"
          dataTypeSemantics="identifier"
          elementId="73" applicability="all" status="current">
     <description>
       <paragraph>
       The Label, Exp, and S fields from the label stack entry that
       was pushed immediately before the label stack entry that would
       be reported by mplsLabelStackSection3.  See the definition of
       mplsTopLabelStackSection for further details.
       </paragraph>
       <paragraph>
       The size of this Information Element is 3 octets.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 3032.
       </paragraph>
     </reference>
   </field>
   <field name="mplsLabelStackSection5" dataType="octetArray"
          group="subIpHeader"
          dataTypeSemantics="identifier"
          elementId="74" applicability="all" status="current">
     <description>
       <paragraph>
       The Label, Exp, and S fields from the label stack entry that
       was pushed immediately before the label stack entry that would
       be reported by mplsLabelStackSection4.  See the definition of
       mplsTopLabelStackSection for further details.
       </paragraph>
       <paragraph>
       The size of this Information Element is 3 octets.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 3032.
       </paragraph>

Quittek, et al. Standards Track [Page 128] RFC 5102 IPFIX Information Model January 2008

     </reference>
   </field>
   <field name="mplsLabelStackSection6" dataType="octetArray"
          group="subIpHeader"
          dataTypeSemantics="identifier"
          elementId="75" applicability="all" status="current">
     <description>
       <paragraph>
       The Label, Exp, and S fields from the label stack entry that
       was pushed immediately before the label stack entry that would
       be reported by mplsLabelStackSection5.  See the definition of
       mplsTopLabelStackSection for further details.
       </paragraph>
       <paragraph>
       The size of this Information Element is 3 octets.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 3032.
       </paragraph>
     </reference>
   </field>
   <field name="mplsLabelStackSection7" dataType="octetArray"
          group="subIpHeader"
          dataTypeSemantics="identifier"
          elementId="76" applicability="all" status="current">
     <description>
       <paragraph>
       The Label, Exp, and S fields from the label stack entry that
       was pushed immediately before the label stack entry that would
       be reported by mplsLabelStackSection6.  See the definition of
       mplsTopLabelStackSection for further details.
       </paragraph>
       <paragraph>
       The size of this Information Element is 3 octets.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 3032.
       </paragraph>
     </reference>
   </field>
   <field name="mplsLabelStackSection8" dataType="octetArray"

Quittek, et al. Standards Track [Page 129] RFC 5102 IPFIX Information Model January 2008

          group="subIpHeader"
          dataTypeSemantics="identifier"
          elementId="77" applicability="all" status="current">
     <description>
       <paragraph>
       The Label, Exp, and S fields from the label stack entry that
       was pushed immediately before the label stack entry that would
       be reported by mplsLabelStackSection7.  See the definition of
       mplsTopLabelStackSection for further details.
       </paragraph>
       <paragraph>
       The size of this Information Element is 3 octets.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 3032.
       </paragraph>
     </reference>
   </field>
   <field name="mplsLabelStackSection9" dataType="octetArray"
          group="subIpHeader"
          dataTypeSemantics="identifier"
          elementId="78" applicability="all" status="current">
     <description>
       <paragraph>
       The Label, Exp, and S fields from the label stack entry that
       was pushed immediately before the label stack entry that would
       be reported by mplsLabelStackSection8.  See the definition of
       mplsTopLabelStackSection for further details.
       </paragraph>
       <paragraph>
       The size of this Information Element is 3 octets.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 3032.
       </paragraph>
     </reference>
   </field>
   <field name="mplsLabelStackSection10" dataType="octetArray"
          group="subIpHeader"
          dataTypeSemantics="identifier"
          elementId="79" applicability="all" status="current">
     <description>

Quittek, et al. Standards Track [Page 130] RFC 5102 IPFIX Information Model January 2008

       <paragraph>
       The Label, Exp, and S fields from the label stack entry that
       was pushed immediately before the label stack entry that would
       be reported by mplsLabelStackSection9.  See the definition of
       mplsTopLabelStackSection for further details.
       </paragraph>
       <paragraph>
       The size of this Information Element is 3 octets.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 3032.
       </paragraph>
     </reference>
   </field>
   <field name="ipPayloadLength" dataType="unsigned32"
          group="derived"
          elementId="204" applicability="all" status="current">
     <description>
       <paragraph>
       The effective length of the IP payload.
       </paragraph>
       <paragraph>
       For IPv4 packets, the value of this Information Element is
       the difference between the total length of the IPv4 packet
       (as reported by Information Element totalLengthIPv4) and the
       length of the IPv4 header (as reported by Information Element
       headerLengthIPv4).
       </paragraph>
       <paragraph>
       For IPv6, the value of the Payload Length field
       in the IPv6 header is reported except in the case that
       the value of this field is zero and that there is a valid
       jumbo payload option.  In this case, the value of the
       Jumbo Payload Length field in the jumbo payload option
       is reported.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 791 for the specification of
       IPv4 packets.
       See RFC 2460 for the specification of the
       IPv6 payload length.
       See RFC 2675 for the specification of the
       IPv6 jumbo payload length.

Quittek, et al. Standards Track [Page 131] RFC 5102 IPFIX Information Model January 2008

       </paragraph>
     </reference>
     <units>octets</units>
   </field>
   <field name="ipNextHopIPv4Address" dataType="ipv4Address"
          group="derived"
          dataTypeSemantics="identifier"
          elementId="15" applicability="data" status="current">
     <description>
       <paragraph>
       The IPv4 address of the next IPv4 hop.
       </paragraph>
     </description>
   </field>
   <field name="ipNextHopIPv6Address" dataType="ipv6Address"
          group="derived"
          dataTypeSemantics="identifier"
          elementId="62" applicability="data" status="current">
     <description>
       <paragraph>
       The IPv6 address of the next IPv6 hop.
       </paragraph>
     </description>
   </field>
   <field name="bgpSourceAsNumber" dataType="unsigned32"
          group="derived"
          dataTypeSemantics="identifier"
          elementId="16" applicability="all" status="current">
     <description>
       <paragraph>
       The autonomous system (AS) number of the source IP address.
       If AS path information for this Flow is only available as
       an unordered AS set (and not as an ordered AS sequence),
       then the value of this Information Element is 0.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 4271 for a description of BGP-4, and see RFC 1930
       for the definition of the AS number.
       </paragraph>
     </reference>
   </field>
   <field name="bgpDestinationAsNumber" dataType="unsigned32"

Quittek, et al. Standards Track [Page 132] RFC 5102 IPFIX Information Model January 2008

          group="derived"
          dataTypeSemantics="identifier"
          elementId="17" applicability="all" status="current">
     <description>
       <paragraph>
       The autonomous system (AS) number of the destination IP
       address.  If AS path information for this Flow is only
       available as an unordered AS set (and not as an ordered AS
       sequence), then the value of this Information Element is 0.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 4271 for a description of BGP-4, and see RFC 1930 for
          the definition of the AS number.
       </paragraph>
     </reference>
   </field>
   <field name="bgpNextAdjacentAsNumber" dataType="unsigned32"
          group="derived"
          dataTypeSemantics="identifier"
          elementId="128" applicability="all" status="current">
     <description>
       <paragraph>
       The autonomous system (AS) number of the first AS in the AS
       path to the destination IP address.  The path is deduced
       by looking up the destination IP address of the Flow in the
       BGP routing information base.  If AS path information for
       this Flow is only available as an unordered AS set (and not
       as an ordered AS sequence), then the value of this Information
       Element is 0.
     </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 4271 for a description of BGP-4, and
       see RFC 1930 for the definition of the AS number.
       </paragraph>
     </reference>
   </field>
   <field name="bgpPrevAdjacentAsNumber" dataType="unsigned32"
          group="derived"
          dataTypeSemantics="identifier"
          elementId="129" applicability="all" status="current">
     <description>
       <paragraph>

Quittek, et al. Standards Track [Page 133] RFC 5102 IPFIX Information Model January 2008

       The autonomous system (AS) number of the last AS in the AS
       path from the source IP address.  The path is deduced
       by looking up the source IP address of the Flow in the BGP
       routing information base.  If AS path information for this
       Flow is only available as an unordered AS set (and not as
       an ordered AS sequence), then the value of this Information
       Element is 0.  In case of BGP asymmetry, the
       bgpPrevAdjacentAsNumber might not be able to report the correct
       value.
     </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 4271 for a description of BGP-4, and
       see RFC 1930 for the definition of the AS number.
       </paragraph>
     </reference>
   </field>
   <field name="bgpNextHopIPv4Address" dataType="ipv4Address"
          group="derived"
          dataTypeSemantics="identifier"
          elementId="18" applicability="all" status="current">
     <description>
       <paragraph>
       The IPv4 address of the next (adjacent) BGP hop.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 4271 for a description of BGP-4.
       </paragraph>
     </reference>
   </field>
   <field name="bgpNextHopIPv6Address" dataType="ipv6Address"
          group="derived"
          dataTypeSemantics="identifier"
          elementId="63" applicability="all" status="current">
     <description>
       <paragraph>
       The IPv6 address of the next (adjacent) BGP hop.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 4271 for a description of BGP-4.
       </paragraph>

Quittek, et al. Standards Track [Page 134] RFC 5102 IPFIX Information Model January 2008

     </reference>
   </field>
   <field name="mplsTopLabelType" dataType="unsigned8"
          group="derived"
          dataTypeSemantics="identifier"
          elementId="46" applicability="data" status="current">
     <description>
       <paragraph>
       This field identifies the control protocol that allocated the
       top-of-stack label.  Initial values for this field are
       listed below.  Further values may be assigned by IANA in
       the MPLS label type registry.
       </paragraph>
       <artwork>
      - 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
       </artwork>
     </description>
     <reference>
       <paragraph>
       See RFC 3031 for the MPLS label structure.
       See RFC 4364 for the association of MPLS labels
       with Virtual Private Networks (VPNs).
       See RFC 4271 for BGP and BGP routing.
       See RFC 5036 for Label Distribution Protocol (LDP).
       See the list of MPLS label types assigned by IANA at
       http://www.iana.org/assignments/mpls-label-values.
       </paragraph>
     </reference>
   </field>
   <field name="mplsTopLabelIPv4Address" dataType="ipv4Address"
          group="derived"
          dataTypeSemantics="identifier"
          elementId="47" applicability="data" status="current">
     <description>
       <paragraph>
         The IPv4 address of the system that the MPLS top label will
         cause this Flow to be forwarded to.
       </paragraph>
     </description>
     <reference>
       <paragraph>

Quittek, et al. Standards Track [Page 135] RFC 5102 IPFIX Information Model January 2008

       See RFC 3031 for the association between
       MPLS labels and IP addresses.
       </paragraph>
     </reference>
   </field>
   <field name="mplsTopLabelIPv6Address" dataType="ipv6Address"
          group="derived"
          dataTypeSemantics="identifier"
          elementId="140" applicability="data" status="current">
     <description>
       <paragraph>
         The IPv6 address of the system that the MPLS top label will
         cause this Flow to be forwarded to.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 3031 for the association between
       MPLS labels and IP addresses.
       </paragraph>
     </reference>
   </field>
   <field name="mplsVpnRouteDistinguisher" dataType="octetArray"
          group="derived"
          dataTypeSemantics="identifier"
          elementId="90" applicability="all" status="current">
     <description>
       <paragraph>
       The value of the VPN route distinguisher of a corresponding
       entry in a VPN routing and forwarding table.  Route
       distinguisher ensures that the same address can be used in
       several different MPLS VPNs and that it is possible for BGP to
       carry several completely different routes to that address, one
       for each VPN.  According to RFC 4364, the size of
       mplsVpnRouteDistinguisher is 8 octets.  However, in RFC 4382 an
       octet string with flexible length was chosen for representing a
       VPN route distinguisher by object MplsL3VpnRouteDistinguisher.
       This choice was made in order to be open to future changes of
       the size.  This idea was adopted when choosing octetArray as
       abstract data type for this Information Element.  The maximum
       length of this Information Element is 256 octets.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 4364 for the specification of the route

Quittek, et al. Standards Track [Page 136] RFC 5102 IPFIX Information Model January 2008

       distinguisher.  See RFC 4382 for the specification
       of the MPLS/BGP Layer 3 Virtual Private Network (VPN)
       Management Information Base.
       </paragraph>
     </reference>
   </field>
   <field name="minimumIpTotalLength" dataType="unsigned64"
          group="minMax"
          elementId="25" applicability="all" status="current">
     <description>
       <paragraph>
       Length of the smallest packet observed for this Flow.
       The packet length includes the IP header(s) length and
       the IP payload length.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 791 for the specification of the
       IPv4 total length.
       See RFC 2460 for the specification of the
       IPv6 payload length.
       See RFC 2675 for the specification of the
       IPv6 jumbo payload length.
       </paragraph>
     </reference>
     <units>octets</units>
   </field>
   <field name="maximumIpTotalLength" dataType="unsigned64"
          group="minMax"
          elementId="26" applicability="all" status="current">
     <description>
       <paragraph>
       Length of the largest packet observed for this Flow.
       The packet length includes the IP header(s) length and
       the IP payload length.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 791 for the specification of the
       IPv4 total length.
       See RFC 2460 for the specification of the
       IPv6 payload length.
       See RFC 2675 for the specification of the
       IPv6 jumbo payload length.

Quittek, et al. Standards Track [Page 137] RFC 5102 IPFIX Information Model January 2008

       </paragraph>
     </reference>
     <units>octets</units>
   </field>
   <field name="minimumTTL" dataType="unsigned8"
          group="minMax"
          elementId="52" applicability="data" status="current">
     <description>
       <paragraph>
         Minimum TTL value observed for any packet in this Flow.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 791 for the definition of the IPv4
       Time to Live field.
       See RFC 2460 for the definition of the IPv6
       Hop Limit field.
       </paragraph>
     </reference>
     <units>hops</units>
   </field>
   <field name="maximumTTL" dataType="unsigned8"
          group="minMax"
          elementId="53" applicability="data" status="current">
     <description>
       <paragraph>
         Maximum TTL value observed for any packet in this Flow.
       </paragraph>
     </description>
     <reference>
      <paragraph>
      See RFC 791 for the definition of the IPv4
      Time to Live field.
      See RFC 2460 for the definition of the IPv6
      Hop Limit field.
      </paragraph>
     </reference>
     <units>hops</units>
   </field>
   <field name="ipv4Options" dataType="unsigned32"
          dataTypeSemantics="flags"
          group="minMax"
          elementId="208" applicability="all" status="current">
     <description>

Quittek, et al. Standards Track [Page 138] RFC 5102 IPFIX Information Model January 2008

       <paragraph>
       IPv4 options in packets of this Flow.
       The information is encoded in a set of bit fields.  For
       each valid IPv4 option type, there is a bit in this set.
       The bit is set to 1 if any observed packet of this Flow
       contains the corresponding IPv4 option type.  Otherwise,
       if no observed packet of this Flow contained the
       respective IPv4 option type, the value of the
       corresponding bit is 0.
       </paragraph>
       <paragraph>
       The list of valid IPv4 options is maintained by IANA.
       Note that for identifying an option not just the 5-bit
       Option Number, but all 8 bits of the Option Type need to
       match one of the IPv4 options specified at
       http://www.iana.org/assignments/ip-parameters.
       </paragraph>
       <paragraph>
       Options are mapped to bits according to their option numbers.
       Option number X is mapped to bit X.
       The mapping is illustrated by the figure below.
       </paragraph>
       <artwork>
         0      1      2      3      4      5      6      7
     +------+------+------+------+------+------+------+------+
     | EOOL | NOP  | SEC  | LSR  |  TS  |E-SEC |CIPSO |  RR  | ...
     +------+------+------+------+------+------+------+------+
         8      9     10     11     12     13     14     15
     +------+------+------+------+------+------+------+------+
 ... | SID  | SSR  | ZSU  | MTUP | MTUR | FINN | VISA |ENCODE| ...
     +------+------+------+------+------+------+------+------+
        16     17     18     19     20     21     22     23
     +------+------+------+------+------+------+------+------+
 ... |IMITD | EIP  |  TR  |ADDEXT|RTRALT| SDB  |NSAPA | DPS  | ...
     +------+------+------+------+------+------+------+------+
        24     25     26     27     28     29     30     31
     +------+------+------+------+------+------+------+------+
 ... | UMP  |  QS  |   to be assigned by IANA  | EXP  |      |
     +------+------+------+------+------+------+------+------+
         Type   Option
     Bit Value  Name    Reference
     ---+-----+-------+------------------------------------
      0     0   EOOL    End of Options List, RFC 791
      1     1   NOP     No Operation, RFC 791

Quittek, et al. Standards Track [Page 139] RFC 5102 IPFIX Information Model January 2008

      2   130   SEC     Security, RFC 1108
      3   131   LSR     Loose Source Route, RFC 791
      4    68   TS      Time Stamp, RFC 791
      5   133   E-SEC   Extended Security, RFC 1108
      6   134   CIPSO   Commercial Security
      7     7   RR      Record Route, RFC 791
      8   136   SID     Stream ID, RFC 791
      9   137   SSR     Strict Source Route, RFC 791
     10    10   ZSU     Experimental Measurement
     11    11   MTUP    (obsoleted) MTU Probe, RFC 1191
     12    12   MTUR    (obsoleted) MTU Reply, RFC 1191
     13   205   FINN    Experimental Flow Control
     14   142   VISA    Experimental Access Control
     15    15   ENCODE
     16   144   IMITD   IMI Traffic Descriptor
     17   145   EIP     Extended Internet Protocol, RFC 1385
     18    82   TR      Traceroute, RFC 3193
     19   147   ADDEXT  Address Extension
     20   148   RTRALT  Router Alert, RFC 2113
     21   149   SDB     Selective Directed Broadcast
     22   150   NSAPA   NSAP Address
     23   151   DPS     Dynamic Packet State
     24   152   UMP     Upstream Multicast Pkt.
     25    25   QS      Quick-Start
     30    30   EXP     RFC3692-style Experiment
     30    94   EXP     RFC3692-style Experiment
     30   158   EXP     RFC3692-style Experiment
     30   222   EXP     RFC3692-style Experiment
     ...  ...   ...     Further options numbers
                        may be assigned by IANA
       </artwork>
     </description>
     <reference>
       <paragraph>
       See RFC 791 for the definition of IPv4 options.
       See the list of IPv4 option numbers assigned by IANA
       at http://www.iana.org/assignments/ip-parameters.
       </paragraph>
     </reference>
   </field>
   <field name="ipv6ExtensionHeaders" dataType="unsigned32"
          dataTypeSemantics="flags"
          group="minMax"
          elementId="64" applicability="all" status="current">
     <description>
       <paragraph>

Quittek, et al. Standards Track [Page 140] RFC 5102 IPFIX Information Model January 2008

       IPv6 extension headers observed in packets of this Flow.
       The information is encoded in a set of bit fields.  For
       each IPv6 option header, there is a bit in this set.
       The bit is set to 1 if any observed packet of this Flow
       contains the corresponding IPv6 extension header.
       Otherwise, if no observed packet of this Flow contained
       the respective IPv6 extension header, the value of the
       corresponding bit is 0.
       </paragraph>
       <artwork>
            0     1     2     3     4     5     6     7
        +-----+-----+-----+-----+-----+-----+-----+-----+
        | Res | FRA1| RH  | FRA0| UNK | Res | HOP | DST |  ...
        +-----+-----+-----+-----+-----+-----+-----+-----+
            8     9    10    11    12    13    14    15
        +-----+-----+-----+-----+-----+-----+-----+-----+
    ... | PAY | AH  | ESP |         Reserved            | ...
        +-----+-----+-----+-----+-----+-----+-----+-----+
           16    17    18    19    20    21    22    23
        +-----+-----+-----+-----+-----+-----+-----+-----+
    ... |                  Reserved                     | ...
        +-----+-----+-----+-----+-----+-----+-----+-----+
           24    25    26    27    28    29    30    31
        +-----+-----+-----+-----+-----+-----+-----+-----+
    ... |                  Reserved                     |
        +-----+-----+-----+-----+-----+-----+-----+-----+
      Bit    IPv6 Option   Description
     0, Res               Reserved
     1, FRA1     44       Fragmentation header - not first fragment
     2, RH       43       Routing header
     3, FRA0     44       Fragment header - first fragment
     4, UNK               Unknown Layer 4 header
                          (compressed, encrypted, not supported)
     5, Res               Reserved
     6, HOP       0       Hop-by-hop option header
     7, DST      60       Destination option header
     8, PAY     108       Payload compression header
     9, AH       51       Authentication Header
    10, ESP      50       Encrypted security payload
    11 to 31              Reserved
       </artwork>
     </description>
     <reference>
       <paragraph>
       See RFC 2460 for the general definition of

Quittek, et al. Standards Track [Page 141] RFC 5102 IPFIX Information Model January 2008

       IPv6 extension headers and for the specification of
       the hop-by-hop options header, the routing header,
       the fragment header, and the destination options header.
       See RFC 4302 for the specification of the
       authentication header.
       See RFC 4303 for the specification of the
       encapsulating security payload.
       </paragraph>
     </reference>
   </field>
   <field name="tcpControlBits" dataType="unsigned8"
          dataTypeSemantics="flags"
          group="minMax"
          elementId="6" applicability="all" status="current">
     <description>
       <paragraph>
       TCP control bits observed for packets of this Flow.
       The information is encoded in a set of bit fields.
       For each TCP control bit, there is a bit in this
       set.  A bit is set to 1 if any observed packet of this
       Flow has the corresponding TCP control bit set to 1.
       A value of 0 for a bit indicates that the corresponding
       bit was not set in any of the observed packets
       of this Flow.
       </paragraph>
       <artwork>
        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
       </artwork>
     </description>
     <reference>
       <paragraph>
       See RFC 793 for the definition of
       the TCP control bits in the TCP header.
       </paragraph>
     </reference>
   </field>

Quittek, et al. Standards Track [Page 142] RFC 5102 IPFIX Information Model January 2008

   <field name="tcpOptions" dataType="unsigned64"
          dataTypeSemantics="flags"
          group="minMax"
          elementId="209" applicability="all" status="current">
     <description>
       <paragraph>
      TCP options in packets of this Flow.
      The information is encoded in a set of bit fields.  For
      each TCP option, there is a bit in this set.
      The bit is set to 1 if any observed packet of this Flow
      contains the corresponding TCP option.
      Otherwise, if no observed packet of this Flow contained
      the respective TCP option, the value of the
      corresponding bit is 0.
       </paragraph>
       <paragraph>
       Options are mapped to bits according to their option
       numbers.  Option number X is mapped to bit X.
       TCP option numbers are maintained by IANA.
       </paragraph>
       <artwork>
            0     1     2     3     4     5     6     7
        +-----+-----+-----+-----+-----+-----+-----+-----+
        |   0 |   1 |   2 |   3 |   4 |   5 |   6 |   7 |  ...
        +-----+-----+-----+-----+-----+-----+-----+-----+
            8     9    10    11    12    13    14    15
        +-----+-----+-----+-----+-----+-----+-----+-----+
    ... |   8 |   9 |  10 |  11 |  12 |  13 |  14 |  15 |...
        +-----+-----+-----+-----+-----+-----+-----+-----+
           16    17    18    19    20    21    22    23
        +-----+-----+-----+-----+-----+-----+-----+-----+
    ... |  16 |  17 |  18 |  19 |  20 |  21 |  22 |  23 |...
        +-----+-----+-----+-----+-----+-----+-----+-----+
                              . . .
           56    57    58    59    60    61    62    63
        +-----+-----+-----+-----+-----+-----+-----+-----+
    ... |  56 |  57 |  58 |  59 |  60 |  61 |  62 |  63 |
        +-----+-----+-----+-----+-----+-----+-----+-----+
       </artwork>
     </description>
     <reference>
       <paragraph>
       See RFC 793 for the definition of TCP options.
       See the list of TCP option numbers assigned by IANA

Quittek, et al. Standards Track [Page 143] RFC 5102 IPFIX Information Model January 2008

       at http://www.iana.org/assignments/tcp-parameters.
       </paragraph>
     </reference>
   </field>
   <field name="flowStartSeconds" dataType="dateTimeSeconds"
          group="timestamp"
          elementId="150" applicability="data" status="current">
     <description>
       <paragraph>
       The absolute timestamp of the first packet of this Flow.
       </paragraph>
     </description>
     <units>seconds</units>
   </field>
   <field name="flowEndSeconds" dataType="dateTimeSeconds"
          group="timestamp"
          elementId="151" applicability="data" status="current">
     <description>
       <paragraph>
       The absolute timestamp of the last packet of this Flow.
       </paragraph>
     </description>
     <units>seconds</units>
   </field>
   <field name="flowStartMilliseconds" dataType="dateTimeMilliseconds"
          group="timestamp"
          elementId="152" applicability="data" status="current">
     <description>
       <paragraph>
       The absolute timestamp of the first packet of this Flow.
       </paragraph>
     </description>
     <units>milliseconds</units>
   </field>
   <field name="flowEndMilliseconds" dataType="dateTimeMilliseconds"
          group="timestamp"
          elementId="153" applicability="data" status="current">
     <description>
       <paragraph>
       The absolute timestamp of the last packet of this Flow.
       </paragraph>
     </description>
     <units>milliseconds</units>
   </field>

Quittek, et al. Standards Track [Page 144] RFC 5102 IPFIX Information Model January 2008

   <field name="flowStartMicroseconds" dataType="dateTimeMicroseconds"
          group="timestamp"
          elementId="154" applicability="data" status="current">
     <description>
       <paragraph>
       The absolute timestamp of the first packet of this Flow.
       </paragraph>
     </description>
     <units>microseconds</units>
   </field>
   <field name="flowEndMicroseconds" dataType="dateTimeMicroseconds"
          group="timestamp"
          elementId="155" applicability="data" status="current">
     <description>
       <paragraph>
       The absolute timestamp of the last packet of this Flow.
       </paragraph>
     </description>
     <units>microseconds</units>
   </field>
   <field name="flowStartNanoseconds" dataType="dateTimeNanoseconds"
          group="timestamp"
          elementId="156" applicability="data" status="current">
     <description>
       <paragraph>
       The absolute timestamp of the first packet of this Flow.
       </paragraph>
     </description>
     <units>nanoseconds</units>
   </field>
   <field name="flowEndNanoseconds" dataType="dateTimeNanoseconds"
          group="timestamp"
          elementId="157" applicability="data" status="current">
     <description>
       <paragraph>
       The absolute timestamp of the last packet of this Flow.
       </paragraph>
     </description>
     <units>nanoseconds</units>
   </field>
   <field name="flowStartDeltaMicroseconds" dataType="unsigned32"
          group="timestamp"
          elementId="158" applicability="data" status="current">
     <description>

Quittek, et al. Standards Track [Page 145] RFC 5102 IPFIX Information Model January 2008

       <paragraph>
       This is a relative timestamp only valid within the scope
       of a single IPFIX Message.  It contains the negative time
       offset of the first observed packet of this Flow relative
       to the export time specified in the IPFIX Message Header.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See the IPFIX protocol specification [RFC5101] for the
       definition of the IPFIX Message Header.
       </paragraph>
     </reference>
     <units>microseconds</units>
   </field>
   <field name="flowEndDeltaMicroseconds" dataType="unsigned32"
          group="timestamp"
          elementId="159" applicability="data" status="current">
     <description>
       <paragraph>
       This is a relative timestamp only valid within the scope
       of a single IPFIX Message.  It contains the negative time
       offset of the last observed packet of this Flow relative
       to the export time specified in the IPFIX Message Header.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See the IPFIX protocol specification [RFC5101] for the
       definition of the IPFIX Message Header.
       </paragraph>
     </reference>
     <units>microseconds</units>
   </field>
   <field name="systemInitTimeMilliseconds"
          dataType="dateTimeMilliseconds"
          group="timestamp"
          elementId="160" applicability="data" status="current">
     <description>
       <paragraph>
       The absolute timestamp of the last (re-)initialization of the
       IPFIX Device.
       </paragraph>
     </description>
     <units>milliseconds</units>
   </field>

Quittek, et al. Standards Track [Page 146] RFC 5102 IPFIX Information Model January 2008

   <field name="flowStartSysUpTime" dataType="unsigned32"
          group="timestamp"
          elementId="22" applicability="data" status="current">
     <description>
       <paragraph>
       The relative timestamp of the first packet of this Flow.
       It indicates the number of milliseconds since the
       last (re-)initialization of the IPFIX Device (sysUpTime).
       </paragraph>
     </description>
     <units>milliseconds</units>
   </field>
   <field name="flowEndSysUpTime" dataType="unsigned32"
          group="timestamp"
          elementId="21" applicability="data" status="current">
     <description>
       <paragraph>
       The relative timestamp of the last packet of this Flow.
       It indicates the number of milliseconds since the
       last (re-)initialization of the IPFIX Device (sysUpTime).
       </paragraph>
     </description>
     <units>milliseconds</units>
   </field>
   <field name="octetDeltaCount" dataType="unsigned64"
          dataTypeSemantics="deltaCounter"
          group="flowCounter"
          elementId="1" applicability="data" status="current">
     <description>
       <paragraph>
       The number of octets since the previous report (if any)
       in incoming packets for this Flow at the Observation Point.
       The number of octets includes IP header(s) and IP payload.
       </paragraph>
     </description>
     <units>octets</units>
   </field>
   <field name="postOctetDeltaCount" dataType="unsigned64"
          dataTypeSemantics="deltaCounter"
          group="flowCounter"
          elementId="23" applicability="data" status="current">
     <description>
       <paragraph>
       The definition of this Information Element is identical
       to the definition of Information Element

Quittek, et al. Standards Track [Page 147] RFC 5102 IPFIX Information Model January 2008

       'octetDeltaCount', except that it reports a
       potentially modified value caused by a middlebox
       function after the packet passed the Observation Point.
       </paragraph>
     </description>
     <units>octets</units>
   </field>
   <field name="octetDeltaSumOfSquares" dataType="unsigned64"
          group="flowCounter"
          elementId="198" applicability="data" status="current">
     <description>
       <paragraph>
       The sum of the squared numbers of octets per incoming
       packet since the previous report (if any) for this
       Flow at the Observation Point.
       The number of octets includes IP header(s) and IP payload.
       </paragraph>
     </description>
   </field>
   <field name="octetTotalCount" dataType="unsigned64"
          dataTypeSemantics="totalCounter"
          group="flowCounter"
          elementId="85" applicability="all" status="current">
     <description>
       <paragraph>
       The total number of octets in incoming packets
       for this Flow at the Observation Point since the Metering
       Process (re-)initialization for this Observation Point.  The
       number of octets includes IP header(s) and IP payload.
       </paragraph>
     </description>
     <units>octets</units>
   </field>
   <field name="postOctetTotalCount" dataType="unsigned64"
          dataTypeSemantics="totalCounter"
          group="flowCounter"
          elementId="171" applicability="all" status="current">
     <description>
       <paragraph>
       The definition of this Information Element is identical
       to the definition of Information Element
       'octetTotalCount', except that it reports a
       potentially modified value caused by a middlebox
       function after the packet passed the Observation Point.
       </paragraph>

Quittek, et al. Standards Track [Page 148] RFC 5102 IPFIX Information Model January 2008

     </description>
     <units>octets</units>
   </field>
   <field name="octetTotalSumOfSquares" dataType="unsigned64"
          group="flowCounter"
          elementId="199" applicability="all" status="current">
     <description>
       <paragraph>
       The total sum of the squared numbers of octets in incoming
       packets for this Flow at the Observation Point since the
       Metering Process (re-)initialization for this Observation
       Point.  The number of octets includes IP header(s) and IP
       payload.
       </paragraph>
     </description>
     <units>octets</units>
   </field>
   <field name="packetDeltaCount" dataType="unsigned64"
          dataTypeSemantics="deltaCounter"
          group="flowCounter"
          elementId="2" applicability="data" status="current">
     <description>
       <paragraph>
       The number of incoming packets since the previous report
       (if any) for this Flow at the Observation Point.
       </paragraph>
     </description>
     <units>packets</units>
   </field>
   <field name="postPacketDeltaCount" dataType="unsigned64"
          dataTypeSemantics="deltaCounter"
          group="flowCounter"
          elementId="24" applicability="data" status="current">
     <description>
       <paragraph>
       The definition of this Information Element is identical
       to the definition of Information Element
       'packetDeltaCount', except that it reports a
       potentially modified value caused by a middlebox
       function after the packet passed the Observation Point.
       </paragraph>
     </description>
     <units>packets</units>
   </field>

Quittek, et al. Standards Track [Page 149] RFC 5102 IPFIX Information Model January 2008

   <field name="packetTotalCount" dataType="unsigned64"
          dataTypeSemantics="totalCounter"
          group="flowCounter"
          elementId="86" applicability="all" status="current">
     <description>
       <paragraph>
       The total number of incoming packets for this Flow
       at the Observation Point since the Metering Process
       (re-)initialization for this Observation Point.
       </paragraph>
     </description>
     <units>packets</units>
   </field>
   <field name="postPacketTotalCount" dataType="unsigned64"
          dataTypeSemantics="totalCounter"
          group="flowCounter"
          elementId="172" applicability="all" status="current">
     <description>
       <paragraph>
       The definition of this Information Element is identical
       to the definition of Information Element
       'packetTotalCount', except that it reports a
       potentially modified value caused by a middlebox
       function after the packet passed the Observation Point.
       </paragraph>
     </description>
     <units>packets</units>
   </field>
   <field name="droppedOctetDeltaCount" dataType="unsigned64"
          dataTypeSemantics="deltaCounter"
          group="flowCounter"
          elementId="132" applicability="data" status="current">
     <description>
       <paragraph>
       The number of octets since the previous report (if any)
       in packets of this Flow dropped by packet treatment.
       The number of octets includes IP header(s) and IP payload.
       </paragraph>
     </description>
     <units>octets</units>
   </field>
   <field name="droppedPacketDeltaCount" dataType="unsigned64"
          dataTypeSemantics="deltaCounter"
          group="flowCounter"
          elementId="133" applicability="data" status="current">

Quittek, et al. Standards Track [Page 150] RFC 5102 IPFIX Information Model January 2008

     <description>
       <paragraph>
       The number of packets since the previous report (if any)
       of this Flow dropped by packet treatment.
       </paragraph>
     </description>
     <units>packets</units>
   </field>
   <field name="droppedOctetTotalCount" dataType="unsigned64"
          dataTypeSemantics="totalCounter"
          group="flowCounter"
          elementId="134" applicability="data" status="current">
     <description>
       <paragraph>
       The total number of octets in packets of this Flow dropped
       by packet treatment since the Metering Process
       (re-)initialization for this Observation Point.
       The number of octets includes IP header(s) and IP payload.
       </paragraph>
     </description>
     <units>octets</units>
   </field>
   <field name="droppedPacketTotalCount" dataType="unsigned64"
          dataTypeSemantics="totalCounter"
          group="flowCounter"
          elementId="135" applicability="data" status="current">
     <description>
       <paragraph>
       The number of packets of this Flow dropped by packet
       treatment since the Metering Process
       (re-)initialization for this Observation Point.
       </paragraph>
     </description>
     <units>packets</units>
   </field>
   <field name="postMCastPacketDeltaCount" dataType="unsigned64"
          dataTypeSemantics="deltaCounter"
          group="flowCounter"
          elementId="19" applicability="data" status="current">
     <description>
       <paragraph>
       The number of outgoing multicast packets since the
       previous report (if any) sent for packets of this Flow
       by a multicast daemon within the Observation Domain.
       This property cannot necessarily be observed at the

Quittek, et al. Standards Track [Page 151] RFC 5102 IPFIX Information Model January 2008

       Observation Point, but may be retrieved by other means.
       </paragraph>
     </description>
     <units>packets</units>
   </field>
   <field name="postMCastOctetDeltaCount" dataType="unsigned64"
          dataTypeSemantics="deltaCounter"
          group="flowCounter"
          elementId="20" applicability="data" status="current">
     <description>
       <paragraph>
       The number of octets since the previous report (if any)
       in outgoing multicast packets sent for packets of this
       Flow by a multicast daemon within the Observation Domain.
       This property cannot necessarily be observed at the
       Observation Point, but may be retrieved by other means.
       The number of octets includes IP header(s) and IP payload.
       </paragraph>
     </description>
     <units>octets</units>
   </field>
   <field name="postMCastPacketTotalCount" dataType="unsigned64"
          dataTypeSemantics="totalCounter"
          group="flowCounter"
          elementId="174" applicability="data" status="current">
     <description>
       <paragraph>
       The total number of outgoing multicast packets sent for
       packets of this Flow by a multicast daemon within the
       Observation Domain since the Metering Process
       (re-)initialization.  This property cannot necessarily
       be observed at the Observation Point, but may be retrieved
       by other means.
       </paragraph>
     </description>
     <units>packets</units>
   </field>
   <field name="postMCastOctetTotalCount" dataType="unsigned64"
          dataTypeSemantics="totalCounter"
          group="flowCounter"
          elementId="175" applicability="data" status="current">
     <description>
       <paragraph>
       The total number of octets in outgoing multicast packets
       sent for packets of this Flow by a multicast daemon in the

Quittek, et al. Standards Track [Page 152] RFC 5102 IPFIX Information Model January 2008

       Observation Domain since the Metering Process
       (re-)initialization.  This property cannot necessarily be
       observed at the Observation Point, but may be retrieved by
       other means.
       The number of octets includes IP header(s) and IP payload.
       </paragraph>
     </description>
     <units>octets</units>
   </field>
   <field name="tcpSynTotalCount" dataType="unsigned64"
          dataTypeSemantics="totalCounter"
          group="flowCounter"
          elementId="218" applicability="data" status="current">
     <description>
       <paragraph>
        The total number of packets of this Flow with
        TCP "Synchronize sequence numbers" (SYN) flag set.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 793 for the definition of the TCP SYN flag.
       </paragraph>
     </reference>
     <units>packets</units>
   </field>
   <field name="tcpFinTotalCount" dataType="unsigned64"
          dataTypeSemantics="totalCounter"
          group="flowCounter"
          elementId="219" applicability="data" status="current">
     <description>
       <paragraph>
        The total number of packets of this Flow with
        TCP "No more data from sender" (FIN) flag set.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 793 for the definition of the TCP FIN flag.
       </paragraph>
     </reference>
     <units>packets</units>
   </field>
   <field name="tcpRstTotalCount" dataType="unsigned64"
          dataTypeSemantics="totalCounter"

Quittek, et al. Standards Track [Page 153] RFC 5102 IPFIX Information Model January 2008

          group="flowCounter"
          elementId="220" applicability="data" status="current">
     <description>
       <paragraph>
        The total number of packets of this Flow with
        TCP "Reset the connection" (RST) flag set.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 793 for the definition of the TCP RST flag.
       </paragraph>
     </reference>
     <units>packets</units>
   </field>
   <field name="tcpPshTotalCount" dataType="unsigned64"
          dataTypeSemantics="totalCounter"
          group="flowCounter"
          elementId="221" applicability="data" status="current">
     <description>
       <paragraph>
        The total number of packets of this Flow with
        TCP "Push Function" (PSH) flag set.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 793 for the definition of the TCP PSH flag.
       </paragraph>
     </reference>
     <units>packets</units>
   </field>
   <field name="tcpAckTotalCount" dataType="unsigned64"
          dataTypeSemantics="totalCounter"
          group="flowCounter"
          elementId="222" applicability="data" status="current">
     <description>
       <paragraph>
        The total number of packets of this Flow with
        TCP "Acknowledgment field significant" (ACK) flag set.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 793 for the definition of the TCP ACK flag.
       </paragraph>

Quittek, et al. Standards Track [Page 154] RFC 5102 IPFIX Information Model January 2008

     </reference>
     <units>packets</units>
   </field>
   <field name="tcpUrgTotalCount" dataType="unsigned64"
          dataTypeSemantics="totalCounter"
          group="flowCounter"
          elementId="223" applicability="data" status="current">
     <description>
       <paragraph>
        The total number of packets of this Flow with
        TCP "Urgent Pointer field significant" (URG) flag set.
       </paragraph>
     </description>
     <reference>
       <paragraph>
       See RFC 793 for the definition of the TCP URG flag.
       </paragraph>
     </reference>
     <units>packets</units>
   </field>
   <field name="flowActiveTimeout" dataType="unsigned16"
          group="misc"
          elementId="36" applicability="all" status="current">
     <description>
       <paragraph>
       The number of seconds after which an active Flow is timed out
       anyway, even if there is still a continuous flow of packets.
       </paragraph>
     </description>
     <units>seconds</units>
   </field>
   <field name="flowIdleTimeout" dataType="unsigned16"
          group="misc"
          elementId="37" applicability="all" status="current">
     <description>
       <paragraph>
        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.
       </paragraph>
     </description>
     <units>seconds</units>
   </field>
   <field name="flowEndReason" dataType="unsigned8"

Quittek, et al. Standards Track [Page 155] RFC 5102 IPFIX Information Model January 2008

          group="misc"
          dataTypeSemantics="identifier"
          elementId="136" applicability="data" status="current">
     <description>
       <paragraph>
       The reason for Flow termination.  The range of values includes
       the following:
       </paragraph>
       <artwork>
    0x01: idle timeout
          The Flow was terminated because it was considered to be
          idle.
    0x02: active timeout
          The Flow was terminated for reporting purposes while it was
          still active, for example, after the maximum lifetime of
          unreported Flows was reached.
    0x03: end of Flow detected
          The Flow was terminated because the Metering Process
          detected signals indicating the end of the Flow,
          for example, the TCP FIN flag.
    0x04: forced end
          The Flow was terminated because of some external event,
          for example, a shutdown of the Metering Process initiated
          by a network management application.
    0x05: lack of resources
          The Flow was terminated because of lack of resources
          available to the Metering Process and/or the Exporting
          Process.
       </artwork>
     </description>
   </field>
   <field name="flowDurationMilliseconds" dataType="unsigned32"
          group="misc"
          elementId="161" applicability="data" status="current">
     <description>
       <paragraph>
       The difference in time between the first observed packet
       of this Flow and the last observed packet of this Flow.
       </paragraph>
     </description>
     <units>milliseconds</units>
   </field>
   <field name="flowDurationMicroseconds" dataType="unsigned32"
          group="misc"
          elementId="162" applicability="data" status="current">
     <description>

Quittek, et al. Standards Track [Page 156] RFC 5102 IPFIX Information Model January 2008

       <paragraph>
       The difference in time between the first observed packet
       of this Flow and the last observed packet of this Flow.
       </paragraph>
     </description>
     <units>microseconds</units>
   </field>
   <field name="flowDirection" dataType="unsigned8"
          dataTypeSemantics="identifier"
          group="misc"
          elementId="61" applicability="data" status="current">
     <description>
       <paragraph>
       The direction of the Flow observed at the Observation
       Point.  There are only two values defined.
       </paragraph>
       <artwork>
       0x00: ingress flow
       0x01: egress flow
       </artwork>
     </description>
   </field>
   <field name="paddingOctets" dataType="octetArray"
          group="padding"
          elementId="210" applicability="option" status="current">
     <description>
       <paragraph>
         The value of this Information Element is always a sequence of
         0x00 values.
       </paragraph>
     </description>
   </field>
 </fieldDefinitions>

Appendix B. XML Specification of Abstract Data Types

 This appendix contains a machine-readable description of the abstract
 data types to be used for IPFIX Information Elements and a machine-
 readable description of the template used for defining IPFIX
 Information Elements.  Note that this appendix is of informational
 nature, while the text in Sections 2 and 3 (generated from this
 appendix) is normative.
 At the same time, this appendix is also an XML schema that was used
 for creating the XML specification of Information Elements in

Quittek, et al. Standards Track [Page 157] RFC 5102 IPFIX Information Model January 2008

 Appendix A.  It may also be used for specifying further Information
 Elements in extensions of the IPFIX information model.  This schema
 and its namespace are registered by IANA at
 http://www.iana.org/assignments/xml-registry/schema/ipfix.xsd.
 <?xml version="1.0" encoding="UTF-8"?>
 <schema targetNamespace="urn:ietf:params:xml:ns:ipfix-info"
         xmlns:ipfix="urn:ietf:params:xml:ns:ipfix-info"
         xmlns="http://www.w3.org/2001/XMLSchema"
         elementFormDefault="qualified">
   <simpleType name="dataType">
     <restriction base="string">
       <enumeration value="unsigned8">
         <annotation>
           <documentation>The type "unsigned8" represents a
             non-negative integer value in the range of 0 to 255.
           </documentation>
         </annotation>
       </enumeration>
       <enumeration value="unsigned16">
         <annotation>
           <documentation>The type "unsigned16" represents a
             non-negative integer value in the range of 0 to 65535.
           </documentation>
         </annotation>
       </enumeration>
       <enumeration value="unsigned32">
         <annotation>
           <documentation>The type "unsigned32" represents a
              non-negative integer value in the range of 0 to
              4294967295.
           </documentation>
         </annotation>
       </enumeration>
       <enumeration value="unsigned64">
         <annotation>
           <documentation>The type "unsigned64" represents a
             non-negative integer value in the range of 0 to
             18446744073709551615.
           </documentation>
         </annotation>
       </enumeration>

Quittek, et al. Standards Track [Page 158] RFC 5102 IPFIX Information Model January 2008

       <enumeration value="signed8">
         <annotation>
           <documentation>The type "signed8" represents
             an integer value in the range of -128 to 127.
           </documentation>
         </annotation>
       </enumeration>
       <enumeration value="signed16">
         <annotation>
           <documentation>The type "signed16" represents an
             integer value in the range of -32768 to 32767.
           </documentation>
         </annotation>
       </enumeration>
       <enumeration value="signed32">
         <annotation>
           <documentation>The type "signed32" represents an
              integer value in the range of -2147483648 to
              2147483647.
           </documentation>
         </annotation>
       </enumeration>
       <enumeration value="signed64">
         <annotation>
           <documentation>The type "signed64" represents an
              integer value in the range of -9223372036854775808
              to 9223372036854775807.
           </documentation>
         </annotation>
       </enumeration>
       <enumeration value="float32">
         <annotation>
           <documentation>The type "float32" corresponds to an IEEE
             single-precision 32-bit floating point type as defined
             in [IEEE.754.1985].
           </documentation>
         </annotation>
       </enumeration>
       <enumeration value="float64">
         <annotation>
           <documentation>The type "float64" corresponds to an IEEE
             double-precision 64-bit floating point type as defined
             in [IEEE.754.1985].

Quittek, et al. Standards Track [Page 159] RFC 5102 IPFIX Information Model January 2008

           </documentation>
         </annotation>
       </enumeration>
       <enumeration value="boolean">
         <annotation>
           <documentation>The type "boolean" represents a binary
             value.  The only allowed values are "true" and "false".
           </documentation>
         </annotation>
       </enumeration>
       <enumeration value="macAddress">
         <annotation>
           <documentation>The type "macAddress" represents a
             string of 6 octets.
           </documentation>
         </annotation>
       </enumeration>
       <enumeration value="octetArray">
         <annotation>
           <documentation>The type "octetArray" represents a
          finite-length string of octets.
           </documentation>
         </annotation>
       </enumeration>
       <enumeration value="string">
         <annotation>
           <documentation>
             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.
           </documentation>
         </annotation>
       </enumeration>
       <enumeration value="dateTimeSeconds">
         <annotation>
           <documentation>
             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

Quittek, et al. Standards Track [Page 160] RFC 5102 IPFIX Information Model January 2008

             protocol specification.  Leap seconds are excluded.
             Note that transformation of values might be required
             between different encodings if different epoch values
             are used.
           </documentation>
         </annotation>
       </enumeration>
       <enumeration value="dateTimeMilliseconds">
         <annotation>
           <documentation>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.
           </documentation>
         </annotation>
       </enumeration>
       <enumeration value="dateTimeMicroseconds">
         <annotation>
           <documentation>The type "dateTimeMicroseconds" represents
             a time value in units of microseconds
             based on coordinated universal time (UTC).
             The choice of an epoch, for example,  00:00 UTC,
             January 1, 1970, is left to corresponding encoding
             specifications for this type, for example, the IPFIX
             protocol specification.  Leap seconds are excluded.
             Note that transformation of values might be required
             between different encodings if different epoch values
             are used.
           </documentation>
         </annotation>
       </enumeration>
       <enumeration value="dateTimeNanoseconds">
         <annotation>
           <documentation>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

Quittek, et al. Standards Track [Page 161] RFC 5102 IPFIX Information Model January 2008

             protocol specification.  Leap seconds are excluded.
             Note that transformation of values might be required
             between different encodings if different epoch values
             are used.
           </documentation>
         </annotation>
       </enumeration>
       <enumeration value="ipv4Address">
         <annotation>
           <documentation>The type "ipv4Address" represents a value
             of an IPv4 address.
           </documentation>
         </annotation>
       </enumeration>
       <enumeration value="ipv6Address">
         <annotation>
           <documentation>The type "ipv6Address" represents a value
             of an IPv6 address.
           </documentation>
         </annotation>
       </enumeration>
     </restriction>
   </simpleType>
   <simpleType name="dataTypeSemantics">
     <restriction base="string">
       <enumeration value="quantity">
         <annotation>
           <documentation>
             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.
           </documentation>
         </annotation>
       </enumeration>
       <enumeration value="totalCounter">
         <annotation>
           <documentation>
             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

Quittek, et al. Standards Track [Page 162] RFC 5102 IPFIX Information Model January 2008

             increment until reaching the value of 2**64 - 1.  At
             this point, the next increment will wrap its value to
             zero and continue counting from zero.  The semantics
             of a total counter is similar to the semantics of
             counters used in SNMP, such as Counter32 defined in
             RFC 2578 [RFC2578].  The only difference between total
             counters and counters used in SNMP is that the total
             counters have an initial value of 0.  A total counter
             counts independently of the export of its value.
           </documentation>
         </annotation>
       </enumeration>
       <enumeration value="deltaCounter">
         <annotation>
           <documentation>
             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.
           </documentation>
         </annotation>
       </enumeration>
       <enumeration value="identifier">
         <annotation>
           <documentation>
             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.
           </documentation>
         </annotation>
       </enumeration>
       <enumeration value="flags">
         <annotation>
           <documentation>

Quittek, et al. Standards Track [Page 163] RFC 5102 IPFIX Information Model January 2008

             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.
           </documentation>
         </annotation>
       </enumeration>
     </restriction>
   </simpleType>
   <simpleType name="applicability">
     <restriction base="string">
       <enumeration value="data">
         <annotation>
           <documentation>
             Used for Information Elements that are applicable to
             Flow Records only.
           </documentation>
         </annotation>
       </enumeration>
       <enumeration value="option">
         <annotation>
           <documentation>
             Used for Information Elements that are applicable to
             option records only.
           </documentation>
         </annotation>
       </enumeration>
       <enumeration value="all">
         <annotation>
           <documentation>
             Used for Information Elements that are applicable to
             Flow Records as well as to option records.
           </documentation>
         </annotation>
       </enumeration>
     </restriction>
   </simpleType>
   <simpleType name="status">
     <restriction base="string">
       <enumeration value="current">
         <annotation>
           <documentation>
             Indicates that the Information Element definition
             is current and valid.

Quittek, et al. Standards Track [Page 164] RFC 5102 IPFIX Information Model January 2008

           </documentation>
         </annotation>
       </enumeration>
       <enumeration value="deprecated">
         <annotation>
           <documentation>
             Indicates that the Information Element definition is
             obsolete, but it permits new/continued implementation
             in order to foster interoperability with older/existing
             implementations.
           </documentation>
         </annotation>
       </enumeration>
       <enumeration value="obsolete">
         <annotation>
           <documentation>
             Indicates that the Information Element definition is
             obsolete and should not be implemented and/or can be
             removed if previously implemented.
           </documentation>
         </annotation>
       </enumeration>
     </restriction>
   </simpleType>
   <complexType name="text">
     <choice maxOccurs="unbounded" minOccurs="0">
       <element name="paragraph">
         <complexType mixed="true">
           <sequence>
              <element maxOccurs="unbounded" minOccurs="0"
                name="xref">
                <complexType>
                  <attribute name="target" type="string"
                    use="required"/>
                </complexType>
              </element>
           </sequence>
         </complexType>
       </element>
       <element name="artwork">
         <simpleType>
           <restriction base="string"/>
         </simpleType>
       </element>
     </choice>
   </complexType>

Quittek, et al. Standards Track [Page 165] RFC 5102 IPFIX Information Model January 2008

   <simpleType name="range">
     <restriction base="string"/>
   </simpleType>
   <element name="fieldDefinitions">
     <complexType>
       <sequence>
         <element maxOccurs="unbounded" minOccurs="1" name="field">
           <complexType>
             <sequence>
               <element maxOccurs="1" minOccurs="1" name="description"
                        type="ipfix:text">
                 <annotation>
                   <documentation>
                     The semantics of this Information Element.
                     Describes how this Information Element is
                     derived from the Flow or other information
                     available to the observer.
                   </documentation>
                 </annotation>
               </element>
               <element maxOccurs="1" minOccurs="0" name="reference"
                        type="ipfix:text">
                 <annotation>
                   <documentation>
                     Identifies additional specifications that more
                     precisely define this item or provide additional
                     context for its use.
                   </documentation>
                 </annotation>
               </element>
               <element maxOccurs="1" minOccurs="0" name="units"
                        type="string">
                 <annotation>
                   <documentation>
                     If the Information Element is a measure of some
                     kind, the units identify what the measure is.
                   </documentation>
                 </annotation>
               </element>
               <element maxOccurs="1" minOccurs="0" name="range"
                        type="ipfix:range">
                 <annotation>
                   <documentation>
                     Some Information Elements may only be able to
                     take on a restricted set of values that can be

Quittek, et al. Standards Track [Page 166] RFC 5102 IPFIX Information Model January 2008

                     expressed as a range (e.g., 0 through 511
                     inclusive).  If this is the case, the valid
                     inclusive range should be specified.
                   </documentation>
                 </annotation>
               </element>
             </sequence>
             <attribute name="name" type="string" use="required">
               <annotation>
                 <documentation>
                   A unique and meaningful name for the Information
                   Element.
                 </documentation>
               </annotation>
             </attribute>
             <attribute name="dataType" type="ipfix:dataType"
                        use="required">
               <annotation>
                 <documentation>
                   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.
                 </documentation>
               </annotation>
             </attribute>
             <attribute name="dataTypeSemantics"
                        type="ipfix:dataTypeSemantics" use="optional">
               <annotation>
                 <documentation>
                   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.
                 </documentation>
               </annotation>
             </attribute>
             <attribute name="elementId" type="nonNegativeInteger"

Quittek, et al. Standards Track [Page 167] RFC 5102 IPFIX Information Model January 2008

                        use="required">
               <annotation>
                 <documentation>
                   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.
                 </documentation>
               </annotation>
             </attribute>
             <attribute name="enterpriseId" type="nonNegativeInteger"
                        use="optional">
               <annotation>
                 <documentation>
                   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.
                 </documentation>
               </annotation>
             </attribute>
             <attribute name="applicability"
                        type="ipfix:applicability" use="optional">
               <annotation>
                 <documentation>
                   This property of an Information
                   Element indicates in which kind of records the
                   Information Element can be used.

Quittek, et al. Standards Track [Page 168] RFC 5102 IPFIX Information Model January 2008

                   Allowed values for this property are 'data',
                   'option', and 'all'.
                 </documentation>
               </annotation>
             </attribute>
             <attribute name="status" type="ipfix:status"
                        use="required">
               <annotation>
                 <documentation>
                   The status of the specification of this
                   Information Element.  Allowed values are 'current',
                   'deprecated', and 'obsolete'.
                 </documentation>
               </annotation>
             </attribute>
             <attribute name="group" type="string"
                        use="required">
               <annotation>
                 <documentation>to be done ...</documentation>
               </annotation>
             </attribute>
           </complexType>
         </element>
       </sequence>
     </complexType>
     <unique name="infoElementIdUnique">
       <selector xpath="field"/>
       <field xpath="elementId"/>
     </unique>
   </element>
 </schema>

Quittek, et al. Standards Track [Page 169] RFC 5102 IPFIX Information Model January 2008

Authors' Addresses

 Juergen Quittek
 NEC
 Kurfuersten-Anlage 36
 Heidelberg 69115
 Germany
 Phone: +49 6221 90511-15
 EMail: quittek@nw.neclab.eu
 URI:   http://www.neclab.eu/
 Stewart Bryant
 Cisco Systems, Inc.
 250, Longwater Ave., Green Park
 Reading RG2 6GB
 United Kingdom
 EMail: stbryant@cisco.com
 Benoit Claise
 Cisco Systems, Inc.
 De Kleetlaan 6a b1
 Diegem 1831
 Belgium
 Phone: +32 2 704 5622
 EMail: bclaise@cisco.com
 Paul Aitken
 Cisco Systems, Inc.
 96 Commercial Quay
 Edinburgh EH6 6LX
 Scotland
 Phone: +44 131 561 3616
 EMail: paitken@cisco.com
 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. Standards Track [Page 170] RFC 5102 IPFIX Information Model January 2008

Full Copyright Statement

 Copyright (C) The IETF Trust (2008).
 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.
 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, THE IETF TRUST 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.

Intellectual Property

 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.

Quittek, et al. Standards Track [Page 171]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5102.txt · Last modified: 2008/01/31 22:38 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki