Skip to main content

Information Model for IP Flow Information eXport (IPFIX)
draft-ietf-ipfix-information-model-rfc5102bis-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7012.
Authors Benoît Claise , Brian Trammell
Last updated 2012-01-24
Replaces draft-claise-ipfix-information-model-rfc5102bis
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state Became RFC 7012 (Proposed Standard)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-ipfix-information-model-rfc5102bis-00
Network Working Group                                     B. Claise, Ed.
Internet Draft                                       Cisco Systems, Inc.
Obsoletes: 5102                                         B. Trammell, Ed.
Category: Standards Track                                     ETH Zurich
Expires: July 27, 2012                                  January 24, 2012

        Information Model for IP Flow Information eXport (IPFIX)
          draft-ietf-ipfix-information-model-rfc5102bis-00.txt
                                    

Abstract

This memo defines an overview of the 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.  This document obsoletes RFC
5102.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on March 23, 2012.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
 

Claise, Trammell            Standards Track                     [Page 1]
Internet-Draft          IPFIX Information Model         January 18, 2012

   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1. Changes since RFC 5102  . . . . . . . . . . . . . . . . . .  4
     1.2. IPFIX Documents Overview  . . . . . . . . . . . . . . . . .  5
   2.  Properties of IPFIX Protocol Information Elements  . . . . . .  5
     2.1.  Information Elements Specification Template  . . . . . . .  5
     2.2.  Scope of Information Elements  . . . . . . . . . . . . . .  7
     2.3.  Naming Conventions for Information Elements  . . . . . . .  7
   3.  Type Space . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     3.1.  Abstract Data Types  . . . . . . . . . . . . . . . . . . .  8
       3.1.1.  unsigned8  . . . . . . . . . . . . . . . . . . . . . .  9
       3.1.2.  unsigned16 . . . . . . . . . . . . . . . . . . . . . .  9
       3.1.3.  unsigned32 . . . . . . . . . . . . . . . . . . . . . .  9
       3.1.4.  unsigned64 . . . . . . . . . . . . . . . . . . . . . .  9
       3.1.5.  signed8  . . . . . . . . . . . . . . . . . . . . . . .  9
       3.1.6.  signed16 . . . . . . . . . . . . . . . . . . . . . . .  9
       3.1.7.  signed32 . . . . . . . . . . . . . . . . . . . . . . .  9
       3.1.8.  signed64 . . . . . . . . . . . . . . . . . . . . . . .  9
       3.1.9.  float32  . . . . . . . . . . . . . . . . . . . . . . .  9
       3.1.10.  float64 . . . . . . . . . . . . . . . . . . . . . . .  9
       3.1.11.  boolean . . . . . . . . . . . . . . . . . . . . . . . 10
       3.1.12.  macAddress  . . . . . . . . . . . . . . . . . . . . . 10
       3.1.13.  octetArray  . . . . . . . . . . . . . . . . . . . . . 10
       3.1.14.  string  . . . . . . . . . . . . . . . . . . . . . . . 10
       3.1.15.  dateTimeSeconds . . . . . . . . . . . . . . . . . . . 10
       3.1.16.  dateTimeMilliseconds  . . . . . . . . . . . . . . . . 10
       3.1.17.  dateTimeMicroseconds  . . . . . . . . . . . . . . . . 10
       3.1.18.  dateTimeNanoseconds . . . . . . . . . . . . . . . . . 10
       3.1.19.  ipv4Address . . . . . . . . . . . . . . . . . . . . . 11
       3.1.20.  ipv6Address . . . . . . . . . . . . . . . . . . . . . 11
     3.2.  Data Type Semantics  . . . . . . . . . . . . . . . . . . . 11
       3.2.1.  quantity . . . . . . . . . . . . . . . . . . . . . . . 11
       3.2.2.  totalCounter . . . . . . . . . . . . . . . . . . . . . 11
       3.2.3.  deltaCounter . . . . . . . . . . . . . . . . . . . . . 11
       3.2.4.  identifier . . . . . . . . . . . . . . . . . . . . . . 12
       3.2.5.  flags  . . . . . . . . . . . . . . . . . . . . . . . . 12
   4.  Information Element Identifiers  . . . . . . . . . . . . . . . 12
   5.  Information Elements . . . . . . . . . . . . . . . . . . . . . 16
     5.1.  Identifiers  . . . . . . . . . . . . . . . . . . . . . . . 18
     5.3.  Metering and Exporting Process Statistics  . . . . . . . . 19
 

