view Side-By-Side changes

Network Working Group                                         J. Quittek
Internet-Draft                                                       NEC
Expires: March 26, December 21, 2006                                     S. Bryant
                                                               B. Claise
                                                           Cisco Systems
                                                                J. Meyer
                                                                  PayPal
                                                      September 22, 2005
                                                           June 19, 2006


            Information Model for IP Flow Information Export
                        draft-ietf-ipfix-info-11
                        draft-ietf-ipfix-info-12

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on March 26, December 21, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005). (2006).

Abstract

   This memo defines an information model for the IP Flow Information
   eXport (IPFIX) protocol.  It is used by the IPFIX protocol for
   encoding measured traffic information and information related to the
   traffic Observation Point, the traffic Metering Process and the



Quittek, et al.       draft-ietf-ipfix-info-11.txt              [Page 1]

Internet-Draft           IPFIX Information Model          September 2005               June 2006


   Exporting Process.  Although developed for the IPFIX protocol, the
   model is defined in an open way that easily allows using it in other
   protocols, interfaces, and applications.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   7
   2.  Properties of IPFIX Protocol Information Elements . . . . . .   7   8
     2.1.  Information Elements Specification Template . . . . . . .   8
     2.2.  Scope of Information Elements . . . . . . . . . . . . . .   9
     2.3.  Naming Conventions for Information Elements . . . . . . .   9  10
   3.  Type Space  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     3.1.  Abstract Data Types . . . . . . . . . . . . . . . . . . . . . . .  10
       3.1.1.  octet . .   unsigned8  . . . . . . . . . . . . . . . . . . . . . .  10  11
       3.1.2.   unsigned16 . . . . . . . . . . . . . . . . . . . . .  11
       3.1.3.   unsigned32 . . . . . . . . . . . . . . . . . . . . .  11
       3.1.4.   unsigned64 . . . . . . . . . . . . . . . . . . . . .  11
       3.1.5.  float32 .   signed8  . . . . . . . . . . . . . . . . . . . . . .  11
       3.1.6.  boolean .   signed16 . . . . . . . . . . . . . . . . . . . . . .  11
       3.1.7.  macAddress   signed32 . . . . . . . . . . . . . . . . . . . . . .  11
       3.1.8.  octetArray   signed64 . . . . . . . . . . . . . . . . . . . . . .  11
       3.1.9.  string  .   float32  . . . . . . . . . . . . . . . . . . . . . .  11
       3.1.10. dateTimeSeconds  float64  . . . . . . . . . . . . . . . . . . .  11 . . .  12
       3.1.11. dateTimeMilliSeconds  boolean  . . . . . . . . . . . . . . . .  12
       3.1.12. dateTimeMicroSeconds . . . . . .  12
       3.1.12.  macAddress . . . . . . . . . .  12
       3.1.13. dateTimeNanoSeconds . . . . . . . . . . .  12
       3.1.13.  octetArray . . . . . .  12
       3.1.14. ipv4Address . . . . . . . . . . . . . . .  12
       3.1.14.  string . . . . . .  12
       3.1.15. ipv6Address . . . . . . . . . . . . . . . . .  12
       3.1.15.  dateTimeSeconds  . . . .  12
     3.2.  Data Type Semantics . . . . . . . . . . . . . .  12
       3.1.16.  dateTimeMilliseconds . . . . .  12
       3.2.1.  quantity . . . . . . . . . . .  12
       3.1.17.  dateTimeMicroseconds . . . . . . . . . . .  12
       3.2.2.  totalCounter . . . . .  12
       3.1.18.  dateTimeNanoseconds  . . . . . . . . . . . . . . .  12
       3.2.3.  deltaCounter .  12
       3.1.19.  ipv4Address  . . . . . . . . . . . . . . . . . . .  13
       3.2.4.  identifier .  12
       3.1.20.  ipv6Address  . . . . . . . . . . . . . . . . . . . .  13
       3.2.5.  flags
     3.2.  Data Type Semantics . . . . . . . . . . . . . . . . . . .  13
       3.2.1.   quantity . . . . . . .  13
   4.  Information Element Identifiers . . . . . . . . . . . . . . .  13
   5.  Information Elements
       3.2.2.   totalCounter . . . . . . . . . . . . . . . . . . . .  17
     5.1.  Identifiers  13
       3.2.3.   deltaCounter . . . . . . . . . . . . . . . . . . . .  13
       3.2.4.   identifier . . .  18
       5.1.1.  lineCardId . . . . . . . . . . . . . . . . . .  13
       3.2.5.   flags  . . .  18
       5.1.2.  portId . . . . . . . . . . . . . . . . . . . .  14
   4.  Information Element Identifiers . . .  18
       5.1.3.  ingressInterface . . . . . . . . . . . .  14
   5.  Information Elements  . . . . . .  18
       5.1.4.  egressInterface . . . . . . . . . . . . . .  18
     5.1.  Identifiers . . . . .  19
       5.1.5.  meteringProcessId . . . . . . . . . . . . . . . . . .  19
       5.1.6.  exportingProcessId  18
       5.1.1.   lineCardId . . . . . . . . . . . . . . . . . . . . .  19
       5.1.7.  flowId
       5.1.2.   portId . . . . . . . . . . . . . . . . . . . . . . .  19
       5.1.8.  templateId
       5.1.3.   ingressInterface . . . . . . . . . . . . . . . . . .  19
       5.1.4.   egressInterface  . . . . .  20
       5.1.9.  sourceId . . . . . . . . . . . . .  20
       5.1.5.   meteringProcessId  . . . . . . . . .  20
     5.2.  Metering and Exporting Process Properties . . . . . . . .  20



Quittek, et al.       draft-ietf-ipfix-info-11.txt              [Page 2]

Internet-Draft           IPFIX Information Model          September 2005


       5.2.1.  exporterIPv4Address               June 2006


       5.1.6.   exportingProcessId . . . . . . . . . . . . . . . . .  21
       5.2.2.  exporterIPv6Address  20
       5.1.7.   flowId . . . . . . . . . . . . . . . . .  21
       5.2.3.  exportedMessageTotalCount . . . . . .  21
       5.1.8.   templateId . . . . . . . .  21
       5.2.4.  exportedOctetTotalCount . . . . . . . . . . . . .  21
       5.1.9.   observationDomainId  . .  21
       5.2.5.  exportedFlowTotalCount . . . . . . . . . . . . . .  21
       5.1.10.  observationPointId . .  22
       5.2.6.  observedFlowTotalCount . . . . . . . . . . . . . . .  22
       5.2.7.  ignoredPacketTotalCount
       5.1.11.  commonPropertiesId . . . . . . . . . . . . . . . . .  22
       5.2.8.  ignoredOctetTotalCount
     5.2.  Metering and Exporting Process Configuration  . . . . . .  22
       5.2.1.   exporterIPv4Address  . . . . . . . . .  22
       5.2.9.  notSentFlowTotalCount . . . . . . .  22
       5.2.2.   exporterIPv6Address  . . . . . . . . .  23
       5.2.10. notSentPacketTotalCount . . . . . . .  23
       5.2.3.   collectorIPv4Address . . . . . . . .  23
       5.2.11. notSentOctetTotalCount . . . . . . . .  23
       5.2.4.   collectorIPv6Address . . . . . . .  23
       5.2.12. flowKeyIndicator . . . . . . . . .  23
       5.2.5.   collectorInterface . . . . . . . . .  24
     5.3.  IP Header Fields . . . . . . . .  23
       5.2.6.   collectorProtocolVersion . . . . . . . . . . . .  24
       5.3.1.  ipVersion . . . . . . . . . .  24
       5.2.7.   collectorTransportProtocol . . . . . . . . . . . .  25
       5.3.2.  sourceIPv4Address .  24
       5.2.8.   collectorTransportPort . . . . . . . . . . . . . . .  24
       5.2.9.   flowKeyIndicator . .  25
       5.3.3.  sourceIPv6Address . . . . . . . . . . . . . . . .  25
     5.3.  Metering and Exporting Process Statistics . .  26
       5.3.4.  sourceIPv4Mask . . . . . .  25
       5.3.1.   exportedMessageTotalCount  . . . . . . . . . . . . .  26
       5.3.5.  sourceIPv6Mask
       5.3.2.   exportedOctetTotalCount  . . . . . . . . . . . . . .  26
       5.3.3.   exportedFlowRecordTotalCount . . . . .  26
       5.3.6.  sourceIPv4Prefix . . . . . . .  26
       5.3.4.   observedFlowTotalCount . . . . . . . . . . .  26
       5.3.7.  sourceIPv6Prefix . . . .  27
       5.3.5.   ignoredPacketTotalCount  . . . . . . . . . . . . . .  26
       5.3.8.  destinationIPv4Address  27
       5.3.6.   ignoredOctetTotalCount . . . . . . . . . . . . . . .  27
       5.3.9.  destinationIPv6Address  . .
       5.3.7.   notSentFlowTotalCount  . . . . . . . . . . . . .  27
       5.3.10. destinationIPv4Mask . .  28
       5.3.8.   notSentPacketTotalCount  . . . . . . . . . . . . . .  28
       5.3.9.   notSentOctetTotalCount .  27
       5.3.11. destinationIPv6Mask . . . . . . . . . . . . . .  28
     5.4.  IP Header Fields  . . .  27
       5.3.12. destinationIPv4Prefix . . . . . . . . . . . . . . . .  28
       5.3.13. destinationIPv6Prefix .  29
       5.4.1.   ipVersion  . . . . . . . . . . . . . . .  28
       5.3.14. ipTimeToLive . . . . . .  29
       5.4.2.   sourceIPv4Address  . . . . . . . . . . . . . .  28
       5.3.15. protocolIdentifier . . .  29
       5.4.3.   sourceIPv6Address  . . . . . . . . . . . . . .  28
       5.3.16. nextHeaderIPv6 . . .  30
       5.4.4.   sourceIPv4PrefixLength . . . . . . . . . . . . . . .  30
       5.4.5.   sourceIPv6PrefixLength .  29
       5.3.17. ipClassOfService . . . . . . . . . . . . . .  30
       5.4.6.   sourceIPv4Prefix . . . .  29
       5.3.18. ipDiffServCodePoint . . . . . . . . . . . . . .  30
       5.4.7.   sourceIPv6Prefix . . .  29
       5.3.19. ipPrecedence . . . . . . . . . . . . . . .  31
       5.4.8.   destinationIPv4Address . . . . .  30
       5.3.20. classOfServiceIPv4 . . . . . . . . . .  31
       5.4.9.   destinationIPv6Address . . . . . . .  30
       5.3.21. postClassOfServiceIPv4 . . . . . . . .  31
       5.4.10.  destinationIPv4PrefixLength  . . . . . . .  30
       5.3.22. classOfServiceIPv6 . . . . .  31
       5.4.11.  destinationIPv6PrefixLength  . . . . . . . . . . . .  31
       5.3.23. postClassOfServiceIPv6  . . .
       5.4.12.  destinationIPv4Prefix  . . . . . . . . . . . .  31
       5.3.24. flowLabelIPv6 . . .  32
       5.4.13.  destinationIPv6Prefix  . . . . . . . . . . . . . . .  32
       5.4.14.  ipTTL  . .  31
       5.3.25. isMulticast . . . . . . . . . . . . . . . . . . . . .  32
       5.3.26. identificationIPv4
       5.4.15.  protocolIdentifier . . . . . . . . . . . . . . . . .  32
       5.3.27. fragmentOffsetIPv4
       5.4.16.  nextHeaderIPv6 . . . . . . . . . . . . . . . . .  33
       5.3.28. fragmentFlagsIPv4 . .  33
       5.4.17.  ipDiffServCodePoint  . . . . . . . . . . . . . . . .  33
       5.3.29. ipHeaderLength
       5.4.18.  ipPrecedence . . . . . . . . . . . . . . . . . . .  33
       5.3.30. headerLengthIPv4 .  34
       5.4.19.  ipClassOfService . . . . . . . . . . . . . . . . . .  34
       5.3.31. internetHeaderLengthIPv4
       5.4.20.  postIpClassOfService . . . . . . . . . . . . . . . .  34
       5.3.32. totalLengthIPv4
       5.4.21.  flowLabelIPv6  . . . . . . . . . . . . . . . . . . .  34
       5.3.33. payloadLengthIPv6  35



Quittek, et al.       draft-ietf-ipfix-info-11.txt              [Page 3]

Internet-Draft           IPFIX Information Model               June 2006


       5.4.22.  isMulticast  . . . . . . . . . . . . . . . . . . . .  35
       5.3.34. ipPayloadLength
       5.4.23.  fragmentIdentification . . . . . . . . . . . . . . .  36
       5.4.24.  fragmentOffset . . . .  35
     5.4.  Transport Header Fields . . . . . . . . . . . . . . .  36
       5.4.25.  fragmentFlags  . .  35



Quittek, et al.       draft-ietf-ipfix-info-11.txt              [Page 3]

Internet-Draft           IPFIX Information Model          September 2005


       5.4.1.  sourceTransportPort . . . . . . . . . . . . . . . . .  36
       5.4.2.  destinationTransportPort  37
       5.4.26.  ipHeaderLength . . . . . . . . . . . . . .  36
       5.4.3.  udpSourcePort . . . . .  37
       5.4.27.  ipv4IHL  . . . . . . . . . . . . . . .  37
       5.4.4.  udpDestinationPort . . . . . . .  38
       5.4.28.  totalLengthIPv4  . . . . . . . . . .  37
       5.4.5.  udpMessageLength . . . . . . . .  38
       5.4.29.  payloadLengthIPv6  . . . . . . . . . .  37
       5.4.6.  tcpSourcePort . . . . . . .  38
       5.4.30.  ipPayloadLength  . . . . . . . . . . . . .  37
       5.4.7.  tcpDestinationPort . . . . .  39
     5.5.  Transport Header Fields . . . . . . . . . . . .  38
       5.4.8.  tcpSequenceNumber . . . . .  39
       5.5.1.   sourceTransportPort  . . . . . . . . . . . . .  38
       5.4.9.  tcpAcknowledgementNumber . . .  40
       5.5.2.   destinationTransportPort . . . . . . . . . . .  38
       5.4.10. tcpWindowSize . . .  40
       5.5.3.   udpSourcePort  . . . . . . . . . . . . . . . . .  38
       5.4.11. tcpUrgentPointer . .  41
       5.5.4.   udpDestinationPort . . . . . . . . . . . . . . . .  38
       5.4.12. tcpHeaderLength . . .  41
       5.5.5.   udpMessageLength . . . . . . . . . . . . . . . .  39
       5.4.13. icmpTypeCodeIPv4 . .  41
       5.5.6.   tcpSourcePort  . . . . . . . . . . . . . . . .  39
       5.4.14. icmpTypeIPv4 . . .  42
       5.5.7.   tcpDestinationPort . . . . . . . . . . . . . . . . .  39
       5.4.15. icmpCodeIPv4  42
       5.5.8.   tcpSequenceNumber  . . . . . . . . . . . . . . . . .  42
       5.5.9.   tcpAcknowledgementNumber . . .  39
       5.4.16. icmpTypeCodeIPv6 . . . . . . . . . . .  42
       5.5.10.  tcpWindowSize  . . . . . . .  40
       5.4.17. icmpTypeIPv6 . . . . . . . . . . . .  43
       5.5.11.  tcpUrgentPointer . . . . . . . .  40
       5.4.18. icmpCodeIPv6 . . . . . . . . . .  43
       5.5.12.  tcpHeaderLength  . . . . . . . . . .  40
       5.4.19. igmpType . . . . . . . .  43
       5.5.13.  icmpTypeCodeIPv4 . . . . . . . . . . . . . .  40
     5.5.  Sub-IP Header Fields . . . .  43
       5.5.14.  icmpTypeIPv4 . . . . . . . . . . . . . .  40
       5.5.1.  sourceMacAddress . . . . . .  44
       5.5.15.  icmpCodeIPv4 . . . . . . . . . . . .  41
       5.5.2.  postSourceMacAddress . . . . . . . .  44
       5.5.16.  icmpTypeCodeIPv6 . . . . . . . .  41
       5.5.3.  vlanId . . . . . . . . . .  44
       5.5.17.  icmpTypeIPv6 . . . . . . . . . . . . .  41
       5.5.4.  postVlanId . . . . . . .  44
       5.5.18.  icmpCodeIPv6 . . . . . . . . . . . . . .  42
       5.5.5.  destinationMacAddress . . . . . .  45
       5.5.19.  igmpType . . . . . . . . . .  42
       5.5.6.  postDestinationMacAddr . . . . . . . . . . . .  45
     5.6.  Sub-IP Header Fields  . . .  42
       5.5.7.  wlanChannelId . . . . . . . . . . . . . . .  45
       5.6.1.   sourceMacAddress . . . . .  42
       5.5.8.  wlanSsid . . . . . . . . . . . . .  46
       5.6.2.   postSourceMacAddress . . . . . . . . .  43
       5.5.9.  mplsTopLabelTtl . . . . . . .  46
       5.6.3.   vlanId . . . . . . . . . . . .  43
       5.5.10. mplsTopLabelExp . . . . . . . . . . .  46
       5.6.4.   postVlanId . . . . . . . .  43
       5.5.11. mplsLabelStackDepth . . . . . . . . . . . . .  47
       5.6.5.   destinationMacAddress  . . . .  44
       5.5.12. mplsLabelStackLength . . . . . . . . . . .  47
       5.6.6.   postDestinationMacAddr . . . . .  44
       5.5.13. mplsPayloadLength . . . . . . . . . .  47
       5.6.7.   wlanChannelId  . . . . . . . .  44
       5.5.14. mplsTopLabelStackEntry . . . . . . . . . . .  48
       5.6.8.   wlanSSID . . . .  44
       5.5.15. mplsLabelStackEntry2 . . . . . . . . . . . . . . . .  45
       5.5.16. mplsLabelStackEntry3 . .  48
       5.6.9.   mplsTopLabelTTL  . . . . . . . . . . . . . .  45
       5.5.17. mplsLabelStackEntry4 . . . .  48
       5.6.10.  mplsTopLabelExp  . . . . . . . . . . . .  45
       5.5.18. mplsLabelStackEntry5 . . . . . .  48
       5.6.11.  mplsLabelStackDepth  . . . . . . . . . .  46
       5.5.19. mplsLabelStackEntry6 . . . . . .  49
       5.6.12.  mplsLabelStackLength . . . . . . . . . .  46
       5.5.20. mplsLabelStackEntry7 . . . . . .  49
       5.6.13.  mplsPayloadLength  . . . . . . . . . .  46
       5.5.21. mplsLabelStackEntry8 . . . . . . .  49
       5.6.14.  mplsTopLabelStackEntry . . . . . . . . .  47
       5.5.22. mplsLabelStackEntry9 . . . . . .  50
       5.6.15.  mplsLabelStackEntry2 . . . . . . . . . .  47
       5.5.23. mplsLabelStackEntry10 . . . . . .  50
       5.6.16.  mplsLabelStackEntry3 . . . . . . . . . .  47
     5.6.  Derived Packet Properties . . . . . .  50
       5.6.17.  mplsLabelStackEntry4 . . . . . . . . . .  47
       5.6.1.  ipNextHopIPv4Address . . . . . .  51
       5.6.18.  mplsLabelStackEntry5 . . . . . . . . . .  48
       5.6.2.  ipNextHopIPv6Address . . . . . .  51



Quittek, et al.       draft-ietf-ipfix-info-11.txt              [Page 4]

Internet-Draft           IPFIX Information Model               June 2006


       5.6.19.  mplsLabelStackEntry6 . . . . . . . . . .  48
       5.6.3.  bgpSourceAsNumber . . . . . .  51
       5.6.20.  mplsLabelStackEntry7 . . . . . . . . . . . .  48
       5.6.4.  bgpDestinationAsNumber . . . .  52
       5.6.21.  mplsLabelStackEntry8 . . . . . . . . . . .  49



Quittek, et al.       draft-ietf-ipfix-info-11.txt              [Page 4]

Internet-Draft           IPFIX Information Model          September 2005


       5.6.5.  bgpNextAdjacentAsNumber . . . . .  52
       5.6.22.  mplsLabelStackEntry9 . . . . . . . . . .  49
       5.6.6.  bgpPrevAdjacentAsNumber . . . . . .  52
       5.6.23.  mplsLabelStackEntry10  . . . . . . . . .  49
       5.6.7.  bgpNextHopIPv4Address . . . . . .  53
     5.7.  Derived Packet Properties . . . . . . . . . .  50
       5.6.8.  bgpNextHopIPv6Address . . . . . .  53
       5.7.1.   ipNextHopIPv4Address . . . . . . . . . .  50
       5.6.9.  mplsTopLabelType . . . . . .  53
       5.7.2.   ipNextHopIPv6Address . . . . . . . . . . . .  50
       5.6.10. mplsTopLabelIPv4Address . . . .  53
       5.7.3.   bgpSourceAsNumber  . . . . . . . . . . .  50
       5.6.11. mplsTopLabelIPv6Address . . . . . .  54
       5.7.4.   bgpDestinationAsNumber . . . . . . . . .  51
     5.7.  Min/Max Flow Properties . . . . . .  54
       5.7.5.   bgpNextAdjacentAsNumber  . . . . . . . . . . .  51
       5.7.1.  minimumPacketLength . . .  54
       5.7.6.   bgpPrevAdjacentAsNumber  . . . . . . . . . . . . . .  51
       5.7.2.  maximumPacketLength  55
       5.7.7.   bgpNextHopIPv4Address  . . . . . . . . . . . . . . .  55
       5.7.8.   bgpNextHopIPv6Address  . . . .  51
       5.7.3.  minimumTtl . . . . . . . . . . .  55
       5.7.9.   mplsTopLabelType . . . . . . . . . .  52
       5.7.4.  maximumTtl . . . . . . . .  56
       5.7.10.  mplsTopLabelIPv4Address  . . . . . . . . . . . . .  52
       5.7.5.  ipv4Options .  56
       5.7.11.  mplsTopLabelIPv6Address  . . . . . . . . . . . . . .  56
       5.7.12.  mplsVpnRouteDistinguisher  . . . . . . .  52
       5.7.6.  ipv6ExtensionHeaders . . . . . .  57
     5.8.  Min/Max Flow Properties . . . . . . . . . .  54
       5.7.7.  tcpControlBits . . . . . . .  57
       5.8.1.   minimumPacketLength  . . . . . . . . . . . .  56
       5.7.8.  tcpOptions . . . .  57
       5.8.2.   maximumPacketLength  . . . . . . . . . . . . . . . .  58
       5.8.3.   minimumTTL .  56
     5.8.  Flow Time Stamps . . . . . . . . . . . . . . . . . . . .  57
       5.8.1.  flowStartSeconds  58
       5.8.4.   maximumTTL . . . . . . . . . . . . . . . . . .  57
       5.8.2.  flowEndSeconds . . .  58
       5.8.5.   ipv4Options  . . . . . . . . . . . . . . . . . . . .  58
       5.8.3.  flowStartMilliSeconds
       5.8.6.   ipv6ExtensionHeaders . . . . . . . . . . . . . . . .  58
       5.8.4.  flowEndMilliSeconds  60
       5.8.7.   tcpControlBits . . . . . . . . . . . . . . . . .  58
       5.8.5.  flowStartMicroSeconds . .  62
       5.8.8.   tcpOptions . . . . . . . . . . . . . .  58
       5.8.6.  flowEndMicroSeconds . . . . . . .  62
     5.9.  Flow Time Stamps  . . . . . . . . . .  58
       5.8.7.  flowStartNanoSeconds . . . . . . . . . .  63
       5.9.1.   flowStartSeconds . . . . . .  58
       5.8.8.  flowEndNanoSeconds . . . . . . . . . . . .  63
       5.9.2.   flowEndSeconds . . . . .  59
       5.8.9.  flowStartDeltaMicroSeconds . . . . . . . . . . . . .  59
       5.8.10. flowEndDeltaMicroSeconds .  64
       5.9.3.   flowStartMilliseconds  . . . . . . . . . . . . .  59
       5.8.11. systemInitTimeMilliSeconds . .  64
       5.9.4.   flowEndMilliseconds  . . . . . . . . . . .  59
       5.8.12. flowStartSysUpTime . . . . .  64
       5.9.5.   flowStartMicroseconds  . . . . . . . . . . . .  60
       5.8.13. flowEndSysUpTime . . .  64
       5.9.6.   flowEndMicroseconds  . . . . . . . . . . . . . . .  60
     5.9.  Per-Flow Counters .  64
       5.9.7.   flowStartNanoseconds . . . . . . . . . . . . . . . .  65
       5.9.8.   flowEndNanoseconds . . .  60
       5.9.1.  octetDeltaCount . . . . . . . . . . . . . .  65
       5.9.9.   flowStartDeltaMicroseconds . . . . .  61
       5.9.2.  postOctetDeltaCount . . . . . . . .  65
       5.9.10.  flowEndDeltaMicroseconds . . . . . . . . .  61
       5.9.3.  octetDeltaSumOfSquares . . . . .  65
       5.9.11.  systemInitTimeMilliseconds . . . . . . . . . .  61
       5.9.4.  octetTotalCount . . .  66
       5.9.12.  flowStartSysUpTime . . . . . . . . . . . . . . . .  62
       5.9.5.  postOctetTotalCount .  66
       5.9.13.  flowEndSysUpTime . . . . . . . . . . . . . . . .  62
       5.9.6.  octetTotalSumOfSquares . .  66
     5.10. Per-Flow Counters . . . . . . . . . . . . .  62
       5.9.7.  packetDeltaCount . . . . . . .  66
       5.10.1.  octetDeltaCount  . . . . . . . . . . .  62
       5.9.8.  postPacketDeltaCount . . . . . . .  67
       5.10.2.  postOctetDeltaCount  . . . . . . . . .  63
       5.9.9.  packetTotalCount . . . . . . .  67
       5.10.3.  octetDeltaSumOfSquares . . . . . . . . . . .  63
       5.9.10. postPacketTotalCount . . . .  68
       5.10.4.  octetTotalCount  . . . . . . . . . . . .  63
       5.9.11. droppedOctetDeltaCount . . . . . .  68
       5.10.5.  postOctetTotalCount  . . . . . . . . .  64
       5.9.12. droppedPacketDeltaCount . . . . . . .  68
       5.10.6.  octetTotalSumOfSquares . . . . . . . .  64
       5.9.13. droppedOctetTotalCount . . . . . . .  68



Quittek, et al.       draft-ietf-ipfix-info-11.txt              [Page 5]

Internet-Draft           IPFIX Information Model               June 2006


       5.10.7.  packetDeltaCount . . . . . . . .  64
       5.9.14. droppedPacketTotalCount . . . . . . . . . .  69
       5.10.8.  postPacketDeltaCount . . . . .  64
       5.9.15. postMCastPacketDeltaCount . . . . . . . . . . .  69
       5.10.9.  packetTotalCount . . .  65
       5.9.16. postMCastOctetDeltaCount . . . . . . . . . . . . . .  65
       5.9.17. postMCastPacketTotalCount .  69
       5.10.10. postPacketTotalCount . . . . . . . . . . . . .  65



Quittek, et al.       draft-ietf-ipfix-info-11.txt              [Page 5]

Internet-Draft           IPFIX Information Model          September 2005


       5.9.18. . . .  70
       5.10.11. droppedOctetDeltaCount . . . . . . . . . . . . . . .  70
       5.10.12. droppedPacketDeltaCount  . . . . . . . . . . . . . .  70
       5.10.13. droppedOctetTotalCount . . . . . . . . . . . . . . .  70
       5.10.14. droppedPacketTotalCount  . . . . . . . . . . . . . .  71
       5.10.15. postMCastPacketDeltaCount  . . . . . . . . . . . . .  71
       5.10.16. postMCastOctetDeltaCount . . . . . . . . . . . . . .  71
       5.10.17. postMCastPacketTotalCount  . . . . . . . . . . . . .  72
       5.10.18. postMCastOctetTotalCount . . . . . . . . . . . . . .  66
     5.10.  72
     5.11. Miscellaneous Flow Properties . . . . . . . . . . . . . .  66
       5.10.1. flowActiveTimeOut  72
       5.11.1.  flowActiveTimeout  . . . . . . . . . . . . . . . . .  73
       5.11.2.  flowIdleTimeout  .  66
       5.10.2. flowInactiveTimeout . . . . . . . . . . . . . . . . .  66
       5.10.3.  73
       5.11.3.  flowEndReason  . . . . . . . . . . . . . . . . . . . .  67
       5.10.4. flowDurationMilliSeconds  73
       5.11.4.  flowDurationMilliseconds . . . . . . . . . . . . . .  67
       5.10.5. flowDurationMicroSeconds  74
       5.11.5.  flowDurationMicroseconds . . . . . . . . . . . . . .  68
     5.11.  74
     5.12. Padding . . . . . . . . . . . . . . . . . . . . . . . . .  68
       5.11.1.  74
       5.12.1.  paddingOctets  . . . . . . . . . . . . . . . . . . . .  68  74
   6.  Extending the Information Model . . . . . . . . . . . . . . .  68  75
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  69  75
     7.1.  IPFIX Information Elements  . . . . . . . . . . . . . . .  75
     7.2.  MPLS Label Type Identifier  . . . . . . . . . . . . . . .  76
     7.3.  XML Namespace and Schema  . . . . . . . . . . . . . . . .  76
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  70  77
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  70  77
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  70  77
     10.1. Normative References  . . . . . . . . . . . . . . . . . .  70  77
     10.2. Informative References  . . . . . . . . . . . . . . . . .  70  77
   Appendix A.  Formal  XML Specification of IPFIX Information Element Elements  .  73 .  81
   Appendix B.  Formal  XML Specification of Abstract Data Types . . . . 127 . . 144
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . 139 156
   Intellectual Property and Copyright Statements  . . . . . . . . . 140 157

















Quittek, et al.       draft-ietf-ipfix-info-11.txt              [Page 6]

Internet-Draft           IPFIX Information Model          September 2005               June 2006


1.  Introduction

   The IP Flow Information eXport (IPFIX) protocol serves for
   transmitting information related to measured IP traffic over the
   Internet.  The protocol specification in [I-D.ietf-ipfix-protocol]
   defines how Information Elements are transmitted.  For Information
   Elements, it specifies the encoding of a set of basic data types.
   However, the list of Information Elements that can be transmitted by
   the protocol, such as Flow attributes (source IP address, number of
   packets, etc.) and information about the Metering and Exporting
   Process (packet Observation Point, sampling rate, Flow timeout
   interval, etc.), is not specified in [I-D.ietf-ipfix-protocol].

   This document complements the IPFIX protocol specification by
   providing the IPFIX information model.  IPFIX-specific terminology
   used in this document is defined in section 3 of [I-D.ietf-ipfix-
   protocol].  As in [I-D.ietf-ipfix-protocol], these IPFIX-specific
   terms have the first letter of a word capitalized when used in this
   document.

   The main part of this document is section 5 defining the (extensible)
   list of Information Elements to be transmitted by the IPFIX protocol.
   Section 2 defines a template for specifying IPFIX Information
   Elements in section 4. 5.  Section 3 defines the set of abstract data
   types that are available for IPFIX Information Elements.  Section 5 6
   discusses extensibility of the IPFIX information model.

   The main bodies of sections 2, 3 and 4 5 were generated from XML
   documents.  The XML-based specification of template, abstract data
   types and IPFIX Information Elements can be used for automatically
   checking syntactical correctness of the specification of IPFIX
   Information Elements.  It can further be used for generating IPFIX
   protocol implementation code that deals with processing IPFIX
   Information Elements.  Also code for applications that further
   process traffic information transmitted via the IPFIX protocol can be
   generated with the XML specification of IPFIX Information Elements.

   For that reason, the XML document that served as source for section 4 5
   and the XML schema that served as source for sections 2 and 3 are
   attached to this document in Appendices A and B.

   Note that although partially generated from the attached XML
   documents, the main body of this document is normative while the
   appendices are informational.


2.  Properties of IPFIX Protocol Information Elements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].



Quittek, et al.       draft-ietf-ipfix-info-11.txt              [Page 7]

Internet-Draft           IPFIX Information Model          September 2005               June 2006


2.  Properties of IPFIX Protocol Information Elements

2.1.  Information Elements Specification Template

   Information in messages of the IPFIX protocol is modeled in terms of
   Information Elements of the IPFIX information model.  IPFIX
   Information Elements are specified in section 4. 5.  For specifying
   these Information Elements, a template is used that is described
   below.

   All Information Elements specified for the IPFIX protocol either in
   this document or by any future extension MUST have the following
   properties defined:

   name - A unique and meaningful name for the Information Element.

   elementId - A numeric identifier of the Information Element.  If this
      identifier is used without an enterprise identifier (see
      [I-D.ietf-ipfix-protocol] and enterpriseId below), then it is
      globally unique and the list of allowed values is administered by
      IANA.  It is used for compact identification of an Information
      Element when encoding Templates in the protocol.

   description - The semantics of this Information Element.  Describes
      how this Information Element is derived from the Flow or other
      information available to the observer.

   dataType - One of the types listed in section 3.1 of this document or
      in a future extension of the information model.  The type space
      for attributes is constrained to facilitate implementation.  The
      existing type space does however encompass most basic types used
      in modern programming languages, as well as some derived types
      (such as ipv4Address) which are common to this domain and useful
      to distinguish.

   status - The status of the specification of this Information Element.
      Allowed values are 'current', 'deprecated', and 'obsolete'.


   Enterprise-specific Information Elements MUST have the following
   property defined:

   enterpriseId - Enterprises may wish to define Information Elements
      without registering them with IANA, for example for enterprise-
      internal purposes.  For such Information Elements the Information
      Element identifier described above is not sufficient when the
      Information Element is used outside the enterprise.  If
      specifications of enterprise-specific Information Elements are



Quittek, et al.       draft-ietf-ipfix-info-11.txt              [Page 8]

Internet-Draft           IPFIX Information Model               June 2006


      made public and/or if enterprise-specific identifiers are used by
      the IPFIX protocol outside the enterprise, then the enterprise-
      specific identifier MUST be made globally unique by combining it
      with an enterprise identifier.  Valid values for the enterpriseId
      are defined by IANA as SMI network management private enterprise
      codes.  They are defined at
      http://www.iana.org/assignments/enterprise-numbers.





Quittek, et al.       draft-ietf-ipfix-info-11.txt              [Page 8]

Internet-Draft           IPFIX Information Model          September 2005


   All Information Elements specified for the IPFIX protocol either in
   this document or by any future extension MAY have the following
   properties defined:

   dataTypeSemantics - The integral types may be qualified by additional
      semantic details.  Valid values for the data type semantics are
      specified in section 3.2 of this document or in a future extension
      of the information model.

   units - If the Information Element is a measure of some kind, the
      units identify what the measure is.

   range - Some Information Elements may only be able to take on a
      restricted set of values which can be expressed as a range (e.g. 0
      through 511 inclusive).  If this is the case, the valid inclusive
      range should be specified.

   reference - Identifies additional specifications which more precisely
      define this item or provide additional context for its use.


2.2.  Scope of Information Elements

   By default, most Information Elements have a scope specified in their
   definitions.

   o  The Information Elements defined in section 5.2 have a default of
      "a specific Metering Process" or of "a specific Exporting
      Process", respectively.
   o  The Information Elements defined in sections 5.3 - 5.9 have a
      scope of "a specific Flow".

   Within Data Records defined by Option Templates, the IPFIX protocol
   allows further limiting of the Information Element scope.  The new
   scope is specified by one or more scope fields and defined as the
   combination of all specified scope values. values, see section 3.4.2.1 on
   IPFIX scopes in [I-D.ietf-ipfix-protocol].





Quittek, et al.       draft-ietf-ipfix-info-11.txt              [Page 9]

Internet-Draft           IPFIX Information Model               June 2006


2.3.  Naming Conventions for Information Elements

   The following naming conventions were used for naming Information
   Elements in this document.  It is recommended that extensions of the
   model use the same conventions.

   o  Names of Information Elements start with non-capitalized letters.





Quittek, et al.       draft-ietf-ipfix-info-11.txt              [Page 9]

Internet-Draft           IPFIX Information Model          September 2005
   o  Composed names use capital letters for the first letter of each
      component (except for the first one).  All other letters are non-
      capitalized, even for acronyms.  Exceptions are made for acronyms
      containing non-capitalized letter, such as 'IPv4' and 'IPv6'.
      Examples are sourceMacAddress and destinationIPv4Address.
   o  Middleboxes [RFC3234] may change Flow properties, such as the DSCP
      value or the source IP address.  If an IPFIX Observation Point is
      located in the path of a Flow before one or more middleboxes that
      potentially modify packets of the Flow, then it may be desirable
      to report also flow Flow properties after the modification performed by
      the middleboxes.  An example is an observation point Observation Point before a
      packet marker changing a packet's IPv4 TOS field that is encoded
      in Information Element classOfServiceIPv4.  Then the value
      observed and reported by Information Element classOfServiceIPv4 is
      valid at the observation point, Observation Point, but not anymore after the packet
      passed the packet marker.  For reporting the change value of the
      TOS field, the IPFIX information model uses Information Elements
      that have a name prefix "post", for example,
      "postClassOfServiceIPv4".  Information Elements with prefix "post"
      report on Flow properties that are not necessarily observed at the
      observation point,
      Observation Point, but which are obtained withing within the Flow's
      Observation Domain by other means that are considered to be
      sufficiently reliable, for example, by analyzing the packet
      marker's marking tables.


3.  Type Space

   This section describes the abstract data types that can be used for
   the specification of IPFIX Information Elements in section 4.
   Section 3.1 describes the set of abstract data types.

   Data

   Abstract data types octet, unsigned8, unsigned16, unsigned32, unsigned64,
   signed8, signed16, signed32, and unsigned64 signed64 are integral data types.
   As described in section 3.2, their data type semantics can be further
   specified, for example, by 'totalCounter', 'deltaCounter',
   'identifier' or 'flags'.

3.1.  Abstract Data Types

   This section describes the set of valid abstract data types of the



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 10]

Internet-Draft           IPFIX Information Model               June 2006


   IPFIX information model.  Note that further abstract data types may
   be specified by future protocol extensions. extensions of the IPFIX information model.

