2.4.8 IP Flow Information Export (ipfix)

NOTE: This charter is a snapshot of the 59th IETF Meeting in Seoul, Korea. It may now be out-of-date.

Last Modified: 2004-02-12

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
May 04  Submit IPFIX Protocol Evaluation Report to IESG for publication as Informational RFC
May 04  Submit IPFX-ARCHITECTURE to IESG for publication as Proposed Standard RFC
May 04  Submit IPFX-INFO_DATAMODEL to IESG for publication as Informational RFC
May 04  Submit IPFX-APPLICABILITY to IESG for publication as Informational RFC
Internet-Drafts:
  • - draft-ietf-ipfix-reqs-15.txt
  • - draft-leinen-ipfix-eval-contrib-02.txt
  • - draft-ietf-ipfix-info-03.txt
  • - draft-ietf-ipfix-arch-02.txt
  • - draft-ietf-ipfix-protocol-03.txt
  • - draft-ietf-ipfix-as-01.txt
  • No Request For Comments

    Current Meeting Report

    =======================================
    Minutes of the IPFIX session at IETF 59
    Wednesday March 3, 15:30 h - 17:30 h
    =======================================
    
    Minutes taken by Ralf Wolter and Tanja Zseby
    
    ----------
    0. Session Summary
    
      The IPFIX WG discussed open issues of the protocol 
    specification. Major issues were the required accuracy of 
    timestamps.  There seems to be agreement on having this unspecified and 
    signaling it within an option record.  A suggested extension of the 
    definition of flows to also cover IP packet encapsulation properties was 
    rejected.
    
      For several fields that exist in NetFlowV9 but not yet in IPFIX the WG 
    discussed whether or not to include them in the IPFIX information model.  A 
    presentation on traffic metering at middleboxes showed that a large set of 
    further fields is required in the information model.
    
      Document status:
      Two documents are already under review at the IESG.  The discussion on 
    calling the requirements document back because the security 
    requirements are too hard is closed. The document can progress as it is.  
    The remaining WG documents all have a deadline for completion in May. The 
    editors estimated that this deadline will not be met, but that with two 
    further iterations a stable version would probably be available at the next 
    IETF meeting.
    
    ----------
    1. WG Status (Juergen Quittek)
    
    Juergen presented the list of WG documents and summarized their states.  I-D 
    draft-leinen-ipfix-eval-contrib-02.txt is a working group document 
    although its name does not indicate it.
    
    ----------
    2.1. Requirement I-D:  draft-ietf-ipfix-reqs-15.txt (Juergen)
    
    The WG discussed on whether encryption should be mandatory to 
    implement or not. The document will not pass IESG if we would change it by 
    weakening the security, so Jürgen proposed to leave it as is.
    
    ---------
    2.2. Evaluation I-D: 
    draft-leinen-ipfix-eval-contrib-02.txt (Simon Leinen)
    
    Simon got some feedback from the AD, so he prepared a revised draft. There 
    are issues with status of the document, but there will be a 
    workaround, a note about the references was added. There are still 
    references to non-RFCs (e.g. requirements I-D) but in most cases the 
    references are ok.
    
    [Juergen] Same problem in MIDCOM.  There an evaluation documents where 
    postponed until all references I-Ds became RFC.
    
    ----------
    3.1. Protocol Specification I-D:  
    draft-ietf-ipfix-protocol-03.txt (Benoit Claise)
    
    Benoit described the changes from version 01 to 02
    - Time synchronization
    - IEs for different precision
    - Flow records with multiple precision possible
      Q: [Juergen] Does a protocol implementation require support of all 
    precisions?
      A: [Benoit] MUST only for microseconds (but he will double check)
    - Linkage with Info Model
    - Encoding rules
    - New Security section
    - Vendor specific information:
      [Juergen] There was a comment on the mailing list. FlowSet ID 2 and 3 
    might only be needed, and not 0 and 1 which were defined to be NetFlow 
    compliant. Should be OK if FlowSet ID 0 and 1 are reserved for NetFlow, as 
    the packet header already has a different version number (10) instead of the 
    one which is used by NetFlow (9).
    - Metering process statistics
    - Option template for statistics
    - New proposal on mailing list from Maurizio
    - Editorial changes
    - Overview section on IPFIX docs
    
    Then he listed changes from version 02 to 03:
    - Terminology synchronized between protocol and architecture
    - Flow Expiration
    - Section Synchronized with architecture
    - Flow export vs. flow expiration
    - Editorial changes
    - Abstract and structure changed
    - Transport Protocol: finally agreed on SCTP MUST, TCP MAY, UDP MAY
      Q: [Juergen] Is an implementation compliant if it just supports 
    PR-SCTP?
      A: [Benoit] MUST for PR-SCTP makes most sense, but I have to ask Nevil.
      A: [Nevil Brownlee (via Jabber)] I will talk to SCTP people on SCTP vs 
    PR-SCTP.
    - Input is required for UDP and TCP:
      [Simon] volunteers to write one of these sections.
    
    Then Bemoit showed a list of 30 open issues and discussed some of them.
    - Exporter Time Accuracy: what if the exporter does not provide 
    microsecond accuracy?
      [Simon] We should support devices with less accuracy but also export the 
    accuracy provided by the device (option template).  Precision field 
    should be added to the template.
      [Simon (and others)] Support for exporters with less capabilities is 
    needed. They can report their precision. He will send a proposal to the 
    mailing list.
    - IP encapsulated packets: Benoit addressed the issue of whether 
    limiting IPFIX to IP only or to be flexible for encapsulating 
    protocols such as MPLS. He also roposed to also include GRE, IP-in-IP, IPv6 
    tunnel, MPLS, AtoM and replace "IP packets" by "packets" in the flow 
    definition.
      [Juergen] feels that MPLS packets are covered by explicitly 
    mentioning it in the requirements I-D, but AtoM is not. What about IP over 
    Sonet, IP over lambda, SDH, etc.? Why limit to IP? The charter says we have 
    to look for IP packets.
      [several] Discussion about the IP focus of the charter. Extending 
    beyond IP would slow down the group.  Even if we make it open for other 
    protocols but make sure that everyone understands that we limit IPFIX to IP. 
    If we limit it to IP only, there might be an issue with PSAMPs AtoM 
    collection.
      [AD Bert Wijnen (via Jabber)] Don't try to boil the ocean.
    - Padding: currently a should for the exporting process, and a must for the 
    collector.  Proposal to have a MAY for the exporting process
    
    ----------
    3.2. Informatio Model I-D:  
    draft-ietf-ipfix-info-03.txt (Juergen)
    
    Paul and Jeff couldn't make it, so Juergen presented.  Several 
    editorial changes were applied and the XML representation of the info 
    model was changed. This change included replacing the 
    representation of IPFIX protocol fields and adding an XML 
    representation of field template and abstract data types. Juergen 
    explained the new XML representation, which uses the xml2rfc tool from 
    Marshall Rose. This will make the programming of IPFIX applications easy and 
    increase safety.
    
    Juergen listed the open issues:
    - Datatypes: several changes applied like more precise names, 
    Milliseconds and Nanoseconds were removed. They need to be added again. The 
    IPDR data types were removed. Jeff wants to keep UUID, this needs to be 
    discussed on the mailing list.
    - Field IDs: Some fields from NetFlowV9 should not be re-used, because they 
    are NetFlow/Cisco specific.  Still, the IDs of these fields should be 
    reserved in order to avoid incompatibilities between IPFIX and 
    NetFlowV9. This needs to be considered when registering fields IDs at 
    IANA.
    - Some NetFlowV9 fields (like in/out packets) do not apply to an 
    observer like a probe. How to deal with them?  No comments from the room, to 
    be solved on the mailing list.  NFv9 has separate values for IPv4 and IPv6 
    netmask length.  Sampling interval and sampling algorithm is used in NFv9 
    but probably not required (according to PSAMP).
      [Tanja,Benoit] Use the the PSAMP info model.
    - List of not yet used NFv9 fields: there are multiple fields defined by 
    NFv9 which are not yet considered by IPFIX, but are candidates:
      engineType and engineID.
      [Benoit] Several line cards at one device require more granularity than 
    the IP address.
      [Stewart Bryant] Engine ID and txpe are Cisco-specific. NFv9 defines 10 
    MPLSlabels, shall IPFIX also reserve 10 fields?
      [Simon] destClassOfService/ToS field should be reproted before and after 
    writing it, maybe refer to DiffServ terminology.
      [Juergen] Let's sort it out on the mailing list.
    
    ----------
    4. new I-D on IPFIX implementation at middleboxes:
       draft-ietf-ipfix-info-03.txt (Martin Stiemerling)
    
    Refer to RFC 3234 for a definition of middleboxes. For IPFIX a clearly 
    indication of the location of the observation point is required. An 
    observation point in the midlebox might be ambiguous. Martin suggests to 
    measure not within a middlebox, but outside of it with a clearly defined 
    observation point.  Still it is possible to report the effect of the 
    middlebox on flows as 'middlebox internels.
    
    Open issues:
    - investigate security implications
    - should this become a WG draft?
    [Tanja] Middleboxes are not included in the applicability statement, so it 
    should become a separate WG I-D.
    [Juergen] The results of the paper need to be considered in the info model by 
    fields reporting middlebox internals, such as changed DSCP or 
    tranlated addresses and prot numbers.
    [Benoit] We standardize export, we should rather not include middlebox 
    recommendations for metering.
    [Emile Stephane] At least location of observation point should be 
    included in other IPFIX document.
    Q: [?] Can a router that changes DSCP be a middlebox?
    A: [Juergen] A router in this case is a routing device with middlebox 
    function. on this devices, the observation point must be defined 
    relative to the middlebox function.
    Q: [Ralf Wolter] Do we limit IPFIX to ingress?
    A: [Juergen] No we don't!
    
    Conclusion: middlebox discussion to be finalized on the mailing list
    
    ----------
    5. WG Schedule
    
    Initial I-D     Final I-D     Deliverable
    Done            Done          IPFIX requirements
    Done            May 04        IPFIX architecture
    Done            May 04        IPFIX protocol
    Done            May 04        IPFIX information model
    Done            May 04        IPFIX applicability statement
    
    Q: [Juergen] When to finalize the architecture draft?
    A: [Benoit] May is too early, We will manage to have two iterations until 
    the next IETF meeting.
    [Juergen] Information model will progress in parallel.
    [Tanja] I did not receive comments on the applicability I-D, so there is no 
    new version. If more details are be requested, I will produce a new 
    version. Iuggest to finish the protocol document first. Volunteers for 
    sections on RMONMIB and TEWG relations to IPFIX are very welcome. 
    [Benoit] Accidentally, there was no new version on the 
    architecture. Ganesh will post one soon.
    
    --
    $Id: minutes.txt,v 1.1 2004/03/29 14:42:04 dplonka Exp $
    

    Slides

    Agenda
    IPFIX Protocol Specifications
    IPFIX Information Model
    Guidelines for IPFIX Implementations on Middleboxes