Claise, Trammell            Standards Track                     [Page 2]
Internet-Draft          IPFIX Information Model         January 18, 2012

     5.4.  IP Header Fields . . . . . . . . . . . . . . . . . . . . . 19
     5.5.  Transport Header Fields  . . . . . . . . . . . . . . . . . 20
     5.6.  Sub-IP Header Fields . . . . . . . . . . . . . . . . . . . 21
     5.7.  Derived Packet Properties  . . . . . . . . . . . . . . . . 21
     5.9.  Flow Timestamps  . . . . . . . . . . . . . . . . . . . . . 21
     5.10.  Per-Flow Counters . . . . . . . . . . . . . . . . . . . . 22
     5.11.  Miscellaneous Flow Properties . . . . . . . . . . . . . . 23
     5.12.  Padding . . . . . . . . . . . . . . . . . . . . . . . . . 24
   6.  Extending the Information Model  . . . . . . . . . . . . . . . 24
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 24
     7.1.  IPFIX Information Elements . . . . . . . . . . . . . . . . 24
     7.2.  MPLS Label Type Identifier . . . . . . . . . . . . . . . . 25
     7.3.  XML Namespace and Schema . . . . . . . . . . . . . . . . . 25
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 26
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
   10.  References  . . . . . . . . . . . . . . . . . . . . . . . . . 27
     10.1.  Normative References  . . . . . . . . . . . . . . . . . . 27
     10.2.  Informative References  . . . . . . . . . . . . . . . . . 27
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30

OPEN ISSUES:

   * "revision", "date", "enterprise-specific" added from [IPFIX-IE-
   DOCTORS]. So we need to change the section 2.1. Harmonize with IE-
   DOCTORS section 12.

   * Do we want to have a new column in IANA for the max length for
   string, arrary, and potentially others? DISCUSSION on the mailing
   list

   Clarified the dateTimeSeconds and dateTimeMilliseconds. "excluding
   leap seconds" in the current definition is not clear according to
   Paul Aitken.

1.  Introduction

   The IP Flow Information eXport (IPFIX) protocol serves for
   transmitting information related to measured IP traffic over the
   Internet.  The protocol specification in [RFC5101bis] defines how
   Information Elements are transmitted.  For Information Elements, it
   specifies the encoding of a set of basic data types.  However, the
   list of Information Elements that can be transmitted by the protocol,
   such as Flow attributes (source IP address, number of packets, etc.)
   and information about the Metering and Exporting Process (packet
   Observation Point, sampling rate, Flow timeout interval, etc.), is
   not specified in [RFC5101bis].
 

Claise, Trammell            Standards Track                     [Page 3]
Internet-Draft          IPFIX Information Model         January 18, 2012

   This document complements the IPFIX protocol specification by
   providing an overview of the IPFIX information model and specifying
   data types for it.  IPFIX-specific terminology used in this document
   is defined in Section 2 of [RFC5101bis].  As in [RFC5101bis], these
   IPFIX-specific terms have the first letter of a word capitalized when
   used in this document.

   The use of the term 'information model' is not fully in line with the
   definition of this term in [RFC3444].  The IPFIX information model
   does not specify relationships between Information Elements, but also
   it does not specify a concrete encoding of Information Elements.
   Besides the encoding used by the IPFIX protocol, other encodings of
   IPFIX Information Elements can be applied, for example, XML-based
   encodings.

   The main part of this document is Section 5, which displays some 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 key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

1.1. Changes since RFC 5102

   This document obsoletes the Proposed Standard revision of the IPFIX
   Protocol Specification [RFC5102].  The following changes have been
   made to this document with respect to the previous document:

   - EDITOR'S NOTE: not sure if we need to this information
      Errata ID: 1307 (technical)
      Errata ID: 1492 (technical)
      Errata ID: 1736 (technical)
      Errata ID: 2879 (editorial)
      Errata ID: 2944, which updates 1737 (technical)
      Errata ID: 2945, which updates 1738 (technical)
      Errata ID: 2946, which updates 1739 (technical)
      Updated the reference to RFC5101bis
      Clarified the time-related IEs

   - Since this document is based on the IPFIX Draft Standard
   [RFC5101bis], all improvements have been taken into account. For
   example, the timestamps.- Instead of repeating every Information
   Elements from [RFC5102], a reference to the IPFIX IANA registry
   [IPFIX-IANA] is introduced. However the category in section 5 have
 