3.1.1.  octet  unsigned8

   The type "octet" "unsigned8" represents a non-negative integer value in the
   range of 0 to 255.




Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 10]

Internet-Draft           IPFIX Information Model          September 2005

3.1.2.  unsigned16

   The type "unsigned16" represents a non-negative integer value in the
   range of 0 to 65535.

3.1.3.  unsigned32

   The type "unsigned32" represents a non-negative integer value in the
   range of 0 to 4294967295.

3.1.4.  unsigned64

   The type "unsigned64" represents a non-negative integer value in the
   range of 0 to 18446744073709551615.

3.1.5.  signed8

   The type "signed8" represents an integer value in the range of -128
   to 127.

3.1.6.  signed16

   The type "signed16" represents an integer value in the range of
   -32768 to 32767.

3.1.7.  signed32

   The type "signed32" represents an integer value in the range of
   -2147483648 to 2147483647.

3.1.8.  signed64

   The type "signed64" represents an integer value in the range of
   -9223372036854775808 to 9223372036854775807.

3.1.9.  float32

   The type "float32" corresponds to an IEEE single-precision 32-bit
   floating point type as defined in [IEEE.754.1985].

3.1.6.  boolean




Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 11]

Internet-Draft           IPFIX Information Model               June 2006


3.1.10.  float64

   The type "boolean" represents "float64" corresponds to an IEEE double-precision 64-bit
   floating point type as defined in [IEEE.754.1985].

3.1.11.  boolean

   The type "boolean" represents a binary value.  The only allowed
   values are "true" and false.

3.1.7. "false".

3.1.12.  macAddress

   The type "macAddress" represents a string of 6 octets.

3.1.8.

3.1.13.  octetArray

   The type "octetArray" represents a finite length string of octets.

3.1.9.

3.1.14.  string

   The type "string" represents a finite length string of valid
   characters from the Unicode character encoding set [ISO.10646-
   1.1993].  Unicode allows for ASCII [ISO.646.1991] and many other
   international character sets to be used.  It is expected that strings
   will be encoded in UTF-8 format, which is identical in encoding for
   ASCII characters, but also accommodates other Unicode multi-byte
   characters.

3.1.10.

3.1.15.  dateTimeSeconds

   The type "dateTimeSeconds" represents a time value in units of
   seconds normalized to the GMT time zone.




Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 11]

Internet-Draft           IPFIX Information Model          September 2005


3.1.11.  dateTimeMilliSeconds

3.1.16.  dateTimeMilliseconds

   The type "dateTimeMilliSeconds" "dateTimeMilliseconds" represents a time value in units of
   milliseconds normalized to the GMT time zone.

3.1.12.  dateTimeMicroSeconds

3.1.17.  dateTimeMicroseconds

   The type "dateTimeMicroSeconds" "dateTimeMicroseconds" represents a time value in units of
   microseconds normalized to the GMT time zone.

3.1.13.  dateTimeNanoSeconds

3.1.18.  dateTimeNanoseconds

   The type "dateTimeNanoSeconds" "dateTimeNanoseconds" represents a time value in units of
   nanoseconds normalized to the GMT time zone.

3.1.14.

3.1.19.  ipv4Address

   The type "ipv4Address" represents a value of an IPv4 address.

3.1.15.



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 12]

Internet-Draft           IPFIX Information Model               June 2006


3.1.20.  ipv6Address

   The type "ipv6Address" represents a value of an IPv6 address.

3.2.  Data Type Semantics

   This section describes the set of valid data type semantics of the
   IPFIX information model.  Note that further data type semantics may
   be specified by future protocol extensions. extensions of the IPFIX information model.

3.2.1.  quantity

   A quantity value represents a discrete measured value pertaining to
   the record.  This is distinguished from counters which represent an
   ongoing measured value whose "odometer" reading is captured as part
   of a given record.  If no semantic qualifier is given, the
   Information Elements that have an integral data type should behave as
   a quantity.

3.2.2.  totalCounter

   An integral value reporting the value of a counter.  Basically the
   same semantics as counters in SNMP.  Counters are
   unsigned and wrap back to zero after reaching the limit of the type.
   For example, an unsigned64 with counter semantics will continue to
   increment until reaching the value of 2**64 - 1.  At this point the
   next increment will wrap its value to zero and continue counting from
   zero.  The semantics of a total counter is similar to the semantics
   of counters used in SNMP, such as Counter32 defined in RFC 2578
   [RFC2578].  The only difference between total counters and counters
   used in SNMP is that the total counters have an initial value of 0.
   A
   running total counter counts independently of the export of its value.




Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 12]

Internet-Draft           IPFIX Information Model          September 2005

3.2.3.  deltaCounter

   An integral value reporting the value of a counter.  Basically the
   same semantics as counters in SNMP.  Counters are
   unsigned and wrap back to zero after reaching the limit of the type.
   For example, an unsigned64 with counter semantics will continue to
   increment until reaching the value of 2**64 - 1.  At this point the
   next increment will wrap its value to zero and continue counting from
   zero.  The semantics of a delta counter is similar to the semantics
   of counters used in SNMP, such as Counter32 defined in RFC 2578
   [RFC2578].  The only difference between delta counters and counters
   used in SNMP is that the delta counters have an initial value of 0.
   A delta counter is reset to zero 0 each time its value is exported.

3.2.4.  identifier

   An integral value which serves as an identifier.  Specifically



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 13]

Internet-Draft           IPFIX Information Model               June 2006


   mathematical operations on two identifiers (aside from the equality
   operation) are meaningless.  For example, Autonomous System ID 1 *
   Autonomous System ID 2 is meaningless.

3.2.5.  flags

   An integral value which actually represents a set of bit fields.
   Logical operations are appropriate on such values, but not other
   mathematical operations.  Flags should always be of an unsigned type.


4.  Information Element Identifiers

   All Information Elements defined in section 5 of this document or in
   future extensions of the IPFIX information model have their
   identifiers assigned by IANA.  Their identifiers can be retrieved at
   http://www.iana.org/assignments/ipfix-element-numbers.

   EDITORIAL NOTE: this URL needs probably to be updated after IANA
   created a URL for IPFIX Information Elements

   The value of these identifiers are in the range of 1 - 32767.  Within
   this range, Information Element identifier values in the sub-range of
   1-127 are compatible with field types used by NetFlow version 9
   [RFC3954].













Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 13]

Internet-Draft           IPFIX Information Model          September 2005











   +---------------------------------+---------------------------------+
   | Range of IANA-assigned          | Description                     |
   | Information Element identifiers |                                 |
   +---------------------------------+---------------------------------+
   | 0                               | Reserved.                       |
   | 1 - 127                         | Information Element identifiers |
   |                                 | compatible with NetFlow version |
   |                                 | 9 field types [RFC3954].        |
   | 128 - 32767                     | Further Information Element     |
   |                                 | identifiers.                    |
   +---------------------------------+---------------------------------+




Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 14]

Internet-Draft           IPFIX Information Model               June 2006


   Enterprise-specific Information Element identifiers have the same
   range of 1-32767, but they are coupled with an additional enterprise
   identifier.

   Enterprise-specific Information Element identifiers can be chosen by
   an enterprise arbitrarily within the range of 1-32767.  The same
   identifier may be assigned by other enterprises for different
   purposes.

   Still, Collecting Processes can distinguish these Information
   Elements because the Information Element identifier is coupled with
   an enterprise identifier.

   Enterprise identifiers MUST be registered as SMI network management
   private enterprise code numbers with IANA.  The registry can be found
   at http://www.iana.org/assignments/enterprise-numbers.





   The following list gives an overview of the Information Element
   identifiers that are specified in section 5 and are compatible with
   field types used by NetFlow version 9 [RFC3954].



























Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 14] 15]

Internet-Draft           IPFIX Information Model          September 2005               June 2006


   +-------+-------------------------+-------+-------------------------+
   |    ID | Name                    |    ID | Name                    |
   +-------+-------------------------+-------+-------------------------+
   |    1 | octetDeltaCount          |    43 | RESERVED                |
   |    2 | packetDeltaCount         |    44 | sourceIPv4Prefix        |
   |    3 | RESERVED                 |    45 | destinationIPv4Prefix   |
   |    4 | protocolIdentifier       |    46 | mplsTopLabelType        |
   |    5 | classOfServiceIPv4 ipClassOfService         |    47 | mplsTopLabelIPv4Address |
   |    6 | tcpControlBits           | 48-51 | RESERVED                |
   |    7 | sourceTransportPort      |    52 | minimumTtl minimumTTL              |
   |    8 | sourceIPv4Address        |    53 | maximumTtl maximumTTL              |
   |    9 | sourceIPv4Mask sourceIPv4PrefixLength   |    54 | identificationIPv4 fragmentIdentification  |
   |   10 | ingressInterface         |    55 | postClassOfServiceIPv4 postIpClassOfService    |
   |   11 | destinationTransportPort| destinationTransportPort |    56 | sourceMacAddress        |
   |   12 | destinationIPv4Address   |    57 | postDestinationMacAddr  |
   |   13 | destinationIPv4Mask     | destinationIPv4PrefixLength|  58 | vlanId                  |
   |   14 | egressInterface          |    59 | postVlanId              |
   |   15 | ipNextHopIPv4Address     |    60 | ipVersion               |
   |   16 | bgpSourceAsNumber        |    61 | RESERVED                |
   |   17 | bgpDestinationAsNumber   |    62 | ipNextHopIPv6Address    |
   |   18 | bgpNexthopIPv4Address    |    63 | bgpNexthopIPv6Address   |
   |   19 | postMCastPacketDeltaCount|    64 | ipv6ExtensionHeaders    |
   |   20 | postMCastOctetDeltaCount| postMCastOctetDeltaCount | 65-69 | RESERVED                |
   |   21 | flowEndSysUpTime         |    70 | mplsTopLabelStackEntry  |
   |   22 | flowStartSysUpTime       |    71 | mplsLabelStackEntry2    |
   |   23 | postOctetDeltaCount      |    72 | mplsLabelStackEntry3    |
   |   24 | postPacketDeltaCount     |    73 | mplsLabelStackEntry4    |
   |   25 | minimumPacketLength      |    74 | mplsLabelStackEntry5    |
   |   26 | maximumPacketLength      |    75 | mplsLabelStackEntry6    |
   |   27 | sourceIPv6Address        |    76 | mplsLabelStackEntry7    |
   |   28 | destinationIPv6Address   |    77 | mplsLabelStackEntry8    |
   |   29 | sourceIPv6Mask sourceIPv6PrefixLength   |    78 | mplsLabelStackEntry9    |
   |   30 | destinationIPv6Mask      |    79 | mplsLabelStackEntry10   |
   |   31 | flowLabelIPv6            |    80 | destinationMacAddress   |
   |   32 | icmpTypeCodeIPv4         |    81 | postSourceMacAddress    |
   |   33 | igmpType                 | 82-84 | RESERVED                |
   | 34-35
   |34-35 | RESERVED                 |    85 | octetTotalCount         |
   |   36 | flowActiveTimeOut flowActiveTimeout        |    86 | packetTotalCount        |
   |   37 | flowInactiveTimeout flowIdleTimeout          |    87 | RESERVED                |
   | 38-39
   |38-39 | RESERVED                 |    88 | fragmentOffsetIPv4 fragmentOffset          |
   |   40 | exportedOctetTotalCount |89-127  |    89 | RESERVED                |
   |   41 | exportedMessageTotalCount|    90 |mplsVpnRouteDistinguisher|
   |  42|exportedFlowRecordTotalCount|91-127 |
   |    42 | exportedFlowTotalCount  |       | RESERVED                |
   +-------+-------------------------+-------+-------------------------+

   The following list gives an overview of the Information Element
   identifiers that are specified in section 5 and extend the list of
   Information Element identifiers specified already in [RFC3954].



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 15] 16]

Internet-Draft           IPFIX Information Model          September 2005               June 2006


   +-----+---------------------------+-----+---------------------------+
   |  ID | Name                      |  ID | Name                      |
   +-----+---------------------------+-----+---------------------------+
   | 128 | bgpNextAdjacentAsNumber   | 172 | postPacketTotalCount      |
   | 129 | bgpPrevAdjacentAsNumber   | 173 | flowKeyIndicator          |
   | 130 | exporterIPv4Address       | 174 | postMCastPacketTotalCount |
   | 131 | exporterIPv6Address       | 175 | postMCastOctetTotalCount  |
   | 132 | droppedOctetDeltaCount    | 176 | icmpTypeIPv4              |
   | 133 | droppedPacketDeltaCount   | 177 | icmpCodeIPv4              |
   | 134 | droppedOctetTotalCount    | 178 | icmpTypeIPv6              |
   | 135 | droppedPacketTotalCount   | 179 | icmpCodeIPv6              |
   | 136 | flowEndReason             | 180 | udpSourcePort             |
   | 137 | classOfServiceIPv6 commonPropertiesId        | 181 | udpDestinationPort        |
   | 138 | postClassOfServiceIPv6 observationPointId        | 182 | tcpSourcePort             |
   | 139 | icmpTypeCodeIPv6          | 183 | tcpDestinationPort        |
   | 140 | mplsTopLabelIPv6Address   | 184 | tcpSequenceNumber         |
   | 141 | lineCardId                | 185 | tcpAcknowledgementNumber  |
   | 142 | portId                    | 186 | tcpWindowSize             |
   | 143 | meteringProcessId         | 187 | tcpUrgentPointer          |
   | 144 | exportingProcessId        | 188 | tcpHeaderLength           |
   | 145 | templateId                | 189 | ipHeaderLength            |
   | 146 | wlanChannelId             | 190 | totalLengthIPv4           |
   | 147 | wlanSsid wlanSSID                  | 191 | payloadLengthIPv6         |
   | 148 | flowId                    | 192 | ipTimeToLive ipTTL                     |
   | 149 | sourceId observationDomainId       | 193 | nextHeaderIPv6            |
   | 150 | flowStartSeconds          | 194 | ipClassOfService mplsPayloadLength         |
   | 151 | flowEndSeconds            | 195 | ipDiffServCodePoint       |
   | 152 | flowStartMilliSeconds flowStartMilliseconds     | 196 | ipPrecedence              |
   | 153 | flowEndMilliSeconds flowEndMilliseconds       | 197 | fragmentFlagsIPv4 fragmentFlags             |
   | 154 | flowStartMicroSeconds flowStartMicroseconds     | 198 | octetDeltaSumOfSquares    |
   | 155 | flowEndMicroSeconds flowEndMicroseconds       | 199 | octetTotalSumOfSquares    |
   | 156 | flowStartNanoSeconds flowStartNanoseconds      | 200 | mplsTopLabelTtl mplsTopLabelTTL           |
   | 157 | flowEndNanoSeconds flowEndNanoseconds        | 201 | mplsLabelStackLength      |
   | 158 | flowStartDeltaMicroSeconds| flowStartDeltaMicroseconds| 202 | mplsLabelStackDepth       |
   | 159 | flowEndDeltaMicroSeconds flowEndDeltaMicroseconds  | 203 | mplsTopLabelExp           |
   | 160 | systemInitTimeMilliSeconds| systemInitTimeMilliseconds| 204 | ipPayloadLength           |
   | 161 | flowDurationMilliSeconds flowDurationMilliseconds  | 205 | udpMessageLength          |
   | 162 | flowDurationMicroSeconds flowDurationMicroseconds  | 206 | isMulticast               |
   | 163 | observedFlowTotalCount    | 207 | internetHeaderLengthIPv4 ipv4IHL                   |
   | 164 | ignoredPacketTotalCount   | 208 | ipv4Options               |
   | 165 | ignoredOctetTotalCount    | 209 | tcpOptions                |
   | 166 | notSentFlowTotalCount     | 210 | paddingOctets             |
   | 167 | notSentPacketTotalCount   | 211 | collectorIPv4Address      |
   | 168 | notSentOctetTotalCount    | 212 | collectorIPv6Address      |
   | 169 | destinationIPv6Prefix     | 213 | headerLengthIPv4 collectorInterface        |
   | 170 | sourceIPv6Prefix          | 214 | mplsPayloadLength collectorProtocolVersion  |
   | 171 | postOctetTotalCount       | 215 | collectorTransportProtocol|
   |
   +-----+---------------------------+-----+---------------------------+



Quittek, et al.     |                           | 216 | collectorTransportPort    |



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 16] 17]

Internet-Draft           IPFIX Information Model          September 2005


   Information Element identifiers 211-212 are already in use by some
   implementations, but their descriptions were not agreed when this
   document was edited.               June 2006


   +-----+---------------------------+-----+---------------------------+


5.  Information Elements

   This section describes the Flow attributes Information Elements of the IPFIX
   information model.  The elements are grouped into 9 groups according
   to their semantics and their applicability:

   1.   Identifiers
   2.   Metering and Exporting Process Properties
   3.   IP Header Fields
   4.   Transport Header Fields
   5.   Sub-IP Header Fields
   6.   Derived Packet Properties
   7.   Min/Max Flow Properties
   8.   Flow Time Stamps
   9.   Per-Flow Counters
   10.  Miscellaneous Flow Properties

   The Information Elements that are derived from fields of packets or
   from packet treatment, such as the Information Elements in groups
   3.-6., can serve as Flow Keys used for mapping packets to Flows.

   If they do not serve as Flow Keys, their value may change from packet
   to packet within a single Flow.  For Information Elements with values
   that are derived from fields of packets or from packet treatment and
   for which the value may change from packet to packet within a single
   Flow, the IPFIX information model defines that their value is
   determined by the first packet observed for the corresponding Flow,
   unless the description of the Information Element explicitly
   specifies a different semantics.  This simple rule allows writing all
   Information Elements related to header fields once when the first
   packet of the Flow is observed.  For further observed packets of the
   same Flow, only Flow properties that depend on more than one packet,
   such as the Information Elements in groups 7.-9., need to be updated.

   Information Elements with a name having the "post" prefix, for
   example, "postClassOfServiceIPv4", do not report properties that were
   actually observed at the Observation Point, but retrieved by other
   means within the Observation Domain.  These information Elements can
   be used if there are middlebox functions within the Observation
   Domain changing Flow properties after packets passed the Observation
   Point.





Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 17]

Internet-Draft           IPFIX Information Model          September 2005

5.1.  Identifiers

   Information Elements grouped in the table below are identifying



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 18]

Internet-Draft           IPFIX Information Model               June 2006


   components of the IPFIX architecture, of an IPFIX Device, or of the
   IPFIX protocol.  All of them have an integral abstract data type and
   data type semantics "identifier" as described in section 3.2.4.

   Typically, some of them are used for limiting scopes of other
   Information Elements.  However, also other Information Elements MAY
   be used for limiting scopes.  Note also that all Information Elements
   listed below MAY be used for other purposes than limiting scopes.

   +-----+---------------------------+-----+---------------------------+
   |  ID | Name                      |  ID | Name                      |
   +-----+---------------------------+-----+---------------------------+
   | 141 | lineCardId                | 143 148 | meteringProcessId flowId                    |
   | 142 | portId                    | 144 145 | exportingProcessId templateId                |
   |  10 | ingressInterface          | 148 149 | flowId observationDomainId       |
   |  14 | egressInterface           | 145 138 | templateId observationPointId        |
   | 143 | meteringProcessId         | 137 | commonPropertiesId        |
   | 144 | exportingProcessId        | 149     | sourceId                           |
   +-----+---------------------------+-----+---------------------------+

5.1.1.  lineCardId

   Description:
      A locally unique
      An identifier of a line card at an that is unique per IPFIX Device
      hosting an Observation Point.  Typically, this Information Element
      is used for limiting the scope of other Information Elements.
   Abstract Data Type: unsigned32
   Data Type Semantics: identifier
   ElementId: 141
   Status: current

5.1.2.  portId

   Description:
      A locally unique identifier of a line port at an that is unique per IPFIX Device
      hosting an Observation Point.  Typically, this Information Element
      is used for limiting the scope of other Information Elements.
   Abstract Data Type: unsigned32
   Data Type Semantics: identifier
   ElementId: 142
   Status: current

5.1.3.  ingressInterface








Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 18] 19]

Internet-Draft           IPFIX Information Model          September 2005               June 2006


   Description:
      The index of the IP interface (ifIndex) where packets of this Flow are being
      received.  The value matches the value of managed object 'ifIndex'
      as defined in RFC 2863 [RFC2863].  Note that ifIndex values are
      not assigned statically to an interface, and that the interfaces
      may be renumbered every time the device's management system is re-
      initialized, as specified in RFC 2863 [RFC2863].
   Abstract Data Type: unsigned32
   Data Type Semantics: identifier
   ElementId: 10
   Status: current
   Reference:
      See RFC 2863 [RFC2863] for the definition of the ifIndex object.

5.1.4.  egressInterface

   Description:
      The index of the IP interface (ifIndex) where packets of this Flow are being
      sent.  The value matches the value of managed object 'ifIndex' as
      defined in RFC 2863 [RFC2863].  Note that ifIndex values are not
      assigned statically to an interface, and that the interfaces may
      be renumbered every time the device's management system is re-
      initialized, as specified in RFC 2863 [RFC2863].
   Abstract Data Type: unsigned32
   Data Type Semantics: identifier
   ElementId: 14
   Status: current
   Reference:
      See RFC 2863 [RFC2863] for the definition of the ifIndex object.

5.1.5.  meteringProcessId

   Description:
      A locally unique
      An identifier of a Metering Process at an that is unique per IPFIX
      Device.  Typically, this Information Element is used for limiting
      the scope of other Information Elements.  Note that process
      identifiers are typically assigned dynamically.  The Metering
      Process may be re-started with a different ID.
   Abstract Data Type: unsigned32
   Data Type Semantics: identifier
   ElementId: 143
   Status: current

5.1.6.  exportingProcessId







Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 20]

Internet-Draft           IPFIX Information Model               June 2006


   Description:
      A locally unique
      An identifier of an Exporting Process at an that is unique per IPFIX
      Device.  Typically, this Information Element is used for limiting
      the scope of other Information Elements.  Note that process
      identifiers are typically assigned dynamically.  The Exporting
      Process may be re-started with a different ID.
   Abstract Data Type: unsigned32
   Data Type Semantics: identifier
   ElementId: 144
   Status: current

5.1.7.  flowId








Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 19]

Internet-Draft           IPFIX Information Model          September 2005

   Description:
      An identifier of a Flow that is unique within an Observation
      Domain.  This Information Element can be used to distinguish
      between different Flows if Flow Keys such as IP addresses and port
      numbers are not reported or are reported in separate records.
   Abstract Data Type: unsigned32
   Data Type Semantics: identifier
   ElementId: 148
   Status: current

5.1.8.  templateId

   Description:
      An identifier of a Template that is locally unique to within the
      communication between an Exporting Process and a Collecting
      Process.  Typically, this Information Element is used for limiting
      the scope of other Information Elements.  Note that after a re-
      start of the Exporting Process Template identifiers may be re-
      assigned.
   Abstract Data Type: unsigned16
   Data Type Semantics: identifier
   ElementId: 145
   Status: current

5.1.9.  sourceId  observationDomainId

   Description:
      An identifier of an Observation Domain that is locally unique to
      an per
      Exporting Process.  It is RECOMMENDED that this identifier is also
      unique per IPFIX Device.  Typically, this Information Element is
      used for limiting the scope of other Information Elements.







Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 21]

Internet-Draft           IPFIX Information Model               June 2006


   Abstract Data Type: unsigned32
   Data Type Semantics: identifier
   ElementId: 149
   Status: current

5.1.10.  observationPointId

   Description:
      An identifier of an Observation Point that is unique per
      Observation Domain.  It is RECOMMENDED that this identifier is
      also unique per IPFIX Device.  Typically, this Information Element
      is used for limiting the scope of other Information Elements.
   Abstract Data Type: unsigned32
   Data Type Semantics: identifier
   ElementId: 138
   Status: current

5.1.11.  commonPropertiesId

   Description:
      An identifier of a set of common properties that is unique per
      Observation Domain.  Typically, this Information Element is used
      to link to information reported in separate records.
   Abstract Data Type: unsigned64
   Data Type Semantics: identifier
   ElementId: 137
   Status: current

5.2.  Metering and Exporting Process Properties Configuration

   Information Elements in this section describe static and dynamic
   properties the configuration of
   the Metering Process and/or or the Exporting Process.  The set of these
   Information Elements is listed in the table below

   +-----+---------------------------+-----+---------------------------+

   +-----+--------------------------+-----+----------------------------+
   |  ID | Name                     |  ID | Name                       |
   +-----+---------------------------+-----+---------------------------+
   +-----+--------------------------+-----+----------------------------+
   | 130 | exporterIPv4Address      | 164 213 | ignoredPacketTotalCount collectorInterface         |
   | 131 | exporterIPv6Address      | 165 | ignoredOctetTotalCount    |
   |  41 | exportedMessageTotalCount | 166 214 | notSentFlowTotalCount collectorProtocolVersion   |
   |  40 211 | exportedOctetTotalCount collectorIPv4Address     | 167 215 | notSentPacketTotalCount collectorTransportProtocol |
   |  42 212 | exportedFlowTotalCount collectorIPv6Address     | 168 216 | notSentOctetTotalCount collectorTransportPort     |
   | 163     | observedFlowTotalCount                          | 173 | flowKeyIndicator           |
   +-----+---------------------------+-----+---------------------------+
   +-----+--------------------------+-----+----------------------------+

5.2.1.  exporterIPv4Address






Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 20] 22]

Internet-Draft           IPFIX Information Model          September 2005


5.2.1.  exporterIPv4Address               June 2006


   Description:
      The IPv4 address used by the Exporting Process.  This is used by
      the Collector to identify the Exporter in cases where the identity
      of the Exporter may have been obscured by the use of a proxy.
   Abstract Data Type: ipv4Address
   Data Type Semantics: identifier
   ElementId: 130
   Status: current

5.2.2.  exporterIPv6Address

   Description:
      The IPv6 address used by the Exporting Process.  This is used by
      the Collector to identify the Exporter in cases where the identity
      of the Exporter may have been obscured by the use of a proxy.
   Abstract Data Type: ipv6Address
   Data Type Semantics: identifier
   ElementId: 131
   Status: current

5.2.3.  exportedMessageTotalCount  collectorIPv4Address

   Description:
      The total number of IPFIX Messages that the Exporting Process
      successfully sent since
      An IPv4 address to which the Exporting Process (re-)initialization sends Flow
      information.
   Abstract Data Type: ipv4Address
   Data Type Semantics: identifier
   ElementId: 211
   Status: current

5.2.4.  collectorIPv6Address

   Description:
      An IPv6 address to which the Collecting Exporting Process receiving a report that contains this
      Information Element. sends Flow
      information.
   Abstract Data Type: unsigned64 ipv6Address
   Data Type Semantics: totalCounter identifier
   ElementId: 41 212
   Status: current
   Units: messages

5.2.4.  exportedOctetTotalCount

5.2.5.  collectorInterface

   Description:
      The total number index of octets that the Exporting Process successfully
      sent since IP interface where the Exporting Process (re-)initialization to the
      Collecting Process receiving a report that contains this
      Information Element. sends
      Flow information.  The value of this Information Element is
      calculated by summing up matches the IPFIX Message header length values value of
      all IPFIX Messages managed object
      'ifIndex' as defined in RFC 2863 [RFC2863].  Note that were successfully sent ifIndex
      values are not assigned statically to the Collecting
      Process receiving a report an interface, and that contains this Information Element. the
      interfaces may be renumbered every time the device's management



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 21] 23]

Internet-Draft           IPFIX Information Model          September 2005               June 2006


      system is re-initialized, as specified in RFC 2863 [RFC2863].
   Abstract Data Type: unsigned64 unsigned32
   Data Type Semantics: totalCounter identifier
   ElementId: 40 213
   Status: current
   Units: octets

5.2.5.  exportedFlowTotalCount
   Reference:
      See RFC 2863 [RFC2863] for the definition of the ifIndex object.

5.2.6.  collectorProtocolVersion

   Description:
      The total number of Flows Records that protocol version used by the Exporting Process
      successfully sent as Data Records since for sending
      Flow information, The protocol version is given by the Exporting Process
      (re-)initialization to value of
      the Collecting Process receiving a report Version Number field in the Message Header.
      The protocol version is 10 for IPFIX and 9 for NetFlow version 9.
      A value of 0 indicates that contains this Information Element. no export protocol is in use.
   Abstract Data Type: unsigned64 unsigned8
   Data Type Semantics: totalCounter identifier
   ElementId: 42 214
   Status: current
   Units: Flows

5.2.6.  observedFlowTotalCount

   Description:
      The total number
   Reference:
      See [I-D.ietf-ipfix-protocol] for the definition of Flows observed in the Observation Domain since IPFIX
      Message header.  See RFC 3954 [RFC3954] or the Metering Process (re-)initialization for this Observation
      Point.
   Abstract Data Type: unsigned64
   Data Type Semantics: totalCounter
   ElementId: 163
   Status: current
   Units: Flows definition of the
      NetFlow version 9 message header.

5.2.7.  ignoredPacketTotalCount  collectorTransportProtocol

   Description:
      The total number value of observed IP packets that the Metering Process
      did not process since protocol number in the (re-)initialization of IP packet header.  The
      protocol number identifies the Metering
      Process.
   Abstract Data Type: unsigned64 IP packet payload type.  Protocol
      numbers are defined in the IANA Protocol Numbers registry.
      In Internet Protocol version 4 (IPv4) this is carried in the
      "Protocol" field.  In Internet Protocol version 6 (IPv6) this is
      carried in the "Next Header" field in the last extension header of
      the packet.
   Abstract Data Type: unsigned8
   Data Type Semantics: totalCounter identifier
   ElementId: 164 215
   Status: current
   Units: packets
   Reference:
      See RFC 791 [RFC0791] for the specification of the IPv4 protocol
      field.  See RFC 2460 [RFC2460] for the specification of the IPv6
      protocol field.  See the list of protocol numbers assigned by IANA
      at http://www.iana.org/assignments/protocol-numbers.

5.2.8.  ignoredOctetTotalCount  collectorTransportPort





Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 22] 24]

Internet-Draft           IPFIX Information Model          September 2005               June 2006


   Description:
      The total number of octets in observed IP packets that destination port identifier to which the
      Metering Exporting Process did not process since
      sends Flow information.  For the (re-)initialization of transport protocols UDP, TCP and
      SCTP this is the Metering Process. destination port number.  This field MAY also be
      used for future transport protocols that have 16 bit source port
      identifiers.
   Abstract Data Type: unsigned64 unsigned16
   Data Type Semantics: totalCounter identifier
   ElementId: 165 216
   Status: current
   Units: octets

5.2.9.  notSentFlowTotalCount

   Description:
      The total number of Flow Records that were generated by
   Reference:
      See RFC 768 [RFC0768] for the
      Metering Process and but dropped by definition of the Metering Process or by UDP destination
      port field.  See RFC 793 [RFC0793] for the
      Exporting Process instead definition of sending it to the Collecting Process.
      There are several potential reasons TCP
      destination port field.  See RFC 2960 [RFC2960] for this including resource
      shortage and special Flow export policies.
   Abstract Data Type: unsigned64
   Data Type Semantics: totalCounter
   ElementId: 166
   Status: current
   Units: Flows

5.2.10.  notSentPacketTotalCount

   Description:
      The total number the definition
      of packets in Flow Records that were generated by
      the Metering Process and but dropped by the Metering Process or by
      the Exporting Process instead of sending it to the Collecting
      Process.  There are several potential reasons for this including
      resource shortage and special Flow export policies.
   Abstract Data Type: unsigned64
   Data Type Semantics: totalCounter
   ElementId: 167
   Status: current
   Units: packets

5.2.11.  notSentOctetTotalCount

   Description:
      The total number of octets in packets in Flow Records that were
      generated by the Metering Process and but dropped by the Metering
      Process or by the Exporting Process instead of sending it to the
      Collecting Process.  There are several potential reasons for this
      including resource shortage SCTP.
      Additional information on defined UDP and special Flow export policies.





Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 23]

Internet-Draft           IPFIX Information Model          September 2005


   Abstract Data Type: unsigned64
   Data Type Semantics: totalCounter
   ElementId: 168
   Status: current
   Units: octets

5.2.12. TCP port numbers can be
      found at http://www.iana.org/assignments/port-numbers.

5.2.9.  flowKeyIndicator

   Description:
      This set of bit fields is used for marking the Information
      Elements of a Data Record that serve as Flow Key. Each bit
      represents an Information Element in the Data Record with the n-th
      bit representing the n-th Information Element.  A set bit with set to value
      1 indicates that the corresponding Information element Element is a Flow
      Key of the reported Flow.  A bit set to value of 0 indicates that
      this is not the case.
      If the Data Record contains more than 64 Information Elements, the
      corresponding Template SHOULD be designed such that all Flow Keys
      are among the first 64 Information Elements, because the
      flowKeyIndicator only contains 64 bits.  If the Data Record
      contains less than 64 Information Elements, then the bits in the
      flowKeyIndicator for which no corresponding Information Element
      exists SHOULD have the value 0.
   Abstract Data Type: unsigned64
   Data Type Semantics: flags
   ElementId: 173
   Status: current

5.3.  IP Header Fields  Metering and Exporting Process Statistics

   Information Elements in this section indicate values describe statistics of IP header
   fields or are derived from IP header field values the
   Metering Process and/or the Exporting Process.  The set of these
   Information Elements is listed in combination with
   further information. the table below






Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 24] 25]

Internet-Draft           IPFIX Information Model          September 2005


   +-----+---------------------------+-----+---------------------------+               June 2006


   +-----+-----------------------------+-----+-------------------------+
   |  ID | Name                        |  ID | Name                    |
   +-----+---------------------------+-----+---------------------------+
   |  60 | ipVersion                 | 195 | ipDiffServCodePoint       |
   |   8 | sourceIPv4Address         | 196 | ipPrecedence
   +-----+-----------------------------+-----+-------------------------+
   |  41 |  27 exportedMessageTotalCount   | sourceIPv6Address 165 |   5 ignoredOctetTotalCount  | classOfServiceIPv4
   |  40 |   9 exportedOctetTotalCount     | sourceIPv4Mask 166 |  55 notSentFlowTotalCount   | postClassOfServiceIPv4
   |  42 |  29 exportedFlowRecordTotalCount| 167 | sourceIPv6Mask notSentPacketTotalCount | 137
   | classOfServiceIPv6 163 | observedFlowTotalCount      |  44 168 | sourceIPv4Prefix notSentOctetTotalCount  | 138
   | postClassOfServiceIPv6 164 | ignoredPacketTotalCount     | 170     | sourceIPv6Prefix                         |  31 | flowLabelIPv6             |
   |  12 | destinationIPv4Address    | 206 | isMulticast               |
   |  28 | destinationIPv6Address    |  54 | identificationIPv4        |
   |  13 | destinationIPv4Mask       |  88 | fragmentOffsetIPv4        |
   |  30 | destinationIPv6Mask       | 197 | fragmentFlagsIPv4         |
   |  45 | destinationIPv4Prefix     | 189 | ipHeaderLength            |
   | 169 | destinationIPv6Prefix     | 213 | headerLengthIPv4          |
   | 192 | ipTimeToLive              | 207 | internetHeaderLengthIPv4  |
   |   4 | protocolIdentifier        | 190 | totalLengthIPv4           |
   | 193 | nextHeaderIPv6            | 191 | payloadLengthIPv6         |
   | 194 | ipClassOfService          | 204 | ipPayloadLength           |
   +-----+---------------------------+-----+---------------------------+
   +-----+-----------------------------+-----+-------------------------+

5.3.1.  ipVersion  exportedMessageTotalCount

   Description:
      The IP version field in the IP packet header.
   Abstract Data Type: octet
   Data Type Semantics: identifier
   ElementId: 60
   Status: current
   Reference:
      See RFC 791 for a definition total number of IPFIX Messages that the version field in the IPv4
      packet header.  See RFC 2460 for a definition of Exporting Process
      successfully sent since the version field
      in Exporting Process (re-)initialization
      to the IPv6 packet header.  Additional information on defined
      version numbers can be found at
      http://www.iana.org/assignments/version-numbers.

5.3.2.  sourceIPv4Address

   Description: Collecting Process receiving a report that contains this
      Information Element.  The IPv4 source address in reported number excludes the IP packet header.
   Abstract Data Type: ipv4Address
   Data Type Semantics: identifier
   ElementId: 8
   Status: current







Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 25]

Internet-Draft IPFIX Information Model          September 2005


   Reference: See RFC 791 for the definition of the IPv4 source address
      field.

5.3.3.  sourceIPv6Address

   Description:
      The IPv6 source address in
      Message that carries the IP packet header. counter value.
   Abstract Data Type: ipv6Address unsigned64
   Data Type Semantics: identifier totalCounter
   ElementId: 27 41
   Status: current

5.3.4.  sourceIPv4Mask
   Units: messages

5.3.2.  exportedOctetTotalCount

   Description:
      The total number of contiguous bits octets that are relevant in the
      sourceIPv4Prefix Information Element.
   Abstract Data Type: octet
   ElementId: 9
   Status: current
   Units: bits
   Range: Exporting Process successfully
      sent since the Exporting Process (re-)initialization to the
      Collecting Process receiving a report that contains this
      Information Element.  The valid range value of this Information Element is 0-32.

5.3.5.  sourceIPv6Mask

   Description:
      The number
      calculated by summing up the IPFIX Message Header length values of contiguous bits
      all IPFIX Messages that are relevant in were successfully sent to the
      sourceIPv6Prefix Collecting
      Process receiving a report that contains this Information Element.
   Abstract Data Type: octet
   ElementId: 29
   Status: current
   Units: bits
   Range:
      The valid range is 0-128.

5.3.6.  sourceIPv4Prefix

   Description:
      IPv4 source address prefix. reported number excludes octets in the IPFIX Message that
      carries the counter value.
   Abstract Data Type: ipv4Address unsigned64
   Data Type Semantics: totalCounter
   ElementId: 44 40
   Status: current

5.3.7.  sourceIPv6Prefix
   Units: octets

5.3.3.  exportedFlowRecordTotalCount








Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 26]

