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

1
IPFIX Information Modelltdraft-ipfix-info-04.txtgt

• 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

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

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?

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.

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

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?

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

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.