2.4.8 IP Flow Information Export (ipfix)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.

Last Modified: 2004-09-13


Nevil Brownlee <n.brownlee@auckland.ac.nz>
Dave Plonka <plonka@doit.wisc.edu>

Operations and Management Area Director(s):

Bert Wijnen <bwijnen@lucent.com>
David Kessens <david.kessens@nokia.com>

Operations and Management Area Advisor:

David Kessens <david.kessens@nokia.com>

Mailing Lists:

General Discussion: ipfix@net.doit.wisc.edu
To Subscribe: majordomo@net.doit.wisc.edu
In Body: subscribe ipfix
Archive: http://ipfix.doit.wisc.edu/archive/

Description of Working Group:

There are a number of IP flow information export systems in common
use.  These systems differ significantly, even though some have
adopted a common transport mechanism; such differences make it
difficult to develop generalised flow analysis tools.  As such, there
is a need in industry and the Internet research community for IP
devices such as routers to export flow information in a standard way
to external systems such as mediation systems, accounting/billing
systems, and network management systems to facilitate services such as
Internet research, measurement, accounting, and billing.

An IP flow information export system includes a data model, which
represents the flow information, and a transport protocol.  An
"exporter," which is typically an IP router or IP traffic measurement
device, will employ the IP flow information export system to report
information about "IP flows," these being series of related IP packets
that have been either forwarded or dropped.  The reported flow
information will include both (1) those attributes derived from the IP
packet headers such as source and destination address, protocol, and
port number and (2) those attributes often known only to the exporter
such as ingress and egress ports, IP (sub)net mask, autonomous system
numbers and perhaps sub-IP-layer information.

This group will select a protocol by which IP flow information can be
transferred in a timely fashion from an "exporter" to a collection
station or stations and define an architecture which employs it.  The
protocol must run over an IETF approved congestion-aware transport
protocol such as TCP or SCTP.

Specific Goals

o Define the notion of a "standard IP flow."  The flow definition
  will be a practical one, similar to those currently in use by
  existing non-standard flow information export protocols which
  have attempted to achieve similar goals but have not documented
  their flow defintion.

o Devise data encodings that support analysis of IPv4 and IPv6
  unicast and multicast flows traversing a network element at
  packet header level and other levels of aggregation as requested
  by the network operator according to the capabilities of the
  given router implementation.

o Consider the notion of IP flow information export based upon
  packet sampling.

o Identify and address any security privacy concerns affecting
  flow data.  Determine technology for securing the flow information
  export data, e.g. TLS.

o Specify the transport mapping for carrying IP flow information,
  one which is amenable to router and instrumentation implementors,
  and to deployment.

o Ensure that the flow export system is reliable in that it will
  minimize the likelihood of flow data being lost due to resource
  constraints in the exporter or receiver and to accurately report
  such loss if it occurs.

Goals and Milestones:

Done  Submit Revised Internet-Draft on IP Flow Export Requirements
Done  Submit Internet-Draft on IP Flow Export Architecture
Done  Submit Internet-Draft on IP Flow Export Data Model
Done  Submit Internet-Draft on IPFIX Protocol Evaluation Report
Done  Submit Internet-Draft on IP Flow Export Applicability Statement
Done  Select IPFIX protocol, revise Architecture and Data Model drafts
Done  Submit IPFX-REQUIREMENTS to IESG for publication as Informational RFC
Done  Submit IPFIX Protocol Evaluation Report to IESG for publication as Informational RFC
Sep 04  Submit IPFX-ARCHITECTURE to IESG for publication as Proposed Standard RFC
Sep 04  Submit IPFX-INFO_MODEL to IESG for publication as Informational RFC
Sep 04  Submit IPFX-APPLICABILITY to IESG for publication as Informational RFC
Sep 04  Submit IPFX-PROTOCOL to IESG for publication as Proposed Standard RFC


  • draft-ietf-ipfix-architecture-04.txt
  • draft-ietf-ipfix-info-05.txt
  • draft-ietf-ipfix-protocol-06.txt
  • draft-ietf-ipfix-as-03.txt

    Request For Comments:

    RFC3917 I Requirements for IP Flow Information Export
    RFC3955 I Evaluation of Candidate Protocols for IP Flow Information Export (IPFIX)

    Current Meeting Report

    Minutes of the IP Flow Information eXport (IPFIX) WG
    61st IETF, Washington DC, Thursday November 11, 2004
    53 people in attendance

    submitted by Dave Plonka (co-chair) based on notes
    from Ralf Wolter and George Michaelson.

    The text messaging log is available here:


    The meeting agenda and slides are available here:


    [please see the agenda slides there for the sequence of topics:
    http://ipfix.doit.wisc.edu/IETF61/0-ietf61-ipfix-agenda.pdf ]


    Architecture changes & Issues (Dave Plonka for Nevil Brownlee)

    [see slides for details:
    http://ipfix.doit.wisc.edu/IETF61/1-ietf61-ipfix-brownlee-arch.pdf ]

    Dave provided an overview of IPFIX documents, such as Applicability
    Statements, Architecture, Protocol, etc.
    Several editorial changes
    Some sections restructured
    Technical changes:
    Clarification between "information element" and "field"
    Add exporter to terminology section
    Changes in terminology section
    Flow aggregates
    Added "Collection Process" section
    There was no mention of transport protocols
    Added IANA consideration section
    Open Issues:
    Do we need more details on how "option templates" and "option data" should be used

    Security considerations
    What's next?
    More contribution required
    Nevil to make additional editorial changes
    WG chairs should then start WG last call
    Flow key notion:
    1.Flow key is the list of information elements?
    2.Or flow key is the set of all information elements?
    Text missing about time granularity
    Text in sections 9 +10 to be improved


    IPFIX over TCP (Simon Leinen)

    [see slides for details:
    http://ipfix.doit.wisc.edu/IETF61/2-ietf61-ipfix-leinen-tcp.pdf ]

    Individual draft, describes IPFIX over TCP
    Exporter now connects to collector
    TLS use described

    Simon aggress that changing the metering process based on the TCP rate is not a good idea.

    Remaining issues:
    Some parts do not belong there (max message size etc.)
    Structure not aligned with UDP/SCTP sections
    Terminology nits
    What's next:
    Finish integration into ipfix-protocol draft
    Enhance as an addition to the WG document


    Protocol draft: changes & open issues (Benoit Claise)

    [see slides for details:
    http://ipfix.doit.wisc.edu/IETF61/3-ietf61-ipfix-claise-proto.pdf ]

    Closed issues in v5
    Flow set replaced by Set
    Data types removed
    Scope issues sorted out
    Correct examples
    Terminology issues: introduced Exporter, removed "IPFIX Node"
    Juergen: distinguish between "Exporter" and "Exporting process"
    Private addresses used in examples
    Improved padding
    Add new text about measurement parameters
    Editorial changes
    Closed issues in v6:
    Metering process statistics option template, new text IANA considerations inserted
    "Linkage with the information model" must be completed with base types used in IPFIX

    Variable length of 255 byte length is now possible
    IPFIX message length issues (as identified by Simon)
    Open issues in v6:
    TCP section adapted from Simon's draft
    SCTP: sequence number; 2 SCTP contradictory sentences; non
    matching source ID

    Finalize time details - new text to be proposed
    Update "Template Management"
    IANA assigned ports (UDP, TCP, SCTP) for IPFIX?
    Simon: this is not required, e.g. avoid attacks on well
    known ports

    Argument: firewalls depend on well known ports

    [Note: Since there was no opposition voiced to acquiring a well-known port
    number for IPFIX, the chairs will pursue this getting a port number
    assigned by IANA.]

    What happens (at the collector) when reaching the max number of template IDs?

    Review by security expert required
    Review IPFIX requirements
    New proposal:
    IPFIX charter is targeted to export flow records related information
    However, in theory everything could be exported: packet reports, MIB variables, SLA info, ?

    Change name to "IP Flexible Information eXport protocol (IPFIX)"
    Simon: netconf could also use ipfix to export configuration details. Danger: it could become too attractive

    Dave: protocol name change is possible, but is it in line with the original charter? Is IPFIX a generic transport protocol?

    Benoit: everything could be exported by IPFIX, define right information element

    Juergen: makes a lot of sense, also from PSAMP perspective. However, a serious delay would be introduced, as all

    docs need to be reviewed and modified

    Tanja: agrees with Juergen, keep the original definition and change later

    Chris: change name now or never? Name change makes sense
    Ruediger: applicability statement required in this case to define details
    Benoit: requirements are already flexible.
    Bert (individual): "flow" appears often in the docs, a change requires a lot of editorial work
    Emile: export of other details (i/f counter) is a good idea No consensus to change the name (6 for change, 12 against the change)


    Information model (Juergen Quittek)

    [see slides for details:
    http://ipfix.doit.wisc.edu/IETF61/4-ietf61-ipfix-quittek-info.ppt ]

    Mainly structural changes applied, minor model changes:
    Boilerplates updated
    New section on data type semantics
    Added section on Information Element Identifiers
    Grouped information elements
    Action items:
    Check with requirement and protocol specification
    Add IEs for specifying properties/stats of metering/exporting process
    Revise extensibility section
    Add WLAN related IE
    Open Issues:
    How to add new data types? ? to be specified on the mailing list
    Next steps:
    Ready for WG last call before Christmas


    Applicability statement (Tanja)

    [see slides for details:
    http://ipfix.doit.wisc.edu/IETF61/5-ietf61-ipfix-zseby-applicability.ppt ]

    Corrections and changes
    Open issues:
    IPFIX and IPv6, RMON, TEWG
    "Where not to use IPFIX?" (planned)
    Sections found in other AS drafts (intended use, advantages compared to other protocols, scalability and limitations, ?)

    Are different scenarios required?
    Proposal: more detailed scenarios, e.g. how to use IPFIX and QoS etc.
    Comment: simple and general examples are also required to avoid that people only use IPFIX for twisted ideas

    Nevil: try to keep it short; conf call next week to clarify


    Use of IPFIX for Export of Per-Packet-Information (Elisa Boschi)

    [see slides for details:
    http://ipfix.doit.wisc.edu/IETF61/6-ietf61-ipfix-boschi-pktid.pdf ]

    Follow on from last meeting, the idea is to propose a better way to export packets

    Proposal: distinguish flow and packet information, as export records have a lot of similar entries which introduces redundancy. Therefore, separate between "Flow properties template" and "Data properties template"

    Pros and Cons presented
    For a OWD example, 16 bytes/packet instead of 28 bytes/packet would be exported
    Integrate in IPFIX or PSAMP?
    Propose a separate draft?
    Juergen: what is missing in IPFIX today to apply the proposal:
    Elisa: nothing, it's all there
    Emile: some field IDs are missing?
    Dave: extensions proposes new identifiers. An idea would be to build/pre-fill a new template

    IPFIX Implement Interoperability Testing (Andreas Kind, IBM Zurich)
    IBM has an IPFIX implementation and would like to start interoperability tests
    Dave: at least two other implementations exist; a mailing list will be setup

    Review, upgrade milestones
    4 docs missed the deadline: architecture, information model, applicability, protocol

    The chairs propose doing a series of WG last calls between now and the next meeting

    Propose submission to IESG for publication by April 6, 2005

    $Id: minutes.txt,v 1.1 2004/11/12 16:58:14 dplonka Exp $


    IPFIX: Architecture 04
    Describes IPFIX mapping over TCP
    IPFIX Protocol Specifications
    IPFIX Information Model
    IPFIX Applicability Update
    Use of IPFIX for Export of Per-Packet Information