Internet-Draft           IPFIX Information Model          September 2005               June 2006


   Description:
      IPv6 source address prefix.
   Abstract
      The total number of Flows Records that the Exporting Process
      successfully sent as Data Type: ipv6Address
   ElementId: 170
   Status: current

5.3.8.  destinationIPv4Address

   Description: Records since the Exporting Process
      (re-)initialization to the Collecting Process receiving a report
      that contains this Information Element.  The IPv4 destination address reported number
      excludes Flow Records in the IP packet header. IPFIX message that carries the
      counter value.
   Abstract Data Type: ipv4Address unsigned64
   Data Type Semantics: identifier totalCounter
   ElementId: 12 42
   Status: current
   Reference: See RFC 791 for the definition of the IPv4 destination
      address field.

5.3.9.  destinationIPv6Address
   Units: flows

5.3.4.  observedFlowTotalCount

   Description:
      The IPv6 destination address total number of Flows observed in the IP packet header. Observation Domain since
      the Metering Process (re-)initialization for this Observation
      Point.
   Abstract Data Type: ipv6Address unsigned64
   Data Type Semantics: identifier totalCounter
   ElementId: 28 163
   Status: current

5.3.10.  destinationIPv4Mask
   Units: flows

5.3.5.  ignoredPacketTotalCount

   Description:
      The total number of contiguous bits observed IP packets that are relevant in the
      destinationIPv4Prefix Information Element.
   Abstract Data Type: octet Metering Process
      did not process since the (re-)initialization of the Metering
      Process.
   Abstract Data Type: unsigned64
   Data Type Semantics: totalCounter
   ElementId: 13 164
   Status: current
   Units: bits
   Range: The valid range is 0-32.

5.3.11.  destinationIPv6Mask packets

5.3.6.  ignoredOctetTotalCount

   Description:
      The total number of contiguous bits that are relevant octets in observed IP packets (including the
      destinationIPv6Prefix Information Element.
      IP header) that the Metering Process did not process since the
      (re-)initialization of the Metering Process.
   Abstract Data Type: octet
   ElementId: 30 unsigned64







Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 27]

Internet-Draft           IPFIX Information Model          September 2005


   Status: current
   Units: bits
   Range: The valid range is 0-128.

5.3.12.  destinationIPv4Prefix

   Description:
      IPv4 destination address prefix.
   Abstract               June 2006


   Data Type: ipv4Address Type Semantics: totalCounter
   ElementId: 45 165
   Status: current

5.3.13.  destinationIPv6Prefix
   Units: octets

5.3.7.  notSentFlowTotalCount

   Description:
      IPv6 destination address prefix.
      The total number of Flow Records that were generated by the
      Metering Process and but dropped by the Metering Process or by the
      Exporting Process instead of sending it to the Collecting Process.
      There are several potential reasons for this including resource
      shortage and special Flow export policies.
   Abstract Data Type: ipv6Address unsigned64
   Data Type Semantics: totalCounter
   ElementId: 169 166
   Status: current

5.3.14.  ipTimeToLive
   Units: Flows

5.3.8.  notSentPacketTotalCount

   Description:
      For IPv4, the value of the Information Element matches the value
      The total number of the Time to Live field packets in Flow Records that were generated by
      the IPv4 packet header.  For IPv6,
      the value of Metering Process and but dropped by the Information Element matches Metering Process or by
      the value Exporting Process instead of sending it to the Hop
      Limit field in the IPv6 packet header. Collecting
      Process.  There are several potential reasons for this including
      resource shortage and special Flow export policies.
   Abstract Data Type: octet unsigned64
   Data Type Semantics: totalCounter
   ElementId: 192 167
   Status: current
   Units: hops
   Reference: See RFC 791 for the definition of the IPv4 Time to Live
      field.  See RFC 2460 for the definition of the IPv6 Hop Limit
      field.

5.3.15.  protocolIdentifier packets

5.3.9.  notSentOctetTotalCount

   Description:
      The value of the protocol number in the IP packet header.  The
      protocol total number identifies the IP packet payload type.  Protocol
      numbers are defined of octets in the IANA Protocol Numbers registry.
      In Internet Protocol version 4 (IPv4) this is carried packets in Flow Records that were
      generated by the
      "Protocol" field.  In Internet Protocol version 6 (IPv6) this is
      carried in Metering Process and but dropped by the "Next Header" field in Metering
      Process or by the last extension header Exporting Process instead of sending it to the packet.
      Collecting Process.  There are several potential reasons for this
      including resource shortage and special Flow export policies.
   Abstract Data Type: unsigned64
   Data Type Semantics: totalCounter
   ElementId: 168







Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 28]

Internet-Draft           IPFIX Information Model          September 2005


   Abstract Data Type: octet
   Data Type Semantics: identifier
   ElementId: 4               June 2006


   Status: current
   Reference:
      See RFC 791 for the specification of the IPv4 protocol field.  See
      RFC 2460 for the specification of the IPv6 protocol field.  See
      the list of protocol numbers assigned by IANA at
      http://www.iana.org/assignments/protocol-numbers.

5.3.16.  nextHeaderIPv6

   Description:
      The value of the Next
   Units: octets

5.4.  IP Header field of the IPv6 header.  The value
      identifies the type Fields

   Information Elements in this section indicate values of the following IPv6 extension IP header
   fields or of
      the following are derived from IP payload.  Valid header field values are defined in the IANA
      Protocol Numbers registry.
   Abstract Data Type: octet
   ElementId: combination with
   further information.

   +-----+----------------------------+-----+--------------------------+
   |  ID | Name                       |  ID | Name                     |
   +-----+----------------------------+-----+--------------------------+
   |  60 | ipVersion                  | 193
   Status: current
   Reference: See RFC 2460 for the definition of the IPv6 Next Header
      field.  See the list of protocol numbers assigned by IANA at
      http://www.iana.org/assignments/protocol-numbers.

5.3.17. | nextHeaderIPv6           |
   |   8 | sourceIPv4Address          | 195 | ipDiffServCodePoint      |
   |  27 | sourceIPv6Address          | 196 | ipPrecedence             |
   |   9 | sourceIPv4PrefixLength     |   5 | ipClassOfService         |
   |  29 | sourceIPv6PrefixLength     |  55 | postIpClassOfService     |
   |  44 | sourceIPv4Prefix           |  31 | flowLabelIPv6            |
   | 170 | sourceIPv6Prefix           | 206 | isMulticast              |
   |  12 | destinationIPv4Address     |  54 | fragmentIdentification   |
   |  28 | destinationIPv6Address     |  88 | fragmentOffset           |
   |  13 | destinationIPv4PrefixLength| 197 | fragmentFlags            |
   |  30 | destinationIPv6PrefixLength| 189 | ipHeaderLength           |
   |  45 | destinationIPv4Prefix      | 207 | ipv4IHL                  |
   | 169 | destinationIPv6Prefix      | 190 | totalLengthIPv4          |
   | 192 | ipTTL                      | 191 | payloadLengthIPv6        |
   |   4 | protocolIdentifier         | 204 | ipPayloadLength          |
   +-----+----------------------------+-----+--------------------------+

5.4.1.  ipVersion

   Description:
      For IPv4 packets, this is the value of the TOS field in the IPv4
      packet header.  For IPv6 packets, this is the value of the Traffic
      Class
      The IP version field in the IPv6 IP packet header.
   Abstract Data Type: octet unsigned8
   Data Type Semantics: identifier
   ElementId: 194 60
   Status: current
   Reference:
      See section 5.3.2 of RFC 1812 and RFC 791 [RFC0791] for the a definition of the version field in the
      IPv4 TOS field. packet header.  See RFC 2460 [RFC2460] for the definition
      of the IPv6 Traffic Class field.

5.3.18.  ipDiffServCodePoint

   Description:
      The value of a Differentiated Services Code Point (DSCP) encoded
      in the Differentiated Services Field.  The Differentiated Services
      Field spans the most significant 6 bits definition of
      the IPv4 TOS version field or in the IPv6 Traffic class field, respectively. packet header.  Additional
      information on defined version numbers can be found at
      http://www.iana.org/assignments/version-numbers.

5.4.2.  sourceIPv4Address






Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 29]

Internet-Draft           IPFIX Information Model          September 2005


      This Information Element encodes only the 6 bits of               June 2006


   Description:
      The IPv4 source address in the
      Differentiated Services field.  Therefore its value may range from
      0 to 63. IP packet header.
   Abstract Data Type: octet ipv4Address
   Data Type Semantics: identifier
   ElementId: 195 8
   Status: current
   Range: The valid range is 0-63.
   Reference:
      See RFC 3260 for the definition of the Differentiated
      Services Field.  See section 5.3.2 of RFC 1812 and RFC 791 [RFC0791] for the definition of the IPv4 TOS field.  See RFC 2460 for the definition
      of the IPv6 Traffic Class source
      address field.

5.3.19.  ipPrecedence

5.4.3.  sourceIPv6Address

   Description:
      The value of the IP Precedence.  The IP Precedence value is
      encoded in the first 3 bits of the IPv4 TOS field or the IPv6
      Traffic class field, respectively.
      This Information Element encodes only the 3 bits of source address in the
      Differentiated Services field.  Therefore its value may range from
      0 to 7. IP packet header.
   Abstract Data Type: octet ipv6Address
   Data Type Semantics: identifier
   ElementId: 196 27
   Status: current

5.4.4.  sourceIPv4PrefixLength

   Description:
      The number of contiguous bits that are relevant in the
      sourceIPv4Prefix Information Element.
   Abstract Data Type: unsigned8
   ElementId: 9
   Status: current
   Units: bits
   Range: The valid range is 0-7.
   Reference: See section 5.3.3 of RFC 1812 and RFC 791 for the
      definition of the IP Precedence.  See section 5.3.2 of RFC 1812
      and RFC 791 for the definition of the IPv4 TOS field.  See RFC
      2460 for the definition of the IPv6 Traffic Class field.

5.3.20.  classOfServiceIPv4 0-32.

5.4.5.  sourceIPv6PrefixLength

   Description:
      The value number of the TOS field contiguous bits that are relevant in the IPv4 packet header.
      sourceIPv6Prefix Information Element.
   Abstract Data Type: octet
   Data Type Semantics: identifier unsigned8
   ElementId: 5 29
   Status: current
   Reference: See RFC 791 for the definition of the IPv4 TOS field.

5.3.21.  postClassOfServiceIPv4
   Units: bits
   Range: The valid range is 0-128.

5.4.6.  sourceIPv4Prefix

   Description:







Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 30]

Internet-Draft           IPFIX Information Model          September 2005


   Description:
      The definition of this Information Element is identical to the
      definition of Information Element 'classOfServiceIPv4', except
      that it reports a potentially modified value caused by a middlebox
      function after the packet passed the observation point.               June 2006


      IPv4 source address prefix.
   Abstract Data Type: octet ipv4Address
   ElementId: 44
   Status: current

5.4.7.  sourceIPv6Prefix

   Description:
      IPv6 source address prefix.
   Abstract Data Type Semantics: identifier Type: ipv6Address
   ElementId: 55 170
   Status: current
   Reference: See RFC 791 for the definition of the IPv4 TOS field.  See
      RFC 3234 for the definition of middleboxes.

5.3.22.  classOfServiceIPv6

5.4.8.  destinationIPv4Address

   Description:
      The value of the Traffic Class field IPv4 destination address in the IPv6 IP packet header.
   Abstract Data Type: octet ipv4Address
   Data Type Semantics: identifier
   ElementId: 137 12
   Status: current
   Reference:
      See RFC 2460 791 [RFC0791] for the definition of the IPv6 Traffic Class IPv4 destination
      address field.

5.3.23.  postClassOfServiceIPv6

5.4.9.  destinationIPv6Address

   Description:
      The definition of this Information Element is identical to the
      definition of Information Element 'classOfServiceIPv6', except
      that it reports a potentially modified value caused by a middlebox
      function after IPv6 destination address in the IP packet passed the observation point. header.
   Abstract Data Type: octet ipv6Address
   Data Type Semantics: identifier
   ElementId: 138 28
   Status: current
   Reference: See RFC 2460 for the definition of the IPv6 traffic class
      field.

5.3.24.  flowLabelIPv6

5.4.10.  destinationIPv4PrefixLength

   Description:
      The value number of the IPv6 Flow Label field contiguous bits that are relevant in the IP packet header.
      destinationIPv4Prefix Information Element.
   Abstract Data Type: unsigned32
   Data Type Semantics: identifier unsigned8
   ElementId: 31 13
   Status: current
   Units: bits
   Range: The valid range is 0-32.

5.4.11.  destinationIPv6PrefixLength





Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 31]

Internet-Draft           IPFIX Information Model          September 2005


   Status: current
   Reference: See RFC 2460 for a definition               June 2006


   Description:
      The number of the flow label field contiguous bits that are relevant in the IPv6 packet header.

5.3.25.  isMulticast
      destinationIPv6Prefix Information Element.
   Abstract Data Type: unsigned8
   ElementId: 30
   Status: current
   Units: bits
   Range: The valid range is 0-128.

5.4.12.  destinationIPv4Prefix

   Description:
      If the IP
      IPv4 destination address is a reserved multicast prefix.
   Abstract Data Type: ipv4Address
   ElementId: 45
   Status: current

5.4.13.  destinationIPv6Prefix

   Description:
      IPv6 destination address then prefix.
   Abstract Data Type: ipv6Address
   ElementId: 169
   Status: current

5.4.14.  ipTTL

   Description:
      For IPv4, the value of this the Information Element is not equal to zero.
      Otherwise, matches the value
      of all bits of the octet is zero.
      The first bit of this octet is set Time to 1 if the Version field of
      the IP header has the value 4 and if the Destination Address Live field
      contains a reserved multicast address in the range from 224.0.0.0
      to 239.255.255.255.  Otherwise, this bit is set to 0.
      The second and third bit of this octet are reserved for future
      use.
      The remaining bits of the octet are only set to values other than
      zero if th IP Destination Address is a reserved IPv6 multicast
      address.  Then the fourth bit of the octet is set to IPv4 packet header.  For IPv6,
      the value of the T flag in the IPv6 multicast address and the remaining four
      bits are set to Information Element matches the value of the scope Hop
      Limit field in the IPv6 multicast
      address.

             0      1      2      3      4      5      6      7
          +------+------+------+------+------+------+------+------+
          | MCv4 | RES. | RES. |  T   |   IPv6 multicast scope    |
          +------+------+------+------+------+------+------+------+

          Bit 0:    set to 1 if IPv4 multicast
          Bit 1-2:  reserved for future use
          Bit 4:    set to value of T-flag, if IPv6 multicast
          Bit 4-7:  set to value of multicast scope if IPv6 multicast packet header.
   Abstract Data Type: octet
   Data Type Semantics: flags unsigned8
   ElementId: 206 192
   Status: current
   Units: hops
   Reference:
      See RFC 1112 791 [RFC0791] for the specification definition of reserved the IPv4
      multicast addresses. Time to Live
      field.  See RFC 3513 2460 [RFC2460] for the specification of
      reserved IPv6 multicast addresses and the definition of the T-flag
      and the IPv6 multicast scope.

5.3.26.  identificationIPv4 Hop
      Limit field.

5.4.15.  protocolIdentifier

   Description:







Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 32]

Internet-Draft           IPFIX Information Model          September 2005


   Description:               June 2006


      The value of the IPv4 packet identification field protocol number in the IP packet header.  The
      protocol number identifies the IP packet payload type.  Protocol
      numbers are defined in the IANA Protocol Numbers registry.
      In Internet Protocol version 4 (IPv4) this is carried in the
      "Protocol" field.  In Internet Protocol version 6 (IPv6) this is
      carried in the "Next Header" field in the last extension header of
      the packet.
   Abstract Data Type: unsigned16 unsigned8
   Data Type Semantics: identifier
   ElementId: 54 4
   Status: current
   Reference:
      See RFC 791 [RFC0791] for the definition specification of the IPv4 identification protocol
      field.  See RFC 2460 [RFC2460] for the specification of the IPv6
      protocol field.

5.3.27.  fragmentOffsetIPv4  See the list of protocol numbers assigned by IANA
      at http://www.iana.org/assignments/protocol-numbers.

5.4.16.  nextHeaderIPv6

   Description:
      The value of the IPv4 fragment offset Next Header field in of the IP packet IPv6 header.  The value
      identifies the type of the following IPv6 extension header or of
      the following IP payload.  Valid values are defined in the IANA
      Protocol Numbers registry.
   Abstract Data Type: unsigned16
   Data Type Semantics: identifier unsigned8
   ElementId: 88 193
   Status: current
   Reference:
      See RFC 791 2460 [RFC2460] for the specification definition of the IPv4 fragment offset.

5.3.28.  fragmentFlagsIPv4 IPv6 Next Header
      field.  See the list of protocol numbers assigned by IANA at
      http://www.iana.org/assignments/protocol-numbers.

5.4.17.  ipDiffServCodePoint

   Description:
      The value of a Differentiated Services Code Point (DSCP) encoded
      in the Differentiated Services Field.  The Differentiated Services
      Field spans the fragmentation most significant 6 bits in of the IPv4 packet header.

         Bit 0:    reserved, must be zero.
         Bit 1:    (DF) 0 = May Fragment,  1 = Don't Fragment.
         Bit 2:    (MF) 0 = Last Fragment, 1 = More Fragments.
         Bits 3-7: (DC) Don't Care, value is irrelevant.

             0   1   2   3   4   5 TOS field or
      the IPv6 Traffic class field, respectively.
      This Information Element encodes only the 6   7
           +---+---+---+---+---+---+---+---+
           |   | D | M | D | D | D | D | D |
           | bits of the
      Differentiated Services field.  Therefore its value may range from
      0 | F | F | C | C | C | C | C |
           +---+---+---+---+---+---+---+---+ to 63.
   Abstract Data Type: octet unsigned8
   Data Type Semantics: flags
   ElementId: 197
   Status: current
   Reference:
      See RFC 791 for the specification of the IPv4 fragment flags.

5.3.29.  ipHeaderLength identifier







Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 33]

Internet-Draft           IPFIX Information Model          September 2005


   Description:
      The length of the IP header.  For IPv6, the value of this
      Information Element is 40.
   Abstract Data Type: octet               June 2006


   ElementId: 189 195
   Status: current
   Units: octets
   Range: The valid range is 0-63.
   Reference:
      See RFC 791 3260 [RFC3260] for the specification definition of the IPv4 header. Differentiated
      Services Field.  See section 5.3.2 of RFC
      2460 1812 [RFC1812] and RFC
      791 [RFC0791] for the specification of the IPv6 header.

5.3.30.  headerLengthIPv4

   Description:
      The length definition of the IPv4 header.
   Abstract Data Type: octet
   ElementId: 213
   Status: current
   Units: octets
   Reference: TOS field.  See RFC 791
      2460 [RFC2460] for the specification definition of the IPv4 header.

5.3.31.  internetHeaderLengthIPv4 IPv6 Traffic Class field.

5.4.18.  ipPrecedence

   Description:
      The value of the Internet Header Length (IHL) field IP Precedence.  The IP Precedence value is
      encoded in the first 3 bits of the IPv4
      header.  It specifies TOS field or the length of IPv6
      Traffic class field, respectively.
      This Information Element encodes only the header in units 3 bits of 4
      octets. the
      Differentiated Services field.  Therefore its value may range from
      0 to 7.
   Abstract Data Type: octet unsigned8
   Data Type Semantics: identifier
   ElementId: 207 196
   Status: current
   Units: 4 octets
   Range: The valid range is 0-7.
   Reference:
      See section 5.3.3 of RFC 1812 [RFC1812] and RFC 791 [RFC0791] for
      the specification definition of the IPv4 header.

5.3.32.  totalLengthIPv4

   Description:
      The total length IP Precedence.  See section 5.3.2 of the IPv4 packet.
   Abstract Data Type: unsigned16
   ElementId: 190
   Status: current
   Units: octets
   Reference:







Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 34]

Internet-Draft           IPFIX Information Model          September 2005


      See RFC
      1812 [RFC1812] and RFC 791 [RFC0791] for the specification definition of the
      IPv4 total length.

5.3.33.  payloadLengthIPv6

   Description:
      The length of the IPv6 payload, i.e., TOS field.  See RFC 2460 [RFC2460] for the rest definition of the packet
      following the
      IPv6 header, in octets.  Note that any extension
      headers present are considered part of the payload, i.e., included
      in the length count.
      This Information Element reports Traffic Class field.

5.4.19.  ipClassOfService

   Description:
      For IPv4 packets, this is the value of the Payload Length TOS field in the IPv4
      packet header.  For IPv6 header except in the case that the value of packets, this
      field is zero and that there is a valid jumbo payload option.
      Then the value of the Jumbo Payload Length Traffic
      Class field in the jumbo
      payload option is reported. IPv6 packet header.
   Abstract Data Type: unsigned32 unsigned8
   Data Type Semantics: identifier
   ElementId: 191 5
   Status: current
   Reference:
      See section 5.3.2 of RFC 2460 1812 [RFC1812] and RFC 791 [RFC0791] for
      the specification definition of the IPv6 payload length. IPv4 TOS field.  See RFC 2675 2460 [RFC2460] for
      the specification definition of the IPv6 jumbo payload
      length.

5.3.34.  ipPayloadLength Traffic Class field.

5.4.20.  postIpClassOfService





Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 34]

Internet-Draft           IPFIX Information Model               June 2006


   Description:
      The effective length of the IP payload.
      For IPv4 packets the value definition of this Information Element is identical to the
      difference between the total length of the IPv4 packet (as
      reported by Information Element totalLengthIPv4) and the length
      definition of
      the IPv4 header (as reported by Information Element
      headerLengthIPv4).
      For IPv6, the value of the Payload Length field in the IPv6 header
      is reported 'ipClassOfService', except in the case that the
      it reports a potentially modified value of this field is
      zero and that there is caused by a valid jumbo payload option.  In this case
      the value of middlebox
      function after the Jumbo Payload Length field in packet passed the jumbo payload
      option is reported. Observation Point.
   Abstract Data Type: unsigned64 unsigned8
   Data Type Semantics: identifier
   ElementId: 204 55
   Status: current
   Reference:
      See RFC 791 [RFC0791] for the specification definition of the IPv4 packets. TOS field.
      See RFC 2460 [RFC2460] for the specification definition of the IPv6 payload length. traffic
      class field.  See RFC 2675 3234 [RFC3234] for the specification of the IPv6 jumbo payload length.

5.4.  Transport Header Fields

   The set definition of Information Elements related to transport header fields
   and length includes the Information Elements listed in the table



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 35]

Internet-Draft           IPFIX Information Model          September 2005


   below.

   +-----+---------------------------+-----+---------------------------+
   |  ID | Name                      |  ID | Name                      |
   +-----+---------------------------+-----+---------------------------+
   |   7 | sourceTransportPort       | 187 | tcpUrgentPointer          |
   |  11 | destinationTransportPort  | 188 | tcpHeaderLength           |
   | 180 | udpSourcePort             |  32 | icmpTypeCodeIPv4          |
   | 181 | udpDestinationPort        | 176 | icmpTypeIPv4              |
   | 205 | udpMessageLength          | 177 | icmpCodeIPv4              |
   | 182 | tcpSourcePort             | 139 | icmpTypeCodeIPv6          |
   | 183 | tcpDestinationPort        | 178 | icmpTypeIPv6              |
   | 184 | tcpSequenceNumber         | 179 | icmpCodeIPv6              |
   | 185 | tcpAcknowledgementNumber  |  33 | igmpType                  |
   | 186 | tcpWindowSize             |     |                           |
   +-----+---------------------------+-----+---------------------------+

5.4.1.  sourceTransportPort
      middleboxes.

5.4.21.  flowLabelIPv6

   Description:
      The source port identifier in the transport header.  For the
      transport protocols UDP, TCP and SCTP this is value of the source port
      number given IPv6 Flow Label field in the respective IP packet header.  This field MAY also be
      used for future transport protocols that have 16 bit source port
      identifiers.
   Abstract Data Type: unsigned16 unsigned32
   Data Type Semantics: identifier
   ElementId: 7 31
   Status: current
   Reference:
      See RFC 768 2460 [RFC2460] for the a definition of the UDP source port field.  See
      RFC 793 for flow label field in
      the definition IPv6 packet header.

5.4.22.  isMulticast

   Description:
      If the IP destination address is a reserved multicast address then
      the value of this Information Element is not equal to zero.
      Otherwise, the TCP source port field.  See RFC
      2960 for value of all bits of the definition octet is zero.
      The first bit of SCTP.
      Additional information on defined UDP this octet is set to 1 if the Version field of
      the IP header has the value 4 and TCP port numbers can be
      found at http://www.iana.org/assignments/port-numbers.

5.4.2.  destinationTransportPort

   Description:
      The destination port identifier in if the transport header.  For Destination Address field
      contains a reserved multicast address in the
      transport protocols UDP, TCP range from 224.0.0.0
      to 239.255.255.255.  Otherwise, this bit is set to 0.
      The second and SCTP third bit of this octet are reserved for future
      use.
      The remaining bits of the octet are only set to values other than
      zero if the IP Destination Address is a reserved IPv6 multicast
      address.  Then the fourth bit of the octet is set to the destination port
      number given value of
      the T flag in the respective header.  This IPv6 multicast address and the remaining four
      bits are set to the value of the scope field MAY also be
      used for future transport protocols that have 16 bit destination
      port identifiers. in the IPv6 multicast
      address.






Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 36] 35]

Internet-Draft           IPFIX Information Model          September 2005


   Abstract Data Type: unsigned16
   Data Type Semantics: identifier
   ElementId: 11
   Status: current
   Reference:
      See RFC 768 for the definition of the UDP source port field.  See
      RFC 793 for the definition of the TCP source port field.  See RFC
      2960               June 2006


             0      1      2      3      4      5      6      7
          +------+------+------+------+------+------+------+------+
          | MCv4 | RES. | RES. |  T   |   IPv6 multicast scope    |
          +------+------+------+------+------+------+------+------+

          Bit 0:    set to 1 if IPv4 multicast
          Bit 1-2:  reserved for the definition future use
          Bit 4:    set to value of SCTP.
      Additional information on defined UDP and TCP port numbers can be
      found at http://www.iana.org/assignments/port-numbers.

5.4.3.  udpSourcePort

   Description: The source port identifier in the UDP header. T-flag, if IPv6 multicast
          Bit 4-7:  set to value of multicast scope if IPv6 multicast

   Abstract Data Type: unsigned16 unsigned8
   Data Type Semantics: identifier flags
   ElementId: 180 206
   Status: current
   Reference:
      See RFC 768 1112 [RFC1112] for the specification of reserved IPv4
      multicast addresses.  See RFC 3513 [RFC3513] for the specification
      of reserved IPv6 multicast addresses and the definition of the UDP source port
      field.  Additional information on defined UDP port numbers can be
      found at http://www.iana.org/assignments/port-numbers.

5.4.4.  udpDestinationPort
      T-flag and the IPv6 multicast scope.

5.4.23.  fragmentIdentification

   Description:
      The destination port identifier value of the Identification field in the UDP IPv4 packet header or
      the IPv6 Fragment header, respectively.  The value is 0 for IPv6
      if there is no Fragment header.
   Abstract Data Type: unsigned16 unsigned32
   Data Type Semantics: identifier
   ElementId: 181 54
   Status: current
   Reference:
      See RFC 768 791 [RFC0791] for the definition of the UDP source port IPv4
      Identification field.  Additional information on defined UDP port numbers can be
      found at http://www.iana.org/assignments/port-numbers.

5.4.5.  udpMessageLength  See RFC 2460 [RFC2460] for the definition
      of the Identification field in the IPv6 Fragment header.

5.4.24.  fragmentOffset

   Description:
      The value of the Length IP fragment offset field in the UDP IPv4 packet
      header or the IPv6 Fragment header, respectively.  The value is 0
      for IPv6 if there is no Fragment header.
   Abstract Data Type: unsigned16
   Data Type Semantics: identifier
   ElementId: 205 88







Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 36]

Internet-Draft           IPFIX Information Model               June 2006


   Status: current
   Units: octets
   Reference:
      See RFC 768 791 [RFC0791] for the specification of the UDP header.

5.4.6.  tcpSourcePort








Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 37]

Internet-Draft           IPFIX Information Model          September 2005


   Description: The source port identifier fragment offset
      in the TCP IPv4 header.
   Abstract Data Type: unsigned16
   Data Type Semantics: identifier
   ElementId: 182
   Status: current
   Reference:  See RFC 793 2460 [RFC2460] for the definition specification
      of the TCP source port
      field.  Additional information on defined TCP port numbers can be
      found at http://www.iana.org/assignments/port-numbers.

5.4.7.  tcpDestinationPort fragment offset in the IPv6 Fragment header.

5.4.25.  fragmentFlags

   Description:
      Fragmentation properties indicated by flags in the IPv4 packet
      header or the IPv6 Fragment header, respectively.


         Bit 0:    (RS) Reserved.
                   The destination port identifier value of this bit MUST be 0 until specified
                   otherwise.
         Bit 1:    (DF) 0 = May Fragment,  1 = Don't Fragment.
                   Corresponds to the value of the DF flag in the TCP
                   IPv4 header.  Will always be 0 for IPv6 unless
                   a "don't fragment" feature is introduced to IPv6.
         Bit 2:    (MF) 0 = Last Fragment, 1 = More Fragments.
                   Corresponds to the MF flag in the IPv4 header
                   or to the M flag in the IPv6 Fragment header,
                   respectively.  The value is 0 for IPv6 if there
                   is no Fragment header.
         Bits 3-7: (DC) Don't Care.
                   The values of these bits are irrelevant.

             0   1   2   3   4   5   6   7
           +---+---+---+---+---+---+---+---+
           | R | D | M | D | D | D | D | D |
           | S | F | F | C | C | C | C | C |
           +---+---+---+---+---+---+---+---+

   Abstract Data Type: unsigned16 unsigned8
   Data Type Semantics: identifier flags
   ElementId: 183 197
   Status: current
   Reference:
      See RFC 793 791 [RFC0791] for the definition specification of the TCP source port
      field.  Additional information on defined TCP port numbers can be
      found at http://www.iana.org/assignments/port-numbers.

5.4.8.  tcpSequenceNumber

   Description: The sequence number in the TCP header.
   Abstract Data Type: unsigned32
   ElementId: 184
   Status: current
   Reference: See RFC 793 for the definition of the TCP sequence number.

5.4.9.  tcpAcknowledgementNumber

   Description: The acknowledgement number in the TCP header.
   Abstract Data Type: unsigned32
   ElementId: 185
   Status: current
   Reference: IPv4 fragment
      flags.  See RFC 793 2460 [RFC2460] for the definition specification of the TCP acknowledgement
      number.

5.4.10.  tcpWindowSize

   Description: The window field in the TCP IPv6
      Fragment header.
   Abstract Data Type: unsigned16
   ElementId: 186
   Status: current
   Reference: See RFC 793 for the definition of the TCP window field.

5.4.11.  tcpUrgentPointer

5.4.26.  ipHeaderLength







Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 38] 37]

Internet-Draft           IPFIX Information Model          September 2005               June 2006


   Description:
      The urgent pointer in length of the TCP IP header.  For IPv6, the value of this
      Information Element is 40.
   Abstract Data Type: unsigned16 unsigned8
   ElementId: 187 189
   Status: current
   Units: octets
   Reference:
      See RFC 793 791 [RFC0791] for the definition of the TCP urgent pointer.

5.4.12.  tcpHeaderLength

   Description: The length specification of the TCP IPv4 header.
   Abstract Data Type: unsigned16
   ElementId: 188
   Status: current
   Units: octets
   Reference:
      See RFC 793 2460 [RFC2460] for the definition specification of the TCP IPv6 header.

5.4.13.  icmpTypeCodeIPv4

5.4.27.  ipv4IHL

   Description:
      Type and Code
      The value of the Internet Header Length (IHL) field in the IPv4 ICMP message.  The combination
      header.  It specifies the length of both
      values the header in units of 4
      octets.  Please note that its unit is reported as (ICMP type * 256) + ICMP code. different to most of the
      other Information Elements reporting length values.
   Abstract Data Type: unsigned16
   Data Type Semantics: identifier unsigned8
   ElementId: 32 207
   Status: current
   Units: 4 octets
   Reference:
      See RFC 792 791 [RFC0791] for a definition the specification of the IPv4 ICMP type and
      code fields.

5.4.14.  icmpTypeIPv4 header.

5.4.28.  totalLengthIPv4

   Description:
      Type
      The total length of the IPv4 ICMP message. packet.
   Abstract Data Type: octet
   Data Type Semantics: identifier unsigned16
   ElementId: 176 190
   Status: current
   Units: octets
   Reference:
      See RFC 792 791 [RFC0791] for a definition the specification of the IPv4 ICMP type field.

5.4.15.  icmpCodeIPv4 total
      length.

5.4.29.  payloadLengthIPv6

   Description:
      Code
      The length of the IPv4 ICMP message.
   Abstract Data Type: octet
   Data Type Semantics: identifier
   ElementId: 177 IPv6 payload, i.e., the rest of the packet
      following the IPv6 header, in octets.  Note that any extension
      headers present are considered part of the payload, i.e., included
      in the length count.







Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 39] 38]

Internet-Draft           IPFIX Information Model          September 2005


   Status: current
   Reference: See RFC 792 for a definition of               June 2006


      This Information Element reports the IPv4 ICMP code field.

5.4.16.  icmpTypeCodeIPv6

   Description:
      Type and Code value of the Payload Length
      field in the IPv6 ICMP message.  The combination header except in the case that the value of both
      values this
      field is zero and that there is reported as (ICMP type * 256) + ICMP code.
   Abstract Data Type: unsigned16
   Data Type Semantics: identifier
   ElementId: 139
   Status: current
   Reference: See RFC 2463 for a definition of valid jumbo payload option.
      Then the IPv6 ICMP type and
      code fields.

5.4.17.  icmpTypeIPv6

   Description:
      Type value of the IPv6 ICMP message. Jumbo Payload Length field in the jumbo
      payload option is reported.
   Abstract Data Type: octet
   Data Type Semantics: identifier unsigned32
   ElementId: 178 191
   Status: current
   Reference:
      See RFC 2463 2460 [RFC2460] for a definition of the IPv6 ICMP type field.

5.4.18.  icmpCodeIPv6

   Description:
      Code specification of the IPv6 ICMP message.
   Abstract Data Type: octet
   Data Type Semantics: identifier
   ElementId: 179
   Status: current
   Reference: payload
      length.  See RFC 2463 2675 [RFC2675] for a definition the specification of the IPv6 ICMP code field.

5.4.19.  igmpType
      jumbo payload length.

5.4.30.  ipPayloadLength

   Description:
      The type field effective length of the IGMP message.
   Abstract Data Type: octet
   Data Type Semantics: identifier
   ElementId: 33
   Status: current
   Reference: See RFC 2236 for a definition of IP payload.
      For IPv4 packets the IGMP type field. value of this Information Element is the
      difference between the total length of the IPv4 packet (as
      reported by Information Element totalLengthIPv4) and the length of
      the IPv4 header (as reported by Information Element
      headerLengthIPv4).
      For IPv6, the value of the Payload Length field in the IPv6 header
      is reported except in the case that the value of this field is
      zero and that there is a valid jumbo payload option.  In this case
      the value of the Jumbo Payload Length field in the jumbo payload
      option is reported.
   Abstract Data Type: unsigned64
   ElementId: 204
   Status: current
   Reference:
      See RFC 791 [RFC0791] for the specification of IPv4 packets.  See
      RFC 2460 [RFC2460] for the specification of the IPv6 payload
      length.  See RFC 2675 [RFC2675] for the specification of the IPv6
      jumbo payload length.

5.5.  Sub-IP  Transport Header Fields

   The set of Information Elements related to Sub-IP transport header fields
   and length includes the Information Elements listed in the table
   below.










Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 40] 39]

Internet-Draft           IPFIX Information Model          September 2005               June 2006


   +-----+---------------------------+-----+---------------------------+
   |  ID | Name                      |  ID | Name                      |
   +-----+---------------------------+-----+---------------------------+
   |  56 | sourceMacAddress          | 214 | mplsPayloadLength         |
   |  81 | postSourceMacAddress      |  70 | mplsTopLabelStackEntry    |
   |  58   7 | vlanId sourceTransportPort       |  71 187 | mplsLabelStackEntry2 tcpUrgentPointer          |
   |  59  11 | postVlanId destinationTransportPort  |  72 188 | mplsLabelStackEntry3 tcpHeaderLength           |
   |  80 180 | destinationMacAddress udpSourcePort             |  73  32 | mplsLabelStackEntry4 icmpTypeCodeIPv4          |
   |  57 181 | postDestinationMacAddr udpDestinationPort        |  74 176 | mplsLabelStackEntry5 icmpTypeIPv4              |
   | 146 205 | wlanChannelId udpMessageLength          |  75 177 | mplsLabelStackEntry6 icmpCodeIPv4              |
   | 147 182 | wlanSsid tcpSourcePort             |  76 139 | mplsLabelStackEntry7 icmpTypeCodeIPv6          |
   | 200 183 | mplsTopLabelTtl tcpDestinationPort        |  77 178 | mplsLabelStackEntry8 icmpTypeIPv6              |
   | 203 184 | mplsTopLabelExp tcpSequenceNumber         |  78 179 | mplsLabelStackEntry9 icmpCodeIPv6              |
   | 202 185 | mplsLabelStackDepth tcpAcknowledgementNumber  |  79  33 | mplsLabelStackEntry10 igmpType                  |
   | 201 186 | mplsLabelStackLength tcpWindowSize             |     |                           |
   +-----+---------------------------+-----+---------------------------+

5.5.1.  sourceMacAddress  sourceTransportPort

   Description:
      The IEEE 802 source MAC address field.
   Abstract Data Type: macAddress
   Data Type Semantics: port identifier
   ElementId: 56
   Status: current
   Reference: See IEEE.802-3.2002.