Claise, Trammell            Standards Track                     [Page 4]
Internet-Draft          IPFIX Information Model         January 18, 2012

   been kept.- The appendix A and B have been removed- Introduced
   [IPFIX-IE-DOCTORS] 

1.2. IPFIX Documents Overview

   The IPFIX protocol provides network administrators with access to IP
   flow information.  The architecture for the export of measured IP
   flow information out of an IPFIX Exporting Process to a Collecting
   Process is defined in [RFC5470], per the requirements defined in
   [RFC3917].  The IPFIX specifications [RFC5101bis] document specifies
   how IPFIX data records and templates are carried via a number of
   transport protocols from IPFIX Exporting Processes to IPFIX
   Collecting Processes.

   Four IPFIX optimizations/extensions are currently specified: a
   bandwidth saving method for the IPFIX protocol in [RFC5473], an
   efficient method for exporting bidirectional flow in [RFC5103], a
   method for the definition and export of complex data structures in
   [RFC6313], and the specification of the Protocol for IPFIX Mediations
   [IPFIX-MED-PROTO] based on the IPIFX Mediation Framework [RFC6183].

   IPFIX has a formal description of IPFIX Information Elements, their
   name, type and additional semantic information, as specified in this
   document, with the export of the Information Element types specified
   in [RFC5610].

   [IPFIX-CONF] specifies a data model for configuring and monitoring
   IPFIX and PSAMP compliant devices using the NETCONF protocol, while
   the [RFC5815bis] specifies a MIB module for monitoring.

   In terms of development, [RFC5153] provides guidelines for the
   implementation and use of the IPFIX protocol, while [RFC5471]
   provides guidelines for testing.

   Finally, [RFC5472] describes what type of applications can use the
   IPFIX protocol and how they can use the information provided.  It
   furthermore shows how the IPFIX framework relates to other
   architectures and frameworks.

2.  Properties of IPFIX Protocol Information Elements

2.1.  Information Elements Specification Template

   Information in messages of the IPFIX protocol is modeled in terms of
   Information Elements of the IPFIX information model.  The IPFIX
   Information Elements mentioned in Section 5 are specified in [IPFIX-
   IANA].  For specifying these Information Elements, a template is used
 

Claise, Trammell            Standards Track                     [Page 5]
Internet-Draft          IPFIX Information Model         January 18, 2012

   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.

   elementId - A numeric identifier of the Information Element.  If this
      identifier is used without an enterprise identifier (see
      [RFC5101bis] and enterpriseId below), then it is globally unique
      and the list of allowed values is administered by IANA.  It is
      used for compact identification of an Information Element when
      encoding Templates in the protocol.

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

   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.

 

Claise, Trammell            Standards Track                     [Page 6]
Internet-Draft          IPFIX Information Model         January 18, 2012

   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.

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

2.3.  Naming Conventions for Information Elements

   The following naming conventions were used for naming Information
   Elements in this document.  It is recommended that extensions of the
   model use the same conventions.

   o  Names of Information Elements should be descriptive.

   o  Names of Information Elements that are not enterprise-specific
      MUST be unique within the IPFIX information model. 
 

Claise, Trammell            Standards Track                     [Page 7]
Internet-Draft          IPFIX Information Model         January 18, 2012

      Enterprise-specific Information Elements SHOULD be prefixed with a
      vendor name.

   o  Names of Information Elements start with non-capitalized letters.

   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 ipClassOfService.  Then the value observed and
      reported by Information Element ipClassOfService is valid at the
      Observation Point, but not after the packet passed the packet
      marker.  For reporting the change value of the TOS field, the
      IPFIX information model uses Information Elements that have a name
      prefix "post", for example, "postIpClassOfService".  Information
      Elements with prefix "post" report on Flow properties that are not
      necessarily observed at the Observation Point, but which are
      obtained within the Flow's Observation Domain by other means
      considered to be sufficiently reliable, for example, by analyzing
      the packet marker's marking tables.

