1 / 9

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

IPFIX Information Model <draft-ipfix-info-04.txt>. Jeff Meyer, Juergen Quittek, Stewart Bryant 60th IETF meeting, IPFIX session. Changes Since Version -03. No structural changes structure converged Current version is in an intermediate state complete revision of all fields (Section 4)

trevinom
Télécharger la présentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related