Current Meeting Report
Jabber Logs

2.4.7 IP Flow Information Export (ipfix)

NOTE: This charter is a snapshot of the 55th IETF Meeting in Altanta, Georgia USA. It may now be out-of-date.

Last Modifield: 05/23/2002

Nevil Brownlee <>
Dave Plonka <>
Operations and Management Area Director(s):
Randy Bush <>
Bert Wijnen <>
Operations and Management Area Advisor:
Randy Bush <>
Mailing Lists:
General Discussion:
To Subscribe:
In Body: subscribe ipfix
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
FEB 02  Submit IPFX-REQUIREMENTS to IESG for publication as an Informational RFC
Done  Submit Internet-Draft on IP Flow Export Architecture
Done  Submit Internet-Draft on IP Flow Export Data Model
MAY 02  Submit IPFX-DATAMODEL to IESG for publication as an Informational RFC
MAY 02  Submit IPFX-ARCHITECTURE to IESG for publication, Proposed Standard RFC (also need an Applicability Statement RFC)
  • - draft-ietf-ipfix-reqs-05.txt
  • - draft-ietf-ipfix-architecture-02.txt
  • - draft-ietf-ipfix-data-00.txt
  • No Request For Comments

    Current Meeting Report

    Minutes of the IP Flow Information eXport (IPFIX) WG
    IETF 55, Atlanta, Thursday November 21, 2002
    49 people in attendance
    Reported by Dave Plonka & Nevil Brownlee (co-chairs) based on notes from 
    scribes Cindy Mills, Chris Elliot, and George Michaelson
    The meeting agenda and slides are available here:
    Mark Allman gave a short "public service announcement" regaring the IMRG:
    Opening remarks from the chair: IPFIX charter remains the same.
    Focus is on 'base level' standard which supports what people do now using 
    one-way transport, but should not lock out the ability to do a next level on 
    top of IPFIX that can provide different levels of transport 
    The Applicability Draft 
    "draft-zseby-ipfix-applicability-00.txt" was adopted as a WG draft by a 
    hum, i.e. the next version will be submitted as a WG draft.
    Juergen Quittek presented the requirements draft 
    Regarding the requirement of reporting ICMP type and code it was agreed by a 
    hum that the requirements document will be updated to say SHOULD rather 
    than MUST.
    No objections were raised regarding leaving the document as-is with 
    respect to these issues:
     - VPN-ID attribute
     - exporting NAT'ed flows
     - Ignore Port Copy
     - anonymization
     - MPLS label/FEC
     - enabling de-duplication of received records
    Paul Calato reminded us about the outstanding issue of requiring the 
    export to identify which flow attributes were used to distinguish the 
    flows, i.e. which were part of the "flow key".  He will supply 
    clarifying text for the requirements document.
    The issue of reliability was discussed.  Juergen proposed, and it was 
    agreed to by a hum, that the requirements document should specify that the 
    IPFIX protocol MAY have "aditional reliability" and that it MUST be open to 
    reliability extensions.  Tal Givoly will supply clarifying text about this 
    higher level of reliability, describing it in an implementation 
    independent way.
    Reinaldo Penno presented the evaluation team's report.  None of the 
    protocols conform to the requirements as they stand today.  He suggest that 
    two more revisions of the advocacy drafts and evaluation report would 
    probably be required.
    It was pointed out that IPDR shouldn't be marked as "'F'ailed" for Pull 
    Mode reporting, since it is a supported IPDR mode.  (The editor is 
    requested to correct this.)
    Various participants expressed concern that the evaluation summary 
    (requirements compatibility matrix) did not indicate the importance of the 
    requirements or other distinguishing features of the candidate 
    It was suggested that advocates must elaborate on how their protocol will be 
    extended, it is not sufficient for an unexplained "'E'xtension Needed" 
    status to appear in the evaluation matrix.  For example, an advocate who 
    proposes to use SCTP for transport or IPSEC for security must explain 
    which modes and/or options of these protocols will be used to comply with 
    the IPFIX requirements.  The evaluation team can take into account the 
    degree of difficulty to implement the extension.
    Arguments were made for and against the current list of 
    compatibility status values, including proposals to discard the 
    "'U'pcoming" status, to further differentiate amongst the candidate 
    protocols.  However, no consensus was reached.
    A member of the evaluation team commented that the team is to look at 
    protocols, not products, therefore installed base is not an important 
    feature, a well-defined protocol is what's important.  Evaluators should 
    decide if protocols can be implemented at reasonable cost.
    Another member of the team said that the team should complete this 
    document and give it back to the advocates so that the advocates can see how 
    much effort they neec to expend to make their E's into T's.
    Reinaldo agreed to submit the "-00" draft for commentary as soon as 
    To accelerate the evluation process, the chair encouraged the 
    advocates to critically evaluate each others protocols, and to interact 
    with the evaluation team members (in the public IPFIX mailing list).
    Bert Wijnen, sitting in as our Area Director, reminded us that the 
    working group, not necessarily the advocate, will modify the protocol as it 
    sees fit once it has been selected as the IPFIX starting point.
    Juergen Quittek, co-chair of the PSAMP working group, gave a short 
    presentation on possible synergies between PSAMP and IPFIX.
    Nevil reviewed the milestones and the following updates were 
    suggested, to which there were no objections:
     - the evaluation draft version "-01" (or greater) will be submitted by 
    late January, 2002.
     - the applicability document versions will be postponed until after the 
    selection of one of the candidate protocols.
     - the starting-point IPFIX protocol will be selected in the 
    March/April timeframe.


    On the Relationship between PSAMP and IPFIX
    IPFIX Requirements
    (not available)