Last Modifield: 05/23/2002
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.
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|
|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)|
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: http://ipfix.doit.wisc.edu/IETF55/ Mark Allman gave a short "public service announcement" regaring the IMRG: http://www.irtf.org/charters/imrg.html http://imrg.grc.nasa.gov/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 reliability/service. 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 "draft-ietf-ipfix-reqs-07.txt". 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 protocols. 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 possible. 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.