2.4.7 IP Flow Information Export (ipfix)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date.

Last Modified: 2005-01-19

Chair(s):

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

Internet-Drafts:

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

    Request For Comments:

    RFCStatusTitle
    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
    62nd IETF, Minneapolis, Thursday March 10, 2005
    35 people in attendance

    submitted by Dave Plonka and Nevil Brownlee (co-chairs) based on notes from George Michaelson, Simon Leinen, and Ralf Wolter.

    The text messaging log is available here:

    http://www.xmpp.org/ietf-logs/ipfix@ietf.xmpp.org/2005-03-10.html

    The meeting agenda and slides are available here:

    http://ipfix.doit.wisc.edu/IETF62/

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

    ----

    The chairs mentioned that the four drafts are at the tail end of a WG last call currently. We're optimistic because The documents have improved greatly during this process, thanks to the authors/editors and contributions from reviewers.

    There were no objections raised to discussing the very recent (yet-to-be-published) changes to the documents.

    Our target is to submit them to the IESG by mid-April.

    David Kessens (our Area Director) reminded the working group that we need to get this work done now because of PSAMP depending on IPFIX and because he is hearing from industry folks that want it.

    ----

    Architecture draft changes (Nevil Brownlee)

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

    ----

    Protocol draft changes (Benoit Claise)

    [see slides for details:
    http://ipfix.doit.wisc.edu/IETF62/2-ietf62-ipfix-claise-proto.ppt ]

    version 10 of this draft will be posted next week.

    There appears to be consensus on the term Data Record (rather than Flow Data Record) as discussed recently in the mailing list.

    There is an open issue regarding the micro/milli-second timestamp deltas relative to what is currently called the "export time". This will be discussed after Juergen presents it in the information model discussion (below).

    ----

    Information model (Juergen Quittek)

    [see slides for details:
    http://ipfix.doit.wisc.edu/IETF62/3-ietf62-ipfix-quittek-info.ppt ]

    In response to a question as to whether or not there is a IANA registry for the information elements that can be used to define scope (such as lineCardId), Juergen and Benoit pointed out that any information element can be used to define scope, but some make much more (or less) sense than others. So, we just have one registry for all IPFIX information elements.

    There is a proposal to use 32-bit rather than 64-bit values as delta/offset times from a base time. Currently the message header has a time field called "export time". If this were used as the base for delta times, they would have to be signed negative values (for the start and end of the flow) or implictly negative unsigned values.

    So, depending upon what is chosen as the base time, the relative timestamps might be positive or negative. Which do we prefer?

    Simon Leinen suggested that an arbitrary base time (of the implementer's choosing) that is before the start or equal to the oldest time might be better than "export time" which may be interesting, but not of much use in practice. This requires only positive values for relative timestamps and permits some performance optimizations because it would not be necessary to make additional passes across the flow data to fix these relative timestamps prior to export.

    Others suggested that the export time be preserved as-is because it is useful when an exporter lags, and that perhaps an additional base time be added as an information element. Nevil noted that there is no simple way to make such a change to the protocol at this point.

    Juergen mentioned that there is a sourceId in the message header that is used to define a sort of scope, this is potentially unnecessary or ambiguous since information elements could be used to define scope. Should sourceId be an information element instead?

    There was insufficient time to discuss the timestamp and sourceId issues at length, so we will continue it in the mailing list.

    ----

    Applicability statement (Tanja Zseby)

    [see slides for details:
    http://ipfix.doit.wisc.edu/IETF62/4-ietf62-ipfix-zseby-applicability.ppt ]

    ----

    IPFIX Aggregation (Juergen Quittek for Falko Dressler)

    [see slides for details:
    http://ipfix.doit.wisc.edu/IETF62/5-ietf62-ipfix-dressler-aggregation.ppt ]

    This was a discussion about a new draft discussing aggregation techniques for devices or environments where it is not feasible or desired to report all 5-tuple flows.

    The chairs encouraged feedback to Falko on this draft.

    ----

    Per-Packet Information Export (Elisa Boschi)
    draft-pohl-perpktinfo-02.txt

    [see slides for details:
    http://ipfix.doit.wisc.edu/IETF62/6-ietf62-ipfix-boschi-perpktinfo.ppt ]

    Elisa mentioned that a flowId information element has been added so that, now, no further changes to IPFIX are needed to make this work.

    So, now which working group's document should this be integrated into: IPFIX or PSAMP?

    The chairs suggested that we have the right split now, the required information element is in the IPFIX draft, so the rest of the work could continue to PSAMP. This will prevent the integration of this new content from slowing the process of taking the IPFIX drafts through to RFC as soon as possible.

    There was some general discussion and concern that IPFIX work needed to continue. It was noted that even if IPFIX doesn't meet continually, the WG can still exist (or recharter, theoretically) and continue pertinent work.

    Our focus now though is to get the existing work and with both IPFIX and PSAMP there is a place for this work.

    ----

    The chairs propose doing one more WG last call on each of the documents once the next revision is published. We'll ask the ADs to push our milestone deadlines out 21 days to a month from now.

    Propose submission to IESG for publication by mid-April, 2005

    --
    $Id: minutes.txt,v 1.4 2005/03/28 22:07:33 dplonka Exp $

    Slides

    Agenda
    IPFIX: Architecture
    IPFIX Protocol Specifications
    IPFIX Information Model
    IPFIX Applicability Update
    IPFIX Aggregation
    Draft-pohl-perpktinfo-02.txt