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.
| Done | Submit Revised Internet-Draft on IP Flow Export Requirements | |
| Feb 02 | Submit IPFX-REQUIREMENTS to IESG for publication as an Informational RFC | |
| Feb 02 | Submit Internet-Draft on IP Flow Export Architecture | |
| Feb 02 | 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) |
Current Meeting Report
DRAFT minutes of the IP Flow Information eXport (IPFIX) WG
IETF 52, Wednesday 12 December 2002, 95 people attending.
Reported by Cyndi Mills (scribe), Dave Plonka & Nevil Brownlee (co-chairs)
Dave Plonka introduced the session by reviewing the agenda:
* Adminstrivia, Intro, Agenda bashing
* Requirements Document
* New (individual) drafts relating to IPFIX
* Getting Started on IPFIX Architecture & Data Model I-Ds
* Other material relevant to IPFIX
One item was added: "review IPFIX deliverables".
Nevil gave a brief overview of the purpose of IPFIX.
1) Juergen Quittek reviewed the state of the Requirements document.
The following topics were addressed:
* the flow definition was modified slightly
* addition of a "Terminology" section, which defines the following terms: export, collector, record, observation point, in-band/out-of-band
* It was asked whether or not IPFIX' focus was solely to define the record and transport, or whether it would deal with the measurement techniques involved as well. This issue was revisited a number of times during the meeting, and is unresolved at this point.
We were reminded that this group was chartered to standardize existing practice, and that specifying new measurement techniques is out of scope.
* "network surveillance" was removed from the list of target applications
* Remarks were made about "overload" behavior including dynamic timeouts, dynamic flow rules, or measurement shutdown. We considered whether or not the requirements should define what the flow-exporter must or should do when resource limits are hit.
* The document was changed slightly to specify that flows must be able to be distinguished by the input and/or output interface pair, rather than, necessarily, by both of them.
* unidirectional vs. bidirection flow definition:
Currently the Requirements document allows either.
A number of arguments for each were expressed for each, and it was noted that both methodologies are used in existing practice and products. Due to time constraints we will continue this discussion in the mailing list.
* It was noted that data tranfer should be "congestion friendly" (rather than "congestion aware"). TCP was mentioned to be a candidate for transport.
* It was suggested that the Requirements document address "reliability".
* Juergen expects to have the next draft ready in January.
2) Kevin Zhang presented his updates to the CRANE Internet Draft.
field padding and alignment requirements were specified, new query messages server to client for protocol version negotiation
This Internet Draft is intended to be submitted for publication as an Information RFC in Q1 2002.
3) We considered how best to get working on our upcoming milestone Internet Draft documents.
The chairs proposed the possibility of having either (1) document "design teams" of authors or (2) "focus groups" in particular topics of expertise along with document editors.
Consensus was that design teams are preferred.
The design team's first task is to provide an outline for the document, which would be a framework in which folks with specific areas of expertise could participate.
Architecture
It was suggested that the architecture investigation drive the determination of what pieces are most important to address.
Data Model
Discussion began with this assertion:
"Flow attributes" include "packet properties" and "subsidiary information" indicating the packet treament and/or network element state.
There was some confusion as to what belongs in the data model.
[Note: the chairs ask the data model design team to clarify this. Please consider this definition as a starting point: The Data Model consists of data objects and structure to be exported and the record layouts used in their transfer.]
Twelve people, initially, volunteered to participate in the authoring of these two documents (either one or both).
4) We reviewed the WG milestones.
The Requirements document is scheduled to go to WG last call before IETF53.
The Architecture and Data Model Internet Drafts are also scheduled to have their first versions prepared before that next meeting.
5) * The Internet Draft, "A Framework for Passive Packet Measurement", was not presented. The chairs recommended reading the document.
* "Cisco's Future Plans for NetFlow: Version 9"
Will Eatherton and Vamsi Valluri.
This was a report on a template-based data tranfer format. It is work-in-progress that is being prepared as an Internet Draft, to be ready in about two months.
It was asked how a collector would know whether or not the same packets or bytes were being reported in more than one flow record (e.g. using a different template). It was agreed that this is illustrative of why IPFIX might need to define more than just data formats and transport.
* "Scalability Analysis of Flow Export Using TCP from a Router"
Ganesh Sadasivan.
This was a report on the potential implications of using TCP to transport NetFlow v5-like flow records from high capacity routers with relatively high link utilizations.
After the meeting the following people volunteered:
A D (A=Architecture, D=Data Model)
- -
X Carter Bullard
X X Paul Calato
X Will Eatherton
X X Reinaldo Penno Filho
X X Ram Gopal
X X Simon Leinen
X X KC Norseth
X X Juergen Quittek
X X Ganesh Sadasivan
X X Vamsi Valluri
X X Tanja Zseby
X Kevin Zhang
The chairs will set up mailing lists for these and any other volunteers for the Architecture and Data Model I-Ds.
Slides
Agenda
IPFIX Requirements
CRANE Version 1.0 - Updates
Netflow V9 Export Format
Scalability Analysis Of Netflow Export using TCP