3.  Type Space

   This section describes the abstract data types that can be used for
   the specification of IPFIX Information Elements in Section 4. 
   Section 3.1 describes the set of abstract data types.

   Abstract data types unsigned8, unsigned16, unsigned32, unsigned64,
   signed8, signed16, signed32, and signed64 are integral data types. 
   As described in Section 3.2, their data type semantics can be further
   specified, for example, by 'totalCounter', 'deltaCounter',
   'identifier', or 'flags'.

3.1.  Abstract Data Types

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

Claise, Trammell            Standards Track                     [Page 8]
Internet-Draft          IPFIX Information Model         January 18, 2012

3.1.1.  unsigned8

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

3.1.2.  unsigned16

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

3.1.3.  unsigned32

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

3.1.4.  unsigned64

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

3.1.5.  signed8

   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
 

Claise, Trammell            Standards Track                     [Page 9]
Internet-Draft          IPFIX Information Model         January 18, 2012

   floating point type as defined in [IEEE.754.1985].

3.1.11.  boolean

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

3.1.12.  macAddress

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

3.1.13.  octetArray

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

3.1.14.  string

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

3.1.15.  dateTimeSeconds

   The type "dateTimeSeconds" represents a time value in units of
   seconds since the UNIX epoch, 1 January 1970 at 00:00 coordinated
   universal time (UTC), excluding leap seconds.

3.1.16.  dateTimeMilliseconds

   The type "dateTimeSeconds" represents a time value in units of
   milliseconds since the UNIX epoch, 1 January 1970 at 00:00
   coordinated universal time (UTC), excluding leap seconds.

3.1.17.  dateTimeMicroseconds

   The type "dateTimeMicroseconds" represents a time value with
   microsecond precision according to the NTP Timestamp format as
   defined in section 6 of [RFC5905]. This field is made up of two
   unsigned 32-bit integers, Seconds and Fraction. The Seconds field is
   the number of seconds since the NTP epoch, 1 January 1900 at 00:00
   UTC. The Fraction field is the fractional number of seconds in units
   of 1/(2^32) seconds (approximately 233 picoseconds). 

3.1.18.  dateTimeNanoseconds

   The type "dateTimeMicroseconds" represents a time value with
   nanosecond precision according to the NTP Timestamp format as defined
 

Claise, Trammell            Standards Track                    [Page 10]
Internet-Draft          IPFIX Information Model         January 18, 2012

   in section 6 of [RFC5905]. This field is made up of two unsigned 32-
   bit integers, Seconds and Fraction. The Seconds field is the number
   of seconds since the NTP epoch, 1 January 1900 at 00:00 UTC. The
   Fraction field is the fractional number of seconds in units of
   1/(2^32) seconds (approximately 233 picoseconds). 

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

Claise, Trammell            Standards Track                    [Page 11]
Internet-Draft          IPFIX Information Model         January 18, 2012

   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
   [IPFIX-IANA].

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

 

Claise, Trammell            Standards Track                    [Page 12]
Internet-Draft          IPFIX Information Model         January 18, 2012

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

 

Claise, Trammell            Standards Track                    [Page 13]
Internet-Draft          IPFIX Information Model         January 18, 2012

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

 

Claise, Trammell            Standards Track                    [Page 14]
Internet-Draft          IPFIX Information Model         January 18, 2012

   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                |
 

Claise, Trammell            Standards Track                    [Page 15]
Internet-Draft          IPFIX Information Model         January 18, 2012

   +-----+---------------------------+-----+---------------------------+
   |  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 Element category for the IPFIX
   information model at the time that RFC5102 [RFC5102] was published.
   Since this category field is not part of the IANA process for
   assigning new Information Element (even though it has been reused,
   for example, in [RFC5103]), the newest Information Elements in IANA
   [IPFIX-IANA] don't have this classification.  The elements are
   grouped into 12 groups according to their semantics and their
   applicability:

   1.   Identifiers
   2.   Metering and Exporting Process Configuration
   3.   Metering and Exporting Process Statistics
   4.   IP Header Fields
   5.   Transport Header Fields
   6.   Sub-IP Header Fields
   7.   Derived Packet Properties
   8.   Min/Max Flow Properties
   9.   Flow Timestamps
   10.  Per-Flow Counters
   11.  Miscellaneous Flow Properties
   12.  Padding

   The Information Elements that are derived from fields of packets or
   from packet treatment, such as the Information Elements in groups
   4-7, can typically serve as Flow Keys used for mapping packets to
   Flows.

   If they do not serve as Flow Keys, their value may change from packet
   to packet within a single Flow.  For Information Elements with values
   that are derived from fields of packets or from packet treatment and
   for which the value may change from packet to packet within a single
   Flow, the IPFIX information model defines that their value is
 