5.5.2.  postSourceMacAddress

   Description:
      The definition of in the transport header.  For the
      transport protocols UDP, TCP and SCTP this Information Element is identical to the
      definition of Information Element 'sourceMacAddress', except that
      it reports a potentially modified value caused by a middlebox
      function after the packet passed source port
      number given in the observation point. respective header.  This field MAY also be
      used for future transport protocols that have 16 bit source port
      identifiers.
   Abstract Data Type: macAddress unsigned16
   Data Type Semantics: identifier
   ElementId: 81 7
   Status: current
   Reference:
      See IEEE.802-3.2002.

5.5.3.  vlanId RFC 768 [RFC0768] for the definition of the UDP source port
      field.  See RFC 793 [RFC0793] for the definition of the TCP source
      port field.  See RFC 2960 [RFC2960] for the definition of SCTP.
      Additional information on defined UDP and TCP port numbers can be
      found at http://www.iana.org/assignments/port-numbers.

5.5.2.  destinationTransportPort

   Description:
      The IEEE 802.1Q VLAN destination port identifier (VID) extracted from in the Tag
      Control Information transport header.  For the
      transport protocols UDP, TCP and SCTP this is the destination port
      number given in the respective header.  This field MAY also be
      used for future transport protocols that was attached to the IP packet. have 16 bit destination
      port identifiers.
   Abstract Data Type: unsigned16
   Data Type Semantics: identifier







Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 41] 40]

Internet-Draft           IPFIX Information Model          September 2005


   Abstract Data Type: unsigned16
   Data Type Semantics: identifier               June 2006


   ElementId: 58 11
   Status: current
   Reference:
      See IEEE.802-1Q.2003.

5.5.4.  postVlanId

   Description:
      The RFC 768 [RFC0768] for the definition of this Information Element is identical to the UDP destination
      port field.  See RFC 793 [RFC0793] for the definition of Information Element 'vlanId', except that it reports
      a potentially modified value caused by a middlebox function after the packet passed TCP
      destination port field.  See RFC 2960 [RFC2960] for the observation point. definition
      of SCTP.
      Additional information on defined UDP and TCP port numbers can be
      found at http://www.iana.org/assignments/port-numbers.

5.5.3.  udpSourcePort

   Description:
      The source port identifier in the UDP header.
   Abstract Data Type: unsigned16
   Data Type Semantics: identifier
   ElementId: 59 180
   Status: current
   Reference:
      See IEEE.802-1Q.2003.

5.5.5.  destinationMacAddress RFC 768 [RFC0768] for the definition of the UDP source port
      field.  Additional information on defined UDP port numbers can be
      found at http://www.iana.org/assignments/port-numbers.

5.5.4.  udpDestinationPort

   Description:
      The IEEE 802 destination MAC address field. port identifier in the UDP header.
   Abstract Data Type: macAddress unsigned16
   Data Type Semantics: identifier
   ElementId: 80 181
   Status: current
   Reference:
      See IEEE.802-3.2002.

5.5.6.  postDestinationMacAddr

   Description:
      The definition of this Information Element is identical to RFC 768 [RFC0768] for the definition of Information Element 'destinationMacAddress', except
      that it reports a potentially modified the UDP destination
      port field.  Additional information on defined UDP port numbers
      can be found at http://www.iana.org/assignments/port-numbers.

5.5.5.  udpMessageLength

   Description:
      The value caused by a middlebox
      function after of the packet passed Length field in the observation point. UDP header.
   Abstract Data Type: macAddress
   Data Type Semantics: identifier unsigned16
   ElementId: 57 205
   Status: current
   Reference: See IEEE.802-3.2002.

5.5.7.  wlanChannelId
   Units: octets







Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 42] 41]

Internet-Draft           IPFIX Information Model          September 2005               June 2006


   Reference:
      See RFC 768 [RFC0768] for the specification of the UDP header.

5.5.6.  tcpSourcePort

   Description:
      The source port identifier of in the 802.11 (Wi-Fi) channel used. TCP header.
   Abstract Data Type: octet unsigned16
   Data Type Semantics: identifier
   ElementId: 146 182
   Status: current
   Reference:
      See IEEE.802-11.1999.

5.5.8.  wlanSsid RFC 793 [RFC0793] for the definition of the TCP source port
      field.  Additional information on defined TCP port numbers can be
      found at http://www.iana.org/assignments/port-numbers.

5.5.7.  tcpDestinationPort

   Description:
      The Service Set IDentifier (SSID) identifying an 802.11 (Wi-Fi)
      network used.  According to IEEE.802-11.1999 destination port identifier in the SSID is encoded
      into a string of up to 32 characters. TCP header.
   Abstract Data Type: string unsigned16
   Data Type Semantics: identifier
   ElementId: 147 183
   Status: current
   Reference:
      See IEEE.802-11.1999.

5.5.9.  mplsTopLabelTtl

   Description: The TTL field from the top MPLS label stack entry, i.e. RFC 793 [RFC0793] for the last label that was pushed. definition of the TCP source port
      field.  Additional information on defined TCP port numbers can be
      found at http://www.iana.org/assignments/port-numbers.

5.5.8.  tcpSequenceNumber

   Description:
      The sequence number in the TCP header.
   Abstract Data Type: unsigned32
   ElementId: 200 184
   Status: current
   Reference:
      See RFC 3032 793 [RFC0793] for the specification definition of the TTL field.

5.5.10.  mplsTopLabelExp TCP sequence
      number.

5.5.9.  tcpAcknowledgementNumber

   Description:
      The Exp field from the top MPLS label stack entry, i.e. acknowledgement number in the last
      label that was pushed.

         Bit 0-4:  Don't Care, value is irrelevant.
         Bit 5-7:  MPLS Exp field

             0   1   2   3   4   5   6   7
           +---+---+---+---+---+---+---+---+
           |     don't care    |    Exp    |
           +---+---+---+---+---+---+---+---+

   Abstract Data Type: octet
   Data Type Semantics: flags TCP header.







Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 43] 42]

Internet-Draft           IPFIX Information Model          September 2005               June 2006


   Abstract Data Type: unsigned32
   ElementId: 203 185
   Status: current
   Reference:
      See RFC 3032 793 [RFC0793] for the specification of the Exp field.  See
      RFC 3270 for usage definition of the Exp field.

5.5.11.  mplsLabelStackDepth TCP
      acknowledgement number.

5.5.10.  tcpWindowSize

   Description:
      The number of labels window field in the MPLS label stack. TCP header.
   Abstract Data Type: unsigned32 unsigned16
   ElementId: 202 186
   Status: current
   Units: label stack entries
   Reference:
      See RFC 3032 793 [RFC0793] for the specification definition of the MPLS label
      stack.

5.5.12.  mplsLabelStackLength TCP window field.

5.5.11.  tcpUrgentPointer

   Description:
      The length of the MPLS label stack urgent pointer in units of octets. the TCP header.
   Abstract Data Type: unsigned32 unsigned16
   ElementId: 201 187
   Status: current
   Units: octets
   Reference:
      See RFC 3032 793 [RFC0793] for the specification definition of the MPLS label
      stack.

5.5.13.  mplsPayloadLength TCP urgent
      pointer.

5.5.12.  tcpHeaderLength

   Description:
      The size length of the MPLS packet without the label stack. TCP header.
   Abstract Data Type: unsigned32 unsigned16
   ElementId: 214 188
   Status: current
   Units: octets
   Reference:
      See RFC 3031 793 [RFC0793] for the specification definition of MPLS packets.  See
      RFC 3032 for the specification TCP header.

5.5.13.  icmpTypeCodeIPv4

   Description:
      Type and Code of the MPLS label stack.

5.5.14.  mplsTopLabelStackEntry

   Description: IPv4 ICMP message.  The label, exp and s fields from the top MPLS label stack entry,
      i.e. the last label that was pushed. combination of both
      values is reported as (ICMP type * 256) + ICMP code.







Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 44] 43]

Internet-Draft           IPFIX Information Model          September 2005


       0                   1                   2
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Label                  | Exp |S|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Label:  Label Value, 20 bits
      Exp:    Experimental Use, 3 bits
      S:      Bottom of Stack, 1 bit               June 2006


   Abstract Data Type: unsigned32 unsigned16
   Data Type Semantics: identifier
   ElementId: 70 32
   Status: current
   Reference:
      See RFC 3032.

5.5.15.  mplsLabelStackEntry2

   Description:
      The label, exp, and s fields from 792 [RFC0792] for a definition of the label stack entry that was
      pushed immediately before IPv4 ICMP type and
      code fields.

5.5.14.  icmpTypeIPv4

   Description:
      Type of the label stack entry that would be
      reported by mplsTopLabelStackEntry. IPv4 ICMP message.
   Abstract Data Type: unsigned8
   Data Type Semantics: identifier
   ElementId: 176
   Status: current
   Reference:
      See the RFC 792 [RFC0792] for a definition of
      mplsTopLabelStackEntry for further details. the IPv4 ICMP type
      field.

5.5.15.  icmpCodeIPv4

   Description:
      Code of the IPv4 ICMP message.
   Abstract Data Type: unsigned32 unsigned8
   Data Type Semantics: identifier
   ElementId: 71 177
   Status: current
   Reference:
      See RFC 3032. 792 [RFC0792] for a definition of the IPv4 ICMP code
      field.

5.5.16.  mplsLabelStackEntry3  icmpTypeCodeIPv6

   Description:
      The label, exp,
      Type and s fields from the label stack entry that was
      pushed immediately before the label stack entry that would be
      reported by mplsLabelStackEntry2.  See Code of the definition IPv6 ICMP message.  The combination of
      mplsTopLabelStackEntry for further details. both
      values is reported as (ICMP type * 256) + ICMP code.
   Abstract Data Type: unsigned32 unsigned16
   Data Type Semantics: identifier
   ElementId: 72 139
   Status: current
   Reference:
      See RFC 3032.

5.5.17.  mplsLabelStackEntry4








Quittek, et al.       draft-ietf-ipfix-info-11.txt 2463 [RFC2463] for a definition of the IPv6 ICMP type and
      code fields.

5.5.17.  icmpTypeIPv6





Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 45] 44]

Internet-Draft           IPFIX Information Model          September 2005               June 2006


   Description:
      The label, exp, and s fields from the label stack entry that was
      pushed immediately before the label stack entry that would be
      reported by mplsLabelStackEntry3.  See the definition
      Type of
      mplsTopLabelStackEntry for further details. the IPv6 ICMP message.
   Abstract Data Type: unsigned32 unsigned8
   Data Type Semantics: identifier
   ElementId: 73 178
   Status: current
   Reference:
      See RFC 3032. 2463 [RFC2463] for a definition of the IPv6 ICMP type
      field.

5.5.18.  mplsLabelStackEntry5  icmpCodeIPv6

   Description:
      The label, exp, and s fields from the label stack entry that was
      pushed immediately before the label stack entry that would be
      reported by mplsLabelStackEntry4.  See the definition
      Code of
      mplsTopLabelStackEntry for further details. the IPv6 ICMP message.
   Abstract Data Type: unsigned32 unsigned8
   Data Type Semantics: identifier
   ElementId: 74 179
   Status: current
   Reference:
      See RFC 3032. 2463 [RFC2463] for a definition of the IPv6 ICMP code
      field.

5.5.19.  mplsLabelStackEntry6  igmpType

   Description:
      The label, exp, and s fields from the label stack entry that was
      pushed immediately before the label stack entry that would be
      reported by mplsLabelStackEntry5.  See the definition type field of
      mplsTopLabelStackEntry for further details. the IGMP message.
   Abstract Data Type: unsigned32 unsigned8
   Data Type Semantics: identifier
   ElementId: 75 33
   Status: current
   Reference:
      See RFC 3032.

5.5.20.  mplsLabelStackEntry7

   Description: 2236 [RFC2236] for a definition of the IGMP type field.

5.6.  Sub-IP Header Fields

   The label, exp, and s set of Information Elements related to Sub-IP header fields from the label stack entry that was
      pushed immediately before
   includes the label stack entry that would be
      reported by mplsLabelStackEntry6.  See Information Elements listed in the definition of
      mplsTopLabelStackEntry for further details. table below.














Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 46] 45]

Internet-Draft           IPFIX Information Model          September 2005


   Abstract Data Type: unsigned32
   Data Type Semantics: identifier
   ElementId: 76
   Status: current
   Reference: See RFC 3032.

5.5.21.  mplsLabelStackEntry8

   Description:
      The label, exp, and s fields from the label stack entry that was
      pushed immediately before the label stack entry that would be
      reported by mplsLabelStackEntry7.  See the definition of
      mplsTopLabelStackEntry for further details.
   Abstract Data Type: unsigned32
   Data Type Semantics: identifier
   ElementId: 77
   Status: current
   Reference: See RFC 3032.

5.5.22.  mplsLabelStackEntry9

   Description:
      The label, exp, and s fields from the label stack entry that was
      pushed immediately before the label stack entry that would be
      reported by mplsLabelStackEntry8.  See the definition of
      mplsTopLabelStackEntry for further details.
   Abstract Data Type: unsigned32
   Data Type Semantics: identifier
   ElementId: 78
   Status: current
   Reference: See RFC 3032.

5.5.23.  mplsLabelStackEntry10

   Description:
      The label, exp, and s fields from the label stack entry that was
      pushed immediately before the label stack entry that would be
      reported by mplsLabelStackEntry9.  See the definition of
      mplsTopLabelStackEntry for further details.
   Abstract Data Type: unsigned32
   Data Type Semantics: identifier
   ElementId: 79
   Status: current
   Reference: See RFC 3032.

5.6.  Derived Packet Properties

   The set of Information Elements derived from values of header fields



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 47]

Internet-Draft           IPFIX Information Model          September 2005


   and further information includes the Information Elements listed in
   the table below.               June 2006


   +-----+---------------------------+-----+---------------------------+
   |  ID | Name                      |  ID | Name                      |
   +-----+---------------------------+-----+---------------------------+
   |  15  56 | ipNextHopIPv4Address sourceMacAddress          |  18 194 | bgpNextHopIPv4Address mplsPayloadLength         |
   |  62  81 | ipNextHopIPv6Address postSourceMacAddress      |  63  70 | bgpNextHopIPv6Address mplsTopLabelStackEntry    |
   |  16  58 | bgpSourceAsNumber vlanId                    |  46  71 | mplsTopLabelType mplsLabelStackEntry2      |
   |  17  59 | bgpDestinationAsNumber postVlanId                |  47  72 | mplsTopLabelIPv4Address mplsLabelStackEntry3      |
   | 128  80 | bgpNextAdjacentAsNumber destinationMacAddress     | 140  73 | mplsTopLabelIPv6Address mplsLabelStackEntry4      |
   | 129  57 | bgpPrevAdjacentAsNumber postDestinationMacAddr    |  74 | mplsLabelStackEntry5      |
   +-----+---------------------------+-----+---------------------------+

5.6.1.  ipNextHopIPv4Address

   Description:
      The IPv4 address of the next IPv4 hop.
   Abstract Data Type: ipv4Address
   Data Type Semantics: identifier
   ElementId: 15
   Status: current

5.6.2.  ipNextHopIPv6Address
   | 146 | wlanChannelId             |  75 | mplsLabelStackEntry6      |
   | 147 | wlanSSID                  |  76 | mplsLabelStackEntry7      |
   | 200 | mplsTopLabelTTL           |  77 | mplsLabelStackEntry8      |
   | 203 | mplsTopLabelExp           |  78 | mplsLabelStackEntry9      |
   | 202 | mplsLabelStackDepth       |  79 | mplsLabelStackEntry10     |
   | 201 | mplsLabelStackLength      |     |                           |
   +-----+---------------------------+-----+---------------------------+

5.6.1.  sourceMacAddress

   Description:
      The IPv6 IEEE 802 source MAC address of the next IPv6 hop. field.
   Abstract Data Type: ipv6Address macAddress
   Data Type Semantics: identifier
   ElementId: 62 56
   Status: current

5.6.3.  bgpSourceAsNumber
   Reference:
      See IEEE.802-3.2002 [IEEE.802-3.2002].

5.6.2.  postSourceMacAddress

   Description:
      The autonomous system (AS) number definition of the source IP address.  If AS
      path information for this Flow Information Element is only available as unordered AS
      set (and not as ordered AS sequence), then identical to the value
      definition of this Information Element is 0. 'sourceMacAddress', except that
      it reports a potentially modified value caused by a middlebox
      function after the packet passed the Observation Point.
   Abstract Data Type: unsigned16 macAddress
   Data Type Semantics: identifier
   ElementId: 16 81
   Status: current
   Reference:
      See RFC 1771 for a description of BGP-4 and see RFC 1930
      for a definition of the AS number. IEEE.802-3.2002 [IEEE.802-3.2002].

5.6.3.  vlanId








Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 48] 46]

Internet-Draft           IPFIX Information Model          September 2005


5.6.4.  bgpDestinationAsNumber               June 2006


   Description:
      The autonomous system (AS) number of the destination IP address.
      If AS path information for this Flow is only available as
      unordered AS set (and not as ordered AS sequence), then IEEE 802.1Q VLAN identifier (VID) extracted from the value
      of this Tag
      Control Information Element is 0. field that was attached to the IP packet.
   Abstract Data Type: unsigned16
   Data Type Semantics: identifier
   ElementId: 17 58
   Status: current
   Reference:
      See RFC 1771 for a description of BGP-4 and see RFC 1930
      for a definition of the AS number.

5.6.5.  bgpNextAdjacentAsNumber IEEE.802-1Q.2003 [IEEE.802-1Q.2003].

5.6.4.  postVlanId

   Description:
      The autonomous system (AS) number definition of this Information Element is identical to the first AS in
      definition of Information Element 'vlanId', except that it reports
      a potentially modified value caused by a middlebox function after
      the AS path
      to packet passed the destination IP address. Observation Point.
   Abstract Data Type: unsigned16
   Data Type Semantics: identifier
   ElementId: 59
   Status: current
   Reference:
      See IEEE.802-1Q.2003 [IEEE.802-1Q.2003].

5.6.5.  destinationMacAddress

   Description:
      The path is deduced by looking up
      the IEEE 802 destination IP MAC address of the Flow in the BGP routing
      information base.  If AS path information for this Flow is only
      available as unordered AS set (and not as ordered AS sequence),
      then the value of this Information Element is 0. field.
   Abstract Data Type: unsigned16 macAddress
   Data Type Semantics: identifier
   ElementId: 128 80
   Status: current
   Reference:
      See RFC 1771 for a description of BGP-4 and see RFC 1930
      for a definition of the AS number. IEEE.802-3.2002 [IEEE.802-3.2002].

5.6.6.  bgpPrevAdjacentAsNumber  postDestinationMacAddr

   Description:
      The autonomous system (AS) number of the last AS in the AS path
      from the source IP address.  The path is deduced by looking up the
      source IP address definition of the Flow in the BGP routing information base.
      If AS path information for this Flow Information Element is only available as
      unordered AS set (and not as ordered AS sequence), then identical to the value
      definition of this Information Element is 0.  In case of BGP asymmetry, 'destinationMacAddress', except
      that it reports a potentially modified value caused by a middlebox
      function after the
      bgpPrevAdjacentAsNumber might not be able to report packet passed the correct
      value. Observation Point.
   Abstract Data Type: unsigned16 macAddress
   Data Type Semantics: identifier
   ElementId: 129







Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 49] 47]

Internet-Draft           IPFIX Information Model          September 2005               June 2006


   ElementId: 57
   Status: current
   Reference:
      See RFC 1771 for a description of BGP-4 and see RFC 1930
      for a definition of the AS number. IEEE.802-3.2002 [IEEE.802-3.2002].

5.6.7.  bgpNextHopIPv4Address  wlanChannelId

   Description:
      The IPv4 address identifier of the next (adjacent) BGP hop. 802.11 (Wi-Fi) channel used.
   Abstract Data Type: ipv4Address unsigned8
   Data Type Semantics: identifier
   ElementId: 18 146
   Status: current
   Reference:
      See RFC 1771 for a description of BGP-4 and IEEE.802-11.1999 [IEEE.802-11.1999].

5.6.8.  bgpNextHopIPv6Address  wlanSSID

   Description:
      The IPv6 address of Service Set IDentifier (SSID) identifying an 802.11 (Wi-Fi)
      network used.  According to IEEE.802-11.1999 the next (adjacent) BGP hop. SSID is encoded
      into a string of up to 32 characters.
   Abstract Data Type: ipv6Address
   Data Type Semantics: identifier string
   ElementId: 63 147
   Status: current
   Reference:
      See RFC 1771 for a description of BGP-4. IEEE.802-11.1999 [IEEE.802-11.1999].

5.6.9.  mplsTopLabelType  mplsTopLabelTTL

   Description:
      This
      The TTL field identifies the control protocol that allocated from the top
      of stack label.  Defined values for this field include:

        - 0x01 TE-MIDPT: Any TE tunnel mid-point or tail label
        - 0x02 Pseudowire: Any PWE3 or Cisco AToM based label
        - 0x03 VPN: Any label associated with VPN
        - 0x04 BGP: Any MPLS label associated with BGP or BGP routing
        - 0x05 LDP: Any stack entry, i.e. the last
      label associated with dynamically assigned
                    labels using LDP that was pushed.
   Abstract Data Type: octet
   Data Type Semantics: identifier unsigned32
   ElementId: 46 200
   Status: current
   Reference:
      See RFC 3031 3032 [RFC3032] for the specification of the TTL field.

5.6.10.  mplsTopLabelExp

   Description:
      The Exp field from the top MPLS label structure.  See RFC 2547
      for stack entry, i.e. the association of MPLS labels with VPNs.  See RFC 1771 for
      BGP and BGP routing.  See RFC 3036 for LDP. and IP addresses.

5.6.10.  mplsTopLabelIPv4Address last
      label that was pushed.







Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 50] 48]

Internet-Draft           IPFIX Information Model          September 2005


   Description:
      The IPv4 address of the system that the               June 2006


         Bit 0-4:  Don't Care, value is irrelevant.
         Bit 5-7:  MPLS top label will cause
      this Flow to be forwarded to. Exp field

             0   1   2   3   4   5   6   7
           +---+---+---+---+---+---+---+---+
           |     don't care    |    Exp    |
           +---+---+---+---+---+---+---+---+

   Abstract Data Type: ipv4Address unsigned8
   Data Type Semantics: identifier flags
   ElementId: 47 203
   Status: current
   Reference:
      See RFC 3031 3032 [RFC3032] for the association between MPLS labels and
      IP addresses. specification of the Exp field.
      See RFC 3270 [RFC3270] for usage of the Exp field.

5.6.11.  mplsTopLabelIPv6Address  mplsLabelStackDepth

   Description:
      The IPv6 address number of the system that labels in the MPLS top label will cause
      this Flow to be forwarded to. stack.
   Abstract Data Type: ipv6Address
   Data Type Semantics: identifier unsigned32
   ElementId: 140 202
   Status: current
   Units: label stack entries
   Reference:
      See RFC 3031 3032 [RFC3032] for the association between MPLS labels and
      IP addresses.

5.7.  Min/Max Flow Properties

   Information Elements in this section are results of minimum or
   maximum operations over all packets specification of a Flow.

   +-----+---------------------------+-----+---------------------------+
   |  ID | Name                      |  ID | Name                      |
   +-----+---------------------------+-----+---------------------------+
   |  25 | minimumPacketLength       | 208 | ipv4Options               |
   |  26 | maximumPacketLength       |  64 | ipv6ExtensionHeaders      |
   |  52 | minimumTtl                |   6 | tcpControlBits            |
   |  53 | maximumTtl                | 209 | tcpOptions                |
   +-----+---------------------------+-----+---------------------------+

5.7.1.  minimumPacketLength the MPLS label
      stack.

5.6.12.  mplsLabelStackLength

   Description:
      Length
      The length of the smallest packet observed for this Flow. MPLS label stack in units of octets.
   Abstract Data Type: unsigned16 unsigned32
   ElementId: 25 201
   Status: current
   Units: octets

5.7.2.  maximumPacketLength
   Reference:
      See RFC 3032 [RFC3032] for the specification of the MPLS label
      stack.

5.6.13.  mplsPayloadLength

   Description:
      The size of the MPLS packet without the label stack.







Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 51] 49]

Internet-Draft           IPFIX Information Model          September 2005


   Description:
      Length of the largest packet observed for this Flow.               June 2006


   Abstract Data Type: unsigned16 unsigned32
   ElementId: 26 194
   Status: current
   Units: octets

5.7.3.  minimumTtl

   Description:
      Minimum TTL value observed
   Reference:
      See RFC 3031 [RFC3031] for any packet in this Flow.
   Abstract Data Type: octet
   ElementId: 52
   Status: current

5.7.4.  maximumTtl

   Description:
      Maximum TTL value observed the specification of MPLS packets.  See
      RFC 3032 [RFC3032] for any packet in this Flow.
   Abstract Data Type: octet
   ElementId: 53
   Status: current

5.7.5.  ipv4Options

   Description:
      IPv4 options in packets of this Flow.  The information is encoded
      in a set of bit fields.  For each valid IPv4 option type there is
      a bit in this set.  The bit is set to 1 if any observed packet of
      this Flow contains the corresponding IPv4 option type.  Otherwise,
      if no observed packet specification of this Flow contained the respective IPv4
      option type, MPLS label stack.

5.6.14.  mplsTopLabelStackEntry

   Description:
      The label, exp and s fields from the value of top MPLS label stack entry,
      i.e. the corresponding bit is 0.
      The list of valid IPv4 options is maintained by IANA.  Note last label that
      for identifying an option not just the 5-bit Option Number, but
      all was pushed.

       0                   1                   2
       0 1 2 3 4 5 6 7 8 bits of the Option Type need to match one of the IPv4
      options specified at
      http://www.iana.org/assignments/ip-parameters.
      Options are mapped to bits according to their option numbers.
      Option number X is mapped to bit X. The mapping is illustrated by
      the figure below. 9 0 1 2 3 4 5 6 7
       +------+------+------+------+------+------+------+------+
       | EOOL | NOP  | SEC  | LSR  |  TS  |E-SEC |CIPSO |  RR  | ...
       +------+------+------+------+------+------+------+------+ 8 9     10     11     12     13     14     15
       +------+------+------+------+------+------+------+------+



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 52]

Internet-Draft           IPFIX Information Model          September 2005


   ... | SID  | SSR  | ZSU  | MTUP | MTUR 0 1 2 3
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | FINN                Label                  | VISA |ENCODE| ...
       +------+------+------+------+------+------+------+------+

          16     17     18     19 Exp |S|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Label:  Label Value, 20     21     22     23
       +------+------+------+------+------+------+------+------+
   ... |IMITD | EIP  |  TR  |ADDEXT|RTRALT| SDB  |NSAPA | DPS  | ...
       +------+------+------+------+------+------+------+------+

          24     25     26     27     28     29     30     31
       +------+------+------+------+------+------+------+------+
   ... | UMP  |             to be assigned by IANA             |
       +------+------+------+------+------+------+------+------+


           Type   Option
       Bit Value  Name    Reference
       ---+-----+-------+------------------------------------
        0     0   EOOL    End bits
      Exp:    Experimental Use, 3 bits
      S:      Bottom of Options List, RFC 791
        1 Stack, 1   NOP     No Operation, RFC 791
        2   130   SEC     Security, RFC 1108
        3   131   LSR     Loose Source Route, RFC 791
        4    68   TS      Time Stamp, RFC 791
        5   133   E-SEC   Extended Security, RFC 1108
        6   134   CIPSO   Commercial Security
        7     7   RR      Record Route, RFC 791
        8   136   SID     Stream ID, RFC 791
        9   137   SSR     Strict Source Route, RFC 791
       10    10   ZSU     Experimental Measurement
       11    11   MTUP    (obsoleted) MTU Probe, RFC 1191
       12    12   MTUR    (obsoleted) MTU Reply, RFC 1191
       13   205   FINN    Experimental Flow Control
       14   142   VISA    Experimental Access Control
       15    15   ENDOCE
       16   144   IMITD   IMI Traffic Descriptor
       17   145   EIP     Extended Internet Protocol, RFC 1385
       18    82   TR      Traceroute, RFC 3193
       19   147   ADDEXT  Address Extension
       20   148   RTRALT  Router Alert, RFC 2113
       21   149   SDB     Selective Directed Broadcast
       22   150   NSAPA   NSAP Address
       23   151   DPS     Dynamic Packet State
       24   152   UMP     Upstream Multicast Pkt.
       ...  ...   ...     Further options numbers
                          may be assigned by IANA







Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 53]

Internet-Draft           IPFIX Information Model          September 2005 bit

   Abstract Data Type: unsigned32
   Data Type Semantics: flags identifier
   ElementId: 208 70
   Status: current
   Reference:
      See RFC 791 for 3032 [RFC3032].

5.6.15.  mplsLabelStackEntry2

   Description:
      The label, exp, and s fields from the definition of IPv4 options.  See label stack entry that was
      pushed immediately before the
      list of IPv4 option numbers assigned label stack entry that would be
      reported by IANA at
      http://www.iana.org/assignments/ip-parameters.

5.7.6.  ipv6ExtensionHeaders

   Description:
      IPv6 extension headers observed in packets of this Flow.  The
      information is encoded in a set of bit fields.  For each IPv6
      option header there is a bit in this set.  The bit is set to 1 if
      any observed packet of this Flow contains the corresponding IPv6
      extension header.  Otherwise, if no observed packet of this Flow
      contained the respective IPv6 extension header, mplsTopLabelStackEntry.  See the value definition of the
      corresponding bit is 0.
      mplsTopLabelStackEntry for further details.
   Abstract Data Type: unsigned32
   Data Type Semantics: identifier
   ElementId: 71
   Status: current
   Reference:
      See RFC 3032 [RFC3032].

5.6.16.  mplsLabelStackEntry3





Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 54] 50]

Internet-Draft           IPFIX Information Model          September 2005


              0     1     2     3     4     5     6     7
          +-----+-----+-----+-----+-----+-----+-----+-----+
          | Res | FRA1| ROU | FRA0| UNK | Res | HOP | DST |  ...
          +-----+-----+-----+-----+-----+-----+-----+-----+

              8     9    10    11    12    13    14    15
          +-----+-----+-----+-----+-----+-----+-----+-----+
      ... | PAY | AUT | ENC |         Reserved            | ...
          +-----+-----+-----+-----+-----+-----+-----+-----+

             16    17    18    19    20    21    22    23
          +-----+-----+-----+-----+-----+-----+-----+-----+
      ... |                  Reserved                     | ...
          +-----+-----+-----+-----+-----+-----+-----+-----+

             24    25    26    27    28    29    30    31
          +-----+-----+-----+-----+-----+-----+-----+-----+
      ... |                  Reserved                     |
          +-----+-----+-----+-----+-----+-----+-----+-----+

        Bit    IPv6 Option   Description

       0, Res               Reserved
       1, FRA1     44       Fragmentation header - not first fragment
       2, ROU      43       Routing header
       3, FRA0     44       Fragment header - first fragment
       4, UNK               Unknown Layer 4 header
                            (compressed, encrypted, not supported)
       5, Res               Reserved
       6, HOP       0       Hop-by-hop option header
       7, DST      60       Destination option header
       8, PAY     108       Payload compression header
       9, AUT      51       Authentication Header
      10, ENC      50       Encrypted security payload
      11 to 31              Reserved               June 2006


   Description:
      The label, exp, and s fields from the label stack entry that was
      pushed immediately before the label stack entry that would be
      reported by mplsLabelStackEntry2.  See the definition of
      mplsTopLabelStackEntry for further details.
   Abstract Data Type: unsigned32
   Data Type Semantics: flags identifier
   ElementId: 64 72
   Status: current
   Reference:
      See RFC 2460 for 3032 [RFC3032].

5.6.17.  mplsLabelStackEntry4

   Description:
      The label, exp, and s fields from the label stack entry that was
      pushed immediately before the label stack entry that would be
      reported by mplsLabelStackEntry3.  See the general definition of IPv6 extensions
      headers and
      mplsTopLabelStackEntry for further details.
   Abstract Data Type: unsigned32
   Data Type Semantics: identifier
   ElementId: 73
   Status: current
   Reference:
      See RFC 3032 [RFC3032].

5.6.18.  mplsLabelStackEntry5

   Description:
      The label, exp, and s fields from the specification of the hop-by-hop options
      header, the routing header, label stack entry that was
      pushed immediately before the fragment header, and label stack entry that would be
      reported by mplsLabelStackEntry4.  See the
      destination options header. definition of
      mplsTopLabelStackEntry for further details.
   Abstract Data Type: unsigned32
   Data Type Semantics: identifier
   ElementId: 74
   Status: current
   Reference:
      See RFC 2402 for 3032 [RFC3032].

5.6.19.  mplsLabelStackEntry6

   Description:
      The label, exp, and s fields from the specification of label stack entry that was
      pushed immediately before the authentication header. label stack entry that would be
      reported by mplsLabelStackEntry5.  See RFC 2406 for the specification definition of
      the encapsulating security payload.
      mplsTopLabelStackEntry for further details.




Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 55] 51]

Internet-Draft           IPFIX Information Model          September 2005


5.7.7.  tcpControlBits               June 2006


   Abstract Data Type: unsigned32
   Data Type Semantics: identifier
   ElementId: 75
   Status: current
   Reference:
      See RFC 3032 [RFC3032].

5.6.20.  mplsLabelStackEntry7

   Description:
      TCP control bits observed for packets of this Flow.
      The
      information is encoded in a set of bit fields.  For each TCP
      control bit there is a bit in this set.  A bit is set to 1 if any
      observed packet of this Flow has label, exp, and s fields from the corresponding TCP control bit
      set to 1.  A value of 0 for a bit indicates label stack entry that the corresponding
      bit was not set in any of
      pushed immediately before the observed packets of this Flow.

          0     1     2     3     4     5     6     7
      +-----+-----+-----+-----+-----+-----+-----+-----+
      |  Reserved | URG | ACK | PSH | RST | SYN | FIN |
      +-----+-----+-----+-----+-----+-----+-----+-----+

      Reserved:  Reserved for future use by TCP.  Must label stack entry that would be zero.
           URG:  Urgent Pointer field significant
           ACK:  Acknowledgment field significant
           PSH:  Push Function
           RST:  Reset
      reported by mplsLabelStackEntry6.  See the connection
           SYN:  Synchronize sequence numbers
           FIN:  No more data from sender definition of
      mplsTopLabelStackEntry for further details.
   Abstract Data Type: octet unsigned32
   Data Type Semantics: flags identifier
   ElementId: 6 76
   Status: current
   Reference:
      See RFC 793 for a definition of the TCP control bits in
      the TCP header.

5.7.8.  tcpOptions 3032 [RFC3032].

5.6.21.  mplsLabelStackEntry8

   Description:
      TCP options in packets of this Flow.  The information is encoded
      in a set of bit fields.  For each TCP option there is a bit in
      this set.
      The bit is set to 1 if any observed packet of this Flow
      contains label, exp, and s fields from the corresponding TCP option.  Otherwise, if no observed
      packet of this Flow contained label stack entry that was
      pushed immediately before the respective TCP option, label stack entry that would be
      reported by mplsLabelStackEntry7.  See the value definition of the corresponding bit is 0.
      Options are mapped to bits according to their option numbers.
      Option number X is mapped to bit X. TCP option numbers are
      maintained
      mplsTopLabelStackEntry for further details.
   Abstract Data Type: unsigned32
   Data Type Semantics: identifier
   ElementId: 77
   Status: current
   Reference:
      See RFC 3032 [RFC3032].

5.6.22.  mplsLabelStackEntry9

   Description:
      The label, exp, and s fields from the label stack entry that was
      pushed immediately before the label stack entry that would be
      reported by IANA. mplsLabelStackEntry8.  See the definition of
      mplsTopLabelStackEntry for further details.
   Abstract Data Type: unsigned64 unsigned32
   Data Type Semantics: flags identifier







Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 56] 52]

Internet-Draft           IPFIX Information Model          September 2005               June 2006


   ElementId: 209 78
   Status: current
   Reference:
      See RFC 793 for 3032 [RFC3032].

5.6.23.  mplsLabelStackEntry10

   Description:
      The label, exp, and s fields from the label stack entry that was
      pushed immediately before the label stack entry that would be
      reported by mplsLabelStackEntry9.  See the definition of TCP options.
      mplsTopLabelStackEntry for further details.
   Abstract Data Type: unsigned32
   Data Type Semantics: identifier
   ElementId: 79
   Status: current
   Reference:
      See the
      list RFC 3032 [RFC3032].

5.7.  Derived Packet Properties

   The set of TCP option numbers assigned by IANA at
      http://www.iana.org/assignments/tcp-parameters.

5.8.  Flow Time Stamps Information Elements in this section are time stamps of events.

   Time stamps flowStartSeconds, flowEndSeconds, flowStartMilliSeconds,
   flowEndMilliSeconds, flowStartMicroSeconds, flowEndMicroSeconds,
   flowStartNanoSeconds, flowEndNanoSeconds, and
   systemInitTimeMilliSeconds are absolute and have a well defined fixed
   time base, such as, for example, the number derived from values of seconds since 0000 UTC
   Jan 1st 1970.

   Time stamps flowStartDeltaMicroSeconds header fields
   and flowEndDeltaMicroSeconds
   are relative time stamps only valid within the scope of a single
   IPFIX Message.  They contain the negative time offsets relative to further information includes the export time specified Information Elements listed in
   the IPFIX Message header.

   Time stamps flowStartSysUpTime and flowEndSysUpTime are relative time
   stamps indicating the time relative to the last (re-)initialization
   of the IPFIX Device.  For reporting the time of the last
   (re-)initialization, systemInitTimeMilliSeconds can be reported, for
   example, in Data Records defined by Option Templates. table below.

   +-----+---------------------------+-----+---------------------------+
   |  ID | Name                      |  ID | Name                      |
   +-----+---------------------------+-----+---------------------------+
   | 150 | flowStartSeconds          | 156 | flowStartNanoSeconds  15 | ipNextHopIPv4Address      | 151  18 | flowEndSeconds bgpNextHopIPv4Address     | 157
   | flowEndNanoSeconds  62 | ipNextHopIPv6Address      | 152  63 | flowStartMilliSeconds bgpNextHopIPv6Address     | 158
   | flowStartDeltaMicroSeconds|  16 | 153 bgpSourceAsNumber         | flowEndMilliSeconds  46 | 159 mplsTopLabelType          | flowEndDeltaMicroSeconds
   |  17 | 154 bgpDestinationAsNumber    | flowStartMicroSeconds  47 | 160 mplsTopLabelIPv4Address   | systemInitTimeMilliSeconds|
   | 155 128 | flowEndMicroSeconds bgpNextAdjacentAsNumber   |  22 140 | flowStartSysUpTime mplsTopLabelIPv6Address   |
   | 129 | bgpPrevAdjacentAsNumber   |  21  90 | flowEndSysUpTime mplsVpnRouteDistinguisher |
   +-----+---------------------------+-----+---------------------------+

