2.4.7 IP Flow Information Export (ipfix)

NOTE: This charter is a snapshot of the 58th IETF Meeting in Minneapolis, Minnesota USA. It may now be out-of-date.

Last Modified: 2003-10-16

Nevil Brownlee <n.brownlee@auckland.ac.nz>
Dave Plonka <plonka@doit.wisc.edu>
Operations and Management Area Director(s):
Randy Bush <randy@psg.com>
Bert Wijnen <bwijnen@lucent.com>
Operations and Management Area Advisor:
Randy Bush <randy@psg.com>
Mailing Lists:
General Discussion: ipfix@net.doit.wisc.edu
To Subscribe: majordomo@net.doit.wisc.edu
In Body: subscribe ipfix
Archive: http://ipfx.doit.wisc.edu/list/ipfix/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
Apr 03  Submit IPFIX Protocol Evaluation Report to IESG for publication as Informational RFC
Done  Submit IPFX-REQUIREMENTS to IESG for publication as Informational RFC
Aug 03  Submit IPFX-ARCHITECTURE to IESG for publication as Proposed Standard RFC
Aug 03  Submit IPFX-DATAMODEL to IESG for publication as Informational RFC
Aug 03  Submit IPFX-APPLICABILITY to IESG for publication as Informational RFC
  • - draft-ietf-ipfix-reqs-11.txt
  • - draft-leinen-ipfix-eval-contrib-01.txt
  • - draft-ietf-ipfix-info-01.txt
  • - draft-ietf-ipfix-arch-02.txt
  • - draft-ietf-ipfix-protocol-01.txt
  • - draft-ietf-ipfix-as-01.txt
  • No Request For Comments

    Current Meeting Report

    DRAFT Minutes of the IP Flow Information eXport (IPFIX) WG
    IETF 58, Minneapolis, Monday November 10, 2003
    58 people in attendance
    Reported by Dave Plonka & Nevil Brownlee (co-chairs) based on notes from 
    Greg Ruth 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:
    Juergen Quittek presented an update on the requirements draft.
    [see slides for details: 
    Nevil reported that, based on a conversation with Allison Mankin 
    (transport area director), anonymsization IPFIX simply MAY be 
    required, rather than MUST as she had suggested previously.  However, the 
    requirements draft should include the rationale for why this is not 
    strictly required.  (Basically that there is not yet a standard 
    anonymization method.)
    Ganesh Sadasivan presented an update on the architecture draft.
    [see slides for details: 
    We need volunteers to provide more text, in this and other drafts.
    Juergen Quittek presented an update on the information model draft.
    [this was an oral report only: no slides.]
    Not many changes have been made recently.
    Benoit Claise presented an update on the protocol draft.
    [see slides for details: 
    The draft has had many changes as the result of feedback regarding the 
    NetFlow v9 draft, to be submitted as an individual Information RFC, which 
    Benoit has been editing in parallel with the IPFIX protocol draft.
    Would like feedback regarding a number of issues listed in the slides:
      1) Do we have consensus to use an options data record per 
    observation domain and per template?
      2) Do we have consensus to replace the count with a length field, in the 
    export packet header?
    Lastly, he noted that the issue of transport protocol and Vendor 
    Specified Information Elements are open issues. (These were addressed 
    Tanja Zseby presented an update on the protocol draft.
    [see slides for details: 
    Highlights included that the middlebox content was removed.
    It was suggested that the applications discussed in the draft be limited to 
    those that are considered high priority, so as to limit the amount of 
    Stuart Bryant presented his draft on Vendor Specified Information 
    [see slides for details: 
    He suggested that IPFIX adopt the "compressed VI qualified" 
    Those present afreed that text from this draft be copied directly into the 
    IPFIX protocol draft.
    Morizio Molina presented his draft on Flow Selection.
    [see slides for details: 
    While the chairs agree that this notion is worth considering, it will not be 
    part of the current IPFIX documents.  However, IPFIX reviewers should take 
    care not to preclude the implementation of such features in the future.
    Nevil Brownlee present his short list of open issues.
    For each, consensus at the meeting was:
       1) Both counter and gauge types are needed in the information model.
          [Here, the chairs suggest considering counter and gauge, a la SNMP 
    such as defined in section sections 7.1.6 and 7.1.7 of RFC-2578.]
          For most information elements (IE), one or the other is 
    sufficient, and IPFIX should specify which MUST be implemented for each IE.
          For some, such as packet and byte counts, both types may be 
       2) The consensus was that a UTC-based seconds and microseconds, 
    similar to Unix struct timeval, should be adopted.
          The IPFIX implementation may need to report its time 
    resolution, which presumably would require new text in the protocol 
          It was noted that 32-bit unsigned counter wraps (c.) should be 
    defined (note precedent from NTP specification).
       3) Variable length information elements are needed, and are being 
    addressed in the information model.
       4) IPFIX templates will specifiy the number of bytes, ie. the 
    encoding, used for numeric information elements. (The information model 
    specifies only the range.)
    At this point we opened discussion regarding the default (MUST 
    transport for IPFIX.
    Randy Bush, our area director, reminded us that one specific transport MUST 
    be implemented to ensure interoperability (the goal of the IETF in 
    In response to issues raised recently in the mailing list 
    questioning the IETF's approval of UDP-based RTP to deliver 
    high-bandwidth HDTV content, Jon Peterson (transport area director) said 
    that the IESG expects IPFIX to work within the letter of its existing 
    charter (and therefore must not use a UDP-based transport).  He also said 
    that the IESG was mistaken, and in hindsight should not have approved the 
    use of RTP in RFC-3497 ("RTP Payload Format for SMPTE Video").
       In the context of this transport discussion, Randall Stewart 
    presented a slideshow about SCTP and PR-SCTP.
       [see slides for details: 
       Randall hypothesized that PR-SCTP may be available as a standard as    
    soon as two months from now.
    Based on past IPFIX meeting discussions and in the mailing list, the 
    chairs claimed that they felt there was rough consensus for choosing TCP as 
    the default transport for IPFIX.
    A show of hands in the meeting showed otherwise, with more favoring SCTP 
    than TCP.  However, many did not express an opinion.  This issue will be 
    taken to the mailing list to test the meeting consensus.
    Nevil reviewed the working group milestones:
    The requirements draft and evaluation report will be submitted by 
    December 1, 2003.
    The other four drafts need text and editing, and we're shooting for May 31, 
    $Id: minutes.txt,v 1.9 2003/12/11 20:32:06 dplonka Exp $


    IPFIX Requirements: Document Changes
    IPFIX Architecture
    IPFIX Protocol Specifications
    IPFIX Applicability Update IPFIX Applicability Update
    IPFIX Default Transport