Claise, Trammell            Standards Track                    [Page 16]
Internet-Draft          IPFIX Information Model         January 18, 2012

   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

 

Claise, Trammell            Standards Track                    [Page 17]
Internet-Draft          IPFIX Information Model         January 18, 2012

   Information Elements related to header fields once when the first
   packet of the Flow is observed.  For further observed packets of the
   same Flow, only Flow properties that depend on more than one packet,
   such as the Information Elements in groups 8-11, need to be updated.

   Information Elements with a name having the "post" prefix, for
   example, "postIpClassOfService", do not report properties that were
   actually observed at the Observation Point, but retrieved by other
   means within the Observation Domain.  These Information Elements can
   be used if there are middlebox functions within the Observation
   Domain changing Flow properties after packets passed the Observation
   Point.

5.1.  Identifiers

   Information Elements grouped in the table below are identifying
   components of the IPFIX architecture, of an IPFIX Device, or of the
   IPFIX protocol.  All of them have an integral abstract data type and
   data type semantics "identifier" as described in Section 3.2.4.

   Typically, some of them are used for limiting scopes of other
   Information Elements.  However, other Information Elements MAY be
   used for limiting scopes.  Note also that all Information Elements
   listed below MAY be used for other purposes than limiting scopes.

   +-----+---------------------------+-----+---------------------------+
   |  ID | Name                      |  ID | Name                      |
   +-----+---------------------------+-----+---------------------------+
   | 141 | lineCardId                | 148 | flowId                    |
   | 142 | portId                    | 145 | templateId                |
   |  10 | ingressInterface          | 149 | observationDomainId       |
   |  14 | egressInterface           | 138 | observationPointId        |
   | 143 | meteringProcessId         | 137 | commonPropertiesId        |
   | 144 | exportingProcessId        |     |                           |
   +-----+---------------------------+-----+---------------------------+

   See [IPFIX-IANA] for the definitions of these Information Elements.

   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                       |
 

Claise, Trammell            Standards Track                    [Page 18]
Internet-Draft          IPFIX Information Model         January 18, 2012

   +-----+--------------------------+-----+----------------------------+
   | 130 | exporterIPv4Address      | 213 | exportInterface            |
   | 131 | exporterIPv6Address      | 214 | exportProtocolVersion      |
   | 217 | exporterTransportPort    | 215 | exportTransportProtocol    |
   | 211 | collectorIPv4Address     | 216 | collectorTransportPort     |
   | 212 | collectorIPv6Address     | 173 | flowKeyIndicator           |
   +-----+--------------------------+-----+----------------------------+

   See [IPFIX-IANA] for the definitions of these Information Elements.

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     |     |                         |
   +-----+-----------------------------+-----+-------------------------+

   See [IPFIX-IANA] for the definitions of these Information Elements.

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              |
 

Claise, Trammell            Standards Track                    [Page 19]
Internet-Draft          IPFIX Information Model         January 18, 2012

   |  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        |
   +-----+----------------------------+-----+--------------------------+

   See [IPFIX-IANA] for the definitions of these Information Elements.

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                  |
   +-----+---------------------------+-----+---------------------------+

   See [IPFIX-IANA] for the definitions of these Information Elements.

 

Claise, Trammell            Standards Track                    [Page 20]
Internet-Draft          IPFIX Information Model         January 18, 2012

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   |
   +-----+---------------------------+-----+---------------------------+

   See [IPFIX-IANA] for the definitions of these Information Elements.

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   |     |                           |
   +-----+---------------------------+-----+---------------------------+

   See [IPFIX-IANA] for the definitions of these Information Elements.

5.9.  Flow Timestamps

 