5.8.1.  flowStartSeconds

5.7.1.  ipNextHopIPv4Address

   Description:
      The absolute timestamp IPv4 address of the first packet of this Flow. next IPv4 hop.
   Abstract Data Type: dateTimeSeconds ipv4Address
   Data Type Semantics: identifier
   ElementId: 15
   Status: current

5.7.2.  ipNextHopIPv6Address





Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 57] 53]

Internet-Draft           IPFIX Information Model          September 2005


   ElementId: 150
   Status: current
   Units: seconds

5.8.2.  flowEndSeconds               June 2006


   Description:
      The absolute timestamp IPv6 address of the last packet of this Flow. next IPv6 hop.
   Abstract Data Type: dateTimeSeconds ipv6Address
   Data Type Semantics: identifier
   ElementId: 151 62
   Status: current
   Units: seconds

5.8.3.  flowStartMilliSeconds

5.7.3.  bgpSourceAsNumber

   Description:
      The absolute timestamp autonomous system (AS) number of the first packet source IP address.  If AS
      path information for this Flow is only available as unordered AS
      set (and not as ordered AS sequence), then the value of this Flow.
      Information Element is 0.
   Abstract Data Type: dateTimeMilliSeconds unsigned32
   Data Type Semantics: identifier
   ElementId: 152 16
   Status: current
   Units: milliseconds

5.8.4.  flowEndMilliSeconds
   Reference:
      See RFC 1771 [RFC1771] for a description of BGP-4 and see RFC 1930
      [RFC1930] for a definition of the AS number.

5.7.4.  bgpDestinationAsNumber

   Description:
      The absolute timestamp autonomous system (AS) number of the last packet destination IP address.
      If AS path information for this Flow is only available as
      unordered AS set (and not as ordered AS sequence), then the value
      of this Flow. Information Element is 0.
   Abstract Data Type: dateTimeMilliSeconds unsigned32
   Data Type Semantics: identifier
   ElementId: 153 17
   Status: current
   Units: milliseconds

5.8.5.  flowStartMicroSeconds

   Description: The absolute timestamp of the first packet
   Reference:
      See RFC 1771 [RFC1771] for a description of this Flow.
   Abstract Data Type: dateTimeMicroSeconds
   ElementId: 154
   Status: current
   Units: microseconds

5.8.6.  flowEndMicroSeconds BGP-4 and see RFC 1930
      [RFC1930] for a definition

5.7.5.  bgpNextAdjacentAsNumber

   Description:
      The absolute timestamp autonomous system (AS) number of the last packet first AS in the AS path
      to the destination IP address.  The path is deduced by looking up
      the destination IP address of the Flow in the BGP routing
      information base.  If AS path information for this Flow is only
      available as unordered AS set (and not as ordered AS sequence),
      then the value of this Flow.
   Abstract Data Type: dateTimeMicroSeconds
   ElementId: 155
   Status: current
   Units: microseconds

5.8.7.  flowStartNanoSeconds Information Element is 0.





Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 58] 54]

Internet-Draft           IPFIX Information Model          September 2005


   Description: The absolute timestamp of the first packet of this Flow.               June 2006


   Abstract Data Type: dateTimeNanoSeconds
   ElementId: 156
   Status: current
   Units: nanoseconds

5.8.8.  flowEndNanoSeconds

   Description: The absolute timestamp of the last packet of this Flow.
   Abstract unsigned32
   Data Type: dateTimeNanoSeconds Type Semantics: identifier
   ElementId: 157 128
   Status: current
   Units: nanoseconds

5.8.9.  flowStartDeltaMicroSeconds

   Description: This is
   Reference:
      See RFC 1771 [RFC1771] for a relative time stamp only valid within the
      scope description of BGP-4 and see RFC 1930
      [RFC1930] for a single IPFIX Message.  It contains the negative time
      offset definition of the first observed packet AS number.

5.7.6.  bgpPrevAdjacentAsNumber

   Description:
      The autonomous system (AS) number of this Flow relative to the
      export time specified last AS in the IPFIX Message header.
   Abstract Data Type: unsigned32
   ElementId: 158
   Status: current
   Units: microseconds
   Reference: See [I-D.ietf-ipfix-protocol] for the definition of AS path
      from the
      IPFIX Message header.

5.8.10.  flowEndDeltaMicroSeconds

   Description: This source IP address.  The path is a relative time stamp only valid within deduced by looking up the
      scope
      source IP address of a single IPFIX Message.  It contains the negative time
      offset of Flow in the last observed packet of BGP routing information base.
      If AS path information for this Flow relative to is only available as
      unordered AS set (and not as ordered AS sequence), then the
      export time specified in value
      of this Information Element is 0.  In case of BGP asymmetry, the IPFIX Message header.
      bgpPrevAdjacentAsNumber might not be able to report the correct
      value.
   Abstract Data Type: unsigned32
   Data Type Semantics: identifier
   ElementId: 159 129
   Status: current
   Units: microseconds
   Reference:
      See [I-D.ietf-ipfix-protocol] RFC 1771 [RFC1771] for the a description of BGP-4 and see RFC 1930
      [RFC1930] for a definition of the
      IPFIX Message header.

5.8.11.  systemInitTimeMilliSeconds AS number.

5.7.7.  bgpNextHopIPv4Address

   Description:
      The absolute timestamp of the last (re-)initialization IPv4 address of the IPFIX Device.







Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 59]

Internet-Draft           IPFIX Information Model          September 2005 next (adjacent) BGP hop.
   Abstract Data Type: dateTimeMilliSeconds ipv4Address
   Data Type Semantics: identifier
   ElementId: 160 18
   Status: current
   Units: milliseconds

5.8.12.  flowStartSysUpTime
   Reference:
      See RFC 1771 [RFC1771] for a description of BGP-4.

5.7.8.  bgpNextHopIPv6Address

   Description:
      The relative timestamp of the first packet of this Flow.
      It indicates the number of milliseconds since the last
      (re-)initialization IPv6 address of the IPFIX Device (sysUpTime). next (adjacent) BGP hop.
   Abstract Data Type: unsigned32 ipv6Address
   Data Type Semantics: identifier







Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 55]

Internet-Draft           IPFIX Information Model               June 2006


   ElementId: 22 63
   Status: current
   Units: milliseconds

5.8.13.  flowEndSysUpTime

   Description: The relative timestamp of the last packet
   Reference:
      See RFC 1771 [RFC1771] for a description of this Flow.
      It indicates BGP-4.

5.7.9.  mplsTopLabelType

   Description:
      This field identifies the number of milliseconds since control protocol that allocated the last
      (re-)initialization top
      of stack label.  Initially values for this field are listed below.
      Further values may be assigned by IANA in the IPFIX Device (sysUpTime). MPLS label type
      registry.

        - 0x01 TE-MIDPT: Any TE tunnel mid-point or tail label
        - 0x02 Pseudowire: Any PWE3 or Cisco AToM based label
        - 0x03 VPN: Any label associated with VPN
        - 0x04 BGP: Any label associated with BGP or BGP routing
        - 0x05 LDP: Any label associated with dynamically assigned
                    labels using LDP

   Abstract Data Type: unsigned32 unsigned8
   Data Type Semantics: identifier
   ElementId: 21 46
   Status: current
   Units: milliseconds

5.9.  Per-Flow Counters

   Information Elements in this section are counters all having integer
   values.  Their values may change
   Reference:
      See RFC 3031 [RFC3031] for every report they are used in.
   They cannot serve as part of a Flow Key used the MPLS label structure.  See RFC 2547
      [RFC2547] for mapping packets to
   Flows.  However, potentially they can be used the association of MPLS labels with VPNs.  See RFC
      1771 [RFC1771] for selecting exported
   Flows, BGP and BGP routing.  See RFC 3036 [RFC3036]
      for example, by only exporting Flows with more than a
   threshold number LDP.  See the list of observed octets.

   There are running counters and delta counters.  Delta counters are
   reset to zero each time their values are exported.  Running counters
   continue counting independently MPLS label types assigned by IANA at
      http://www.iana.org/assignments/mpls-label-types.

5.7.10.  mplsTopLabelIPv4Address

   Description:
      The IPv4 address of the Exporting Process.

   There are per-Flow counters and counters related to the Metering
   Process and/or system that the Exporting Process.  Per-Flow counters are MPLS top label will cause
      this Flow
   properties that potentially change each time a packet belonging to be forwarded to.
   Abstract Data Type: ipv4Address
   Data Type Semantics: identifier
   ElementId: 47
   Status: current
   Reference:
      See RFC 3031 [RFC3031] for the Flow is observed.  The set of per-Flow counters includes the
   Information Elements listed in the table below. association between MPLS labels and
      IP addresses.

5.7.11.  mplsTopLabelIPv6Address






Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 60] 56]

Internet-Draft           IPFIX Information Model          September 2005               June 2006


   Description:
      The IPv6 address of the system that the MPLS top label will cause
      this Flow to be forwarded to.
   Abstract Data Type: ipv6Address
   Data Type Semantics: identifier
   ElementId: 140
   Status: current
   Reference:
      See RFC 3031 [RFC3031] for the association between MPLS labels and
      IP addresses.

5.7.12.  mplsVpnRouteDistinguisher

   Description:
      The value of the VPN route distinguisher of a corresponding entry
      in a VPN routing and forwarding table.  Route distinguisher
      ensures that the same address can be used in several different
      MPLS VPNs, and that it is possible for BGP to carry several
      completely different routes to that address, one for each VPN.
   Abstract Data Type: octetArray
   Data Type Semantics: identifier
   ElementId: 90
   Status: current
   Reference:
      See RFC 4364 [RFC4364] for the specification of the route
      distinguisher.  See RFC 4382 [RFC4382] for the specification of
      the MPLS/BGP Layer 3 Virtual Private Network (VPN) Management
      Information Base.

5.8.  Min/Max Flow Properties

   Information Elements in this section are results of minimum or
   maximum operations over all packets of a Flow.

   +-----+---------------------------+-----+---------------------------+
   |  ID | Name                      |  ID | Name                      |
   +-----+---------------------------+-----+---------------------------+
   |   1 | octetDeltaCount           | 132 | droppedOctetDeltaCount    |
   |  23 | postOctetDeltaCount       | 133 | droppedPacketDeltaCount   |
   | 198 | octetDeltaSumOfSquares    | 134 | droppedOctetTotalCount    |
   |  85 | octetTotalCount           | 135 | droppedPacketTotalCount   |
   | 171 | postOctetTotalCount       |  19 | postMCastPacketDeltaCount |
   | 199 | octetTotalSumOfSquares    |  20 | postMCastOctetDeltaCount  |
   |   2  25 | packetDeltaCount minimumPacketLength       | 174 208 | postMCastPacketTotalCount ipv4Options               |
   |  24  26 | postPacketDeltaCount maximumPacketLength       | 175  64 | postMCastOctetTotalCount ipv6ExtensionHeaders      |
   |  86  52 | packetTotalCount minimumTTL                |   6 | tcpControlBits            |
   | 172  53 | postPacketTotalCount maximumTTL                | 209 | tcpOptions                |
   +-----+---------------------------+-----+---------------------------+

5.9.1.  octetDeltaCount

   Description:
      The number of octets since

5.8.1.  minimumPacketLength







Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 57]

Internet-Draft           IPFIX Information Model               June 2006


   Description:
      Length of the previous report (if any) in
      incoming packets smallest packet observed for this Flow at the Observation Point.  The
      number of octets include IP header(s) and IP payload. Flow.
   Abstract Data Type: unsigned64
   Data Type Semantics: deltaCounter unsigned16
   ElementId: 1 25
   Status: current
   Units: octets

5.9.2.  postOctetDeltaCount

5.8.2.  maximumPacketLength

   Description:
      The definition of this Information Element is identical to the
      definition
      Length of Information Element 'octetDeltaCount', except that
      it reports a potentially modified value caused by a middlebox
      function after the largest packet passed the observation point. observed for this Flow.
   Abstract Data Type: unsigned64
   Data Type Semantics: deltaCounter unsigned16
   ElementId: 23 26
   Status: current
   Units: octets

5.9.3.  octetDeltaSumOfSquares

5.8.3.  minimumTTL

   Description:
      The sum of the squared numbers of octets per incoming packet since
      the previous report (if any)
      Minimum TTL value observed for any packet in this Flow at the Observation
      Point.  The number of octets include IP header(s) and IP payload.





Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 61]

Internet-Draft           IPFIX Information Model          September 2005 Flow.
   Abstract Data Type: unsigned64 unsigned8
   ElementId: 198 52
   Status: current

5.9.4.  octetTotalCount

5.8.4.  maximumTTL

   Description:
      The total number of octets in incoming packets for this Flow at
      the Observation Point since the Metering Process
      (re-)initialization
      Maximum TTL value observed for any packet in this Observation Point.  The number of
      octets include IP header(s) and IP payload. Flow.
   Abstract Data Type: unsigned64
   Data Type Semantics: totalCounter unsigned8
   ElementId: 85 53
   Status: current
   Units: octets

5.9.5.  postOctetTotalCount

5.8.5.  ipv4Options

   Description:
      IPv4 options in packets of this Flow.  The definition information is encoded
      in a set of bit fields.  For each valid IPv4 option type there is
      a bit in this Information Element set.  The bit is identical set to the
      definition 1 if any observed packet of Information Element 'octetTotalCount', except that
      it reports a potentially modified value caused by a middlebox
      function after
      this Flow contains the corresponding IPv4 option type.  Otherwise,
      if no observed packet passed of this Flow contained the observation point.
   Abstract Data Type: unsigned64
   Data Type Semantics: totalCounter
   ElementId: 171
   Status: current
   Units: octets

5.9.6.  octetTotalSumOfSquares

   Description:
      The total sum respective IPv4
      option type, the value of the squared numbers corresponding bit is 0.
      The list of octets in incoming packets valid IPv4 options is maintained by IANA.  Note that
      for this Flow at identifying an option not just the Observation Point since 5-bit Option Number, but
      all 8 bits of the Metering Process
      (re-)initialization for this Observation Point.  The number Option Type need to match one of
      octets include IP header(s) and IP payload.
   Abstract Data Type: unsigned64
   ElementId: 199
   Status: current
   Units: octets

5.9.7.  packetDeltaCount the IPv4
      options specified at
      http://www.iana.org/assignments/ip-parameters.





Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 62] 58]

Internet-Draft           IPFIX Information Model          September 2005


   Description:
      The               June 2006


      Options are mapped to bits according to their option numbers.
      Option number of incoming packets since the previous report (if any)
      for this Flow at the Observation Point.
   Abstract Data Type: unsigned64
   Data Type Semantics: deltaCounter
   ElementId: 2
   Status: current
   Units: packets

5.9.8.  postPacketDeltaCount

   Description:
      The definition of this Information Element X is identical mapped to the
      definition of Information Element 'packetDeltaCount', except that
      it reports a potentially modified value caused bit X. The mapping is illustrated by a middlebox
      function after the packet passed
      the observation point.
   Abstract Data Type: unsigned64
   Data Type Semantics: deltaCounter
   ElementId: 24
   Status: current
   Units: packets

5.9.9.  packetTotalCount

   Description:
      The total number of incoming packets for this Flow at figure below.

           0      1      2      3      4      5      6      7
       +------+------+------+------+------+------+------+------+
       | EOOL | NOP  | SEC  | LSR  |  TS  |E-SEC |CIPSO |  RR  | ...
       +------+------+------+------+------+------+------+------+

           8      9     10     11     12     13     14     15
       +------+------+------+------+------+------+------+------+
   ... | SID  | SSR  | ZSU  | MTUP | MTUR | FINN | VISA |ENCODE| ...
       +------+------+------+------+------+------+------+------+

          16     17     18     19     20     21     22     23
       +------+------+------+------+------+------+------+------+
   ... |IMITD | EIP  |  TR  |ADDEXT|RTRALT| SDB  |NSAPA | DPS  | ...
       +------+------+------+------+------+------+------+------+

          24     25     26     27     28     29     30     31
       +------+------+------+------+------+------+------+------+
   ... | UMP  |             to be assigned by IANA             |
       +------+------+------+------+------+------+------+------+


           Type   Option
       Bit Value  Name    Reference
       ---+-----+-------+------------------------------------
        0     0   EOOL    End of Options List, RFC 791
        1     1   NOP     No Operation, RFC 791
        2   130   SEC     Security, RFC 1108
        3   131   LSR     Loose Source Route, RFC 791
        4    68   TS      Time Stamp, RFC 791
        5   133   E-SEC   Extended Security, RFC 1108
        6   134   CIPSO   Commercial Security
        7     7   RR      Record Route, RFC 791
        8   136   SID     Stream ID, RFC 791
        9   137   SSR     Strict Source Route, RFC 791
       10    10   ZSU     Experimental Measurement
       11    11   MTUP    (obsoleted) MTU Probe, RFC 1191
       12    12   MTUR    (obsoleted) MTU Reply, RFC 1191
       13   205   FINN    Experimental Flow Control
       14   142   VISA    Experimental Access Control
       15    15   ENDOCE
       16   144   IMITD   IMI Traffic Descriptor
       17   145   EIP     Extended Internet Protocol, RFC 1385
       18    82   TR      Traceroute, RFC 3193
       19   147   ADDEXT  Address Extension



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 59]

Internet-Draft           IPFIX Information Model               June 2006


       20   148   RTRALT  Router Alert, RFC 2113
       21   149   SDB     Selective Directed Broadcast
       22   150   NSAPA   NSAP Address
       23   151   DPS     Dynamic Packet State
       24   152   UMP     Upstream Multicast Pkt.
       ...  ...   ...     Further options numbers
                          may be assigned by IANA

   Abstract Data Type: unsigned32
   Data Type Semantics: flags
   ElementId: 208
   Status: current
   Reference:
      See RFC 791 [RFC0791] for the definition of IPv4 options.  See the
      list of IPv4 option numbers assigned by IANA at
      http://www.iana.org/assignments/ip-parameters.

5.8.6.  ipv6ExtensionHeaders

   Description:
      IPv6 extension headers observed in packets of this Flow.  The
      information is encoded in a set of bit fields.  For each IPv6
      option header there is a bit in this set.  The bit is set to 1 if
      any observed packet of this Flow contains the corresponding IPv6
      extension header.  Otherwise, if no observed packet of this Flow
      contained the respective IPv6 extension header, the value of the
      corresponding bit is 0.
























Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 60]

Internet-Draft           IPFIX Information Model               June 2006


              0     1     2     3     4     5     6     7
          +-----+-----+-----+-----+-----+-----+-----+-----+
          | Res | FRA1| ROU | FRA0| UNK | Res | HOP | DST |  ...
          +-----+-----+-----+-----+-----+-----+-----+-----+

              8     9    10    11    12    13    14    15
          +-----+-----+-----+-----+-----+-----+-----+-----+
      ... | PAY | AUT | ENC |         Reserved            | ...
          +-----+-----+-----+-----+-----+-----+-----+-----+

             16    17    18    19    20    21    22    23
          +-----+-----+-----+-----+-----+-----+-----+-----+
      ... |                  Reserved                     | ...
          +-----+-----+-----+-----+-----+-----+-----+-----+

             24    25    26    27    28    29    30    31
          +-----+-----+-----+-----+-----+-----+-----+-----+
      ... |                  Reserved                     |
          +-----+-----+-----+-----+-----+-----+-----+-----+

        Bit    IPv6 Option   Description

       0, Res               Reserved
       1, FRA1     44       Fragmentation header - not first fragment
       2, ROU      43       Routing header
       3, FRA0     44       Fragment header - first fragment
       4, UNK               Unknown Layer 4 header
                            (compressed, encrypted, not supported)
       5, Res               Reserved
       6, HOP       0       Hop-by-hop option header
       7, DST      60       Destination option header
       8, PAY     108       Payload compression header
       9, AUT      51       Authentication Header
      10, ENC      50       Encrypted security payload
      11 to 31              Reserved

   Abstract Data Type: unsigned32
   Data Type Semantics: flags
   ElementId: 64
   Status: current
   Reference:
      See RFC 2460 [RFC2460] for the general definition of IPv6
      extension headers and for the specification of the hop-by-hop
      options header, the routing header, the fragment header, and the
      destination options header.  See RFC 2402 [RFC2402] for the
      specification of the authentication header.  See RFC 2406
      [RFC2406] for the specification of the encapsulating security
      payload.



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 61]

Internet-Draft           IPFIX Information Model               June 2006


5.8.7.  tcpControlBits

   Description:
      TCP control bits observed for packets of this Flow.  The
      information is encoded in a set of bit fields.  For each TCP
      control bit there is a bit in this set.  A bit is set to 1 if any
      observed packet of this Flow has the corresponding TCP control bit
      set to 1.  A value of 0 for a bit indicates that the corresponding
      bit was not set in any of the observed packets of this Flow.

          0     1     2     3     4     5     6     7
      +-----+-----+-----+-----+-----+-----+-----+-----+
      |  Reserved | URG | ACK | PSH | RST | SYN | FIN |
      +-----+-----+-----+-----+-----+-----+-----+-----+

      Reserved:  Reserved for future use by TCP.  Must be zero.
           URG:  Urgent Pointer field significant
           ACK:  Acknowledgment field significant
           PSH:  Push Function
           RST:  Reset the connection
           SYN:  Synchronize sequence numbers
           FIN:  No more data from sender

   Abstract Data Type: unsigned8
   Data Type Semantics: flags
   ElementId: 6
   Status: current
   Reference:
      See RFC 793 [RFC0793] for a definition of the TCP control bits in
      the TCP header.

5.8.8.  tcpOptions

   Description:
      TCP options in packets of this Flow.  The information is encoded
      in a set of bit fields.  For each TCP option there is a bit in
      this set.  The bit is set to 1 if any observed packet of this Flow
      contains the corresponding TCP option.  Otherwise, if no observed
      packet of this Flow contained the respective TCP option, the value
      of the corresponding bit is 0.
      Options are mapped to bits according to their option numbers.
      Option number X is mapped to bit X. TCP option numbers are
      maintained by IANA.
   Abstract Data Type: unsigned64







Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 62]

Internet-Draft           IPFIX Information Model               June 2006


   Data Type Semantics: flags
   ElementId: 209
   Status: current
   Reference:
      See RFC 793 [RFC0793] for the definition of TCP options.  See the
      list of TCP option numbers assigned by IANA at
      http://www.iana.org/assignments/tcp-parameters.

5.9.  Flow Time Stamps

   Information Elements in this section are time stamps of events.

   Time stamps flowStartSeconds, flowEndSeconds, flowStartMilliseconds,
   flowEndMilliseconds, flowStartMicroseconds, flowEndMicroseconds,
   flowStartNanoseconds, flowEndNanoseconds, and
   systemInitTimeMilliseconds are absolute and have a well defined fixed
   time base, such as, for example, the number of seconds since 0000 UTC
   Jan 1st 1970.

   Time stamps flowStartDeltaMicroseconds and flowEndDeltaMicroseconds
   are relative time stamps only valid within the scope of a single
   IPFIX Message.  They contain the negative time offsets relative to
   the export time specified in the IPFIX Message Header.  The maximum
   time offset that can be encoded by these delta counters is 1 hour, 11
   minutes, and 34.967295 seconds.

   Time stamps flowStartSysUpTime and flowEndSysUpTime are relative time
   stamps indicating the time relative to the last (re-)initialization
   of the IPFIX Device.  For reporting the time of the last
   (re-)initialization, systemInitTimeMilliseconds can be reported, for
   example, in Data Records defined by Option Templates.

   +-----+---------------------------+-----+---------------------------+
   |  ID | Name                      |  ID | Name                      |
   +-----+---------------------------+-----+---------------------------+
   | 150 | flowStartSeconds          | 156 | flowStartNanoseconds      |
   | 151 | flowEndSeconds            | 157 | flowEndNanoseconds        |
   | 152 | flowStartMilliseconds     | 158 | flowStartDeltaMicroseconds|
   | 153 | flowEndMilliseconds       | 159 | flowEndDeltaMicroseconds  |
   | 154 | flowStartMicroseconds     | 160 | systemInitTimeMilliseconds|
   | 155 | flowEndMicroseconds       |  22 | flowStartSysUpTime        |
   |     |                           |  21 | flowEndSysUpTime          |
   +-----+---------------------------+-----+---------------------------+

5.9.1.  flowStartSeconds






Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 63]

Internet-Draft           IPFIX Information Model               June 2006


   Description:
      The absolute timestamp of the first packet of this Flow.
   Abstract Data Type: dateTimeSeconds
   ElementId: 150
   Status: current
   Units: seconds

5.9.2.  flowEndSeconds

   Description:
      The absolute timestamp of the last packet of this Flow.
   Abstract Data Type: dateTimeSeconds
   ElementId: 151
   Status: current
   Units: seconds

5.9.3.  flowStartMilliseconds

   Description:
      The absolute timestamp of the first packet of this Flow.
   Abstract Data Type: dateTimeMilliseconds
   ElementId: 152
   Status: current
   Units: milliseconds

5.9.4.  flowEndMilliseconds

   Description:
      The absolute timestamp of the last packet of this Flow.
   Abstract Data Type: dateTimeMilliseconds
   ElementId: 153
   Status: current
   Units: milliseconds

5.9.5.  flowStartMicroseconds

   Description:
      The absolute timestamp of the first packet of this Flow.
   Abstract Data Type: dateTimeMicroseconds
   ElementId: 154
   Status: current
   Units: microseconds

5.9.6.  flowEndMicroseconds







Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 64]

Internet-Draft           IPFIX Information Model               June 2006


   Description:
      The absolute timestamp of the last packet of this Flow.
   Abstract Data Type: dateTimeMicroseconds
   ElementId: 155
   Status: current
   Units: microseconds

5.9.7.  flowStartNanoseconds

   Description:
      The absolute timestamp of the first packet of this Flow.
   Abstract Data Type: dateTimeNanoseconds
   ElementId: 156
   Status: current
   Units: nanoseconds

5.9.8.  flowEndNanoseconds

   Description:
      The absolute timestamp of the last packet of this Flow.
   Abstract Data Type: dateTimeNanoseconds
   ElementId: 157
   Status: current
   Units: nanoseconds

5.9.9.  flowStartDeltaMicroseconds

   Description:
      This is a relative time stamp only valid within the scope of a
      single IPFIX Message.  It contains the negative time offset of the
      first observed packet of this Flow relative to the export time
      specified in the IPFIX Message Header.
   Abstract Data Type: unsigned32
   ElementId: 158
   Status: current
   Units: microseconds
   Reference:
      See [I-D.ietf-ipfix-protocol] for the definition of the IPFIX
      Message Header.

5.9.10.  flowEndDeltaMicroseconds

   Description:
      This is a relative time stamp only valid within the scope of a
      single IPFIX Message.  It contains the negative time offset of the
      last observed packet of this Flow relative to the export time
      specified in the IPFIX Message Header.




Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 65]

Internet-Draft           IPFIX Information Model               June 2006


   Abstract Data Type: unsigned32
   ElementId: 159
   Status: current
   Units: microseconds
   Reference:
      See [I-D.ietf-ipfix-protocol] for the definition of the IPFIX
      Message Header.

5.9.11.  systemInitTimeMilliseconds

   Description:
      The absolute timestamp of the last (re-)initialization of the
      IPFIX Device.
   Abstract Data Type: dateTimeMilliseconds
   ElementId: 160
   Status: current
   Units: milliseconds

5.9.12.  flowStartSysUpTime

   Description:
      The relative timestamp of the first packet of this Flow.  It
      indicates the number of milliseconds since the last
      (re-)initialization of the IPFIX Device (sysUpTime).
   Abstract Data Type: unsigned32
   ElementId: 22
   Status: current
   Units: milliseconds

5.9.13.  flowEndSysUpTime

   Description:
      The relative timestamp of the last packet of this Flow.  It
      indicates the number of milliseconds since the last
      (re-)initialization of the IPFIX Device (sysUpTime).
   Abstract Data Type: unsigned32
   ElementId: 21
   Status: current
   Units: milliseconds

5.10.  Per-Flow Counters

   Information Elements in this section are counters all having integer
   values.  Their values may change for every report they are used in.
   They cannot serve as part of a Flow Key used for mapping packets to
   Flows.  However, potentially they can be used for selecting exported
   Flows, for example, by only exporting Flows with more than a
   threshold number of observed octets.



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 66]

Internet-Draft           IPFIX Information Model               June 2006


   There are running counters and delta counters.  Delta counters are
   reset to zero each time their values are exported.  Running counters
   continue counting independently of the Exporting Process.

   There are per-Flow counters and counters related to the Metering
   Process and/or the Exporting Process.  Per-Flow counters are Flow
   properties that potentially change each time a packet belonging to
   the Flow is observed.  The set of per-Flow counters includes the
   Information Elements listed in the table below.

   +-----+---------------------------+-----+---------------------------+
   |  ID | Name                      |  ID | Name                      |
   +-----+---------------------------+-----+---------------------------+
   |   1 | octetDeltaCount           | 132 | droppedOctetDeltaCount    |
   |  23 | postOctetDeltaCount       | 133 | droppedPacketDeltaCount   |
   | 198 | octetDeltaSumOfSquares    | 134 | droppedOctetTotalCount    |
   |  85 | octetTotalCount           | 135 | droppedPacketTotalCount   |
   | 171 | postOctetTotalCount       |  19 | postMCastPacketDeltaCount |
   | 199 | octetTotalSumOfSquares    |  20 | postMCastOctetDeltaCount  |
   |   2 | packetDeltaCount          | 174 | postMCastPacketTotalCount |
   |  24 | postPacketDeltaCount      | 175 | postMCastOctetTotalCount  |
   |  86 | packetTotalCount          |     |                           |
   | 172 | postPacketTotalCount      |     |                           |
   +-----+---------------------------+-----+---------------------------+

5.10.1.  octetDeltaCount

   Description:
      The number of octets since the previous report (if any) in
      incoming packets for this Flow at the Observation Point.  The
      number of octets include IP header(s) and IP payload.
   Abstract Data Type: unsigned64
   Data Type Semantics: deltaCounter
   ElementId: 1
   Status: current
   Units: octets

5.10.2.  postOctetDeltaCount

   Description:
      The definition of this Information Element is identical to the
      definition of Information Element 'octetDeltaCount', except that
      it reports a potentially modified value caused by a middlebox
      function after the packet passed the Observation Point.







Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 67]

Internet-Draft           IPFIX Information Model               June 2006


   Abstract Data Type: unsigned64
   Data Type Semantics: deltaCounter
   ElementId: 23
   Status: current
   Units: octets

5.10.3.  octetDeltaSumOfSquares

   Description:
      The sum of the squared numbers of octets per incoming packet since
      the previous report (if any) for this Flow at the Observation
      Point.  The number of octets include IP header(s) and IP payload.
   Abstract Data Type: unsigned64
   ElementId: 198
   Status: current

5.10.4.  octetTotalCount

   Description:
      The total number of octets in incoming packets for this Flow at
      the Observation Point since the Metering Process
      (re-)initialization for this Observation Point.  The number of
      octets include IP header(s) and IP payload.
   Abstract Data Type: unsigned64
   Data Type Semantics: totalCounter
   ElementId: 85
   Status: current
   Units: octets

5.10.5.  postOctetTotalCount

   Description:
      The definition of this Information Element is identical to the
      definition of Information Element 'octetTotalCount', except that
      it reports a potentially modified value caused by a middlebox
      function after the packet passed the Observation Point.
   Abstract Data Type: unsigned64
   Data Type Semantics: totalCounter
   ElementId: 171
   Status: current
   Units: octets

5.10.6.  octetTotalSumOfSquares








Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 68]

Internet-Draft           IPFIX Information Model               June 2006


   Description:
      The total sum of the squared numbers of octets in incoming packets
      for this Flow at the Observation Point since the Metering Process
      (re-)initialization for this Observation Point.  The number of
      octets include IP header(s) and IP payload.
   Abstract Data Type: unsigned64
   ElementId: 199
   Status: current
   Units: octets

5.10.7.  packetDeltaCount

   Description:
      The number of incoming packets since the previous report (if any)
      for this Flow at the Observation Point.
   Abstract Data Type: unsigned64
   Data Type Semantics: deltaCounter
   ElementId: 2
   Status: current
   Units: packets

5.10.8.  postPacketDeltaCount

   Description:
      The definition of this Information Element is identical to the
      definition of Information Element 'packetDeltaCount', except that
      it reports a potentially modified value caused by a middlebox
      function after the packet passed the Observation Point.
   Abstract Data Type: unsigned64
   Data Type Semantics: deltaCounter
   ElementId: 24
   Status: current
   Units: packets

5.10.9.  packetTotalCount

   Description:
      The total number of incoming packets for this Flow at the
      Observation Point since the Metering Process (re-)initialization
      for this Observation Point.
   Abstract Data Type: unsigned64
   Data Type Semantics: totalCounter
   ElementId: 86
   Status: current







Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 69]

Internet-Draft           IPFIX Information Model               June 2006


   Units: packets

5.10.10.  postPacketTotalCount

   Description:
      The definition of this Information Element is identical to the
      definition of Information Element 'packetTotalCount', except that
      it reports a potentially modified value caused by a middlebox
      function after the packet passed the Observation Point.
   Abstract Data Type: unsigned64
   Data Type Semantics: totalCounter
   ElementId: 172
   Status: current
   Units: packets

5.10.11.  droppedOctetDeltaCount

   Description:
      The number of octets since the previous report (if any) in packets
      of this Flow dropped by packet treatment.  The number of octets
      include IP header(s) and IP payload.
   Abstract Data Type: unsigned64
   Data Type Semantics: deltaCounter
   ElementId: 132
   Status: current
   Units: octets

5.10.12.  droppedPacketDeltaCount

   Description:
      The number of packets since the previous report (if any) of this
      Flow dropped by packet treatment.
   Abstract Data Type: unsigned64
   Data Type Semantics: deltaCounter
   ElementId: 133
   Status: current
   Units: packets

5.10.13.  droppedOctetTotalCount

   Description:
      The total number of octets in packets of this Flow dropped by
      packet treatment since the Metering Process (re-)initialization
      for this Observation Point.  The number of octets include IP
      header(s) and IP payload.






Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 70]

Internet-Draft           IPFIX Information Model               June 2006


   Abstract Data Type: unsigned64
   Data Type Semantics: totalCounter
   ElementId: 134
   Status: current
   Units: octets

5.10.14.  droppedPacketTotalCount

   Description:
      The number of packets of this Flow dropped by packet treatment
      since the Metering Process (re-)initialization for this
      Observation Point.
   Abstract Data Type: unsigned64
   Data Type Semantics: totalCounter
   ElementId: 135
   Status: current
   Units: packets

5.10.15.  postMCastPacketDeltaCount

   Description:
      The number of outgoing multicast packets since the previous report
      (if any) sent for packets of this Flow by a multicast daemon
      within the Observation Domain.  This property cannot necessarily
      be observed at the Observation Point, but may be retrieved by
      other means.
   Abstract Data Type: unsigned64
   Data Type Semantics: deltaCounter
   ElementId: 19
   Status: current
   Units: packets

5.10.16.  postMCastOctetDeltaCount

   Description:
      The number of octets since the previous report (if any) in
      outgoing multicast packets sent for packets of this Flow by a
      multicast daemon within the Observation Domain.  This property
      cannot necessarily be observed at the Observation Point, but may
      be retrieved by other means.  The number of octets include IP
      header(s) and IP payload.
   Abstract Data Type: unsigned64
   Data Type Semantics: deltaCounter
   ElementId: 20







Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 71]

Internet-Draft           IPFIX Information Model               June 2006


   Status: current
   Units: octets

5.10.17.  postMCastPacketTotalCount

   Description:
      The total number of outgoing multicast packets sent for packets of
      this Flow by a multicast daemon within the Observation Domain
      since the Metering Process (re-)initialization.  This property
      cannot necessarily be observed at the Observation Point, but may
      be retrieved by other means.
   Abstract Data Type: unsigned64
   Data Type Semantics: totalCounter
   ElementId: 174
   Status: current
   Units: packets

5.10.18.  postMCastOctetTotalCount

   Description:
      The total number of octets in outgoing multicast packets sent for
      packets of this Flow by a multicast daemon in the Observation
      Domain since the Metering Process (re-)initialization.  This
      property cannot necessarily be observed at the Observation Point,
      but may be retrieved by other means.  The number of octets include
      IP header(s) and IP payload.
   Abstract Data Type: unsigned64
   Data Type Semantics: totalCounter
   ElementId: 175
   Status: current
   Units: octets

5.11.  Miscellaneous Flow Properties

   Information Elements in this section describe properties of Flows
   that are related to Flow start, Flow duration and Flow termination,
   but they are no time stamps as Information Elements in section 5.8.

   +-----+---------------------------+-----+---------------------------+
   |  ID | Name                      |  ID | Name                      |
   +-----+---------------------------+-----+---------------------------+
   |  36 | flowActiveTimeout         | 161 | flowDurationMilliseconds  |
   |  37 | flowIdleTimeout           | 162 | flowDurationMicroseconds  |
   | 136 | flowEndReason             |     |                           |
   +-----+---------------------------+-----+---------------------------+






Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 72]

Internet-Draft           IPFIX Information Model               June 2006


5.11.1.  flowActiveTimeout

   Description:
      The number of seconds after which an active Flow is timed out
      anyway, even if there is still a continuous flow of packets.
   Abstract Data Type: unsigned16
   ElementId: 36
   Status: current
   Units: seconds

5.11.2.  flowIdleTimeout

   Description:
      A Flow is considered to be timed out if no packets belonging to
      the Flow have been observed for the number of seconds specified by
      this field.
   Abstract Data Type: unsigned16
   ElementId: 37
   Status: current
   Units: seconds

