IPFIX Information Model <draft-ipfix-info-04.txt>

1. IPFIX Information Model<draft-ipfix-info-04.txt> Jeff Meyer, Juergen Quittek, Stewart Bryant 60th IETF meeting, IPFIX session

2. Changes Since Version -03 • No structural changes • structure converged • Current version is in an intermediate state • complete revision of all fields (Section 4) • but no corresponding editorial changes • still a lot to be done • still several fields missing, particularly for option records and scope • still some open issues • described on following slides 2

3. Field Definition Template • name - unique field name • fieldType - numeric identifier administered by IANA. • description - field semantics • dataType • dataTypeSemantics - integral types may be qualified by 'quantity', 'runningCounter', 'deltaCounter', 'identifier' or 'flags' • applicability - to option and/or data templates • status - to be added: current, deprecated, ... • vendorId (optional) - for vendor specific fields • usage - a description of the set of scopes in which this fields may be used 3

4. Variable Field Problem • Some fields contain values that may vary among packets • Obvious: Counters • Reporting their value after the last observed packet was processed • Not critical: max/min values • maxTTL, minTTL, maxPacketLength, etc. • Problem: reported header field values that are not constant over the observed packets • TTL, TCP flags, multicast replication factor, but also source address, etc. • Which value to report? • Do we need to indicate variations? 4

5. Variable Field Solutions • Which value to report? Three options: • allow any observed value • potentially different behavior of different probes • require it to be the last observed one • consistent with counter semantics • not efficient: overwriting of stored value required for each packet • require it to be the first observed one • efficient: stored just once when the flow record is created • Do we need an indicator for non-constant values? • No. It should be clear by the flow key specification. • Everything that is not part of the flow key is considered to be variable • Yes, otherwise constant and variable non-key fields cannot be distinguished. 5

6. Field Type Assignment • Field tyes 1-127 are reserved for NetFlowV9 compatibility • Some are used by IPFIX using the Cisco spec. • Some are not and marked as 'not used' • Few are still under discussion • Starting from field type 128, field type numbers are chosen by IPFIX info model editors • Future field type number assignment will be administrated by IANA 6

7. NetFlowV9 Compatibility • There are some (subtle) differences between the Cisco and the IPFIX model • Which policy to apply in case of minor conflicts? • Three examples • inOctetCount (#1) and outOctetCount (#23) • incoming traffic and outcoming traffic can be reported, but not bidirectional traffic • Shall we use #1 and extend ist definition to "optionally bi-directional"? • Shall we define another octetCount? • flowCount (#3) contains the number of Flows in the observation domain • if we need a counter for the number of flows per observation point, per exporting process, etc. • Shall we extend the specification • Shall we define new fields? 7

8. IANA Considerations • Suggestion by Benoit: • IANA maintains the field type number repository • IANA forwards individual requests for new field types to an assigned expert (team) • expert (team) checks for • accuracy and completeness of specification • security considerations • IANA assigns numbers after expert (team) approval 8

9. Packet Sampling Fields • Fields considering packet sampling are not covered. This is delegated to the psamp WG. • Flow Sampling is not covered yet. • Shall we support it? • Probably not, because the issues has not been studied sufficiently. 9