Claise, Trammell            Standards Track                    [Page 21]
Internet-Draft          IPFIX Information Model         January 18, 2012

   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          |
   +-----+---------------------------+-----+---------------------------+

   See [IPFIX-IANA] for the definitions of these Information Elements.

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
 

Claise, Trammell            Standards Track                    [Page 22]
Internet-Draft          IPFIX Information Model         January 18, 2012

   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
   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          |
   +-----+---------------------------+-----+---------------------------+

See [IPFIX-IANA] for the definitions of these Information Elements.

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             |
   +-----+---------------------------+-----+---------------------------+

See [IPFIX-IANA] for the definitions of these Information Elements.

 

Claise, Trammell            Standards Track                    [Page 23]
Internet-Draft          IPFIX Information Model         January 18, 2012

5.12.  Padding

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

   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             |     |                           |
   +-----+---------------------------+-----+---------------------------+

See [IPFIX-IANA] for the definitions of these Information Elements.

6.  Extending the Information Model

   A key requirement for IPFIX is to allow for extension of the
   Information Model maintained by IANA.  The process for extending the
   Information Model is defined in [IPFIX-IE-DOCTORS], which also
   provides guidelines for authors and reviewers of new Information
   Element definitions.

   For new Information Models, the type space defined in Section 3 can
   be used.  If required, new abstract data types can be added to the
   subregistry defined in [RFC5610]. 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; guidelines
   for using them appear in [IPFIX-IE-DOCTORS].

7.  IANA Considerations

7.1.  IPFIX Information Elements

This document refers to the Information Elements, for which the Internet 
Assigned Numbers Authority (IANA) has created a registry for IPFIX 
Information Element identifiers [IPFIX-IANA]. 

New assignments for IPFIX Information Elements will be administered
 

Claise, Trammell            Standards Track                    [Page 24]
Internet-Draft          IPFIX Information Model         January 18, 2012

by IANA through Expert Review [RFC5226], 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 [RFC5226], 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.

7.3.  XML Namespace and Schema

[IPFIX-XML-SCHEMA] defines an XML schema for IPFIX Information Element
definitions.  All Information Elements specified in [IPFIX-IANA] are
defined by this schema.  This schema may also be used for specifying 
further Information Elements in future extensions of the IPFIX 
information model in a machine-readable way.

[IPFIX-XML-SCHEMA] 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
    *  Registrant Contact: IETF IPFIX Working Group <ipfix@ietf.org>,
       as designated by the IESG <iesg@ietf.org>.
 

Claise, Trammell            Standards Track                    [Page 25]
Internet-Draft          IPFIX Information Model         January 18, 2012

    *  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
    *  Registrant Contact: IETF IPFIX Working Group <ipfix@ietf.org>,
       as designated by the IESG <iesg@ietf.org>.

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.

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

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.

 

Claise, Trammell            Standards Track                    [Page 26]
Internet-Draft          IPFIX Information Model         January 18, 2012

9.  Acknowledgements

The editors would like to thanks the authors of the RFC5102 [RFC5102],
as this document is based upon and develop this original RFC: Juergen
Quittek, Stewart Bryant, Paul Aitken, and Jeff Meyer.

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. 

   [RFC5905]  Mills, D., Delaware, U., Martin, J., Burbank, J. and W.
              Kasch, "Network Time Protocol Version 4: Protocol and
              Algorithms Specification", RFC 5905, June 2010

   [RFC5101bis] Claise, B., and B. Trammell, Editors, "Specification of
              the IP Flow Information eXport (IPFIX) Protocol for the
              Exchange of IP Traffic Flow Information", draft-ietf-
              ipfix-protocol-rfc5101bis-00, Work in Progress, November
              2011.

   [IPFIX-IE-DOCTORS] Trammell, T., and B. Claise, "Guidelines for
              Authors and Reviewers of IPFIX Information Elements",
              draft-ietf-ipfix-ie-doctors-00, Work in Progress, November
              2011.

10.2.  Informative References

   [IEEE.754.1985]
              Institute of Electrical and Electronics Engineers,
              "Standard for Binary Floating-Point Arithmetic", IEEE
              Standard 754, August 1985. 

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

   [RFC2578]  McCloghrie, K., Perkins, D., and J. Schoenwaelder,
 