5.11.3.  flowEndReason

   Description:
      The reason for Flow termination.  The range of values includes

      0x01: idle timeout
            The Flow was terminated because it was considered to be
            idle.
      0x02: active timeout
            The Flow was terminated for reporting purposes while it was
            still active, for example, after the maximum lifetime of
            unreported Flows was reached.
      0x03: end of Flow detected
            The Flow was terminated because the Metering Process
            detected signals indicating the end of the Flow,
            for example, the TCP FIN flag.
      0x04: forced end
            The Flow was terminated because of some external event,
            for example, a shut down of the Metering Process initiated
            by a network management application.
      0x05: cache full
            the Flow was terminated because of lack of resources
            available to the Metering Process and/or the Exporting
            Process






Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 73]

Internet-Draft           IPFIX Information Model               June 2006


   Abstract Data Type: unsigned8
   Data Type Semantics: identifier
   ElementId: 136
   Status: current

5.11.4.  flowDurationMilliseconds

   Description:
      The difference in time between the observation of the first packet
      of this Flow and the observation of the last packet of this Flow.
   Abstract Data Type: unsigned32
   ElementId: 161
   Status: current
   Units: milliseconds

5.11.5.  flowDurationMicroseconds

   Description:
      The difference in time between the observation of the first packet
      of this Flow and the observation of the last packet of this Flow.
   Abstract Data Type: unsigned32
   ElementId: 162
   Status: current
   Units: microseconds

5.12.  Padding

   This section contains a single Information Element only, that can be
   used for padding of Flow Records.

   IPFIX Implementations may wish to align Information Elements within
   Data Records or to align entire Data Records to 4 octet or 8 octet
   boundaries.  This can be achieved by including one or more
   paddingOctets Information Elements in a Data Record.

   +-----+---------------------------+-----+---------------------------+
   |  ID | Name                      |  ID | Name                      |
   +-----+---------------------------+-----+---------------------------+
   | 210 | paddingOctets             |     |                           |
   +-----+---------------------------+-----+---------------------------+

5.12.1.  paddingOctets

   Description:







Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 74]

Internet-Draft           IPFIX Information Model               June 2006


      The value of this Information Element is always a sequence of 0x00
      values.
   Abstract Data Type: octetArray
   ElementId: 210
   Status: current


6.  Extending the Information Model

   A key requirement for IPFIX is to allow for extending the set of
   Information Elements which are reported.  This section defines the
   mechanism for extending this set.

   Extension is done by defining new Information Elements.  Each new
   Information Element MUST be assigned a unique Information Element
   identifier as part of its definition.  These unique Information
   Element identifiers are the connection between the record structure
   communicated by the protocol using Templates and a consuming
   application.  For generally applicable Information Elements using
   IETF and IANA mechanisms for extending the information model is
   recommended.

   Names of new Information Elements SHOULD be chosen according to the
   naming conventions given in section 2.3.

   For extensions, the type space defined in section 3 can be used.  If
   required, new abstract data types can be added.  New abstract data
   types MUST be defined in IETF standards track documents.

   Enterprises may wish to define Information Elements without
   registering them with IANA.  IPFIX explicitly supports enterprise-
   specific Information Elements.  Enterprise-specific Information
   Elements as described in sections 2.1 and 4.

   However, before creating enterprise-specific Information Elements,
   the general applicability of such Information Elements should be
   considered.  IPFIX does not support enterprise-specific abstract data
   types.


7.  IANA Considerations

7.1.  IPFIX Information Elements

   This document specifies an initial set of IPFIX Information Elements.
   The list of these Information Elements with their identifiers is
   given in section 4.  The Internet Assigned Numbers Authority (IANA)
   is requested to create a new registry for IPFIX Information Element



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 75]

Internet-Draft           IPFIX Information Model               June 2006


   identifiers and fill it with the initial list in section 4.

   New assignments for IPFIX Information Elements will be administered
   by IANA, on a First Come First Served basis [RFC2434], subject to
   Expert Review [RFC2434], i.e. review by one of a group of experts
   designated by an IETF Operations and Management Area Director.  The
   group of experts must double check the Information Elements
   definitions with already defined Information Elements for
   completeness, accuracy, redundancy, and correct naming following the
   naming conventions in section 2.3.

   The specification of new IPFIX Information Elements MUST use the
   template specified in section 2.1 and MUST be published using a well
   established and persistent publication medium.  The experts will
   initially be drawn from the Working Group Chairs and document editors
   of the IPFIX and PSAMP Working Groups.

7.2.  MPLS Label Type Identifier

   Information Element #46 named mplsTopLabelType carries MPLS label
   types.  So far, values for 5 different types have initially been
   defined.  For ensuring extensibility of this information, IANA is
   requested to create a new registry for MPLS label types and fill it
   with the initial list the description Information Element #46 named
   mplsTopLabelType.

   New assignments for MPLS label types will be administered by IANA, on
   a First Come First Served basis [RFC2434], subject to Expert Review
   [RFC2434], i.e. review by one of a group of experts designated by an
   IETF Operations and Management Area Director.  The group of experts
   must double check the label type definitions with already defined
   label types for completeness, accuracy, and redundancy.  The
   specification of new MPLS label types MUST be published using a well
   established and persistent publication medium.

7.3.  XML Namespace and Schema

   Appendix B defines an XML schema for IPFIX Information Element
   definitions.  All Information Elements specified in this document are
   defined by the XML specification in Appendix A that is a valid XML
   record according to the schema in appendix B.  This schema may also
   be used for specifying further Information Elements in future
   extensions of the IPFIX information model in a machine readable way.

   Appendix uses URNs to describe an XML namespace and an the XML schema
   for IPFIX Information Elements conforming to a registry mechanism
   described in [RFC3688].  Two URI assignments are requested.




Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 76]

Internet-Draft           IPFIX Information Model               June 2006


   1.  Registration request for the IPFIX information model namespace
       *  URI: urn:ietf:params:xml:ns:ipfix-info-10
       *  Registrant Contact: TBD.
       *  XML: None.  Namespace URIs do not represent an XML
   2.  Registration request for the IPFIX information model schema
       *  URI: urn:ietf:params:xml:schema:ipfix-info-10
       *  Registrant Contact: TBD.
       *  XML: See Appendix B for this document.


8.  Security Considerations

   The IPFIX information model itself does not directly introduce
   security issues.  Rather it defines a set of attributes which may for
   privacy or business issues be considered sensitive information.

   The underlying protocol used to exchange the
      Observation Point since information described
   here must therefore apply appropriate procedures to guarantee the
   integrity and confidentiality of the exported information.  Such
   protocols are defined in separate documents, specifically the IPFIX
   protocol document [I-D.ietf-ipfix-protocol].


9.  Acknowledgements

   The editors thank Paul Callato for creating the initial version of
   this document, Thomas Dietz for developing the XSLT scripts that
   generate large portions of the text part of this document from the
   XML appendices, and Paul Aitken for a very detailed review that
   helped improving the document significantly.


10.  References

10.1.  Normative References

   [I-D.ietf-ipfix-protocol]
              Claise, B., "IPFIX Protocol Specification",
              draft-ietf-ipfix-protocol-19 (work in progress),
              September 2005.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

10.2.  Informative References

   [IEEE.754.1985]
              Institute of Electrical and Electronics Engineers,



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 77]

Internet-Draft           IPFIX Information Model               June 2006


              "Standard for Binary Floating-Point Arithmetic",
              IEEE Standard 754, August 1985.

   [IEEE.802-11.1999]
              "Information technology - Telecommunications and
              information exchange between systems - Local and
              metropolitan area networks - Specific requirements - Part
              11: Wireless LAN Medium Access Control (MAC) and Physical
              Layer (PHY) specifications", IEEE Standard 802.11, 1999,
              <http://standards.ieee.org/getieee802/download/
              802.11-1999.pdf>.

   [IEEE.802-1Q.2003]
              Institute of Electrical and Electronics Engineers, "Local
              and Metropolitan Area Networks: Virtual Bridged Local Area
              Networks", IEEE Standard 802.1Q, March 2003.

   [IEEE.802-3.2002]
              "Information technology - Telecommunications and
              information exchange between systems - Local and
              metropolitan area networks - Specific requirements - Part
              3: Carrier sense multiple access with collision detection
              (CSMA/CD) access method and physical layer
              specifications"", IEEE Standard 802.3, September 2002.

   [ISO.10646-1.1993]
              International Organization for Standardization,
              "Information Technology - Universal Multiple-octet coded
              Character Set (UCS) - Part 1: Architecture and Basic
              Multilingual Plane", ISO Standard 10646-1, May 1993.

   [ISO.646.1991]
              International Organization for Standardization,
              "Information technology - ISO 7-bit coded character set
              for information interchange", ISO Standard 646, 1991.

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              September 1981.

   [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
              RFC 792, September 1981.

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, September 1981.




Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 78]

Internet-Draft           IPFIX Information Model               June 2006


   [RFC1108]  Kent, S., "U.S", RFC 1108, November 1991.

   [RFC1112]  Deering, S., "Host extensions for IP multicasting", STD 5,
              RFC 1112, August 1989.

   [RFC1191]  Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
              November 1990.

   [RFC1385]  Wang, Z., "EIP: The Extended Internet Protocol", RFC 1385,
              November 1992.

   [RFC1771]  Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
              (BGP-4)", RFC 1771, March 1995.

   [RFC1812]  Baker, F., "Requirements for IP Version 4 Routers",
              RFC 1812, June 1995.

   [RFC1930]  Hawkinson, J. and T. Bates, "Guidelines for creation,
              selection, and registration of an Autonomous System (AS)",
              BCP 6, RFC 1930, March 1996.

   [RFC2113]  Katz, D., "IP Router Alert Option", RFC 2113,
              February 1997.

   [RFC2236]  Fenner, W., "Internet Group Management Protocol, Version
              2", RFC 2236, November 1997.

   [RFC2402]  Kent, S. and R. Atkinson, "IP Authentication Header",
              RFC 2402, November 1998.

   [RFC2406]  Kent, S. and R. Atkinson, "IP Encapsulating Security
              Payload (ESP)", RFC 2406, November 1998.

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC2463]  Conta, A. and S. Deering, "Internet Control Message
              Protocol (ICMPv6) for the Metering Process (re-)initialization Internet Protocol Version 6
              (IPv6) Specification", RFC 2463, December 1998.

   [RFC2547]  Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547,
              March 1999.

   [RFC2578]  McCloghrie, K., Ed., Perkins, D., Ed., and J.



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 79]

Internet-Draft           IPFIX Information Model               June 2006


              Schoenwaelder, Ed., "Structure of Management Information
              Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

   [RFC2675]  Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms",
              RFC 2675, August 1999.

   [RFC2863]  McCloghrie, K. and F. Kastenholz, "The Interfaces Group
              MIB", RFC 2863, June 2000.

   [RFC2960]  Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
              Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
              Zhang, L., and V. Paxson, "Stream Control Transmission
              Protocol", RFC 2960, October 2000.

   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031, January 2001.

   [RFC3032]  Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
              Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
              Encoding", RFC 3032, January 2001.

   [RFC3036]  Andersson, L., Doolan, P., Feldman, N., Fredette, A., and
              B. Thomas, "LDP Specification", RFC 3036, January 2001.

   [RFC3193]  Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth,
              "Securing L2TP using IPsec", RFC 3193, November 2001.

   [RFC3234]  Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
              Issues", RFC 3234, February 2002.

   [RFC3260]  Grossman, D., "New Terminology and Clarifications for this Observation Point.
   Abstract Data Type: unsigned64
   Data Type Semantics: totalCounter
   ElementId: 86
   Status: current
   Units: packets

5.9.10.  postPacketTotalCount

   Description:
      The definition of this Information Element is identical to the
      definition
              Diffserv", RFC 3260, April 2002.

   [RFC3270]  Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
              P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-
              Protocol Label Switching (MPLS) Support of Information Element 'packetTotalCount', except that
      it reports a potentially modified value caused by a middlebox
      function after the packet passed the observation point.
   Abstract Data Type: unsigned64
   Data Type Semantics: totalCounter
   ElementId: 172 Differentiated
              Services", RFC 3270, May 2002.

   [RFC3513]  Hinden, R. and S. Deering, "Internet Protocol Version 6
              (IPv6) Addressing Architecture", RFC 3513, April 2003.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              January 2004.

   [RFC3954]  Claise, B., "Cisco Systems NetFlow Services Export Version



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 63] 80]

Internet-Draft           IPFIX Information Model          September 2005


   Status: current
   Units: packets

5.9.11.  droppedOctetDeltaCount

   Description:
      The number               June 2006


              9", RFC 3954, October 2004.

   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
              Networks (VPNs)", RFC 4364, February 2006.

   [RFC4382]  Nadeau, T. and H. van der Linde, "MPLS/BGP Layer 3 Virtual
              Private Network (VPN) Management Information Base",
              RFC 4382, February 2006.


Appendix A.  XML Specification of IPFIX Information Elements

   This appendix contains a machine readable description of octets since the previous report (if any) IPFIX
   information model coded in packets
      of XML.  Note that this Flow dropped by packet treatment.  The number of octets
      include IP header(s) and IP payload.
   Abstract Data Type: unsigned64
   Data Type Semantics: deltaCounter
   ElementId: 132
   Status: current
   Units: octets

5.9.12.  droppedPacketDeltaCount

   Description:
      The number appendix is of packets since
   informational nature, while the text in section 4 (generated from
   this appendix) is normative.

   Using a machine readable syntax for the Information model enables the previous report (if any)
   creation of this
      Flow dropped IPFIX aware tools which can automatically adapt to
   extensions to the information model, by packet treatment.
   Abstract Data Type: unsigned64
   Data Type Semantics: deltaCounter
   ElementId: 133
   Status: current
   Units: packets

5.9.13.  droppedOctetTotalCount

   Description: simply reading updated
   information model specifications.

   The total number of octets in packets wide availability of XML aware tools and libraries for client
   devices is a primary consideration for this Flow dropped by
      packet treatment since choice.  In particular
   libraries for parsing XML documents are readily available.  Also
   mechanisms such as the Metering Process (re-)initialization Extensible Stylesheet Language (XSL) allow for this Observation Point.  The number of octets include IP
      header(s)
   transforming a source XML document into other documents.  This draft
   was authored in XML and IP payload.
   Abstract Data Type: unsigned64
   Data Type Semantics: totalCounter
   ElementId: 134
   Status: current
   Units: octets

5.9.14.  droppedPacketTotalCount

   Description:
      The number transformed according to RFC2629.

   It should be noted that the use of packets XML in Exporters, Collectors or
   other tools is not mandatory for the deployment of IPFIX.  In
   particular Exporting Processes do not produce or consume XML as part
   of their operation.  It is expected that IPFIX Collectors MAY take
   advantage of this Flow dropped by packet treatment
      since the Metering Process (re-)initialization machine readability of the Information Model vs.
   hard coding their behavior or inventing proprietary means for this
      Observation Point.
   accommodating extensions.



   <?xml version="1.0" encoding="UTF-8"?>

   <fieldDefinitions xmlns="urn:ietf:params:xml:ns:ipfix-info-10"
                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                xsi:schemaLocation="urn:ietf:params:xml:ns:ipfix-info-10
                ipfix-info-10.xsd">

     <field name="lineCardId" dataType="unsigned32"
            group="scope"



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 64] 81]

Internet-Draft           IPFIX Information Model          September 2005


   Abstract Data Type: unsigned64
   Data Type Semantics: totalCounter
   ElementId: 135
   Status: current
   Units: packets

5.9.15.  postMCastPacketDeltaCount

   Description:
      The number               June 2006


            dataTypeSemantics="identifier"
            elementId="141" applicability="option" status="current">
       <description>
         <paragraph>
           An identifier of outgoing multicast packets since the previous report
      (if any) sent a line card that is unique per IPFIX
           Device hosting an Observation Point.  Typically, this
           Information Element is used for packets limiting the scope
           of other Information Elements.
         </paragraph>
       </description>
     </field>

     <field name="portId" dataType="unsigned32"
            group="scope"
            dataTypeSemantics="identifier"
            elementId="142" applicability="option" status="current">
       <description>
         <paragraph>
           A identifier of this Flow by a multicast daemon
      within the line port that is unique per IPFIX
           Device hosting an Observation Domain.  This property cannot necessarily
      be observed at Point.  Typically, this
           Information Element is used for limiting the Observation Point, but may be retrieved by scope
           of other means.
   Abstract Data Type: unsigned64
   Data Type Semantics: deltaCounter
   ElementId: 19
   Status: current
   Units: packets

5.9.16.  postMCastOctetDeltaCount

   Description: Information Elements.
         </paragraph>
       </description>
     </field>

     <field name="ingressInterface" dataType="unsigned32"
            group="scope"
            dataTypeSemantics="identifier"
            elementId="10" applicability="all" status="current">
       <description>
         <paragraph>
           The number index of octets since the previous report (if any) in
      outgoing multicast packets sent for IP interface where packets of this Flow by a
      multicast daemon within
           are being received.  The value matches the Observation Domain.  This property
      cannot necessarily be observed at value of managed
           object 'ifIndex' as defined in RFC 2863 [RFC2863].
           Note that ifIndex values are not assigned statically to an
           interface, and that the Observation Point, but interfaces may be retrieved by other means.  The number of octets include IP
      header(s) and IP payload.
   Abstract Data Type: unsigned64
   Data Type Semantics: deltaCounter
   ElementId: 20
   Status: current
   Units: octets

5.9.17.  postMCastPacketTotalCount

   Description:
      The total number of outgoing multicast packets sent for packets of
      this Flow by a multicast daemon within renumbered every
           time the Observation Domain
      since device's management system is re-initialized, as
           specified in RFC 2863 [RFC2863].
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 2863 [RFC2863] for the Metering Process (re-)initialization.  This property
      cannot necessarily be observed at definition of the Observation Point, but may
      be retrieved by other means.
   Abstract Data Type: unsigned64 ifIndex
         object.
         </paragraph>
       </reference>
     </field>



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 65] 82]

Internet-Draft           IPFIX Information Model          September 2005


   Data Type Semantics: totalCounter
   ElementId: 174
   Status: current
   Units: packets

5.9.18.  postMCastOctetTotalCount

   Description:               June 2006


     <field name="egressInterface" dataType="unsigned32"
            group="scope"
            dataTypeSemantics="identifier"
            elementId="14" applicability="all" status="current">
       <description>
         <paragraph>
           The total number index of octets in outgoing multicast packets sent for the IP interface where packets of
           this Flow by a multicast daemon in the Observation
      Domain since the Metering Process (re-)initialization.  This
      property cannot necessarily be observed at the Observation Point,
      but may be retrieved by other means. are being sent.  The number value matches the value of octets include
      IP header(s) and IP payload.
   Abstract Data Type: unsigned64
   Data Type Semantics: totalCounter
   ElementId: 175
   Status: current
   Units: octets

5.10.  Miscellaneous Flow Properties

   Information Elements
           managed object 'ifIndex' as defined in this section describe properties of Flows RFC 2863 [RFC2863].
           Note that ifIndex values are related not assigned statically to Flow start, Flow duration an
           interface, and Flow termination,
   but they are no that the interfaces may be renumbered every
           time stamps the device's management system is re-initialized, as Information Elements
           specified in section 5.8.

   +-----+---------------------------+-----+---------------------------+
   |  ID | Name                      |  ID | Name                      |
   +-----+---------------------------+-----+---------------------------+
   |  36 | flowActiveTimeOut         | 161 | flowDurationMilliSeconds  |
   |  37 | flowInactiveTimeout       | 162 | flowDurationMicroSeconds  |
   | 136 | flowEndReason             |     |                           |
   +-----+---------------------------+-----+---------------------------+

5.10.1.  flowActiveTimeOut

   Description: RFC 2863 [RFC2863].
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 2863 [RFC2863] for the definition of the
         ifIndex object.
         </paragraph>
       </reference>
     </field>

     <field name="meteringProcessId" dataType="unsigned32"
            group="scope"
            dataTypeSemantics="identifier"
            elementId="143" applicability="option" status="current">
       <description>
         <paragraph>
           An identifier of a Metering Process that is unique per
           IPFIX Device.  Typically, this Information Element is used
           for limiting the scope of other Information Elements.
           Note that process identifiers are typically assigned
           dynamically.
           The number Metering Process may be re-started with a different ID.
         </paragraph>
       </description>
     </field>

     <field name="exportingProcessId" dataType="unsigned32"
            group="scope"
            dataTypeSemantics="identifier"
            elementId="144" applicability="option" status="current">
       <description>
         <paragraph>
           An identifier of seconds after which an active Flow Exporting Process that is timed out
      anyway, even if there unique per
           IPFIX Device.  Typically, this Information Element is still a continuous flow used
           for limiting the scope of packets.
   Abstract Data Type: unsigned16
   ElementId: 36
   Status: current
   Units: seconds

5.10.2.  flowInactiveTimeout other Information Elements.



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 66] 83]

Internet-Draft           IPFIX Information Model          September 2005


   Description:
      A               June 2006


           Note that process identifiers are typically assigned
           dynamically.  The Exporting Process may be re-started
           with a different ID.
         </paragraph>
       </description>
     </field>

     <field name="flowId" dataType="unsigned32"
            group="scope"
            dataTypeSemantics="identifier"
            elementId="148" applicability="option" status="current">
       <description>
         <paragraph>
           An identifier of a Flow that is considered to unique within an Observation
           Domain. This Information Element can be timed out if no packets belonging used to
      the Flow have been observed for the number of seconds specified by
      this field.
   Abstract Data Type: unsigned16
   ElementId: 37
   Status: current
   Units: seconds

5.10.3.  flowEndReason

   Description:
      The reason for distinguish
           between different Flows if Flow termination.  The range of values includes

      0x01: idle timeout
            The flow was terminated because it was considered to be
            idle.
      0x02: active timeout
            The flow was terminated for reporting purposes while it was
            still active, for example, after the maximum lifetime of
            unreported flows was reached.
      0x03: end Keys such as IP addresses and
           port numbers are not reported or are reported in separate
           records.
         </paragraph>
       </description>
     </field>

     <field name="templateId" dataType="unsigned16"
            group="scope"
            dataTypeSemantics="identifier"
            elementId="145" applicability="option" status="current">
       <description>
         <paragraph>
           An identifier of Flow detected
            The flow was terminated because a Template that is unique within the Metering
           communication between an Exporting Process
            detected signals indicating the end of the flow, and a
           Collecting Process.  Typically, this Information Element is
           used for example, limiting the TCP FIN flag.
      0x04: forced end
            The flow was terminated because scope of some external event,
            for example, other Information Elements.
           Note that after a shut down re-start of the Metering Exporting Process initiated
            by a network management application.
      0x05: cache full Template
           identifiers may be re-assigned.
         </paragraph>
       </description>
     </field>

     <field name="observationDomainId" dataType="unsigned32"
            group="scope"
            dataTypeSemantics="identifier"
            elementId="149" applicability="option" status="current">
       <description>
         <paragraph>
         An identifier of an Observation Domain that is unique per
         Exporting Process.  It is RECOMMENDED that this identifier is
         also unique per IPFIX Device.  Typically, this Information
         Element is used for limiting the flow was terminated because scope of lack other Information



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 84]

Internet-Draft           IPFIX Information Model               June 2006


         Elements.
         </paragraph>
       </description>
     </field>

     <field name="observationPointId" dataType="unsigned32"
            group="scope"
            dataTypeSemantics="identifier"
            elementId="138" applicability="option" status="current">
       <description>
         <paragraph>
         An identifier of resources
            available to the Metering Process and/or an Observation Point that is unique per
         Observation Domain.  It is RECOMMENDED that this identifier is
         also unique per IPFIX Device.  Typically, this Information
         Element is used for limiting the Exporting
            Process

   Abstract Data Type: octet
   Data Type Semantics: scope of other Information
         Elements.
         </paragraph>
       </description>
     </field>

     <field name="commonPropertiesId" dataType="unsigned64"
            group="scope"
            dataTypeSemantics="identifier"
            elementId="137" applicability="option" status="current">
       <description>
         <paragraph>
           An identifier
   ElementId: 136
   Status: current

5.10.4.  flowDurationMilliSeconds

   Description: of a set of common properties that is unique
           per Observation Domain.  Typically, this Information Element
           is used to link to information reported in separate records.
         </paragraph>
       </description>
     </field>

     <field name="exporterIPv4Address" dataType="ipv4Address"
            dataTypeSemantics="identifier"
            group="config"
            elementId="130" applicability="all" status="current">
       <description>
         <paragraph>
         The difference between in time between IPv4 address used by the observation
      of Exporting Process.  This is used
         by the first packet of this Flow and Collector to identify the observation Exporter in cases where the
         identity of the last
      packet Exporter may have been obscured by the use of this Flow.
         a proxy.
         </paragraph>
       </description>
     </field>

     <field name="exporterIPv6Address" dataType="ipv6Address"



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 67] 85]

Internet-Draft           IPFIX Information Model          September 2005


   Abstract Data Type: unsigned32
   ElementId: 161
   Status: current
   Units: milliseconds

5.10.5.  flowDurationMicroSeconds

   Description:               June 2006


            dataTypeSemantics="identifier"
            group="config"
            elementId="131" applicability="all" status="current">
       <description>
         <paragraph>
         The difference between in time between IPv6 address used by the observation
      of Exporting Process.  This is used
         by the first packet of this Flow and Collector to identify the observation Exporter in cases where the
         identity of the last
      packet Exporter may have been obscured by the use of this Flow.
   Abstract Data Type: unsigned32
   ElementId: 162
   Status: current
   Units: microseconds

5.11.  Padding

   This section contains
         a single Information Element only, that can be
   used for padding of Flow Records.

   IPFIX Implementations may wish to align Information Elements within
   Data Records or proxy.
         </paragraph>
       </description>
     </field>

     <field name="collectorIPv4Address" dataType="ipv4Address"
            dataTypeSemantics="identifier"
            group="config"
            elementId="211" applicability="all" status="current">
       <description>
         <paragraph>
         An IPv4 address to align entire Data Records which the Exporting Process sends Flow
         information.
         </paragraph>
       </description>
     </field>

     <field name="collectorIPv6Address" dataType="ipv6Address"
            dataTypeSemantics="identifier"
            group="config"
            elementId="212" applicability="all" status="current">
       <description>
         <paragraph>
         An IPv6 address to 4 octet or 8 octet
   boundaries.  This can be achieved by including one or more
   paddingOctets Information Elements in a Data Record.

   +-----+---------------------------+-----+---------------------------+
   |  ID | Name                      |  ID | Name                      |
   +-----+---------------------------+-----+---------------------------+
   | 210 | paddingOctets             |     |                           |
   +-----+---------------------------+-----+---------------------------+

5.11.1.  paddingOctets

   Description: which the Exporting Process sends Flow
         information.
         </paragraph>
       </description>
     </field>

     <field name="collectorInterface" dataType="unsigned32"
            group="config"
            dataTypeSemantics="identifier"
            elementId="213" applicability="all" status="current">
       <description>
         <paragraph>
           The value index of this Information Element is always 0.
   Abstract Data Type: octetArray
   ElementId: 210
   Status: current


6.  Extending the Information Model

   A key requirement for IPFIX is to allow for extending IP interface where the set Exporting Process
           sends Flow information.  The value matches the value of
   Information Elements which
           managed object 'ifIndex' as defined in RFC 2863 [RFC2863].
           Note that ifIndex values are reported.  This section defines not assigned statically to an
           interface, and that the
   mechanism for extending this set.

   Extension is done by defining new Information Elements.  Each new
   Information Element MUST interfaces may be assigned a unique Information Element renumbered every



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 68] 86]

Internet-Draft           IPFIX Information Model          September 2005


   identifier as part of its definition.  These unique Information
   Element identifiers are the connection between the record structure
   communicated by               June 2006


           time the protocol using templates and a consuming
   application.  For generally applicable Information Elements using
   IETF and IANA mechanisms device's management system is re-initialized, as
           specified in RFC 2863 [RFC2863].
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 2863 [RFC2863] for extending the information model is
   recommended.

   Names definition of new Information Elements SHOULD be chosen according to the
   naming conventions given in section 2.3.

   For extensions, the type space defined in section 3 can be used.  If
   required, new data types can be added.  New data types SHOULD be
   defined in IETF standards track documents.

   Enterprises may wish to define Information Elements without
   registering them with IANA.  IPFIX explicitly supports enterprise-
   specific Information Elements.  Enterprise-specific Information
   Elements as described in sections 2.1 and 4.

   However, before creating enterprise-specific Information Elements,
         ifIndex object.
         </paragraph>
       </reference>
     </field>

     <field name="collectorProtocolVersion" dataType="unsigned8"
            dataTypeSemantics="identifier"
            group="config"
            elementId="214" applicability="all" status="current">
       <description>
         <paragraph>
           The protocol version used by the general applicability of such Information Elements should be
   considered.  IPFIX does not support enterprise-specific data types.


7.  IANA Considerations

   This documents defines an initial set Exporting Process for
           sending Flow information, The protocol version is given
           by the value of IPFIX Information Elements.
   For extending them the Version Number field in the future, IANA needs to create a new registry Message
           Header.
         </paragraph>
         <paragraph>
           The protocol version is 10 for IPFIX Information Element identifiers.

   New assignments and 9 for IPFIX Information Elements will be administered
   by IANA, on a First Come First Served basis [RFC2434], subject to
   Expert Review [RFC2434], i.e. review by one NetFlow
           version 9.
           A value of a group 0 indicates that no export protocol is in use.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See [I-D.ietf-ipfix-protocol] for the definition of experts
   designated by an IETF Operations and Management Area Director. the IPFIX
         Message header.
         See RFC 3954 [RFC3954] or the definition of the NetFlow
         version 9 message header.
         </paragraph>
       </reference>
     </field>

     <field name="collectorTransportProtocol" dataType="unsigned8"
            group="config"
            dataTypeSemantics="identifier"
            elementId="215" applicability="all" status="current">
       <description>
         <paragraph>
         The
   group value of experts must double check the Information Elements
   definitions with already protocol number in the IP packet header.
         The protocol number identifies the IP packet payload type.
         Protocol numbers are defined in the IANA Protocol Numbers



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 87]

Internet-Draft           IPFIX Information Elements for
   completeness, accuracy, redundancy, and correct naming following Model               June 2006


         registry.</paragraph>

         <paragraph>
         In Internet Protocol version 4 (IPv4) this is carried in the
         "Protocol" field. In Internet Protocol version 6 (IPv6) this
         is carried in the "Next Header" field in the last extension
         header of the packet.</paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 791 [RFC0791] for the
   naming conventions in section 2.3.  Those experts will initially be
   drawn from specification of the Working Group Chairs and document editors IPv4
         protocol field.
         See RFC 2460 [RFC2460] for the specification of the IPFIX
   and PSAMP Working Groups.

   Appendix B defines an XML schema which may be used to create
   consistent machine readable extensions to IPv6
         protocol field.
         See the IPFIX information
   model.  This schema introduces a new namespace, which will be list of protocol numbers assigned by IANA according at
         http://www.iana.org/assignments/protocol-numbers.
         </paragraph>
       </reference>
     </field>

     <field name="collectorTransportPort" dataType="unsigned16"
            group="config"
            dataTypeSemantics="identifier"
            elementId="216" applicability="all" status="current">
       <description>
         <paragraph>
         The destination port identifier to RFC 3688.  Currently which the name space for Exporting
         Process sends Flow information.  For the transport protocols
         UDP, TCP and SCTP this schema is identified as http://www.ietf.org/ipfix. the destination port number.
         This field MAY also be used for future transport protocols
         that have 16 bit source port identifiers.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 768 [RFC0768] for the definition of the UDP
         destination port field.
         See RFC 793 [RFC0793] for the definition of the TCP
         destination port field.
         See RFC 2960 [RFC2960] for the definition of SCTP.
         </paragraph>
         <paragraph>
         Additional information on defined UDP and TCP port numbers can
         be found at http://www.iana.org/assignments/port-numbers.
         </paragraph>
       </reference>
     </field>




Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 69] 88]

Internet-Draft           IPFIX Information Model          September 2005


8.  Security Considerations

   The IPFIX information model itself does not directly introduce
   security issues.  Rather it defines a               June 2006


     <field name="flowKeyIndicator" dataType="unsigned64"
            dataTypeSemantics="flags"
            group="config"
            elementId="173" applicability="all" status="current">
       <description>
         <paragraph>
         This set of attributes which may for
   privacy or business issues be considered sensitive information.

   The underlying protocol bit fields is used to exchange the information described
   here must therefore apply appropriate procedures to guarantee the
   integrity and confidentiality of for marking the exported information.  Such
   protocols are defined Information
         Elements of a Data Record that serve as Flow Key.  Each bit
         represents an Information Element in separate documents, specifically the IPFIX
   protocol document [I-D.ietf-ipfix-protocol].


9.  Acknowledgements

   The editors thank Paul Callato for creating Data Record with
         the initial version of
   this document, Thomas Dietz for developing n-th bit representing the XSLT scripts n-th Information Element.
         A bit set to value 1 indicates that
   generate large portions of the text part corresponding
         Information Element is a Flow Key of the reported Flow.
         A bit set to value 0 indicates that this document from is not the
   XML appendices, and Paul Aitken for a very detailed review case.
         </paragraph>
         <paragraph>
         If the
         Data Record contains more than 64 Information Elements, the
         corresponding Template SHOULD be designed such that
   helped improving all Flow
         Keys are among the document significantly.


10.  References

10.1.  Normative References

   [I-D.ietf-ipfix-protocol]
              Claise, B., "IPFIX Protocol Specification",
              draft-ietf-ipfix-protocol-12 (work first 64 Information Elements, because the
         flowKeyIndicator only contains 64 bits.  If the Data Record
         contains less than 64 Information Elements, then the bits in progress),
              April 2005.

10.2.  Informative References

   [I-D.ietf-ipfix-architecture]
              Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek,
              "Architecture
         the flowKeyIndicator for IP Flow which no corresponding Information Export",
              draft-ietf-ipfix-architecture-07 (work in progress),
              March 2005.

   [I-D.ietf-ipfix-as]
              Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IPFIX
              Applicability", draft-ietf-ipfix-as-04 (work in progress),
              February 2005.

   [IEEE.754.1985]
              Institute
         Element exists SHOULD have the value 0.
         </paragraph>
       </description>
     </field>

     <field name="exportedMessageTotalCount" dataType="unsigned64"
            dataTypeSemantics="totalCounter"
            group="processCounter"
            elementId="41" applicability="data" status="current">
       <description>
         <paragraph>
           The total number of Electrical and Electronics Engineers,
              "Standard for Binary Floating-Point Arithmetic",
              IEEE Standard 754, August 1985. IPFIX Messages that the Exporting Process
           successfully sent since the Exporting Process
           (re-)initialization to the Collecting Process receiving a
           report that contains this Information Element.
           The reported number excludes the IPFIX Message that carries
           the counter value.
         </paragraph>
       </description>
       <units>messages</units>
     </field>

     <field name="exportedOctetTotalCount" dataType="unsigned64"
            dataTypeSemantics="totalCounter"
            group="processCounter"
            elementId="40" applicability="data" status="current">



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 70] 89]

Internet-Draft           IPFIX Information Model          September 2005


   [IEEE.802-11.1999]
              "Information technology - Telecommunications and
              information exchange between systems - Local and
              metropolitan area networks - Specific requirements - Part
              11: Wireless LAN Medium Access Control (MAC) and Physical
              Layer (PHY) specifications", IEEE Standard 802.11, 1999,
              <http://standards.ieee.org/getieee802/download/
              802.11-1999.pdf>.

   [IEEE.802-3.2002]
              "Information technology - Telecommunications and
              information exchange between systems - Local and
              metropolitan area networks - Specific requirements - Part
              3: Carrier sense multiple access with collision detection
              (CSMA/CD) access method and physical layer
              specifications"", IEEE Standard 802.3, September 2002.

   [IEEE.P802-1Q.2003]
              Institute               June 2006


       <description>
         <paragraph>
           The total number of Electrical and Electronics Engineers, "Local
              and Metropolitan Area Networks: Virtual Bridged Local Area
              Networks", IEEE Standard 802.1Q, March 2003.

   [ISO.10646-1.1993]
              International Organization for Standardization,
              "Information Technology - Universal Multiple-octet coded
              Character Set (UCS) - Part 1: Architecture and Basic
              Multilingual Plane", ISO Standard 10646-1, May 1993.

   [ISO.646.1991]
              International Organization for Standardization,
              "Information technology - ISO 7-bit coded character set
              for information interchange", ISO Standard 646, 1991.

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              September 1981.

   [RFC0792]  Postel, J., "Internet Control octets that the Exporting Process
           successfully sent since the Exporting Process
           (re-)initialization to the Collecting Process receiving a
           report that contains this Information Element.  The value
           of this Information Element is calculated by summing up
           the IPFIX Message Protocol", STD 5,
              RFC 792, September 1981.

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, September 1981.

   [RFC1771]  Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
              (BGP-4)", RFC 1771, March 1995.




Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 71]

