Network Working Group B. Claise, Ed.
Internet Draft Cisco Systems, Inc.
Obsoletes: 5102 B. Trammell, Ed.
Category: Standards Track ETH Zurich
Expires: April 2, 2013 September 29, 2012
Information Model for IP Flow Information eXport (IPFIX)
draft-ietf-ipfix-information-model-rfc5102bis-05.txt
Abstract
This document provides an overview of the information model for the IP
Flow Information eXport (IPFIX) protocol, as defined in the IANA IPFIX
Information Element Registry. 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
Claise, Trammell Standards Track [Page 1]
Internet-Draft IPFIX Information Model September 29, 2012
publication of this document. Please review these documents
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 . . . . . . . . . . . . . . . . . 4
2. Properties of IPFIX Protocol Information Elements . . . . . . 5
2.1. Information Element Specification Template . . . . . . . . 5
2.2. Scope of Information Elements . . . . . . . . . . . . . . 7
2.3. Naming Conventions for Information Elements . . . . . . . 8
3. Type Space . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Abstract Data Types . . . . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.9. float32 . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.10. float64 . . . . . . . . . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . . 11
3.1.18. dateTimeNanoseconds . . . . . . . . . . . . . . . . . 11
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 . . . . . . . . . . . . . . . . . . . . . 12
3.2.4. identifier . . . . . . . . . . . . . . . . . . . . . . 12
3.2.5. flags . . . . . . . . . . . . . . . . . . . . . . . . 12
4. Information Element Identifiers . . . . . . . . . . . . . . . 12
4.1. NetFlow version 9 compatible Information Element
Identifiers . . . . . . . . . . . . . . . . . . . . . . . 13
Claise, Trammell Standards Track [Page 2]
Internet-Draft IPFIX Information Model September 29, 2012
5. Information Element Categories . . . . . . . . . . . . . . . . 13
5.1. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 14
5.3. Metering and Exporting Process Statistics . . . . . . . . 15
5.4. IP Header Fields . . . . . . . . . . . . . . . . . . . . . 15
5.5. Transport Header Fields . . . . . . . . . . . . . . . . . 16
5.6. Sub-IP Header Fields . . . . . . . . . . . . . . . . . . . 17
5.7. Derived Packet Properties . . . . . . . . . . . . . . . . 17
5.9. Flow Timestamps . . . . . . . . . . . . . . . . . . . . . 18
5.10. Per-Flow Counters . . . . . . . . . . . . . . . . . . . . 18
5.11. Miscellaneous Flow Properties . . . . . . . . . . . . . . 19
5.12. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 20
6. Extending the Information Model . . . . . . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
7.1. IPFIX Information Elements . . . . . . . . . . . . . . . . 21
7.2. MPLS Label Type Identifier . . . . . . . . . . . . . . . . 21
7.3. XML Namespace and Schema . . . . . . . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 23
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
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].
The canonical reference for IPFIX Information Elements the IANA IPFIX
Information Element registry [IPFIX-IANA]; the initial values for
this registry were provided by [RFC5102].
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
Claise, Trammell Standards Track [Page 3]
Internet-Draft IPFIX Information Model September 29, 2012
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 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
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
Claise, Trammell Standards Track [Page 4]
Internet-Draft IPFIX Information Model September 29, 2012
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 Element 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
that is described below.
All Information Elements specified for the IPFIX protocol 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
Claise, Trammell Standards Track [Page 5]
Internet-Draft IPFIX Information Model September 29, 2012
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. Information Elements of
dataType string or octetArray which have a length constraints
(fixed length, minimum and/or maximum length) MUST note these
constraints in their description.
dataType - One of the types listed in Section 3.1 of this document or
registered in the IANA IPFIX Information Element Data Types
registry. 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' and 'deprecated'. All newly-defined
Information Elements have 'current' status. The process for moving
Information Elements to the 'deprecated' status is defined in
Section 5.2 of [IPFIX-IE-DOCTORS].
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
Claise, Trammell Standards Track [Page 6]
Internet-Draft IPFIX Information Model September 29, 2012
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.
The following two Information Element properties are defined to allow
the management of an Information Element registry with Information
Element definitions that may be updated over time, per the process
defined in Section 5.2 of [IPFIX-IE-DOCTORS].
revision - The revision number of an Information Element, starting at
0 for Information Elements at time of definition, and incremented
by one for each revision.
date - The date of the entry of this revision of the Information
Element into the registry.
For Information Elements of the string or octetArray data types which
have size limits (minimum and/or maximum size, or fixed length), the
limits MUST be defined within the description of the Information
Element.
2.2. Scope of Information Elements
By default, most Information Elements have a scope specified in their
definitions.
o The Information Elements listed in Sections 5.2 and 5.3, and
similar Information Elements in [IPFIX-IANA], have a default of "a
specific Metering Process" or of "a specific Exporting Process",
respectively.
o The Information Elements listed in Sections 5.4-5.11, and similar
Information Elements in [IPFIX-IANA], 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
Claise, Trammell Standards Track [Page 7]
Internet-Draft IPFIX Information Model September 29, 2012
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 MUST be unique within the IANA
registry. Enterprise-specific Information Elements SHOULD be
prefixed with a vendor name.
o Names of Information Elements MUST start with non-capitalized
letters.
o Composed names MUST 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 letters, 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
Claise, Trammell Standards Track [Page 8]
Internet-Draft IPFIX Information Model September 29, 2012
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.
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
Claise, Trammell Standards Track [Page 9]
Internet-Draft IPFIX Information Model September 29, 2012
-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].
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 data type dateTimeSeconds is an unsigned 32-bit integer
representing the number of seconds since the UNIX epoch, 1 January
1970 at 00:00 UTC, as defined in [POSIX.1].
3.1.16. dateTimeMilliseconds
The data type dateTimeMilliseconds is an unsigned 64-bit integer
containing the number of milliseconds since the UNIX epoch, 1 January
1970 at 00:00 UTC, as defined in [POSIX.1].
Claise, Trammell Standards Track [Page 10]
Internet-Draft IPFIX Information Model September 29, 2012
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].
3.1.18. dateTimeNanoseconds
The type "dateTimeNanoseconds" represents a time value with
nanosecond precision according to the NTP Timestamp format as defined
in section 6 of [RFC5905].
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. A registry of data type semantics is
established in [RFC5610]; the restrictions specified in section 3.10
of that document are followed here. Note that further data type
semantics may be specified by future extensions of the IPFIX
information model. These semantics apply only to numeric types, as
noted in the description of each semantic below.
3.2.1. quantity
A numeric (integral or floating point) value representing a 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. This is the default semantic type
of all numeric data types.
3.2.2. totalCounter
An numeric 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 [RFC2578]. The
only difference between total counters and counters used in SNMP is
Claise, Trammell Standards Track [Page 11]
Internet-Draft IPFIX Information Model September 29, 2012
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 numeric 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. Identifiers MUST be one of the
signed or unsigned data types.
3.2.5. flags
An integral value that represents a set of bit fields. Logical
operations are appropriate on such values, but not other mathematical
operations. Flags MUST always be of an unsigned data type.
4. Information Element Identifiers
All Information Elements defined in the IANA IPFIX Information
Element registry [IPFIX-IANA] have their identifiers assigned by
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]; Information Element identifiers in this range MUST NOT be
assigned unless the Information Element is compatible with the
NetFlow version 9 protocol. Such Information Elements may ONLY be
requested by a NetFlow v9 expert, to be designated by the IESG.
In general, IANA will add newly registered Information Elements to
the registry, assigning the lowest available Information Element
identifier in the range 128-32767.
Claise, Trammell Standards Track [Page 12]
Internet-Draft IPFIX Information Model September 29, 2012
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; these
Information Elements are distinct 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.
4.1. NetFlow version 9 compatible Information Element Identifiers
Information Elements with identifiers from 1-127 are reserved for
compatibility with corresponding fields in NetFlow version 9.
5. Information Element Categories
This section describes the Information Element category for the IPFIX
information model at the time that [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.
Claise, Trammell Standards Track [Page 13]
Internet-Draft IPFIX Information Model September 29, 2012
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
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.
Claise, Trammell Standards Track [Page 14]
Internet-Draft IPFIX Information Model September 29, 2012
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 |
+-----+--------------------------+-----+----------------------------+
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 |
Claise, Trammell Standards Track [Page 15]
Internet-Draft IPFIX Information Model September 29, 2012
+-----+----------------------------+-----+--------------------------+
| 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 |
+-----+----------------------------+-----+--------------------------+
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 16]
Internet-Draft IPFIX Information Model September 29, 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.
Claise, Trammell Standards Track [Page 17]
Internet-Draft IPFIX Information Model September 29, 2012
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 |
+-----+---------------------------+-----+---------------------------+
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.
Claise, Trammell Standards Track [Page 18]
Internet-Draft IPFIX Information Model September 29, 2012
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
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 |
+-----+---------------------------+-----+---------------------------+
Claise, Trammell Standards Track [Page 19]
Internet-Draft IPFIX Information Model September 29, 2012
See [IPFIX-IANA] for the definitions of these Information Elements.
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 described in [IPFIX-IE-DOCTORS], which also
provides guidelines for authors and reviewers of new Information
Element definitions.
For new Information Elements, 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].
Claise, Trammell Standards Track [Page 20]
Internet-Draft IPFIX Information Model September 29, 2012
7. IANA Considerations
7.1. IPFIX Information Elements
This document refers to Information Elements, for which the Internet
Assigned Numbers Authority (IANA) has created the IPFIX Information
Element Registry [IPFIX-IANA]. The columns of this registry must at
minimum be able to store the information defined in the template in
Section 2.1; it may contain other information as necessary for the
management of the registry.
[NOTE to IANA: on publication of this document, please set the Revision
of all existing Information Elements to 0.]
[NOTE to IANA: on publication of this document, please set the Date of
all existing Information Elements to the publication date of this
document.]
New assignments for IPFIX Information Elements will be administered by
IANA through Expert Review [RFC5226], i.e., review by one of a group of
experts designated by the IESG. Further considerations for this review
are specified in [IPFIX-IE-DOCTORS].
Future assignments added to the IPFIX Information Element Registry which
require subregistries for enumerated values (e.g. section 7.2, below)
must have those subregistries added simultaneously with the new
assignment; additions to these subregistries must be subject to Expert
Review [RFC5226]. Unless specified at assignment time, the experts for
the subregistry will be the same as for the Information Element registry
as a whole.
Changes may also be made to the entries in this registry from time to
time; the process for these changes are specified in [IPFIX-IE-DOCTORS].
[NOTE to IANA: please update the Reference for the IPFIX Information
Element Registry to refer to this document, as well as to [IPFIX-IE-
DOCTORS].]
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
subregistry 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
Claise, Trammell Standards Track [Page 21]
Internet-Draft IPFIX Information Model September 29, 2012
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.
[NOTE to IANA: please update the Reference for the IPFIX MPLS Label Type
subregistry to refer to this document.]
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>.
* 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
Claise, Trammell Standards Track [Page 22]
Internet-Draft IPFIX Information Model September 29, 2012
advantage of the machine readability of the information model vs.
hard coding their behavior or inventing proprietary means for
accommodating extensions.
[NOTE to IANA: please update the Reference for the the IPFIX
information model namespace and schema to refer to 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
[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.
9. Acknowledgements
The editors would like to thanks the authors of the RFC5102 [RFC5102],
as this document is directly based upon 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-
Claise, Trammell Standards Track [Page 23]
Internet-Draft IPFIX Information Model September 29, 2012
ipfix-protocol-rfc5101bis-00, Work in Progress, November
2011.
[IPFIX-IE-DOCTORS]
Trammell, B., 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.
[POSIX.1] IEEE 1003.1-2008 - IEEE Standard for Information
Technology - Portable Operating System Interface, IEEE,
2008.
[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.
[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.
Claise, Trammell Standards Track [Page 24]
Internet-Draft IPFIX Information Model September 29, 2012
[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
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
Claise, Trammell Standards Track [Page 25]
Internet-Draft IPFIX Information Model September 29, 2012
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 26]
Internet-Draft IPFIX Information Model September 29, 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 27]