Claise, Trammell            Standards Track                    [Page 27]
Internet-Draft          IPFIX Information Model         January 18, 2012

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

   [RFC3234]  Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
              Issues", RFC 3234, February 2002.

   [RFC3444]  Pras, A. and J. Schoenwaelder, "On the Difference between
              Information Models and Data Models", RFC 3444, January
              2003.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              January 2004. 

   [RFC3917]  Quittek, J., Zseby, T., Claise, B., and S. Zander,
              "Requirements for IP Flow Information Export (IPFIX)", RFC
              3917, October 2004.

   [RFC3954]  Claise, B., Ed., "Cisco Systems NetFlow Services Export
              Version 9", RFC 3954, October 2004. 

   [RFC5102]  Trammell, B., and E. Boschi, "Bidirectional Flow Export
              Using IP Flow Information Export (IPFIX)", RFC 5103,
              January 2008. 

   [RFC5103]  Quittek, J., Bryant, S. Claise, B., Aitken, P., and J.
              Meyer, "Information Model for IP Flow Information Export",
              RFC 5102, January 2008. 

   [RFC5153]  Boschi, E., Mark, L., Quittek J., and P. Aitken, "IP Flow
              Information Export (IPFIX) Implementation Guidelines",
              RFC5153, April 2008.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008. 

   [RFC5470]  Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek,
              "Architecture for IP Flow Information Export", RFC5470,
              March 2009.

   [RFC5471]  Schmoll, C., Aitken, P., and B. Claise, "Guidelines for IP
              Flow Information Export (IPFIX) Testing", RFC5471, March
              2009.

   [RFC5472]  Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP
 

Claise, Trammell            Standards Track                    [Page 28]
Internet-Draft          IPFIX Information Model         January 18, 2012

              Flow Information Export (IPFIX) Applicability", RFC5472,
              March 2009.

   [RFC5473]  Boschi, E., Mark, L., and B. Claise, "Reducing Redundancy
              in IP Flow Information Export (IPFIX) and Packet Sampling
              (PSAMP) Reports", RFC5473, March 2009.

   [RFC5610]  Boschi, E., Trammell, B., Mark, L., and T. Zseby,
              "Exporting Type Information for IP Flow Information Export
              (IPFIX) Information Elements", July 2009.

   [RFC6313]  Claise, B., Dhandapani, G., Aitken, P, and S. Yates,
              "Export of Structured Data in IP Flow Information Export
              (IPFIX)", RFC6313, July 2011.

   [RFC6183]  Kobayashi, A., Claise, B., Muenz, G, and K. Ishibashi, "IP
              Flow Information Export (IPFIX) Mediation: Framework",
              RFC6183, April 2011.

   [IPFIX-CONF]  Muenz, G., Claise, B., and P. Aitken, "Configuration
              Data Model for IPFIX and PSAMP", draft-ietf-ipfix-
              configuration-model-10, Work in Progress, July 2011.

   [IPFIX-MED-PROTO]  Claise, B., Kobayashi, A., and B. Trammell,
              "Specification of the Protocol for IPFIX Mediations",
              draft-ietf-ipfix-mediation-protocol-00, Work in Progress,
              December 2011.

   [RFC5815bis]   Dietz, T., Kobayashi, A., Claise, B., and G. Muenz,
              "Definitions of Managed Objects for IP Flow Information
              Export", draft-ietf-ipfix-rfc5815bis-01.txt, Work in
              Progress, January 2012.

   [IPFIX-IANA]   http://www.iana.org/assignments/ipfix/ipfix.xml

   [IPFIX-XML-SCHEMA]   http://www.iana.org/assignments/xml-
              registry/schema/ipfix.xsd

 

Claise, Trammell            Standards Track                    [Page 29]
Internet-Draft          IPFIX Information Model         January 18, 2012

Authors' Addresses

   Benoit Claise
   Cisco Systems, Inc.
   De Kleetlaan 6a b1
   Diegem 1831
   Belgium

   Phone: +32 2 704 5622
   EMail: bclaise@cisco.com

   Brian Trammell
   Swiss Federal Institute of Technology Zurich
   Gloriastrasse 35
   8092 Zurich
   Switzerland

   Phone: +41 44 632 70 13
   EMail: trammell@tik.ee.ethz.ch

Claise, Trammell            Standards Track                    [Page 30]