Internet-Draft Header length values of all IPFIX Messages
           that were successfully sent to the Collecting Process
           receiving a report that contains this Information Model          September 2005


   [RFC1812]  Baker, F., "Requirements for IP Version 4 Routers",
              RFC 1812, June 1995.

   [RFC1930]  Hawkinson, J. and T. Bates, "Guidelines for creation,
              selection, and registration of an Autonomous System (AS)",
              BCP 6, RFC 1930, March 1996.

   [RFC2236]  Fenner, W., "Internet Group Management Protocol, Version
              2", RFC 2236, November 1997.

   [RFC2402]  Kent, S. and R. Atkinson, "IP Authentication Header",
              RFC 2402, November 1998.

   [RFC2406]  Kent, S. and R. Atkinson, "IP Encapsulating Security
              Payload (ESP)", RFC 2406, November 1998.

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section Element.
           The reported number excludes octets in RFCs", BCP 26, RFC 2434,
              October 1998.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC2463]  Conta, A. and S. Deering, "Internet Control the IPFIX Message
              Protocol (ICMPv6) for
           that carries the counter value.
         </paragraph>
       </description>
       <units>octets</units>
     </field>

     <field name="exportedFlowRecordTotalCount" dataType="unsigned64"
            group="processCounter"
            dataTypeSemantics="totalCounter"
            elementId="42" applicability="data" status="current">
       <description>
         <paragraph>
           The total number of Flows Records that the Exporting
           Process successfully sent as Data Records since the Exporting
           Process (re-)initialization to the Collecting Process
           receiving a report that contains this Information Element.
           The reported number excludes Flow Records in the IPFIX
           message that carries the counter value.
         </paragraph>
       </description>
       <units>flows</units>
     </field>

     <field name="observedFlowTotalCount" dataType="unsigned64"
            dataTypeSemantics="totalCounter"
            group="processCounter"
            elementId="163" applicability="data" status="current">
       <description>
         <paragraph>
         The total number of Flows observed in the Internet Protocol Version 6
              (IPv6) Specification", RFC 2463, December 1998.

   [RFC2547]  Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547,
              March 1999.

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

   [RFC2863]  McCloghrie, K. and F. Kastenholz, "The Interfaces Group
              MIB", RFC 2863, June 2000.

   [RFC2960]  Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
              Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
              Zhang, L., and V. Paxson, "Stream Control Transmission
              Protocol", RFC 2960, October 2000.

   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031, January 2001.

   [RFC3032]  Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
              Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
              Encoding", RFC 3032, January 2001. Observation Domain
         since the Metering Process (re-)initialization for this
         Observation Point.
         </paragraph>
       </description>
       <units>flows</units>
     </field>




Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 72] 90]

Internet-Draft           IPFIX Information Model          September 2005


   [RFC3036]  Andersson, L., Doolan, P., Feldman, N., Fredette, A., and
              B. Thomas, "LDP Specification", RFC 3036, January 2001.

   [RFC3234]  Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
              Issues", RFC 3234, February 2002.

   [RFC3260]  Grossman, D., "New Terminology and Clarifications for
              Diffserv", RFC 3260, April 2002.

   [RFC3667]  Bradner, S., "IETF Rights in Contributions", RFC 3667,
              February 2004.

   [RFC3668]  Bradner, S., "Intellectual Property Rights in IETF
              Technology", RFC 3668, February 2004.

   [RFC3917]  Quittek, J., Zseby, T., Claise, B., and S. Zander,
              "Requirements for IP Flow Information Export (IPFIX)",
              RFC 3917, October 2004.

   [RFC3954]  Claise, B., "Cisco Systems NetFlow Services Export Version
              9", RFC 3954, October 2004.


Appendix A.  Formal Specification               June 2006


     <field name="ignoredPacketTotalCount" dataType="unsigned64"
            dataTypeSemantics="totalCounter"
            group="processCounter"
            elementId="164" applicability="data" status="current">
       <description>
         <paragraph>
            The total number of IPFIX Information Element

   This appendix contains a formal description observed IP packets that the
            Metering Process did not process since the
            (re-)initialization of the IPFIX information
   model XML document.  Note Metering Process.
         </paragraph>
       </description>
       <units>packets</units>
     </field>

     <field name="ignoredOctetTotalCount" dataType="unsigned64"
            dataTypeSemantics="totalCounter"
            group="processCounter"
            elementId="165" applicability="data" status="current">
       <description>
         <paragraph>
            The total number of octets in observed IP packets
            (including the IP header) that this appendix is the Metering Process
            did not process since the (re-)initialization of informational
   nature, while the text in section 4
            Metering Process.
         </paragraph>
       </description>
       <units>octets</units>
     </field>

     <field name="notSentFlowTotalCount" dataType="unsigned64"
            dataTypeSemantics="totalCounter"
            group="processCounter"
            elementId="166" applicability="data" status="current">
       <description>
         <paragraph>
            The total number of Flow Records that were generated from this appendix is
   normative.

   Using a formal by the
            Metering Process and machine readable syntax for but dropped by the Information model
   enables Metering Process or
            by the creation Exporting Process
            instead of IPFIX aware tools which can automatically
   adapt to extensions sending it to the information model, by simply reading
   updated information model specifications.

   The wide availability of XML aware tools and libraries for client
   devices is a primary consideration for this choice.  In particular
   libraries for parsing XML documents Collecting Process.
            There are readily available.  Also
   mechanisms such as the Extensible Stylesheet Language (XSL) allow several potential reasons for
   transforming a source XML document into other documents.  This draft
   was authored in XML this including
            resource shortage and transformed according to RFC2629.

   It should be noted special Flow export policies.
         </paragraph>
       </description>
       <units>Flows</units>
     </field>

     <field name="notSentPacketTotalCount" dataType="unsigned64"
            dataTypeSemantics="totalCounter"



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 91]

Internet-Draft           IPFIX Information Model               June 2006


            group="processCounter"
            elementId="167" applicability="data" status="current">
       <description>
         <paragraph>
            The total number of packets in Flow Records that were
            generated by the use of XML in Exporters, Collectors Metering Process and but dropped
            by the Metering Process or
   other tools is not mandatory for by the deployment of IPFIX.  In
   particular Exporting Processes do not produce or consume XML as part
   of their operation.  It is expected that IPFIX Collectors MAY take
   advantage Process
            instead of sending it to the machine readability Collecting Process.
            There are several potential reasons for this including
            resource shortage and special Flow export policies.
         </paragraph>
       </description>
       <units>packets</units>
     </field>

     <field name="notSentOctetTotalCount" dataType="unsigned64"
            dataTypeSemantics="totalCounter"
            group="processCounter"
            elementId="168" applicability="data" status="current">
       <description>
         <paragraph>
            The total number of octets in packets in Flow Records
            that were generated by the Information Model vs.
   hard coding their behavior Metering Process and but
            dropped by the Metering Process or inventing proprietary means by the Exporting
            Process instead of sending it to the Collecting Process.
            There are several potential reasons for



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 73]

Internet-Draft           IPFIX Information Model          September 2005


   accommodating extensions.




   <fieldDefinitions> this including
            resource shortage and special Flow export policies.
         </paragraph>
       </description>
       <units>octets</units>
     </field>

     <field name="ipVersion" dataType="octet" dataType="unsigned8"
            group="IpHeader"
            dataTypeSemantics="identifier"
            fieldId="60"
            elementId="60" applicability="all" status="current">
       <description>
         <paragraph>
         The IP version field in the IP packet header.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 791 [RFC0791] for a definition of the version field
         in the IPv4 packet header.
         See RFC 2460 [RFC2460] for a definition of the version field
         in the IPv6 packet header.
         Additional information on defined version numbers



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 92]

Internet-Draft           IPFIX Information Model               June 2006


         can be found at
         http://www.iana.org/assignments/version-numbers.
         </paragraph>
       </reference>
     </field>

     <field name="sourceIPv4Address" dataType="ipv4Address"
            group="IpHeader"
            dataTypeSemantics="identifier"
            fieldId="8"
            elementId="8" applicability="all" status="current">
       <description>
         <paragraph>
         The IPv4 source address in the IP packet header.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 791 [RFC0791] for the definition of the IPv4 source
         address field.
         </paragraph>
       </reference>
     </field>

     <field name="sourceIPv6Address" dataType="ipv6Address"
            group="IpHeader"
            dataTypeSemantics="identifier"
            fieldId="27"
            elementId="27" applicability="all" status="current">
       <description>
         <paragraph>



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 74]

Internet-Draft           IPFIX Information Model          September 2005
         The IPv6 source address in the IP packet header.
         </paragraph>
       </description>
     </field>

     <field name="sourceIPv4Mask" dataType="octet" name="sourceIPv4PrefixLength" dataType="unsigned8"
            group="IpHeader"
            fieldId="9"
            elementId="9" applicability="option" status="current">
       <description>
         <paragraph>
         The number of contiguous bits that are relevant in the
         sourceIPv4Prefix Information Element.
         </paragraph>
       </description>
       <units>bits</units>
       <range>0-32</range>
     </field>

     <field name="sourceIPv6Mask" dataType="octet" name="sourceIPv6PrefixLength" dataType="unsigned8"



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 93]

Internet-Draft           IPFIX Information Model               June 2006


            group="IpHeader"
            fieldId="29"
            elementId="29" applicability="option" status="current">
       <description>
         <paragraph>
         The number of contiguous bits that are relevant in the
         sourceIPv6Prefix Information Element.
         </paragraph>
       </description>
       <units>bits</units>
       <range>0-128</range>
     </field>

     <field name="sourceIPv4Prefix" dataType="ipv4Address"
            group="IpHeader"
            fieldId="44"
            elementId="44" applicability="data" status="current">
       <description>
         <paragraph>
         IPv4 source address prefix.
         </paragraph>
       </description>
     </field>

     <field name="sourceIPv6Prefix" dataType="ipv6Address"
            group="IpHeader"
            fieldId="170"
            elementId="170" applicability="data" status="current">
       <description>
         <paragraph>
         IPv6 source address prefix.
         </paragraph>



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 75]

Internet-Draft           IPFIX Information Model          September 2005
       </description>
     </field>

     <field name="destinationIPv4Address" dataType="ipv4Address"
            group="IpHeader"
            dataTypeSemantics="identifier"
            fieldId="12"
            elementId="12" applicability="all" status="current">
       <description>
         <paragraph>
         The IPv4 destination address in the IP packet header.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 791 [RFC0791] for the definition of the IPv4
         destination address field.
         </paragraph>
       </reference>
     </field>



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 94]

Internet-Draft           IPFIX Information Model               June 2006


     <field name="destinationIPv6Address" dataType="ipv6Address"
            group="IpHeader"
            dataTypeSemantics="identifier"
            fieldId="28"
            elementId="28" applicability="all" status="current">
       <description>
         <paragraph>
         The IPv6 destination address in the IP packet header.
         </paragraph>
       </description>
     </field>

     <field name="destinationIPv4Mask" dataType="octet" name="destinationIPv4PrefixLength" dataType="unsigned8"
            group="IpHeader"
            fieldId="13"
            elementId="13" applicability="option" status="current">
       <description>
         <paragraph>
         The number of contiguous bits that are relevant in the
         destinationIPv4Prefix Information Element.
         </paragraph>
       </description>
       <units>bits</units>
       <range>0-32</range>
     </field>

     <field name="destinationIPv6Mask" dataType="octet" name="destinationIPv6PrefixLength" dataType="unsigned8"
            group="IpHeader"
            fieldId="30"
            elementId="30" applicability="option" status="current">
       <description>
         <paragraph>
         The number of contiguous bits that are relevant in the



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 76]

Internet-Draft           IPFIX Information Model          September 2005
         destinationIPv6Prefix Information Element.
         </paragraph>
       </description>
       <units>bits</units>
       <range>0-128</range>
     </field>

     <field name="destinationIPv4Prefix" dataType="ipv4Address"
            group="IpHeader"
            fieldId="45"
            elementId="45" applicability="data" status="current">
       <description>
         <paragraph> IPv4 destination address prefix. </paragraph>
       </description>
     </field>

     <field name="destinationIPv6Prefix" dataType="ipv6Address"
            group="IpHeader"
            fieldId="169"
            elementId="169" applicability="data" status="current">



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 95]

Internet-Draft           IPFIX Information Model               June 2006


       <description>
         <paragraph> IPv6 destination address prefix. </paragraph>
       </description>
     </field>

     <field name="ipTimeToLive" dataType="octet" name="ipTTL" dataType="unsigned8"
            group="IpHeader"
            fieldId="192"
            elementId="192" applicability="all" status="current">
       <description>
         <paragraph>
         For IPv4, the value of the Information Element matches
         the value of the Time to Live field in the IPv4 packet
         header.  For IPv6, the value of the Information Element
         matches the value of the Hop Limit field in the IPv6
         packet header.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 791 [RFC0791] for the definition of the IPv4
         Time to Live field.
         See RFC 2460 [RFC2460] for the definition of the IPv6
         Hop Limit field.
         </paragraph>
       </reference>
       <units>hops</units>
     </field>

     <field name="protocolIdentifier" dataType="octet" dataType="unsigned8"
            group="IpHeader"
            dataTypeSemantics="identifier"
            fieldId="4"
            elementId="4" applicability="all" status="current">



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 77]

Internet-Draft           IPFIX Information Model          September 2005
       <description>
         <paragraph>
         The value of the protocol number in the IP packet header.
         The protocol number identifies the IP packet payload type.
         Protocol numbers are defined in the IANA Protocol Numbers
         registry.</paragraph>

         <paragraph>
         In Internet Protocol version 4 (IPv4) this is carried in the
         "Protocol" field. In Internet Protocol version 6 (IPv6) this
         is carried in the "Next Header" field in the last extension
         header of the packet.</paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 791 [RFC0791] for the specification of the IPv4



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 96]

Internet-Draft           IPFIX Information Model               June 2006


         protocol field.
         See RFC 2460 [RFC2460] for the specification of the IPv6
         protocol field.
         See the list of protocol numbers assigned by IANA at
         http://www.iana.org/assignments/protocol-numbers.
         </paragraph>
       </reference>
     </field>

     <field name="nextHeaderIPv6" dataType="octet" dataType="unsigned8"
            group="IpHeader"
            fieldId="193"
            elementId="193" applicability="all" status="current">
       <description>
         <paragraph>
         The value of the Next Header field of the IPv6 header.
         The value identifies the type of the following IPv6
         extension header or of the following IP payload.
         Valid values are defined in the IANA
         Protocol Numbers registry.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 2460 [RFC2460] for the definition of the IPv6
         Next Header field.
         See the list of protocol numbers assigned by IANA at
         http://www.iana.org/assignments/protocol-numbers.
       </reference>
     </field>

     <field name="ipClassOfService" dataType="octet"
            group="IpHeader"
            dataTypeSemantics="identifier"
            fieldId="194" applicability="all" status="current">
       <description>
         <paragraph>



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 78]

Internet-Draft           IPFIX Information Model          September 2005


         For IPv4 packets, this is the value of the TOS field in
         the IPv4 packet header. For IPv6 packets, this is the
         value of the Traffic Class field in the IPv6 packet header.
         </paragraph>
       </description>
       <reference>
         See section 5.3.2 of RFC 1812 and RFC 791 for the
         definition of the IPv4 TOS field.
         See RFC 2460 for the definition of the IPv6 Traffic Class
         field.
       </reference>
     </field>

     <field name="ipDiffServCodePoint" dataType="octet" dataType="unsigned8"
            group="IpHeader"
            dataTypeSemantics="identifier"
            fieldId="195"
            elementId="195" applicability="all" status="current">
       <description>
         <paragraph>
         The value of a Differentiated Services Code Point (DSCP)
         encoded in the Differentiated Services Field. The
         Differentiated Services Field spans the most significant
         6 bits of the IPv4 TOS field or the IPv6 Traffic class
         field, respectively.
         </paragraph>
         <paragraph>
         This Information Element encodes only the 6 bits of the
         Differentiated Services field. Therefore its value may
         range from 0 to 63.
         </paragraph>



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 97]

Internet-Draft           IPFIX Information Model               June 2006


       </description>
       <range>0-63</range>
       <reference>
         <paragraph>
         See RFC 3260 [RFC3260] for the definition of the
         Differentiated Services Field.
         See section 5.3.2 of RFC 1812 [RFC1812] and RFC 791 [RFC0791]
         for the definition of the IPv4 TOS field.
         See RFC 2460 [RFC2460] for the definition of the IPv6
         Traffic Class field.
         </paragraph>
       </reference>
       <range>0-63</range>
     </field>

     <field name="ipPrecedence" dataType="octet" dataType="unsigned8"
            group="IpHeader"
            dataTypeSemantics="identifier"
            fieldId="196"
            elementId="196" applicability="all" status="current">
       <description>
         <paragraph>



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 79]

Internet-Draft           IPFIX Information Model          September 2005
         The value of the IP Precedence.  The IP Precedence value
         is encoded in the first 3 bits of the IPv4 TOS field
         or the IPv6 Traffic class field, respectively.
         </paragraph>
         <paragraph>
         This Information Element encodes only the 3 bits of the
         Differentiated Services field. Therefore its value may
         range from 0 to 7.
         </paragraph>
       </description>
       <range>0-7</range>
       <reference>
         <paragraph>
         See section 5.3.3 of RFC 1812 [RFC1812] and RFC 791 [RFC0791]
         for the definition of the IP Precedence.
         See section 5.3.2 of RFC 1812 and RFC 791 for the
         definition of the IPv4 TOS field.
         See RFC 2460 for the definition of the IPv6 Traffic Class
         field.
       </reference>
     </field>

     <field name="classOfServiceIPv4" dataType="octet"
            group="IpHeader"
            dataTypeSemantics="identifier"
            fieldId="5" applicability="all" status="current">
       <description>
         <paragraph>
         The value of the TOS field in the IPv4 packet header.
         </paragraph>
       </description>
       <reference>
         See RFC 791 for the definition of the IPv4 TOS field.
       </reference>
     </field>

     <field name="postClassOfServiceIPv4" dataType="octet"
            group="IpHeader"
            dataTypeSemantics="identifier"
            fieldId="55" applicability="all" status="current">
       <description>
         <paragraph>
         The definition of this Information Element is identical
         to the definition of Information Element
         'classOfServiceIPv4', except that it reports a
         potentially modified value caused by a middlebox
         function after the packet passed the observation point.
         </paragraph>
       </description>



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 80]

Internet-Draft           IPFIX Information Model          September 2005


       <reference> IP Precedence.
         See section 5.3.2 of RFC 1812 [RFC1812] and RFC 791 [RFC0791]
         for the definition of the IPv4 TOS field.
         See RFC 3234 2460 [RFC2460] for the definition of middleboxes. the IPv6
         Traffic Class field.
         </paragraph>
       </reference>
       <range>0-7</range>
     </field>

     <field name="classOfServiceIPv6" dataType="octet" name="ipClassOfService" dataType="unsigned8"
            group="IpHeader"
            dataTypeSemantics="identifier"
            fieldId="137" applicability="data"
            elementId="5" applicability="all" status="current">
       <description>



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 98]

Internet-Draft           IPFIX Information Model               June 2006


         <paragraph>
         The
         For IPv4 packets, this is the value of the TOS field in
         the IPv4 packet header. For IPv6 packets, this is the
         value of the Traffic Class field in the IPv6 packet header.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See section 5.3.2 of RFC 1812 [RFC1812] and RFC 791 [RFC0791]
         for the definition of the IPv4 TOS field.
         See RFC 2460 [RFC2460] for the definition of the IPv6
         Traffic Class field.
         </paragraph>
       </reference>
     </field>

     <field name="postClassOfServiceIPv6" dataType="octet" name="postIpClassOfService" dataType="unsigned8"
            group="IpHeader"
            dataTypeSemantics="identifier"
            fieldId="138" applicability="data"
            elementId="55" applicability="all" status="current">
       <description>
         <paragraph>
         The definition of this Information Element is identical
         to the definition of Information Element
         'classOfServiceIPv6',
         'ipClassOfService', except that it reports a
         potentially modified value caused by a middlebox
         function after the packet passed the observation point. Observation Point.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 791 [RFC0791] for the definition of the IPv4
         TOS field.
         See RFC 2460 [RFC2460] for the definition of the IPv6
         traffic class field.
         See RFC 3234 [RFC3234] for the definition of middleboxes.
         </paragraph>
       </reference>
     </field>

     <field name="flowLabelIPv6" dataType="unsigned32"
            group="IpHeader"
            dataTypeSemantics="identifier"
            fieldId="31"
            elementId="31" applicability="all" status="current">
       <description>
         <paragraph>
         The value of the IPv6 Flow Label field in the IP packet header.
         </paragraph>



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 81] 99]

Internet-Draft           IPFIX Information Model          September 2005


         </paragraph>               June 2006


       </description>
       <reference>
         <paragraph>
         See RFC 2460 [RFC2460] for a definition of the
         flow label field in the IPv6 packet header.
         </paragraph>
       </reference>
     </field>

     <field name="isMulticast" dataType="octet" dataType="unsigned8"
            group="IpHeader"
            dataTypeSemantics="flags"
            fieldId="206"
            elementId="206" applicability="data" status="current">
       <description>
         <paragraph>
           If the IP destination address is a reserved multicast
           address then the value of this Information Element is
           not equal to zero.  Otherwise, the value of all bits
           of the octet is zero.
         </paragraph>
         <paragraph>
           The first bit of this octet is set to 1 if the Version
           field of the IP header has the value 4 and if the
           Destination Address field contains a reserved multicast
           address in the range from 224.0.0.0 to 239.255.255.255.
           Otherwise, this bit is set to 0.
         </paragraph>
         <paragraph>
           The second and third bit of this octet are reserved for
           future use.
         </paragraph>
         <paragraph>
           The remaining bits of the octet are only set to values
           other than zero if th the IP Destination Address is a
           reserved IPv6 multicast address. Then the fourth bit
           of the octet is set to the value of the T flag in the
           IPv6 multicast address and the remaining four bits are
           set to the value of the scope field in the IPv6
           multicast address.
         </paragraph>
         <artwork>
             0      1      2      3      4      5      6      7
          +------+------+------+------+------+------+------+------+
          | MCv4 | RES. | RES. |  T   |   IPv6 multicast scope    |
          +------+------+------+------+------+------+------+------+

          Bit 0:    set to 1 if IPv4 multicast
          Bit 1-2:  reserved for future use



Quittek, et al.       draft-ietf-ipfix-info-11.txt            [Page 100]

Internet-Draft           IPFIX Information Model               June 2006


          Bit 4:    set to value of T-flag, if IPv6 multicast



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 82]

Internet-Draft           IPFIX Information Model          September 2005
          Bit 4-7:  set to value of multicast scope if IPv6 multicast
         </artwork>
       </description>
       <reference>
         <paragraph>
         See RFC 1112 [RFC1112] for the specification of reserved
         IPv4 multicast addresses.
         See RFC 3513 [RFC3513] for the specification of reserved
         IPv6 multicast addresses and the definition of the T-flag
         and the IPv6 multicast scope.
         </paragraph>
       </reference>
     </field>

     <field name="identificationIPv4" dataType="unsigned16" name="fragmentIdentification" dataType="unsigned32"
            group="IpHeader"
            dataTypeSemantics="identifier"
            fieldId="54"
            elementId="54" applicability="data" status="current">
       <description>
         <paragraph>
         The value of the IPv4 packet identification Identification field
         in the IP IPv4 packet header or the IPv6 Fragment header,
         respectively.  The value is 0 for IPv6 if there is
         no Fragment header.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 791 [RFC0791] for the definition of the IPv4 identification
         Identification field.
         See RFC 2460 [RFC2460] for the definition of the
         Identification field in the IPv6 Fragment header.
         </paragraph>
       </reference>
     </field>

     <field name="fragmentOffsetIPv4" name="fragmentOffset" dataType="unsigned16"
            group="IpHeader"
            dataTypeSemantics="identifier"
            fieldId="88"
            elementId="88" applicability="all" status="current">
       <description>
         <paragraph>
         The value of the IP fragment offset field in the
         IPv4 packet header or the IPv6 Fragment header,
         respectively.  The value is 0 for IPv6 if there is
         no Fragment header.
         </paragraph>



Quittek, et al.       draft-ietf-ipfix-info-11.txt            [Page 101]

Internet-Draft           IPFIX Information Model               June 2006


       </description>
       <reference>
         <paragraph>
         See RFC 791 [RFC0791] for the specification of the
         fragment offset field in the IP packet IPv4 header.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 791 2460 [RFC2460] for the specification of the IPv4
         fragment offset. offset in the IPv6 Fragment header.
         </paragraph>
       </reference>
     </field>

     <field name="fragmentFlagsIPv4" dataType="octet" name="fragmentFlags" dataType="unsigned8"
            group="IpHeader"
            dataTypeSemantics="flags"



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 83]

Internet-Draft           IPFIX Information Model          September 2005


            fieldId="197"
            elementId="197" applicability="all" status="current">
       <description>
         <paragraph>
         The value of the fragmentation bits
           Fragmentation properties indicated by flags in the IPv4
           packet header. header or the IPv6 Fragment header, respectively.
         </paragraph>
         <artwork>

         Bit 0:    reserved, must    (RS) Reserved.
                   The value of this bit MUST be zero. 0 until specified
                   otherwise.
         Bit 1:    (DF) 0 = May Fragment,  1 = Don't Fragment.
                   Corresponds to the value of the DF flag in the
                   IPv4 header.  Will always be 0 for IPv6 unless
                   a "don't fragment" feature is introduced to IPv6.
         Bit 2:    (MF) 0 = Last Fragment, 1 = More Fragments.
                   Corresponds to the MF flag in the IPv4 header
                   or to the M flag in the IPv6 Fragment header,
                   respectively.  The value is 0 for IPv6 if there
                   is no Fragment header.
         Bits 3-7: (DC) Don't Care, value is Care.
                   The values of these bits are irrelevant.

             0   1   2   3   4   5   6   7
           +---+---+---+---+---+---+---+---+
           | R | D | M | D | D | D | D | D |
           | 0 S | F | F | C | C | C | C | C |
           +---+---+---+---+---+---+---+---+
         </artwork>
       </description>
       <reference>
         <paragraph>
         See RFC 791 [RFC0791] for the specification of the IPv4
         fragment flags.



Quittek, et al.       draft-ietf-ipfix-info-11.txt            [Page 102]

Internet-Draft           IPFIX Information Model               June 2006


         See RFC 2460 [RFC2460] for the specification of the IPv6
         Fragment header.
         </paragraph>
       </reference>
     </field>

     <field name="ipHeaderLength" dataType="octet" dataType="unsigned8"
            group="IpHeader"
            fieldId="189"
            elementId="189" applicability="all" status="current">
       <description>
         <paragraph>
         The length of the IP header.  For IPv6, the value of this
         Information Element is 40.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 791 [RFC0791] for the specification of the
         IPv4 header.
         See RFC 2460 [RFC2460] for the specification of the
         IPv6 header.
         </paragraph>
       </reference>
       <units>octets</units>
     </field>

     <field name="headerLengthIPv4" dataType="octet"
            group="IpHeader"
            fieldId="213" applicability="all" status="current">
       <description>



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 84]

Internet-Draft           IPFIX Information Model          September 2005


         <paragraph>
         The length of the IPv4 header.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 791 for the specification of the IPv4 header.
         </paragraph>
       </reference>
       <units>octets</units>
     </field>

       <field name="internetHeaderLengthIPv4" dataType="octet" name="ipv4IHL" dataType="unsigned8"
            group="IpHeader"
            fieldId="207"
            elementId="207" applicability="all" status="current">
       <description>
         <paragraph>
         The value of the Internet Header Length (IHL) field in
         the IPv4 header. It specifies the length of the header
         in units of 4 octets.  Please note that its unit is
         different to most of the other Information Elements
         reporting length values.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 791 [RFC0791] for the specification of the
         IPv4 header.
         </paragraph>
       </reference>
       <units>4 octets</units>
     </field>

     <field name="totalLengthIPv4" dataType="unsigned16"



Quittek, et al.       draft-ietf-ipfix-info-11.txt            [Page 103]

Internet-Draft           IPFIX Information Model               June 2006


            group="IpHeader"
            fieldId="190"
            elementId="190" applicability="all" status="current">
       <description>
         <paragraph>
         The total length of the IPv4 packet.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 791 [RFC0791] for the specification of the
         IPv4 total length.
         </paragraph>
       </reference>
       <units>octets</units>
     </field>

     <field name="payloadLengthIPv6" dataType="unsigned32"
            group="IpHeader"



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 85]

Internet-Draft           IPFIX Information Model          September 2005


            fieldId="191"
            elementId="191" applicability="all" status="current">
       <description>
         <paragraph>
         The length of the IPv6 payload, i.e., the rest of the
         packet following the IPv6 header, in octets.  Note that any
         extension headers present are considered part
         of the payload, i.e., included in the length count.
         </paragraph>
         <paragraph>
         This Information Element reports the value of the Payload
         Length field in the IPv6 header except in the case that
         the value of this field is zero and that there is a valid
         jumbo payload option. Then the value of the Jumbo Payload
         Length field in the jumbo payload option is reported.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 2460 [RFC2460] for the specification of the
         IPv6 payload length.
         See RFC 2675 [RFC2675] for the specification of the
         IPv6 jumbo payload length.
         </paragraph>
       </reference>
     </field>

     <field name="ipPayloadLength" dataType="unsigned64"
            group="IpHeader"
            fieldId="204"
            elementId="204" applicability="all" status="current">
       <description>



Quittek, et al.       draft-ietf-ipfix-info-11.txt            [Page 104]

Internet-Draft           IPFIX Information Model               June 2006


         <paragraph>
         The effective length of the IP payload.
         </paragraph>
         <paragraph>
         For IPv4 packets the value of this Information Element is
         the difference between the total length of the IPv4 packet
         (as reported by Information Element totalLengthIPv4) and the
         length of the IPv4 header (as reported by Information Element
         headerLengthIPv4).
         </paragraph>
         <paragraph>
         For IPv6, the value of the Payload Length field
         in the IPv6 header is reported except in the case that
         the value of this field is zero and that there is a valid
         jumbo payload option. In this case the value of the
         Jumbo Payload Length field in the jumbo payload option
         is reported.
         </paragraph>
       </description>



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 86]

Internet-Draft           IPFIX Information Model          September 2005
       <reference>
         <paragraph>
         See RFC 791 [RFC0791] for the specification of
         IPv4 packets.
         See RFC 2460 [RFC2460] for the specification of the
         IPv6 payload length.
         See RFC 2675 [RFC2675] for the specification of the
         IPv6 jumbo payload length.
         </paragraph>
       </reference>
     </field>

     <field name="sourceTransportPort" dataType="unsigned16"
            group="transportHeader"
            dataTypeSemantics="identifier"
            fieldId="7"
            elementId="7" applicability="all" status="current">
       <description>
         <paragraph>
         The source port identifier in the transport header.
         For the transport
         protocols UDP, TCP and SCTP this is the source port number
         given in the respective header.  This field MAY also be used
         for future transport protocols that have 16 bit source port
         identifiers.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 768 [RFC0768] for the definition of the UDP



Quittek, et al.       draft-ietf-ipfix-info-11.txt            [Page 105]

Internet-Draft           IPFIX Information Model               June 2006


         source port field.
         See RFC 793 [RFC0793] for the definition of the TCP
         source port field.
         See RFC 2960 [RFC2960] for the definition of SCTP.</paragraph> SCTP.
         </paragraph>
         <paragraph>
         Additional information on defined UDP and TCP port numbers can
         be found at http://www.iana.org/assignments/port-numbers.
         </paragraph>
       </reference>
     </field>

     <field name="destinationTransportPort" dataType="unsigned16"
            group="transportHeader"
            dataTypeSemantics="identifier"
            fieldId="11"
            elementId="11" applicability="all" status="current">
       <description>
         <paragraph>
         The destination port identifier in the transport header.
         For the transport protocols UDP, TCP and SCTP this is the
         destination port number given in the respective header.
         This field MAY also be used for future transport protocols
         that have 16 bit destination port identifiers.
         </paragraph>



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 87]

Internet-Draft           IPFIX Information Model          September 2005
       </description>
       <reference>
         <paragraph>
         See RFC 768 [RFC0768] for the definition of the UDP source
         destination port field.
         See RFC 793 [RFC0793] for the definition of the TCP source
         destination port field.
         See RFC 2960 [RFC2960] for the definition of SCTP.
         </paragraph>
         <paragraph>
         Additional information on defined UDP and TCP port numbers can
         be found at http://www.iana.org/assignments/port-numbers.
         </paragraph>
       </reference>
     </field>

     <field name="udpSourcePort" dataType="unsigned16"
            group="transportHeader"
            dataTypeSemantics="identifier"
            fieldId="180"
            elementId="180" applicability="all" status="current">
       <description>
         <paragraph>
         The source port identifier in the UDP header.
         </paragraph>



Quittek, et al.       draft-ietf-ipfix-info-11.txt            [Page 106]

Internet-Draft           IPFIX Information Model               June 2006


       </description>
       <reference>
         <paragraph>
         See RFC 768 [RFC0768] for the definition of the
         UDP source port field.
         Additional information on defined UDP port numbers can
         be found at http://www.iana.org/assignments/port-numbers.
         </paragraph>
       </reference>
     </field>

     <field name="udpDestinationPort" dataType="unsigned16"
            group="transportHeader"
            dataTypeSemantics="identifier"
            fieldId="181"
            elementId="181" applicability="all" status="current">
       <description>
         <paragraph>
         The destination port identifier in the UDP header.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 768 [RFC0768] for the definition of the
         UDP source destination port field.
         Additional information on defined UDP port numbers can
         be found at http://www.iana.org/assignments/port-numbers.
         </paragraph>
       </reference>
     </field>

     <field name="udpMessageLength" dataType="unsigned16"
            group="transportHeader"
            fieldId="205"
            elementId="205" applicability="all" status="current">
       <description>
         <paragraph>
         The value of the Length field in the UDP header.
         </paragraph>
       </description>



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 88]

Internet-Draft           IPFIX Information Model          September 2005
       <reference>
         <paragraph>
         See RFC 768 [RFC0768] for the specification of the
         UDP header.
         </paragraph>
       </reference>
       <units>octets</units>
     </field>

     <field name="tcpSourcePort" dataType="unsigned16"



Quittek, et al.       draft-ietf-ipfix-info-11.txt            [Page 107]

Internet-Draft           IPFIX Information Model               June 2006


            group="transportHeader"
            dataTypeSemantics="identifier"
            fieldId="182"
            elementId="182" applicability="all" status="current">
       <description>
         <paragraph>
         The source port identifier in the TCP header.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 793 [RFC0793] for the definition of the TCP
         source port field.
         Additional information on defined TCP port numbers can
         be found at http://www.iana.org/assignments/port-numbers.
         </paragraph>
       </reference>
     </field>

     <field name="tcpDestinationPort" dataType="unsigned16"
            group="transportHeader"
            dataTypeSemantics="identifier"
            fieldId="183"
            elementId="183" applicability="all" status="current">
       <description>
         <paragraph>
         The destination port identifier in the TCP header.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 793 [RFC0793] for the definition of the TCP
         source port field.
         Additional information on defined TCP port numbers can
         be found at http://www.iana.org/assignments/port-numbers.
         </paragraph>
       </reference>
     </field>

     <field name="tcpSequenceNumber" dataType="unsigned32"
            group="transportHeader"
            fieldId="184"
            elementId="184" applicability="all" status="current">
       <description>
         <paragraph>
         The sequence number in the TCP header.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 793 [RFC0793] for the definition of the TCP



Quittek, et al.       draft-ietf-ipfix-info-11.txt            [Page 108]

Internet-Draft           IPFIX Information Model               June 2006


         sequence number.
         </paragraph>
       </reference>
     </field>

     <field name="tcpAcknowledgementNumber" dataType="unsigned32"
            group="transportHeader"
            fieldId="185"
            elementId="185" applicability="all" status="current">



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 89]

Internet-Draft           IPFIX Information Model          September 2005
       <description>
         <paragraph>
         The acknowledgement number in the TCP header.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 793 [RFC0793] for the definition of the TCP
         acknowledgement number.
         </paragraph>
       </reference>
     </field>

     <field name="tcpWindowSize" dataType="unsigned16"
            group="transportHeader"
            fieldId="186"
            elementId="186" applicability="all" status="current">
       <description>
         <paragraph>
         The window field in the TCP header.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 793 [RFC0793] for the definition of the TCP
         window field.
         </paragraph>
       </reference>
     </field>

     <field name="tcpUrgentPointer" dataType="unsigned16"
            group="transportHeader"
            fieldId="187"
            elementId="187" applicability="all" status="current">
       <description>
         <paragraph>
         The urgent pointer in the TCP header.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 793 [RFC0793] for the definition of the TCP



Quittek, et al.       draft-ietf-ipfix-info-11.txt            [Page 109]

Internet-Draft           IPFIX Information Model               June 2006


         urgent pointer.
         </paragraph>
       </reference>
     </field>

     <field name="tcpHeaderLength" dataType="unsigned16"
            group="transportHeader"
            fieldId="188"
            elementId="188" applicability="all" status="current">
       <description>
         <paragraph>
         The length of the TCP header.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 793 [RFC0793] for the definition of the
         TCP header.
         </paragraph>
       </reference>
       <units>octets</units>
     </field>

     <field name="icmpTypeCodeIPv4" dataType="unsigned16"
            group="transportHeader"
            dataTypeSemantics="identifier"
            fieldId="32"
            elementId="32" applicability="all" status="current">
       <description>



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 90]

Internet-Draft           IPFIX Information Model          September 2005
         <paragraph>
         Type and Code of the IPv4 ICMP message. The combination of
         both values is reported as (ICMP type * 256) + ICMP code.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 792 [RFC0792] for a definition of the IPv4 ICMP
         type and code
         fields.
         </paragraph>
       </reference>
     </field>

     <field name="icmpTypeIPv4" dataType="octet" dataType="unsigned8"
            group="transportHeader"
            dataTypeSemantics="identifier"
            fieldId="176"
            elementId="176" applicability="all" status="current">
       <description>
         <paragraph>
         Type of the IPv4 ICMP message.



Quittek, et al.       draft-ietf-ipfix-info-11.txt            [Page 110]

Internet-Draft           IPFIX Information Model               June 2006


         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 792 [RFC0792] for a definition of the IPv4 ICMP
         type field.
         </paragraph>
       </reference>
     </field>

     <field name="icmpCodeIPv4" dataType="octet" dataType="unsigned8"
            group="transportHeader"
            dataTypeSemantics="identifier"
            fieldId="177"
            elementId="177" applicability="all" status="current">
       <description>
         <paragraph>
         Code of the IPv4 ICMP message.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 792 [RFC0792] for a definition of the IPv4
         ICMP code field.
         </paragraph>
       </reference>
     </field>

     <field name="icmpTypeCodeIPv6" dataType="unsigned16"
            group="transportHeader"
            dataTypeSemantics="identifier"
            fieldId="139"
            elementId="139" applicability="all" status="current">
       <description>
         <paragraph>
         Type and Code of the IPv6 ICMP message. The combination of
         both values is reported as (ICMP type * 256) + ICMP code.
         </paragraph>



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 91]

Internet-Draft           IPFIX Information Model          September 2005
       </description>
       <reference>
         <paragraph>
         See RFC 2463 [RFC2463] for a definition of the IPv6
         ICMP type and code fields.
         </paragraph>
       </reference>
     </field>

     <field name="icmpTypeIPv6" dataType="octet" dataType="unsigned8"
            group="transportHeader"
            dataTypeSemantics="identifier"
            fieldId="178"



Quittek, et al.       draft-ietf-ipfix-info-11.txt            [Page 111]

Internet-Draft           IPFIX Information Model               June 2006


            elementId="178" applicability="all" status="current">
       <description>
         <paragraph>
         Type of the IPv6 ICMP message.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 2463 [RFC2463] for a definition of the IPv6
         ICMP type field.
         </paragraph>
       </reference>
     </field>

     <field name="icmpCodeIPv6" dataType="octet" dataType="unsigned8"
            group="transportHeader"
            dataTypeSemantics="identifier"
            fieldId="179"
            elementId="179" applicability="all" status="current">
       <description>
         <paragraph>
         Code of the IPv6 ICMP message.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 2463 [RFC2463] for a definition of the IPv6
         ICMP code field.
         </paragraph>
       </reference>
     </field>

     <field name="igmpType" dataType="octet" dataType="unsigned8"
            group="transportHeader"
            dataTypeSemantics="identifier"
            fieldId="33"
            elementId="33" applicability="all" status="current">
       <description>
         <paragraph>
         The type field of the IGMP message.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 2236 [RFC2236] for a definition of the IGMP
         type field.
         </paragraph>
       </reference>
     </field>

     <field name="sourceMacAddress" dataType="macAddress"




Quittek, et al.       draft-ietf-ipfix-info-11.txt            [Page 92] 112]

Internet-Draft           IPFIX Information Model          September 2005               June 2006


     <field name="sourceMacAddress" dataType="macAddress"
            group="subIpHeader"
            dataTypeSemantics="identifier"
            fieldId="56"
            elementId="56" applicability="data" status="current">
       <description>
         <paragraph>
           The IEEE 802 source MAC address field.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See IEEE.802-3.2002. IEEE.802-3.2002 [IEEE.802-3.2002].
         </paragraph>
       </reference>
     </field>

     <field name="postSourceMacAddress" dataType="macAddress"
            group="subIpHeader"
            dataTypeSemantics="identifier"
            fieldId="81"
            elementId="81" applicability="data" status="current">
       <description>
         <paragraph>
         The definition of this Information Element is identical
         to the definition of Information Element
         'sourceMacAddress', except that it reports a
         potentially modified value caused by a middlebox
         function after the packet passed the observation point. Observation Point.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See IEEE.802-3.2002. IEEE.802-3.2002 [IEEE.802-3.2002].
         </paragraph>
       </reference>
     </field>

     <field name="vlanId" dataType="unsigned16"
            group="subIpHeader"
            dataTypeSemantics="identifier"
            fieldId="58"
            elementId="58" applicability="data" status="current">
       <description>
         <paragraph>
           The IEEE 802.1Q VLAN identifier (VID) extracted from the Tag
           Control Information field that was attached to the IP packet.
         </paragraph>
       </description>
       <reference>
         See IEEE.802-1Q.2003.
       </reference>
     </field>

     <field name="postVlanId" dataType="unsigned16"
            group="subIpHeader"
         <paragraph>



Quittek, et al.       draft-ietf-ipfix-info-11.txt            [Page 93] 113]

Internet-Draft           IPFIX Information Model          September 2005               June 2006


         See IEEE.802-1Q.2003 [IEEE.802-1Q.2003].
         </paragraph>
       </reference>
     </field>

     <field name="postVlanId" dataType="unsigned16"
            group="subIpHeader"
            dataTypeSemantics="identifier"
            fieldId="59"
            elementId="59" applicability="data" status="current">
       <description>
         <paragraph>
         The definition of this Information Element is identical
         to the definition of Information Element
         'vlanId', except that it reports a
         potentially modified value caused by a middlebox
         function after the packet passed the observation point. Observation Point.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See IEEE.802-1Q.2003. IEEE.802-1Q.2003 [IEEE.802-1Q.2003].
         </paragraph>
       </reference>
     </field>

     <field name="destinationMacAddress" dataType="macAddress"
            group="subIpHeader"
            dataTypeSemantics="identifier"
            fieldId="80"
            elementId="80" applicability="data" status="current">
       <description>
         <paragraph>
           The IEEE 802 destination MAC address field.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See IEEE.802-3.2002. IEEE.802-3.2002 [IEEE.802-3.2002].
         </paragraph>
       </reference>
     </field>

     <field name="postDestinationMacAddr" dataType="macAddress"
            group="subIpHeader"
            dataTypeSemantics="identifier"
            fieldId="57"
            elementId="57" applicability="data" status="current">
       <description>
         <paragraph>
         The definition of this Information Element is identical



Quittek, et al.       draft-ietf-ipfix-info-11.txt            [Page 114]

Internet-Draft           IPFIX Information Model               June 2006


         to the definition of Information Element
         'destinationMacAddress', except that it reports a
         potentially modified value caused by a middlebox
         function after the packet passed the observation point. Observation Point.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See IEEE.802-3.2002. IEEE.802-3.2002 [IEEE.802-3.2002].
         </paragraph>
       </reference>
     </field>




Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 94]

Internet-Draft           IPFIX Information Model          September 2005

     <field name="wlanChannelId" dataType="octet" dataType="unsigned8"
            group="subIpHeader"
            dataTypeSemantics="identifier"
            fieldId="146"
            elementId="146" applicability="data" status="current">
       <description>
         <paragraph>
           The identifier of the 802.11 (Wi-Fi) channel used.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See IEEE.802-11.1999. IEEE.802-11.1999 [IEEE.802-11.1999].
         </paragraph>
       </reference>
     </field>

     <field name="wlanSsid" name="wlanSSID" dataType="string"
            group="subIpHeader"
            fieldId="147"
            elementId="147" applicability="data" status="current">
       <description>
         <paragraph>
           The Service Set IDentifier (SSID) identifying an 802.11
           (Wi-Fi) network used.  According to IEEE.802-11.1999 the
           SSID is encoded into a string of up to 32 characters.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See IEEE.802-11.1999. IEEE.802-11.1999 [IEEE.802-11.1999].
         </paragraph>
       </reference>
     </field>

     <field name="mplsTopLabelTtl" name="mplsTopLabelTTL" dataType="unsigned32"
            group="subIpHeader"
            fieldId="200" applicability="all" status="current">
       <description>
         The TTL field from the top MPLS label stack entry,
         i.e. the last label that was pushed.
       </description>
       <reference>
         See RFC 3032 for the specification of the TTL field.
       </reference>
     </field>

     <field name="mplsTopLabelExp" dataType="octet"
            group="subIpHeader"
            dataTypeSemantics="flags"
            fieldId="203" applicability="all" status="current">
       <description>
         <paragraph>
         The Exp field from the top MPLS label stack entry,



Quittek, et al.       draft-ietf-ipfix-info-11.txt            [Page 95] 115]

Internet-Draft           IPFIX Information Model          September 2005


         i.e. the last label that was pushed.
         </paragraph>
         <artwork>
         Bit 0-4:  Don't Care, value is irrelevant.
         Bit 5-7:  MPLS Exp field

             0   1   2   3   4   5   6   7
           +---+---+---+---+---+---+---+---+
           |     don't care    |    Exp    |
           +---+---+---+---+---+---+---+---+
         </artwork>
       </description>
       <reference>
         See RFC 3032 for the specification of the Exp field.
         See RFC 3270 for usage of the Exp field.
       </reference>
     </field>

     <field name="mplsLabelStackDepth" dataType="unsigned32"
            group="subIpHeader"
            fieldId="202" applicability="all" status="current">
       <description>
         The number of labels in the MPLS label stack.
       </description>
       <reference>
         See RFC 3032 for the specification of the MPLS label
         stack.
       </reference>
       <units>label stack entries</units>
     </field>

     <field name="mplsLabelStackLength" dataType="unsigned32"
            group="subIpHeader"
            fieldId="201" applicability="all" status="current">
       <description>
         The length of the MPLS label stack in units of octets.
       </description>
       <reference>
         See RFC 3032 for the specification of the MPLS label
         stack.
       </reference>
       <units>octets</units>
     </field>

     <field name="mplsPayloadLength" dataType="unsigned32"
            group="subIpHeader"
            fieldId="214"               June 2006


            elementId="200" applicability="all" status="current">
       <description>



Quittek, et al.       draft-ietf-ipfix-info-11.txt             [Page 96]

Internet-Draft           IPFIX Information Model          September 2005
         <paragraph>
         The size of TTL field from the MPLS packet without top MPLS label stack entry,
         i.e. the last label stack. that was pushed.
         </paragraph>
       </description>
       <reference>
         See RFC 3031 for the specification of MPLS packets.
         <paragraph>
         See RFC 3032 [RFC3032] for the specification of the MPLS label
         stack.
         TTL field.
         </paragraph>
       </reference>
       <units>octets</units>
     </field>

     <field name="mplsTopLabelStackEntry" dataType="unsigned32" name="mplsTopLabelExp" dataType="unsigned8"
            group="subIpHeader"
            dataTypeSemantics="identifier"
            fieldId="70"
            dataTypeSemantics="flags"
            elementId="203" applicability="all" status="current">
       <description>
         <paragraph>
         The label, exp and s fields Exp field from the top MPLS label stack entry,
         i.e. the last label that was pushed.
         </paragraph>
         <artwork>
       0                   1                   2
       0 1 2 3 4 5 6 7 8 9
         Bit 0-4:  Don't Care, value is irrelevant.
         Bit 5-7:  MPLS Exp field

             0   1   2   3   4   5   6   7 8 9 0 1 2 3
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           +---+---+---+---+---+---+---+---+
           |                Label     don't care    |    Exp |S|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Label:  Label Value, 20 bits
      Exp:    Experimental Use, 3 bits
      S:      Bottom of Stack, 1 bit    |
           +---+---+---+---+---+---+---+---+
         </artwork>
       </description>
       <reference>
         <paragraph>
         See RFC 3032 [RFC3032] for the specification of
         the Exp field.
         See RFC 3032. 3270 [RFC3270] for usage of the Exp field.
         </paragraph>
       </reference>
     </field>

     <field name="mplsLabelStackEntry2" name="mplsLabelStackDepth" dataType="unsigned32"
            group="subIpHeader"
            dataTypeSemantics="identifier"
            fieldId="71"
            elementId="202" applicability="all" status="current">
       <description>
         <paragraph>
         The label, exp, and s fields from the label stack entry that
         was pushed immediately before the label stack entry that would
         be reported by mplsTopLabelStackEntry. See the definition of
         mplsTopLabelStackEntry for further details.
         </paragraph>
       </description>



Quittek, et al.       draft-ietf-ipfix-info-11.txt            [Page 97] 116]

Internet-Draft           IPFIX Information Model          September 2005


       <reference>
         See RFC 3032.
       </reference>
     </field>

     <field name="mplsLabelStackEntry3" dataType="unsigned32"
            group="subIpHeader"
            dataTypeSemantics="identifier"
            fieldId="72" applicability="all" status="current">
       <description>
         <paragraph>               June 2006


         The label, exp, and s fields from the label stack entry that
         was pushed immediately before number of labels in the MPLS label stack entry that would
         be reported by mplsLabelStackEntry2. See the definition of
         mplsTopLabelStackEntry for further details. stack.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 3032. 3032 [RFC3032] for the specification of
         the MPLS label stack.
         </paragraph>
       </reference>
       <units>label stack entries</units>
     </field>

     <field name="mplsLabelStackEntry4" name="mplsLabelStackLength" dataType="unsigned32"
            group="subIpHeader"
            dataTypeSemantics="identifier"
            fieldId="73"
            elementId="201" applicability="all" status="current">
       <description>
         <paragraph>
         The label, exp, and s fields from the label stack entry that
         was pushed immediately before the label stack entry that would
         be reported by mplsLabelStackEntry3. See length of the definition MPLS label stack in units of
         mplsTopLabelStackEntry for further details. octets.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 3032. 3032 [RFC3032] for the specification of
         the MPLS label stack.
         </paragraph>
       </reference>
       <units>octets</units>
     </field>

     <field name="mplsLabelStackEntry5" name="mplsPayloadLength" dataType="unsigned32"
            group="subIpHeader"
            dataTypeSemantics="identifier"
            fieldId="74"
            elementId="194" applicability="all" status="current">
       <description>
         <paragraph>
         The label, exp, and s fields from size of the label stack entry that
         was pushed immediately before MPLS packet without the label stack entry that would
         be reported by mplsLabelStackEntry4. stack.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 3031 [RFC3031] for the specification of
         MPLS packets.
         See RFC 3032 [RFC3032] for the definition specification of
         the MPLS label stack.
         </paragraph>
       </reference>
       <units>octets</units>
     </field>




Quittek, et al.       draft-ietf-ipfix-info-11.txt            [Page 98] 117]

Internet-Draft           IPFIX Information Model          September 2005


         mplsTopLabelStackEntry for further details.
         </paragraph>
       </description>
       <reference>
         See RFC 3032.
       </reference>
     </field>               June 2006


     <field name="mplsLabelStackEntry6" name="mplsTopLabelStackEntry" dataType="unsigned32"
            group="subIpHeader"
            dataTypeSemantics="identifier"
            fieldId="75"
            elementId="70" applicability="all" status="current">
       <description>
         <paragraph>
         The label, exp, exp and s fields from the top MPLS label
         stack entry that
         was pushed immediately before entry, i.e. the last label stack entry that would
         be reported by mplsLabelStackEntry5. See the definition of
         mplsTopLabelStackEntry for further details. was pushed.
         </paragraph>
         <artwork>
       0                   1                   2
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Label                  | Exp |S|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Label:  Label Value, 20 bits
      Exp:    Experimental Use, 3 bits
      S:      Bottom of Stack, 1 bit
         </artwork>
       </description>
       <reference>
         <paragraph>
         See RFC 3032. 3032 [RFC3032].
         </paragraph>
       </reference>
     </field>

     <field name="mplsLabelStackEntry7" name="mplsLabelStackEntry2" dataType="unsigned32"
            group="subIpHeader"
            dataTypeSemantics="identifier"
            fieldId="76"
            elementId="71" applicability="all" status="current">
       <description>
         <paragraph>
         The label, exp, and s fields from the label stack entry that
         was pushed immediately before the label stack entry that would
         be reported by mplsLabelStackEntry6. mplsTopLabelStackEntry. See the definition of
         mplsTopLabelStackEntry for further details.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 3032. 3032 [RFC3032].
         </paragraph>
       </reference>
     </field>

     <field name="mplsLabelStackEntry8" name="mplsLabelStackEntry3" dataType="unsigned32"
            group="subIpHeader"
            dataTypeSemantics="identifier"
            fieldId="77" applicability="all" status="current">
       <description>
         <paragraph>



Quittek, et al.       draft-ietf-ipfix-info-11.txt            [Page 99] 118]

Internet-Draft           IPFIX Information Model          September 2005


         The label, exp, and s fields from the label stack entry that
         was pushed immediately before the label stack entry that would
         be reported by mplsLabelStackEntry7. See the definition of
         mplsTopLabelStackEntry for further details.
         </paragraph>
       </description>
       <reference>
         See RFC 3032.
       </reference>
     </field>

     <field name="mplsLabelStackEntry9" dataType="unsigned32"               June 2006


            group="subIpHeader"
            dataTypeSemantics="identifier"
            fieldId="78"
            elementId="72" applicability="all" status="current">
       <description>
         <paragraph>
         The label, exp, and s fields from the label stack entry that
         was pushed immediately before the label stack entry that would
         be reported by mplsLabelStackEntry8. mplsLabelStackEntry2. See the definition of
         mplsTopLabelStackEntry for further details.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 3032. 3032 [RFC3032].
         </paragraph>
       </reference>
     </field>

     <field name="mplsLabelStackEntry10" name="mplsLabelStackEntry4" dataType="unsigned32"
            group="subIpHeader"
            dataTypeSemantics="identifier"
            fieldId="79"
            elementId="73" applicability="all" status="current">
       <description>
         <paragraph>
         The label, exp, and s fields from the label stack entry that
         was pushed immediately before the label stack entry that would
         be reported by mplsLabelStackEntry9. mplsLabelStackEntry3. See the definition of
         mplsTopLabelStackEntry for further details.
         </paragraph>
       </description>
       <reference>
         See RFC 3032.
       </reference>
     </field>

     <field name="ipNextHopIPv4Address" dataType="ipv4Address"
            group="derived"
            dataTypeSemantics="identifier"



Quittek, et al.       draft-ietf-ipfix-info-11.txt            [Page 100]

Internet-Draft           IPFIX Information Model          September 2005


            fieldId="15" applicability="data" status="current">
       <description>
         <paragraph>
         The IPv4 address of the next IPv4 hop.
         </paragraph>
       </description>
     </field>

     <field name="ipNextHopIPv6Address" dataType="ipv6Address"
            group="derived"
            dataTypeSemantics="identifier"
            fieldId="62" applicability="data" status="current">
       <description>
         <paragraph>
         The IPv6 address of the next IPv6 hop.
         </paragraph>
       </description>
     </field>

   <!--
     <field name="ipNextHopAsNumber" dataType="unsigned16"
            group="derived"
            dataTypeSemantics="identifier"
            fieldId="162" applicability="all" status="current">
       <description>
         <paragraph>
         The autonomous system (AS) number of the next IP hop.
         </paragraph>
       </description>
       <reference>
         See RFC 1771 for a description of BGP-4 and
         see RFC 1930 for a definition of the AS number.
       </reference>
     </field>
   -->

     <field name="bgpSourceAsNumber" dataType="unsigned16"
            group="derived"
            dataTypeSemantics="identifier"
            fieldId="16" applicability="all" status="current">
       <description>
         <paragraph>
         The autonomous system (AS) number of the source IP address.
         If AS path information for this Flow is only available as
         unordered AS set (and not as ordered AS sequence),
         then the value of this Information Element is 0.
         </paragraph>
       </description>



Quittek, et al.       draft-ietf-ipfix-info-11.txt            [Page 101]

Internet-Draft           IPFIX Information Model          September 2005


       <reference>
         See RFC 1771 for a description of BGP-4 and
         see RFC 1930 for a definition of the AS number.
       </reference>
     </field>

     <field name="bgpDestinationAsNumber" dataType="unsigned16"
            group="derived"
            dataTypeSemantics="identifier"
            fieldId="17" applicability="all" status="current">
       <description>
         <paragraph>
         The autonomous system (AS) number of the destination IP
         address.  If AS path information for this Flow is only
         available as unordered AS set (and not as ordered AS
         sequence), then the value of this Information Element is 0.
         </paragraph>
       </description>
       <reference>
         See RFC 1771 for a description of BGP-4 and
         see RFC 1930 for a definition of the AS number. 3032 [RFC3032].
         </paragraph>
       </reference>
     </field>

     <field name="bgpNextAdjacentAsNumber" dataType="unsigned16"
            group="derived" name="mplsLabelStackEntry5" dataType="unsigned32"
            group="subIpHeader"
            dataTypeSemantics="identifier"
            fieldId="128"
            elementId="74" applicability="all" status="current">
       <description>
         <paragraph>
         The autonomous system (AS) number of the first AS in label, exp, and s fields from the AS
         path to label stack entry that
         was pushed immediately before the destination IP address.  The path is deduced label stack entry that would
         be reported by looking up mplsLabelStackEntry4. See the destination IP address definition of the Flow in the
         BGP routing information base.  If AS path information
         mplsTopLabelStackEntry for
         this Flow is only available as unordered AS set (and not as
         ordered AS sequence),
         then the value of this Information Element is 0. further details.
         </paragraph>
       </description>
       <reference>
         See RFC 1771 for a description of BGP-4 and
         see RFC 1930 for a definition of the AS number.
       </reference>
     </field>

     <field name="bgpPrevAdjacentAsNumber" dataType="unsigned16"
            group="derived"
            dataTypeSemantics="identifier"



Quittek, et al.       draft-ietf-ipfix-info-11.txt            [Page 102] 119]

Internet-Draft           IPFIX Information Model          September 2005


            fieldId="129"               June 2006


       </description>
       <reference>
         <paragraph>
         See RFC 3032 [RFC3032].
         </paragraph>
       </reference>
     </field>

     <field name="mplsLabelStackEntry6" dataType="unsigned32"
            group="subIpHeader"
            dataTypeSemantics="identifier"
            elementId="75" applicability="all" status="current">
       <description>
         <paragraph>
         The autonomous system (AS) number of the last AS in the AS
         path label, exp, and s fields from the source IP address.  The path is deduced
         by looking up the source IP address of the Flow in the BGP
         routing information base.  If AS path information for this
         Flow is only available as unordered AS set (and not as
         ordered AS sequence), then the value of this Information
         Element is 0.  In case of BGP asymmetry, label stack entry that
         was pushed immediately before the
         bgpPrevAdjacentAsNumber might not label stack entry that would
         be
         able to report the correct value.
         </paragraph>
       </description>
       <reference>
         See RFC 1771 for a description of BGP-4 and
         see RFC 1930 for a definition of reported by mplsLabelStackEntry5. See the AS number.
       </reference>
     </field>

     <field name="bgpNextHopIPv4Address" dataType="ipv4Address"
            group="derived"
            dataTypeSemantics="identifier"
            fieldId="18" applicability="all" status="current">
       <description>
         <paragraph>
         The IPv4 address definition of the next (adjacent) BGP hop.
         mplsTopLabelStackEntry for further details.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 1771 for a description of BGP-4 and 3032 [RFC3032].
         </paragraph>
       </reference>
     </field>

     <field name="bgpNextHopIPv6Address" dataType="ipv6Address"
            group="derived" name="mplsLabelStackEntry7" dataType="unsigned32"
            group="subIpHeader"
            dataTypeSemantics="identifier"
            fieldId="63"
            elementId="76" applicability="all" status="current">
       <description>
         <paragraph>
         The IPv6 address of label, exp, and s fields from the next (adjacent) BGP hop. label stack entry that
         was pushed immediately before the label stack entry that would
         be reported by mplsLabelStackEntry6. See the definition of
         mplsTopLabelStackEntry for further details.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 1771 for a description of BGP-4. 3032 [RFC3032].
         </paragraph>
       </reference>
     </field>

     <field name="mplsLabelStackEntry8" dataType="unsigned32"
            group="subIpHeader"



Quittek, et al.       draft-ietf-ipfix-info-11.txt            [Page 103] 120]

Internet-Draft           IPFIX Information Model          September 2005


     <field name="mplsTopLabelType" dataType="octet"
            group="derived"               June 2006


            dataTypeSemantics="identifier"
            fieldId="46" applicability="data"
            elementId="77" applicability="all" status="current">
       <description>
         <paragraph>
         This field identifies
         The label, exp, and s fields from the control protocol label stack entry that allocated
         was pushed immediately before the
         top of label stack label.  Defined values entry that would
         be reported by mplsLabelStackEntry7. See the definition of
         mplsTopLabelStackEntry for this field include:
         <artwork>
        - 0x01 TE-MIDPT: Any TE tunnel mid-point or tail label
        - 0x02 Pseudowire: Any PWE3 or Cisco AToM based label
        - 0x03 VPN: Any label associated with VPN
        - 0x04 BGP: Any label associated with BGP or BGP routing
        - 0x05 LDP: Any label associated with dynamically assigned
                    labels using LDP
         </artwork> further details.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 3031 for 3032 [RFC3032].
         </paragraph>
       </reference>
     </field>

     <field name="mplsLabelStackEntry9" dataType="unsigned32"
            group="subIpHeader"
            dataTypeSemantics="identifier"
            elementId="78" applicability="all" status="current">
       <description>
         <paragraph>
         The label, exp, and s fields from the MPLS label structure. stack entry that
         was pushed immediately before the label stack entry that would
         be reported by mplsLabelStackEntry8. See RFC 2547 for the association definition of MPLS labels with VPNs.
         See RFC 1771
         mplsTopLabelStackEntry for BGP and BGP routing. further details.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 3036 for LDP.
         and IP addresses. 3032 [RFC3032].
         </paragraph>
       </reference>
     </field>

     <field name="mplsTopLabelIPv4Address" dataType="ipv4Address"
            group="derived" name="mplsLabelStackEntry10" dataType="unsigned32"
            group="subIpHeader"
            dataTypeSemantics="identifier"
            fieldId="47" applicability="data"
            elementId="79" applicability="all" status="current">
       <description>
         <paragraph>
         The IPv4 address of label, exp, and s fields from the system label stack entry that
         was pushed immediately before the MPLS top label will
           cause this Flow to stack entry that would
         be forwarded to.
         </paragraph>
       </description>
       <reference> reported by mplsLabelStackEntry9. See RFC 3031 for the association between MPLS labels
         and IP addresses.
       </reference>
     </field>

     <field name="mplsTopLabelIPv6Address" dataType="ipv6Address"
            group="derived"
            dataTypeSemantics="identifier"
            fieldId="140" applicability="data" status="current">
       <description> definition of
         mplsTopLabelStackEntry for further details.
         </paragraph>
       </description>



Quittek, et al.       draft-ietf-ipfix-info-11.txt            [Page 104] 121]

Internet-Draft           IPFIX Information Model          September 2005


         <paragraph>
           The IPv6 address of the system that the MPLS top label will
           cause this Flow to be forwarded to.
         </paragraph>
       </description>               June 2006


       <reference>
         <paragraph>
         See RFC 3031 for the association between MPLS labels
         and IP addresses. 3032 [RFC3032].
         </paragraph>
       </reference>
     </field>

     <field name="exporterIPv4Address" name="ipNextHopIPv4Address" dataType="ipv4Address"
            group="derived"
            dataTypeSemantics="identifier"
            group="config"
            fieldId="130" applicability="all"
            elementId="15" applicability="data" status="current">
       <description>
         <paragraph>
         The IPv4 address used by the Exporting Process.  This is used
         by the Collector to identify the Exporter in cases where the
         identity of the Exporter may have been obscured by the use of
         a proxy. next IPv4 hop.
         </paragraph>
       </description>
     </field>

     <field name="exporterIPv6Address" name="ipNextHopIPv6Address" dataType="ipv6Address"
            group="derived"
            dataTypeSemantics="identifier"
            group="config"
            fieldId="131" applicability="all"
            elementId="62" applicability="data" status="current">
       <description>
         <paragraph>
         The IPv6 address used by the Exporting Process.  This is used
         by the Collector to identify the Exporter in cases where the
         identity of the Exporter may have been obscured by the use of
         a proxy. next IPv6 hop.
         </paragraph>
       </description>
     </field>

   <!--
     <field name="minimumPacketLength" dataType="unsigned16"
            group="minMax"
            fieldId="25" name="ipNextHopAsNumber" dataType="unsigned32"
            group="derived"
            dataTypeSemantics="identifier"
            elementId="162" applicability="all" status="current">
       <description>
         <paragraph>
         Length
         The autonomous system (AS) number of the smallest packet observed for this Flow. next IP hop.
         </paragraph>
       </description>
       <units>octets</units>
       <reference>
         See RFC 1771 for a description of BGP-4 and
         see RFC 1930 for a definition of the AS number.
       </reference>
     </field>
   -->

     <field name="bgpSourceAsNumber" dataType="unsigned32"
            group="derived"



Quittek, et al.       draft-ietf-ipfix-info-11.txt            [Page 105] 122]

Internet-Draft           IPFIX Information Model          September 2005


     </field>

     <field name="maximumPacketLength" dataType="unsigned16"
            group="minMax"
            fieldId="26"               June 2006


            dataTypeSemantics="identifier"
            elementId="16" applicability="all" status="current">
       <description>
         <paragraph>
         Length
         The autonomous system (AS) number of the largest packet observed source IP address.
         If AS path information for this Flow. Flow is only available as
         unordered AS set (and not as ordered AS sequence),
         then the value of this Information Element is 0.
         </paragraph>
       </description>
       <units>octets</units>
     </field>

     <field name="minimumTtl" dataType="octet"
            group="minMax"
            fieldId="52" applicability="data" status="current">
       <description>
       <reference>
         <paragraph>
           Minimum TTL value observed
         See RFC 1771 [RFC1771] for any packet in this Flow. a description of
         BGP-4 and see RFC 1930 [RFC1930] for a definition
         of the AS number.
         </paragraph>
       </description>
       </reference>
     </field>

     <field name="maximumTtl" dataType="octet"
            group="minMax"
            fieldId="53" applicability="data" name="bgpDestinationAsNumber" dataType="unsigned32"
            group="derived"
            dataTypeSemantics="identifier"
            elementId="17" applicability="all" status="current">
       <description>
         <paragraph>
           Maximum TTL value observed
         The autonomous system (AS) number of the destination IP
         address.  If AS path information for any packet in this Flow. Flow is only
         available as unordered AS set (and not as ordered AS
         sequence), then the value of this Information Element is 0.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 1771 [RFC1771] for a description of
         BGP-4 and see RFC 1930 [RFC1930] for a definition
         </paragraph>
       </reference>
     </field>

     <field name="ipv4Options" name="bgpNextAdjacentAsNumber" dataType="unsigned32"
            dataTypeSemantics="flags"
            group="minMax"
            fieldId="208"
            group="derived"
            dataTypeSemantics="identifier"
            elementId="128" applicability="all" status="current">
       <description>
         <paragraph>
         IPv4 options in packets of this Flow.
         The information is encoded in a set autonomous system (AS) number of bit fields.  For
         each valid IPv4 option type there is a bit the first AS in this set.
         The bit is set to 1 if any observed packet of this Flow
         contains the corresponding IPv4 option type.  Otherwise,
         if no observed packet of this Flow contained AS
         path to the
         respective IPv4 option type, destination IP address.  The path is deduced
         by looking up the value destination IP address of the
         corresponding bit is 0.
         </paragraph> Flow in the



Quittek, et al.       draft-ietf-ipfix-info-11.txt            [Page 106] 123]

Internet-Draft           IPFIX Information Model          September 2005


         <paragraph>
         The list of valid IPv4 options is maintained by IANA.
         Note that               June 2006


         BGP routing information base.  If AS path information for identifying an option
         this Flow is only available as unordered AS set (and not just the 5-bit
         Option Number, but all 8 bits of as
         ordered AS sequence),
         then the Option Type need to
         match one value of the IPv4 options specified at
         http://www.iana.org/assignments/ip-parameters.
         </paragraph>
         <paragraph>
         Options are mapped to bits according to their option numbers.
         Option number X is mapped to bit X.
         The mapping this Information Element is illustrated by the figure below. 0.
         </paragraph>
         <artwork>
           0      1      2      3      4      5      6      7
       +------+------+------+------+------+------+------+------+
       | EOOL | NOP  | SEC  | LSR  |  TS  |E-SEC |CIPSO |  RR  | ...
       +------+------+------+------+------+------+------+------+

           8      9     10     11     12     13     14     15
       +------+------+------+------+------+------+------+------+
   ... | SID  | SSR  | ZSU  | MTUP | MTUR | FINN | VISA |ENCODE| ...
       +------+------+------+------+------+------+------+------+

          16     17     18     19     20     21     22     23
       +------+------+------+------+------+------+------+------+
   ... |IMITD | EIP  |  TR  |ADDEXT|RTRALT| SDB  |NSAPA | DPS  | ...
       +------+------+------+------+------+------+------+------+

          24     25     26     27     28     29     30     31
       +------+------+------+------+------+------+------+------+
   ... | UMP  |             to be assigned by IANA             |
       +------+------+------+------+------+------+------+------+


           Type   Option
       Bit Value  Name    Reference
       ---+-----+-------+------------------------------------
        0     0   EOOL    End of Options List, RFC 791
        1     1   NOP     No Operation, RFC 791
        2   130   SEC     Security, RFC 1108
        3   131   LSR     Loose Source Route, RFC 791
        4    68   TS      Time Stamp, RFC 791
        5   133   E-SEC   Extended Security,
       </description>
       <reference>
         <paragraph>
         See RFC 1108
        6   134   CIPSO   Commercial Security
        7     7   RR      Record Route, 1771 [RFC1771] for a description of BGP-4 and
         see RFC 791
        8   136   SID     Stream ID, 1930 [RFC1930] for a definition of the AS number.
         </paragraph>
       </reference>
     </field>

     <field name="bgpPrevAdjacentAsNumber" dataType="unsigned32"
            group="derived"
            dataTypeSemantics="identifier"
            elementId="129" applicability="all" status="current">
       <description>
         <paragraph>
         The autonomous system (AS) number of the last AS in the AS
         path from the source IP address.  The path is deduced
         by looking up the source IP address of the Flow in the BGP
         routing information base.  If AS path information for this
         Flow is only available as unordered AS set (and not as
         ordered AS sequence), then the value of this Information
         Element is 0.  In case of BGP asymmetry, the
         bgpPrevAdjacentAsNumber might not be
         able to report the correct value.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 791
        9   137   SSR     Strict Source Route, 1771 [RFC1771] for a description of BGP-4 and
         see RFC 791
       10    10   ZSU     Experimental Measurement 1930 [RFC1930] for a definition of the AS number.
         </paragraph>
       </reference>
     </field>

     <field name="bgpNextHopIPv4Address" dataType="ipv4Address"
            group="derived"
            dataTypeSemantics="identifier"
            elementId="18" applicability="all" status="current">
       <description>
         <paragraph>
         The IPv4 address of the next (adjacent) BGP hop.
         </paragraph>
       </description>



Quittek, et al.       draft-ietf-ipfix-info-11.txt            [Page 107] 124]

Internet-Draft           IPFIX Information Model          September 2005


       11    11   MTUP    (obsoleted) MTU Probe, RFC 1191
       12    12   MTUR    (obsoleted) MTU Reply, RFC 1191
       13   205   FINN    Experimental Flow Control
       14   142   VISA    Experimental Access Control
       15    15   ENDOCE
       16   144   IMITD   IMI Traffic Descriptor
       17   145   EIP     Extended Internet Protocol, RFC 1385
       18    82   TR      Traceroute, RFC 3193
       19   147   ADDEXT  Address Extension
       20   148   RTRALT  Router Alert,               June 2006


       <reference>
         <paragraph>
         See RFC 2113
       21   149   SDB     Selective Directed Broadcast
       22   150   NSAPA   NSAP Address
       23   151   DPS     Dynamic Packet State
       24   152   UMP     Upstream Multicast Pkt.
       ...  ...   ... 1771 [RFC1771] for a description of BGP-4.
         </paragraph>
       </reference>
     </field>

     <field name="bgpNextHopIPv6Address" dataType="ipv6Address"
            group="derived"
            dataTypeSemantics="identifier"
            elementId="63" applicability="all" status="current">
       <description>
         <paragraph>
         The IPv6 address of the next (adjacent) BGP hop.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 1771 [RFC1771] for a description of BGP-4.
         </paragraph>
       </reference>
     </field>

     <field name="mplsTopLabelType" dataType="unsigned8"
            group="derived"
            dataTypeSemantics="identifier"
            elementId="46" applicability="data" status="current">
       <description>
         <paragraph>
         This field identifies the control protocol that allocated the
         top of stack label.  Initially values for this field are
         listed below.  Further options numbers values may be assigned by IANA in
         the MPLS label type registry.
         </paragraph>
         <artwork>
        - 0x01 TE-MIDPT: Any TE tunnel mid-point or tail label
        - 0x02 Pseudowire: Any PWE3 or Cisco AToM based label
        - 0x03 VPN: Any label associated with VPN
        - 0x04 BGP: Any label associated with BGP or BGP routing
        - 0x05 LDP: Any label associated with dynamically assigned
                    labels using LDP
         </artwork>
       </description>
       <reference>
         <paragraph>
         See RFC 791 3031 [RFC3031] for the definition MPLS label structure.
         See RFC 2547 [RFC2547] for the association of IPv4 options. MPLS labels
         with VPNs.



Quittek, et al.       draft-ietf-ipfix-info-11.txt            [Page 125]

Internet-Draft           IPFIX Information Model               June 2006


         See RFC 1771 [RFC1771] for BGP and BGP routing.
         See RFC 3036 [RFC3036] for LDP.
         See the list of IPv4 option numbers MPLS label types assigned by IANA at http://www.iana.org/assignments/ip-parameters.
         http://www.iana.org/assignments/mpls-label-types.
         </paragraph>
       </reference>
     </field>

     <field name="mplsTopLabelIPv4Address" dataType="ipv4Address"
            group="derived"
            dataTypeSemantics="identifier"
            elementId="47" applicability="data" status="current">
       <description>
         <paragraph>
           The IPv4 address of the system that the MPLS top label will
           cause this Flow to be forwarded to.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 3031 [RFC3031] for the association between
         MPLS labels and IP addresses.
         </paragraph>
       </reference>
     </field>

     <field name="ipv6ExtensionHeaders" dataType="unsigned32"
            dataTypeSemantics="flags"
            group="minMax"
            fieldId="64" applicability="all" name="mplsTopLabelIPv6Address" dataType="ipv6Address"
            group="derived"
            dataTypeSemantics="identifier"
            elementId="140" applicability="data" status="current">
       <description>
         <paragraph>
        IPv6 extension headers observed in packets of this Flow.
        The information is encoded in a set of bit fields.  For
        each IPv6 option header there is a bit in this set.
           The bit is set to 1 if any observed packet of this Flow
        contains the corresponding IPv6 extension header.
        Otherwise, if no observed packet address of this Flow contained
        the respective IPv6 extension header, the value of system that the
        corresponding bit is 0.
         </paragraph>
         <artwork>
              0     1     2     3     4     5     6     7
          +-----+-----+-----+-----+-----+-----+-----+-----+
          | Res | FRA1| ROU | FRA0| UNK | Res | HOP | DST |  ...
          +-----+-----+-----+-----+-----+-----+-----+-----+

              8     9    10    11    12    13    14    15
          +-----+-----+-----+-----+-----+-----+-----+-----+



Quittek, et al.       draft-ietf-ipfix-info-11.txt            [Page 108]

Internet-Draft           IPFI