view Side-By-Side changes

Network Working Group                                         J. Quittek
Internet-Draft                                                       NEC
Expires: November 28, 2005 January 8, 2006                                       S. Bryant
                                                               B. Claise
                                                           Cisco Systems
                                                                J. Meyer
                                                                  PayPal
                                                            May 30,
                                                            July 7, 2005


            Information Model for IP Flow Information Export
                        draft-ietf-ipfix-info-07
                        draft-ietf-ipfix-info-08

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section Section 3 of RFC 3667.  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.

   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 November 28, 2005. January 8, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

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



Quittek, et al.        Expires November 28, 2005       draft-ietf-ipfix-info-08.txt              [Page 1]

Internet-Draft           IPFIX Information Model                 May               July 2005


   encoding measured traffic information and information related to the
   traffic Observation Point, the traffic Metering Process and the
   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 . . . . . . . . . . . . . . . . . . . . . . . .   6   7
   2.   Properties of IPFIX Protocol Information Elements  . . . . .   7
     2.1  Information Elements Specification Template  . . . . . . .   7   8
     2.2  Scope of Information Elements  . . . . . . . . . . . . . .   8   9
     2.3  Naming Conventions for Information Elements  . . . . . . .   8   9
   3.   Type Space . . . . . . . . . . . . . . . . . . . . . . . . .  10
     3.1  Data Types . . . . . . . . . . . . . . . . . . . . . . . .  10
       3.1.1  octet  . . . . . . . . . . . . . . . . . . . . . . . .  10
       3.1.2  unsigned16 . . . . . . . . . . . . . . . . . . . . . .  10  11
       3.1.3  unsigned32 . . . . . . . . . . . . . . . . . . . . . .  10  11
       3.1.4  unsigned64 . . . . . . . . . . . . . . . . . . . . . .  10  11
       3.1.5  float32  . . . . . . . . . . . . . . . . . . . . . . .  10  11
       3.1.6  boolean  . . . . . . . . . . . . . . . . . . . . . . .  10  11
       3.1.7  macAddress . . . . . . . . . . . . . . . . . . . . . .  11
       3.1.8  octetArray . . . . . . . . . . . . . . . . . . . . . .  11
       3.1.9  string . . . . . . . . . . . . . . . . . . . . . . . .  11
       3.1.10   dateTimeSeconds  . . . . . . . . . . . . . . . . . .  11
       3.1.11   dateTimeMilliSeconds . . . . . . . . . . . . . . . .  11  12
       3.1.12   dateTimeMicroSeconds . . . . . . . . . . . . . . . .  11  12
       3.1.13   dateTimeNanoSeconds  . . . . . . . . . . . . . . . .  11  12
       3.1.14   ipv4Address  . . . . . . . . . . . . . . . . . . . .  11  12
       3.1.15   ipv6Address  . . . . . . . . . . . . . . . . . . . .  11  12
     3.2  Data Type Semantics  . . . . . . . . . . . . . . . . . . .  12
       3.2.1  quantity . . . . . . . . . . . . . . . . . . . . . . .  12
       3.2.2  totalCounter . . . . . . . . . . . . . . . . . . . . .  12
       3.2.3  deltaCounter . . . . . . . . . . . . . . . . . . . . .  12  13
       3.2.4  identifier . . . . . . . . . . . . . . . . . . . . . .  12  13
       3.2.5  flags  . . . . . . . . . . . . . . . . . . . . . . . .  12  13
   4.   Information Element Identifiers  . . . . . . . . . . . . . .  13
   5.   Information Elements . . . . . . . . . . . . . . . . . . . .  16  17
     5.1  Identifiers  . . . . . . . . . . . . . . . . . . . . . . .  16  17
       5.1.1  lineCardId . . . . . . . . . . . . . . . . . . . . . .  17  18
       5.1.2  portId . . . . . . . . . . . . . . . . . . . . . . . .  17  18
       5.1.3  ingressInterface . . . . . . . . . . . . . . . . . . .  17  18
       5.1.4  egressInterface  . . . . . . . . . . . . . . . . . . .  17  18
       5.1.5  meteringProcessId  . . . . . . . . . . . . . . . . . .  18  19
       5.1.6  exportingProcessId . . . . . . . . . . . . . . . . . .  18  19
       5.1.7  flowId . . . . . . . . . . . . . . . . . . . . . . . .  18  19
       5.1.8  templateId . . . . . . . . . . . . . . . . . . . . . .  18  19
       5.1.9  sourceId . . . . . . . . . . . . . . . . . . . . . . .  19  20



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


     5.2  Metering and Exporting Process Properties  . . . . . . . .  19



Quittek, et al.        Expires November 28, 2005                [Page 2]

Internet-Draft          IPFIX Information Model                 May 2005  20
       5.2.1  exporterIPv4Address  . . . . . . . . . . . . . . . . .  19  20
       5.2.2  exporterIPv6Address  . . . . . . . . . . . . . . . . .  20  21
       5.2.3  exportedMessageTotalCount  . . . . . . . . . . . . . .  20  21
       5.2.4  exportedOctetTotalCount  . . . . . . . . . . . . . . .  20  21
       5.2.5  exportedFlowTotalCount . . . . . . . . . . . . . . . .  20  21
       5.2.6  observedFlowTotalCount . . . . . . . . . . . . . . . .  21  22
       5.2.7  ignoredPacketTotalCount  . . . . . . . . . . . . . . .  21  22
       5.2.8  ignoredOctetTotalCount . . . . . . . . . . . . . . . .  21  22
       5.2.9  notSentFlowTotalCount  . . . . . . . . . . . . . . . .  21  23
       5.2.10   notSentPacketTotalCount  . . . . . . . . . . . . . .  22  23
       5.2.11   notSentOctetTotalCount . . . . . . . . . . . . . . .  22  23
       5.2.12   flowKeyIndicator . . . . . . . . . . . . . . . . . .  22  23
     5.3  IP Header Fields . . . . . . . . . . . . . . . . . . . . .  23  24
       5.3.1  ipVersion  . . . . . . . . . . . . . . . . . . . . . .  23  25
       5.3.2  sourceIPv4Address  . . . . . . . . . . . . . . . . . .  24  25
       5.3.3  sourceIPv6Address  . . . . . . . . . . . . . . . . . .  24  25
       5.3.4  sourceIPv4Mask . . . . . . . . . . . . . . . . . . . .  24  25
       5.3.5  sourceIPv6Mask . . . . . . . . . . . . . . . . . . . .  24  25
       5.3.6  sourceIPv4Prefix . . . . . . . . . . . . . . . . . . .  24  26
       5.3.7  sourceIPv6Prefix . . . . . . . . . . . . . . . . . . .  25  26
       5.3.8  destinationIPv4Address . . . . . . . . . . . . . . . .  25  26
       5.3.9  destinationIPv6Address . . . . . . . . . . . . . . . .  25  26
       5.3.10   destinationIPv4Mask  . . . . . . . . . . . . . . . .  25  26
       5.3.11   destinationIPv6Mask  . . . . . . . . . . . . . . . .  25  27
       5.3.12   destinationIPv4Prefix  . . . . . . . . . . . . . . .  26  27
       5.3.13   destinationIPv6Prefix  . . . . . . . . . . . . . . .  26  27
       5.3.14   classOfServiceIPv4   ipTimeToLive . . . . . . . . . . . . . . . . .  26 . . .  27
       5.3.15   classOfServiceIPv6   protocolIdentifier . . . . . . . . . . . . . . . . .  26  28
       5.3.16   postClassOfServiceIPv4   nextHeaderIPv6 . . . . . . . . . . . . . . .  27 . . . .  28
       5.3.17   postClassOfServiceIPv6   ipClassOfService . . . . . . . . . . . . . . .  27
       5.3.18   flowLabelIPv6 . . .  28
       5.3.18   ipDiffServeCodePoint . . . . . . . . . . . . . . . .  27  29
       5.3.19   identificationIPv4   ipPrecedence . . . . . . . . . . . . . . . . .  27 . . .  29
       5.3.20   protocolIdentifier   classOfServiceIPv4 . . . . . . . . . . . . . . . . .  28  30
       5.3.21   fragmentOffsetIPv4   classOfServiceIPv6 . . . . . . . . . . . . . . . . .  28
     5.4  Transport Header Fields  30
       5.3.22   postClassOfServiceIPv4 . . . . . . . . . . . . . . .  30
       5.3.23   postClassOfServiceIPv6 . .  28
       5.4.1  sourceTransportPort . . . . . . . . . . . . .  30
       5.3.24   flowLabelIPv6  . . . .  29
       5.4.2  destinationTransportPort . . . . . . . . . . . . . . .  29
       5.4.3  icmpTypeCodeIPv4  31
       5.3.25   identificationIPv4 . . . . . . . . . . . . . . . . .  31
       5.3.26   fragmentOffsetIPv4 . .  29
       5.4.4  icmpTypeCodeIPv6 . . . . . . . . . . . . . . .  31
       5.3.27   fragmentFlagsIPv4  . . . .  30
       5.4.5  igmpType . . . . . . . . . . . . .  32
       5.3.28   ipHeaderLength . . . . . . . . . .  30
     5.5  Sub-IP Header Fields . . . . . . . . .  32
       5.3.29   headerLengthIPv4 . . . . . . . . . .  30
       5.5.1  sourceMacAddress . . . . . . . .  32
       5.3.30   packetLengthIPv4 . . . . . . . . . . .  31
       5.5.2  postDestinationMacAddr . . . . . . .  33
       5.3.31   payloadLengthIPv6  . . . . . . . . .  31
       5.5.3  vlanId . . . . . . . .  33
     5.4  Transport Header Fields  . . . . . . . . . . . . . . . .  31
       5.5.4  postVlanId . .  33
       5.4.1  sourceTransportPort  . . . . . . . . . . . . . . . . .  34
       5.4.2  destinationTransportPort . . .  31
       5.5.5  destinationMacAddress . . . . . . . . . . . .  34



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


       5.4.3  udpSourcePort  . . . .  31
       5.5.6  postSourceMacAddress . . . . . . . . . . . . . . . .  35
       5.4.4  udpDestinationPort .  32
       5.5.7  wlanChannelId . . . . . . . . . . . . . . . . .  35
       5.4.5  tcpSourcePort  . . .  32



Quittek, et al.        Expires November 28, 2005                [Page 3]

Internet-Draft          IPFIX Information Model                 May 2005


       5.5.8  wlanSsid . . . . . . . . . . . . . . . . .  35
       5.4.6  tcpDestinationPort . . . . . .  32
       5.5.9  mplsLabelStackEntry1 . . . . . . . . . . . .  35
       5.4.7  tcpSequenceNumber  . . . . .  32
       5.5.10   mplsLabelStackEntry2 . . . . . . . . . . . . .  36
       5.4.8  tcpAcknowledgementNumber . . .  33
       5.5.11   mplsLabelStackEntry3 . . . . . . . . . . . .  36
       5.4.9  tcpWindowSize  . . . .  33
       5.5.12   mplsLabelStackEntry4 . . . . . . . . . . . . . . . .  33
       5.5.13   mplsLabelStackEntry5  36
       5.4.10   tcpUrgentPointer . . . . . . . . . . . . . . . .  34
       5.5.14   mplsLabelStackEntry6 . .  36
       5.4.11   tcpHeaderLength  . . . . . . . . . . . . . .  34
       5.5.15   mplsLabelStackEntry7 . . . .  36
       5.4.12   icmpTypeCodeIPv4 . . . . . . . . . . . .  34
       5.5.16   mplsLabelStackEntry8 . . . . . .  37
       5.4.13   icmpTypeIPv4 . . . . . . . . . .  34
       5.5.17   mplsLabelStackEntry9 . . . . . . . . . .  37
       5.4.14   icmpCodeIPv4 . . . . . .  35
       5.5.18   mplsLabelStackEntry10 . . . . . . . . . . . . . .  37
       5.4.15   icmpTypeCodeIPv6 .  35
     5.6  Derived Packet Properties . . . . . . . . . . . . . . . .  35
       5.6.1  ipNextHopIPv4Address .  37
       5.4.16   icmpTypeIPv6 . . . . . . . . . . . . . . . .  36
       5.6.2  ipNextHopIPv6Address . . . .  38
       5.4.17   icmpCodeIPv6 . . . . . . . . . . . . .  36
       5.6.3  bgpSourceAsNumber . . . . . . .  38
       5.4.18   igmpType . . . . . . . . . . .  36
       5.6.4  bgpDestinationAsNumber . . . . . . . . . . .  38
     5.5  Sub-IP Header Fields . . . . .  36
       5.6.5  bgpNextAdjacentAsNumber . . . . . . . . . . . . . .  38
       5.5.1  sourceMacAddress .  37
       5.6.6  bgpPrevAdjacentAsNumber . . . . . . . . . . . . . . .  37
       5.6.7  bgpNextHopIPv4Address . . .  39
       5.5.2  postDestinationMacAddr . . . . . . . . . . . . .  38
       5.6.8  bgpNextHopIPv6Address . . .  39
       5.5.3  vlanId . . . . . . . . . . . . .  38
       5.6.9  mplsTopLabelType . . . . . . . . . . .  39
       5.5.4  postVlanId . . . . . . . .  38
       5.6.10   mplsTopLabelIPv4Address . . . . . . . . . . . . . .  38
       5.6.11   mplsTopLabelIPv6Address  40
       5.5.5  destinationMacAddress  . . . . . . . . . . . . . .  39
     5.7  Min/Max Flow Properties . .  40
       5.5.6  postSourceMacAddress . . . . . . . . . . . . . . .  39
       5.7.1  minimumPacketLength . .  40
       5.5.7  wlanChannelId  . . . . . . . . . . . . . . .  39
       5.7.2  maximumPacketLength . . . . .  40
       5.5.8  wlanSsid . . . . . . . . . . . .  39
       5.7.3  minimumTtl . . . . . . . . . . .  41
       5.5.9  mplsTopLabelTtl  . . . . . . . . . . .  40
       5.7.4  maximumTtl . . . . . . . .  41
       5.5.10   mplsTopLabelExp  . . . . . . . . . . . . . .  40
       5.7.5  ipv6OptionHeaders . . . .  41
       5.5.11   mplsLabelStackSize . . . . . . . . . . . . . .  40
       5.7.6  tcpControlBits . . .  42
       5.5.12   mplsLabelStackDepth  . . . . . . . . . . . . . . . .  42
       5.5.13   mplsTopLabelEntry  .  41
     5.8  Flow Time Stamps . . . . . . . . . . . . . . . .  42
       5.5.14   mplsLabelStackEntry2 . . . . .  41
       5.8.1  flowStartSeconds . . . . . . . . . . .  43
       5.5.15   mplsLabelStackEntry3 . . . . . . . .  42
       5.8.2  flowEndSeconds . . . . . . . .  43
       5.5.16   mplsLabelStackEntry4 . . . . . . . . . . . .  42
       5.8.3  flowStartMilliSeconds . . . .  43
       5.5.17   mplsLabelStackEntry5 . . . . . . . . . . . .  42
       5.8.4  flowEndMilliSeconds . . . .  43
       5.5.18   mplsLabelStackEntry6 . . . . . . . . . . . . .  43
       5.8.5  flowStartMicroSeconds . . .  44
       5.5.19   mplsLabelStackEntry7 . . . . . . . . . . . . .  43
       5.8.6  flowEndMicroSeconds . . .  44
       5.5.20   mplsLabelStackEntry8 . . . . . . . . . . . . . .  43
       5.8.7  flowStartNanoSeconds . .  44
       5.5.21   mplsLabelStackEntry9 . . . . . . . . . . . . . . .  43
       5.8.8  flowEndNanoSeconds .  45
       5.5.22   mplsLabelStackEntry10  . . . . . . . . . . . . . . .  45
     5.6  Derived Packet Properties  . .  43
       5.8.9  flowStartDeltaMicroSeconds . . . . . . . . . . . . . .  44
       5.8.10   flowEndDeltaMicroSeconds . . . . . . .  45
       5.6.1  ipNextHopIPv4Address . . . . . . .  44
       5.8.11   systemInitTimeMilliSeconds . . . . . . . . . .  46
       5.6.2  ipNextHopIPv6Address . . .  44
       5.8.12   flowStartSysUpTime . . . . . . . . . . . . . .  46
       5.6.3  bgpSourceAsNumber  . . .  44
       5.8.13   flowEndSysUpTime . . . . . . . . . . . . . . .  46
       5.6.4  bgpDestinationAsNumber . . .  44
     5.9  Per-Flow Counters . . . . . . . . . . . . .  46
       5.6.5  bgpNextAdjacentAsNumber  . . . . . . .  45
       5.9.1  octetDeltaCount . . . . . . . .  47
       5.6.6  bgpPrevAdjacentAsNumber  . . . . . . . . . . .  45
       5.9.2  postOctetDeltaCount . . . .  47
       5.6.7  bgpNextHopIPv4Address  . . . . . . . . . . . . .  46
       5.9.3  octetTotalCount . . .  47
       5.6.8  bgpNextHopIPv6Address  . . . . . . . . . . . . . . . .  46  47



Quittek, et al.        Expires November 28, 2005       draft-ietf-ipfix-info-08.txt              [Page 4]

Internet-Draft           IPFIX Information Model                 May               July 2005


       5.9.4  postOctetTotalCount


       5.6.9  mplsTopLabelType . . . . . . . . . . . . . . . . .  46
       5.9.5  packetDeltaCount . .  48
       5.6.10   mplsTopLabelIPv4Address  . . . . . . . . . . . . . .  48
       5.6.11   mplsTopLabelIPv6Address  . . .  46
       5.9.6  postPacketDeltaCount . . . . . . . . . . .  48
     5.7  Min/Max Flow Properties  . . . . . .  47
       5.9.7  packetTotalCount . . . . . . . . . . .  49
       5.7.1  minimumPacketLength  . . . . . . . .  47
       5.9.8  postPacketTotalCount . . . . . . . . .  49
       5.7.2  maximumPacketLength  . . . . . . . .  47
       5.9.9  droppedOctetDeltaCount . . . . . . . . .  49
       5.7.3  minimumTtl . . . . . . .  47
       5.9.10   droppedPacketDeltaCount . . . . . . . . . . . . . .  48
       5.9.11   droppedOctetTotalCount .  49
       5.7.4  maximumTtl . . . . . . . . . . . . . .  48
       5.9.12   droppedPacketTotalCount . . . . . . . .  50
       5.7.5  ipv4Options  . . . . . .  48
       5.9.13   postMulticastPacketCount . . . . . . . . . . . . . .  49
       5.9.14   postMulticastOctetCount .  50
       5.7.6  ipv6OptionHeaders  . . . . . . . . . . . . .  49
     5.10   Miscellaneous Flow Properties . . . . .  50
       5.7.7  tcpControlBits . . . . . . . .  49
       5.10.1   flowActiveTimeOut . . . . . . . . . . . .  52
       5.7.8  tcpOptions . . . . .  49
       5.10.2   flowInactiveTimeout . . . . . . . . . . . . . . . .  50
       5.10.3   flowEndReason .  52
     5.8  Flow Time Stamps . . . . . . . . . . . . . . . . . .  50
       5.10.4   flowDurationMilliSeconds . . .  53
       5.8.1  flowStartSeconds . . . . . . . . . . .  50
       5.10.5   flowDurationMicroSeconds . . . . . . . .  53
       5.8.2  flowEndSeconds . . . . . .  50
   6.   Extending the Information Model . . . . . . . . . . . . . .  51
   7.   IANA Considerations  54
       5.8.3  flowStartMilliSeconds  . . . . . . . . . . . . . . . .  54
       5.8.4  flowEndMilliSeconds  . . . . . .  52
   8.   Security Considerations . . . . . . . . . . .  54
       5.8.5  flowStartMicroSeconds  . . . . . . . . .  53
   9.   Acknowledgements . . . . . . .  54
       5.8.6  flowEndMicroSeconds  . . . . . . . . . . . . . . . . .  54
   10.  Open Issues
       5.8.7  flowStartNanoSeconds . . . . . . . . . . . . . . . . .  54
       5.8.8  flowEndNanoSeconds . . . . . . .  55
   11.  References . . . . . . . . . . .  55
       5.8.9  flowStartDeltaMicroSeconds . . . . . . . . . . . . . .  56
   11.1   Normative Reference  55
       5.8.10   flowEndDeltaMicroSeconds . . . . . . . . . . . . . .  55
       5.8.11   systemInitTimeMilliSeconds . . . . .  56
   11.2   Informative Reference . . . . . . . .  55
       5.8.12   flowStartSysUpTime . . . . . . . . . .  56
        Authors' Addresses . . . . . . .  56
       5.8.13   flowEndSysUpTime . . . . . . . . . . . . . .  58
   A.   Formal Specification of IPFIX Information Element . . . .  56
     5.9  Per-Flow Counters  .  60
   B.   Formal Specification of Abstract Data Types . . . . . . . .  97
        Intellectual Property and Copyright Statements . . . . . . . 108






















Quittek, et al.        Expires November 28, . . . .  56
       5.9.1  octetDeltaCount  . . . . . . . . . . . . . . . . . . .  57
       5.9.2  postOctetDeltaCount  . . . . . . . . . . . . . . . . .  57
       5.9.3  octetDeltaSumOfSquares . . . . . . . . . . . . . . . .  57
       5.9.4  octetTotalCount  . . . . . . . . . . . . . . . . . . .  58
       5.9.5  postOctetTotalCount  . . . . . . . . . . . . . . . . .  58
       5.9.6  octetTotalSumOfSquares . . . . . . . . . . . . . . . .  58
       5.9.7  packetDeltaCount . . . . . . . . . . . . . . . . . . .  59
       5.9.8  postPacketDeltaCount . . . . . . . . . . . . . . . . .  59
       5.9.9  packetTotalCount . . . . . . . . . . . . . . . . . . .  59
       5.9.10   postPacketTotalCount . . . . . . . . . . . . . . . .  59
       5.9.11   droppedOctetDeltaCount . . . . . . . . . . . . . . .  60
       5.9.12   droppedPacketDeltaCount  . . . . . . . . . . . . . .  60
       5.9.13   droppedOctetTotalCount . . . . . . . . . . . . . . .  60
       5.9.14   droppedPacketTotalCount  . . . . . . . . . . . . . .  60
       5.9.15   postMCastPacketDeltaCount  . . . . . . . . . . . . .  61
       5.9.16   postMCastOctetDeltaCount . . . . . . . . . . . . . .  61
       5.9.17   postMCastPacketTotalCount  . . . . . . . . . . . . .  61
       5.9.18   postMCastOctetTotalCount . . . . . . . . . . . . . .  62
     5.10   Miscellaneous Flow Properties  . . . . . . . . . . . . .  62
       5.10.1   flowActiveTimeOut  . . . . . . . . . . . . . . . . .  62
       5.10.2   flowInactiveTimeout  . . . . . . . . . . . . . . . .  62



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


       5.10.3   flowEndReason  . . . . . . . . . . . . . . . . . . .  63
       5.10.4   flowDurationMilliSeconds . . . . . . . . . . . . . .  63
       5.10.5   flowDurationMicroSeconds . . . . . . . . . . . . . .  63
     5.11   Padding  . . . . . . . . . . . . . . . . . . . . . . . .  63
       5.11.1   paddingOneOctet  . . . . . . . . . . . . . . . . . .  64
   6.   Extending the Information Model  . . . . . . . . . . . . . .  64
   7.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .  65
   8.   Security Considerations  . . . . . . . . . . . . . . . . . .  65
   9.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  66
   10.  Open Issues  . . . . . . . . . . . . . . . . . . . . . . . .  66
   11.  References . . . . . . . . . . . . . . . . . . . . . . . . .  66
     11.1   Normative Reference  . . . . . . . . . . . . . . . . . .  66
     11.2   Informative Reference  . . . . . . . . . . . . . . . . .  66
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  69
   A.   Formal Specification of IPFIX Information Element  . . . . .  70
   B.   Formal Specification of Abstract Data Types  . . . . . . . . 120
        Intellectual Property and Copyright Statements . . . . . . . 132


































Quittek, et al.       draft-ietf-ipfix-info-08.txt              [Page 5] 6]

Internet-Draft           IPFIX Information Model                 May               July 2005


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 Flow attributes (source IP address, number of
   packets, etc.) and information about the Metering and Exporting
   Process (packet Observation Point, sampling rate, flow 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]. [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.  Section 3 defines the set of abstract data
   types that are available for IPFIX Information Elements.  Section 5
   discusses extensibility of the IPFIX information model.

   The main bodies of sections 2, 3 and 4 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
   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





Quittek, et al.        Expires November 28, 2005       draft-ietf-ipfix-info-08.txt              [Page 6] 7]

Internet-Draft           IPFIX Information Model                 May               July 2005


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.  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.

   description - The semantics of this Information Element.  Describes
      how this Information Element is derived from the flow 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 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
      made public and/or if enterprise-specific identifiers are used by
      the IPFIX protocol outside the enterprise, then the
      enterprise-specific 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.        Expires November 28, 2005       draft-ietf-ipfix-info-08.txt              [Page 7] 8]

Internet-Draft           IPFIX Information Model                 May               July 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". 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.

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-08.txt              [Page 9]

Internet-Draft           IPFIX Information Model               July 2005


   o  Composed names use capital letters for the first letter of each
      component (except for the first one).  All other letters are



Quittek, et al.        Expires November 28, 2005                [Page 8]

Internet-Draft          IPFIX Information Model                 May 2005


      non-capitalized, 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 Flow properties, such as the DSCP
      value or the source IP address.  There are different Information
      Elements required for  If an IPFIX Observation Point is
      located in the original values path of these a Flow either before or after a
      middleboxes, that potentially modify packets of the Flow, then it
      may be desirable to report also flow properties and on the 'other'
      side of the middlebox.  If, for example, the modified values.  As Observation Point is
      located before a general rule, network address translator, then it is recommended might be
      desirable to also report translated IP addresses besides the ones
      that actually have been observed.
   o  If the 'other' side of the middlebox is located on the data path
      of a Flow before the middlebox, i.e. the middlebox observes the
      modified packets, then the names for of Information Elements containing reporting
      the original Flow properties SHOULD have no specific the prefix while "pre", for
      example preIpDiffServeCodePoint.
   o  If the 'other' side of the middlebox is located on the data path
      of a Flow after the middlebox, i.e. the middlebox observes the
      original packets, then the names of Information Elements containing reporting
      the modified Flow properties SHOULD have the prefix "post", for example, postClassOfServiceIPv4.








































Quittek, et al.        Expires November 28, 2005                [Page 9]

Internet-Draft          IPFIX Information Model                 May 2005
      example postSourceMacAddress.

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 data types.

   Data types octet, unsigned16, unsigned32, and unsigned64 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  Data Types

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

3.1.1  octet

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





Quittek, et al.       draft-ietf-ipfix-info-08.txt             [Page 10]

Internet-Draft           IPFIX Information Model               July 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  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

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





Quittek, et al.        Expires November 28, 2005               [Page 10]

Internet-Draft          IPFIX Information Model                 May 2005

3.1.7  macAddress

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

3.1.8  octetArray

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

3.1.9  string

   The type "string" represents a finite length string of valid
   characters from the Unicode character encoding set
   [ISO.10646-1.1993]. [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  dateTimeSeconds

   The type "dateTimeSeconds" represents a time value having a precision
   of seconds and normalized to the GMT time zone.




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


3.1.11  dateTimeMilliSeconds

   The type "dateTimeMilliSeconds" represents a time value having a
   precision of milliseconds and normalized to the GMT time zone.

3.1.12  dateTimeMicroSeconds

   The type "dateTimeMicroSeconds" represents a time value having a
   precision of microseconds and normalized to the GMT time zone.

3.1.13  dateTimeNanoSeconds

   The type "dateTimeNanoSeconds" represents a time value having a
   precision of nanoseconds and normalized to the GMT time zone.

3.1.14  ipv4Address

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

3.1.15  ipv6Address

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






Quittek, et al.        Expires November 28, 2005               [Page 11]

Internet-Draft          IPFIX Information Model                 May 2005


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.

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.  A
   running counter counts independently of the export of its value.



Quittek, et al.       draft-ietf-ipfix-info-08.txt             [Page 12]

Internet-Draft           IPFIX Information Model               July 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.  A delta
   counter is reset to zero each time its value is exported.

3.2.4  identifier

   An integral value which serves as an identifier.  Specifically
   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.        Expires November 28, 2005       draft-ietf-ipfix-info-08.txt             [Page 12] 13]

Internet-Draft           IPFIX Information Model                 May               July 2005


4.


   +---------------------------------+---------------------------------+
   | Range of IANA-assigned          | Description                     |
   | Information Element Identifiers

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

   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 defined in section 5 of this document or in
   future extensions of because the IPFIX information model have their Information Element identifier is coupled with
   an enterprise identifier.

   Enterprise identifiers assigned by MUST be registered as SMI network management
   private enterprise code numbers with IANA.  Their identifiers  The registry can be retrieved found
   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 http://www.iana.org/assignments/enterprise-numbers.

   The value following list gives an overview of these identifiers are in the range of 1 - 32767.  Within
   this range, Information Element identifier values
   identifiers that are specified in the sub-range of
   1-127 section 5 and are compatible with
   field types used by NetFlow version 9
   [RFC3954].

   +---------------------------------+---------------------------------+ [RFC3954]



















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


   +-------+-------------------------+-------+-------------------------+
   |    ID | Name                    |    ID | Name                    |
   +-------+-------------------------+-------+-------------------------+
   |     1 | RESERVED                |    43 | RESERVED                |
   |     2 | packetDeltaCount        |    44 | sourceIPv4Prefix        |
   |     3 | RESERVED                |    45 | destinationIPv4Prefix   |
   |     4 | protocolIdentifier      |    46 | mplsTopLabelType        |
   |     5 | classOfServiceIPv4      |    47 | mplsTopLabelIPv4Address |
   |     6 | tcpControlBits          | 48-51 | RESERVED                |
   |     7 | sourceTransportPort     |    52 | minimumTtl              |
   |     8 | sourceIPv4Address       |    53 | maximumTtl              |
   |     9 | sourceIPv4Mask          |    54 | identificationIPv4      |
   |    10 | ingressInterface        |    55 | postClassOfServiceIPv4  |
   |    11 | destinationTransportPort|    56 | sourceMacAddress        |
   |    12 | destinationIPv4Address  |    57 | postDestinationMacAddr  |
   |    13 | destinationIPv4Mask     |    58 | vlanID                  |
   |    14 | egressInterface         |    59 | postVlanId              |
   |    15 | ipNextHopIPv4Address    |    60 | Range of IANA-assigned ipVersion               | Description
   |    16 | Information Element identifiers bgpSourceAsNumber       |    61 |
   +---------------------------------+---------------------------------+ RESERVED                | 0
   | Reserved.    17 | bgpDestinationAsNumber  |    62 | ipNextHopIPv6Address    |
   | 1 - 127    18 | Information Element identifiers bgpNexthopIPv4Address   |    63 | bgpNexthopIPv6Address   | compatible with NetFlow version
   |    19 | postMCastPacketDeltaCount|   64 | 9 field types [RFC3954]. ipv6OptionHeaders       |
   |    20 | postMCastOctetDeltaCount| 65-69 | RESERVED                | 128 - 32767
   | Further Information Element    21 | flowEndSysUpTime        |    70 | identifiers. mplsTopLabelEntry       |
   +---------------------------------+---------------------------------+

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

   Enterprise-specific 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.
   |    22 | flowStartSysUpTime      |    71 | mplsLabelStackEntry2    |
   |    23 | RESERVED                |    72 | mplsLabelStackEntry3    |
   |    24 | postPacketDeltaCount    |    73 | mplsLabelStackEntry4    |
   |    25 | minimumPacketLength     |    74 | mplsLabelStackEntry5    |
   |    26 | maximumPacketLength     |    75 | mplsLabelStackEntry6    |
   |    27 | sourceIPv6Address       |    76 | mplsLabelStackEntry7    |
   |    28 | destinationIPv6Address  |    77 | mplsLabelStackEntry8    |
   |    29 | sourceIPv6Mask          |    78 | mplsLabelStackEntry9    |
   |    30 | destinationIPv6Mask     |    79 | mplsLabelStackEntry10   |
   |    31 | flowLabelIPv6           |    80 | destinationMacAddress   |
   |    32 | icmpTypeCodeIPv4        |    81 | postSourceMacAddress    |
   |    33 | igmpType                | 82-85 | RESERVED                |
   | 34-35 | RESERVED                |    86 | packetTotalCount        |
   |    36 | flowActiveTimeOut       |    87 | RESERVED                |
   |    37 | flowInactiveTimeout     |    88 | fragmentOffsetIPv4      |
   | 38-39 | RESERVED                |89-127 | RESERVED                |
   |    40 | exportedOctetTotalCount |       |                         |
   |    41 | exportedMessageTotalCount|      |                         |
   |    42 | exportedFlowTotalCount  |       |                         |
   +-------+-------------------------+-------+-------------------------+

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



Quittek, et al.        Expires November 28, 2005       draft-ietf-ipfix-info-08.txt             [Page 13] 15]

Internet-Draft           IPFIX Information Model                 May               July 2005


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


   +-----+---------------------------+-----+---------------------------+
   |  ID | Name                      |  ID | Name                      |
   +-------+-------------------------+-------+-------------------------+
   +-----+---------------------------+-----+---------------------------+
   |     1 128 | octetDeltaCount bgpNextAdjacentAsNumber   |    43 169 | RESERVED destinationIPv6Prefix     |
   |     2 129 | packetDeltaCount bgpPrevAdjacentAsNumber   |    44 170 | sourceIPv4Prefix sourceIPv6Prefix          |
   |     3 130 | observedFlowTotalCount exporterIPv4Address       |    45 171 | destinationIPv4Prefix postOctetTotalCount       |
   |     4 131 | protocolIdentifier exporterIPv6Address       |    46 172 | mplsTopLabelType postPacketTotalCount      |
   |     5 132 | classOfServiceIPv4 droppedOctetDeltaCount    |    47 173 | mplsTopLabelIPv4Address flowKeyIndicator          |
   |     6 133 | tcpControlBits droppedPacketDeltaCount   | 48-51 174 | RESERVED postMCastPacketTotalCount |
   |     7 134 | sourceTransportPort droppedOctetTotalCount    |    52 175 | minimumTtl postMCastOctetTotalCount  |
   |     8 135 | sourceIPv4Address droppedPacketTotalCount   |    53 176 | maximumTtl icmpTypeIPv4              |
   |     9 136 | sourceIPv4Mask flowEndReason             |    54 177 | identificationIPv4 icmpCodeIPv4              |
   |    10 137 | ingressInterface classOfServiceIPv6        |    55 178 | postClassOfServiceIPv4 icmpTypeIPv6              |
   |    11 138 | destinationTransportPort|    56 postClassOfServiceIPv6    | sourceMacAddress 179 | icmpCodeIPv6              |    12
   | destinationIPv4Address 139 |    57 icmpTypeCodeIPv6          | postDestinationMacAddr 180 | udpSourcePort             |    13
   | destinationIPv4Mask 140 |    58 mplsTopLabelIPv6Address   | vlanID 181 | udpDestinationPort        |    14
   | egressInterface 141 |    59 lineCardId                | postVlanId 182 | tcpSourcePort             |    15
   | ipNextHopIPv4Address 142 |    60 portId                    | ipVersion 183 | tcpDestinationPort        |    16
   | bgpSourceAsNumber 143 |    61 meteringProcessId         | RESERVED 184 | tcpSequenceNumber         |    17
   | bgpDestinationAsNumber 144 |    62 exportingProcessId        | ipNextHopIPv6Address 185 | tcpAcknowledgementNumber  |    18
   | bgpNexthopIPv4Address 145 |    63 templateId                | bgpNexthopIPv6Address 186 | tcpWindowSize             |    19
   | postMulticastPacketCount|    64 146 | ipv6OptionHeaders wlanChannelId             | 187 |    20 tcpUrgentPointer          | postMulticastOctetCount
   | 65-69 147 | RESERVED wlanSsid                  | 188 |    21 tcpHeaderLength           | flowEndSysUpTime
   |    70 148 | mplsLabelStackEntry1 flowId                    | 189 |    22 ipHeaderLength            | flowStartSysUpTime
   |    71 149 | mplsLabelStackEntry2 sourceId                  | 190 |    23 packetLengthIPv4          | postOctetDeltaCount
   |    72 150 | mplsLabelStackEntry3 flowStartSeconds          | 191 |    24 payloadLengthIPv6         | postPacketDeltaCount
   |    73 151 | mplsLabelStackEntry4 flowEndSeconds            | 192 |    25 ipTimeToLive              | minimumPacketLength
   |    74 152 | mplsLabelStackEntry5 flowStartMilliSeconds     | 193 |    26 nextHeaderIPv6            | maximumPacketLength
   |    75 153 | flowEndMilliSeconds       | 194 | ipTypeOfService           |
   | 154 | flowStartMicroSeconds     | 195 | ipDiffServCodePoint       |
   | 155 | flowEndMicroSeconds       | 196 | mplsLabelStackEntry6 ipPrecedence              |
   |    27 156 | sourceIPv6Address flowStartNanoSeconds      |    76 197 | mplsLabelStackEntry7 fragmentFlagsIPv4         |
   |    28 157 | destinationIPv6Address flowEndNanoSeconds        |    77 198 | mplsLabelStackEntry8 octetDeltaSumOfSquares    |
   |    29 158 | sourceIPv6Mask flowStartDeltaMicroSeconds| 199 |    78 octetTotalSumOfSquares    | mplsLabelStackEntry9
   | 159 |    30 flowEndDeltaMicroSeconds  | destinationIPv6Mask 200 |    79 mplsTopLabelTtl           | mplsLabelStackEntry10
   | 160 |    31 systemInitTimeMilliSeconds| 201 | flowLabelIPv6 mplsLabelStackSize        |    80
   | destinationMacAddress 161 | flowDurationMilliSeconds  |    32 202 | icmpTypeCodeIPv4 mplsLabelStackDepth       |    81
   | postSourceMacAddress 162 | flowDurationMicroSeconds  |    33 203 | igmpType mplsTopLabelExp           | 82-84
   | RESERVED 163 | observedFlowTotalCount    | 34-35 204 | RESERVED octetDeltaCount           |    85
   | octetTotalCount 164 | ignoredPacketTotalCount   |    36 205 | flowActiveTimeOut postOctetDeltaCount       |    86
   | packetTotalCount 165 | ignoredOctetTotalCount    |    37 206 | flowInactiveTimeout octetTotalCount           |    87
   | RESERVED 165 | ignoredOctetTotalCount    | 38-39 207 | RESERVED headerLengthIPv4          |    88
   | fragmentOffsetIPv4 166 | notSentFLowTotalCount     |    40 208 | exportedOctetTotalCount |89-127 ipv4Options               | RESERVED
   | 167 |    41 notSentPacketTotalCount   | exportedMessageTotalCount| 209 | tcpOptions                |
   |    42 168 | exportedFlowTotalCount notSentOctetTotalCount    | 210 | paddingOneOctet           |
   +-------+-------------------------+-------+-------------------------+
   +-----+---------------------------+-----+---------------------------+





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


5.  Information Elements

   This section describes the Flow attributes of the IPFIX information
   model.  The following list gives an overview 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
   identifiers that are specified in section 5 and extend explicitly
   specifies a different semantics.  This simple rule allows writing all
   Information Elements related to header fields once when the list 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 Element identifiers specified already Elements in [RFC3954].



Quittek, et al.        Expires November 28, 2005               [Page 14]

Internet-Draft          IPFIX groups 7.-9., need to be updated.

5.1  Identifiers

   Information Model                 May 2005


   +-----+---------------------------+-----+---------------------------+
   |  ID | Name                      |  ID | Name                      |
   +-----+---------------------------+-----+---------------------------+
   | 128 | bgpNextAdjacentAsNumber   | 150 | flowStartSeconds          |
   | 129 | bgpPrevAdjacentAsNumber   | 151 | flowEndSeconds            |
   | 130 | exporterIPv4Address       | 152 | flowStartMilliSeconds     |
   | 131 | exporterIPv6Address       | 153 | flowEndMilliSeconds       |
   | 132 | droppedOctetDeltaCount    | 154 | flowStartMicroSeconds     |
   | 133 | droppedPacketDeltaCount   | 155 | flowEndMicroSeconds       |
   | 134 | droppedOctetTotalCount    | 156 | flowStartNanoSeconds      |
   | 135 | droppedPacketTotalCount   | 157 | flowEndNanoSeconds        |
   | 136 | flowEndReason             | 158 | flowStartDeltaMicroSeconds|
   | 137 | classOfServiceIPv6        | 159 | flowEndDeltaMicroSeconds  |
   | 138 | postClassOfServiceIPv6    | 160 | systemInitTimeMilliSeconds|
   | 139 | icmpTypeCodeIPv6          | 161 | flowDurationMilliSeconds  | Elements grouped in the table below are identifying
   components of the IPFIX architecture, of an IPFIX Device, or of the
   IPFIX protocol.  All of them have an integral 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.






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


   +-----+---------------------------+-----+---------------------------+
   | 140  ID | mplsTopLabelIPv6Address Name                      | 162  ID | flowDurationMicroSeconds Name                      |
   +-----+---------------------------+-----+---------------------------+
   | 141 | lineCardId                | 163 | ignoredPacketTotalCount   |
   | 142 | portId                    | 164 | ignoredOctetTotalCount    |
   | 143 | meteringProcessId         | 165
   | notSentFLowTotalCount 142 | portId                    | 144 | exportingProcessId        | 166 | notSentPacketTotalCount   |
   | 145 | templateId                | 167 | notSentOctetTotalCount    |
   | 146 | wlanChannelId             | 168 | destinationIPv6Prefix     |
   | 147 | wlanSsid                  | 169 | sourceIPv6Prefix  10 | ingressInterface          | 148 | flowId                    | 170 | postOctetTotalCount       |
   | 149  14 | sourceId egressInterface           | 171 145 | postPacketTotalCount templateId                |
   |     |                           | 172 149 | flowKeyIndicator sourceId                  |
   +-----+---------------------------+-----+---------------------------+


5.1.1  lineCardId

   Description:
      A locally unique identifier of a line card at an 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 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

   Description:
      The index of the IP interface (ifIndex) where packets of this Flow
      are being received.
   Abstract Data Type: unsigned32
   Data Type Semantics: identifier
   ElementId: 10
   Status: current
   Reference: See RFC 2863 for the definition of the ifIndex object.

5.1.4  egressInterface






Quittek, et al.        Expires November 28, 2005       draft-ietf-ipfix-info-08.txt             [Page 15] 18]

Internet-Draft           IPFIX Information Model                 May               July 2005


5.  Information Elements

   This section describes the flow attributes


   Description:
      The index 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 interface (ifIndex) where packets of this Flow Properties

   The Information Elements that
      are derived from fields being sent.
   Abstract Data Type: unsigned32
   Data Type Semantics: identifier
   ElementId: 14
   Status: current
   Reference: See RFC 2863 for the definition of packets or
   from packet treatment, such as the ifIndex object.

5.1.5  meteringProcessId

   Description:
      A locally unique identifier of a Metering Process at an IPFIX
      Device.  Typically, this Information Elements in groups
   3.-6., can serve as Flow Keys Element is used for mapping packets to flows.  But
   they also may contain values that are not constant for a single flow.
   For example a flow using a certain source IPv4 address as flow key
   has sourceIPv4Address as constant property but may have
   destinationIPv4Address as a property that changes from packet to
   packet.

   For such limiting
      the scope of other Information Elements that are derived from fields Elements.
   Abstract Data Type: unsigned32
   Data Type Semantics: identifier
   ElementId: 143
   Status: current

5.1.6  exportingProcessId

   Description:
      A locally unique identifier of packets
   or from packet treatment, the an Exporting Process at an IPFIX information model makes
      Device.  Typically, this Information Element is used for limiting
      the
   general assumption scope of other Information Elements.
   Abstract Data Type: unsigned32
   Data Type Semantics: identifier
   ElementId: 144
   Status: current

5.1.7  flowId

   Description:
      An identifier of a Flow that their value is determined by the first packet
   observed locally unique to an Exporting
      Process.  Typically, this Information Element is used for limiting
      the corresponding Flow, unless the description scope of the other Information Element explicitly specifies a different semantics.  This
   simple rule allows writing all Elements.
   Abstract Data Type: unsigned32
   Data Type Semantics: identifier
   ElementId: 148
   Status: current

5.1.8  templateId








Quittek, et al.       draft-ietf-ipfix-info-08.txt             [Page 19]

Internet-Draft           IPFIX Information Elements related to header
   fields once when the first packet of the flow is observed.  For
   further observed packets Model               July 2005


   Description:
      An identifier of the same flow, only flow properties a Template that
   depend on more than one packet, such as the Information Elements in
   groups 7.-9., need is locally unique to be updated.

5.1  Identifiers an Exporting
      Process.  Typically, this Information Elements grouped in Element is used for limiting
      the table below are identifying
   components scope of the IPFIX architecture, other Information Elements.
   Abstract Data Type: unsigned32
   Data Type Semantics: identifier
   ElementId: 145
   Status: current

5.1.9  sourceId

   Description:
      An identifier of an IPFIX device, or of the
   IPFIX protocol.  All of them have Observation Domain that is locally unique to
      an integral data type and data type
   semantics "identifier" as described in section 3.2.4. Exporting Process.  Typically, some of them are this Information Element is used
      for limiting scopes the scope of other Information Elements.  However, also other
   Abstract Data Type: unsigned32
   Data Type Semantics: identifier
   ElementId: 149
   Status: current

5.2  Metering and Exporting Process Properties

   Information Elements MAY
   be used for limiting scopes.  Note also that all in this section describe static and dynamic
   properties of the Metering Process and/or the Exporting Process.  The
   set of these Information Elements is listed in the table below MAY be used for other purposes than limiting scopes.



Quittek, et al.        Expires November 28, 2005               [Page 16]

Internet-Draft          IPFIX Information Model                 May 2005

   +-----+---------------------------+-----+---------------------------+
   |  ID | Name                      |  ID | Name                      |
   +-----+---------------------------+-----+---------------------------+
   | 141 130 | lineCardId exporterIPv4Address       | 143 164 | meteringProcessId ignoredPacketTotalCount   |
   | 142 131 | portId exporterIPv6Address       | 144 165 | exportingProcessId ignoredOctetTotalCount    |
   |  10  41 | ingressInterface exportedMessageTotalCount | 148 166 | flowId notSentFLowTotalCount     |
   |  14  40 | egressInterface exportedOctetTotalCount   | 145 167 | templateId notSentPacketTotalCount   |
   |  42 | exportedFlowTotalCount    | 149 168 | sourceId notSentOctetTotalCount    |
   | 163 | observedFlowTotalCount    | 173 | flowKeyIndicator          |
   +-----+---------------------------+-----+---------------------------+


5.1.1  lineCardId


5.2.1  exporterIPv4Address

   Description:
      A locally unique
      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.







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


   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

   Description:
      The total number of 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.
   Abstract Data Type: unsigned64
   Data Type Semantics: totalCounter
   ElementId: 41
   Status: current
   Units: messages

5.2.4  exportedOctetTotalCount

   Description:
      The total number of octets that the Exporting Process successfully
      sent since the Exporting Process (re-)initialization to the
      Collecting Process receiving a line card at an IPFIX Device
      hosting an Observation Point.  Typically, report that contains this
      Information Element.  The value of this Information Element is used for limiting
      calculated by summing up the scope IPFIX Message header length values of other
      all IPFIX Messages that were successfully sent to the Collecting
      Process receiving a report that contains this Information Elements. Element.
   Abstract Data Type: unsigned32 unsigned64
   Data Type Semantics: identifier totalCounter
   ElementId: 141 40
   Status: current

5.1.2  portId
   Units: octets

5.2.5  exportedFlowTotalCount





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


   Description:
      A locally unique identifier
      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 line port at an IPFIX Device
      hosting an Observation Point.  Typically, report
      that contains this Information Element
      is used for limiting the scope of other Information Elements. Element.
   Abstract Data Type: unsigned32 unsigned64
   Data Type Semantics: identifier totalCounter
   ElementId: 142 42
   Status: current

5.1.3  ingressInterface
   Units: Flows

5.2.6  observedFlowTotalCount

   Description:
      The index total number of Flows observed in the IP interface (ifIndex) where packets of Observation Domain since
      the Metering Process (re-)initialization for this Flow
      are being received. Observation
      Point.
   Abstract Data Type: unsigned32 unsigned64
   Data Type Semantics: identifier totalCounter
   ElementId: 10 3
   Status: current
   Reference: See RFC 2863 for
   Units: Flows

5.2.7  ignoredPacketTotalCount

   Description:
      The total number of observed IP packets that the definition Metering Process
      did not process since the (re-)initialization of the ifIndex object.

5.1.4  egressInterface






Quittek, et al.        Expires November 28, 2005               [Page 17]

Internet-Draft          IPFIX Information Model                 May 2005 Metering
      Process.
   Abstract Data Type: unsigned64
   Data Type Semantics: totalCounter
   ElementId: 164
   Status: current
   Units: packets

5.2.8  ignoredOctetTotalCount

   Description:
      The index total number of the octets in observed IP interface (ifIndex) where packets that the
      Metering Process did not process since the (re-)initialization of this Flow
      are being sent.
      the Metering Process.
   Abstract Data Type: unsigned32 unsigned64
   Data Type Semantics: identifier totalCounter
   ElementId: 14 165







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


   Status: current
   Reference: See RFC 2863 for the definition of the ifIndex object.

5.1.5  meteringProcessId
   Units: octets

5.2.9  notSentFlowTotalCount

   Description:
      A locally unique identifier
      The total number of a Flow Records that were generated by the
      Metering Process at an IPFIX
      Device.  Typically, this Information Element is used for limiting and but dropped by the scope Metering Process or by the
      Exporting Process instead of other Information Elements. sending it to the Collecting Process.
      There are several potential reasons for this including resource
      shortage and special Flow export policies.
   Abstract Data Type: unsigned32 unsigned64
   Data Type Semantics: identifier totalCounter
   ElementId: 143 166
   Status: current

5.1.6  exportingProcessId
   Units: Flows

5.2.10  notSentPacketTotalCount

   Description:
      A locally unique identifier
      The total number of an Exporting packets in Flow Records that were generated by
      the Metering Process at an IPFIX
      Device.  Typically, this Information Element is used for limiting and but dropped by the scope Metering Process or by
      the Exporting Process instead of other Information Elements. sending it to the Collecting
      Process.  There are several potential reasons for this including
      resource shortage and special Flow export policies.
   Abstract Data Type: unsigned32 unsigned64
   Data Type Semantics: identifier totalCounter
   ElementId: 144 167
   Status: current

5.1.7  flowId
   Units: packets

5.2.11  notSentOctetTotalCount

   Description:
      An identifier
      The total number of a octets in packets in Flow Records that is locally unique to an Exporting
      Process.  Typically, this Information Element is used for limiting were
      generated by the scope Metering Process and but dropped by the Metering
      Process or by the Exporting Process instead of other Information Elements. sending it to the
      Collecting Process.  There are several potential reasons for this
      including resource shortage and special Flow export policies.
   Abstract Data Type: unsigned32 unsigned64
   Data Type Semantics: identifier totalCounter
   ElementId: 148 168
   Status: current

5.1.8  templateId

   Description:
   Units: octets

5.2.12  flowKeyIndicator





Quittek, et al.        Expires November 28, 2005       draft-ietf-ipfix-info-08.txt             [Page 18] 23]

Internet-Draft           IPFIX Information Model                 May               July 2005


      An identifier


   Description:
      This set of a Template that is locally unique to an Exporting
      Process.  Typically, this Information Element bit fields is used for limiting marking the scope of other Information Elements.
   Abstract Data Type: unsigned32
   Data Type Semantics: identifier
   ElementId: 145
   Status: current

5.1.9  sourceId

   Description:
      An identifier
      Elements of an Observation Domain a Data Record that is locally unique to serve as Flow Key. Each bit
      represents an Exporting Process.  Typically, this Information Element in the Data Record with the n-th
      bit representing the n-th Information Element.  A set bit with
      value 1 indicates that the corresponding Information element is used
      for limiting a
      Flow Key of the scope reported Flow.  A value of other 0 indicates that this
      is not the case.  If the Data Record contains more than 64
      Information Elements. 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: unsigned32 unsigned64
   Data Type Semantics: identifier flags
   ElementId: 149 173
   Status: current

5.2  Metering and Exporting Process Properties

5.3  IP Header Fields

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

   +-----+---------------------------+-----+---------------------------+
   |  ID | Name                      |  ID | Name                      |
   +-----+---------------------------+-----+---------------------------+
   | 130  60 | exporterIPv4Address ipVersion                 | 163 194 | ignoredPacketTotalCount ipClassOfService          |
   | 131   8 | exporterIPv6Address sourceIPv4Address         | 164 195 | ignoredOctetTotalCount ipDiffServeCodePoint      |
   |  41  27 | exportedMessageTotalCount sourceIPv6Address         | 165 196 | notSentFLowTotalCount ipPrecedence              |
   |  40   9 | exportedOctetTotalCount sourceIPv4Mask            | 166   5 | notSentPacketTotalCount classOfServiceIPv4        |
   |  42  29 | exportedFlowTotalCount sourceIPv6Mask            | 167 137 | notSentOctetTotalCount classOfServiceIPv6        |
   |   3  44 | observedFlowTotalCount sourceIPv4Prefix          |  55 | postClassOfServiceIPv4    |
   | 170 | sourceIPv6Prefix          | 138 | postClassOfServiceIPv6    |
   |  12 | destinationIPv4Address    |  31 | flowLabelIPv6             |
   |  28 | destinationIPv6Address    |  54 | identificationIPv4        |
   |  13 | destinationIPv4Mask       |  88 | fragmentOffsetIPv4        |
   |  30 | destinationIPv6Mask       | 197 | fragmentFlagsIPv4         |
   |  45 | destinationIPv4Prefix     | 189 | ipHeaderLength            |
   | 169 | destinationIPv6Prefix     | 207 | headerLengthIPv4          |
   | 192 | ipTimeToLive              | 190 | packetLengthIPv4          |
   |   4 | protocolIdentifier        | 191 | payloadLengthIPv6         |
   | 193 | nextHeaderIPv6            | 172     | flowKeyIndicator                           |
   +-----+---------------------------+-----+---------------------------+


5.2.1  exporterIPv4Address






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


5.3.1  ipVersion

   Description: The IPv4 address used by the Exporting Process.  This is used by IP version field in the Collector to identify IP packet header.
   Abstract Data Type: octet
   Data Type Semantics: identifier
   ElementId: 60
   Status: current
   Reference:
      See RFC 791 for a definition of the Exporter version field in cases where the identity IPv4
      packet header.  See RFC 2460 for a definition of the Exporter may have been obscured by version field
      in the use of a proxy. 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:
      The IPv4 source address in the IP packet header.
   Abstract Data Type: ipv4Address
   Data Type Semantics: identifier






Quittek, et al.        Expires November 28, 2005               [Page 19]

Internet-Draft          IPFIX Information Model                 May 2005
   ElementId: 130 8
   Status: current

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

5.3.3  sourceIPv6Address

   Description:
      The IPv6 source 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. IP packet header.
   Abstract Data Type: ipv6Address
   Data Type Semantics: identifier
   ElementId: 131 27
   Status: current

5.2.3  exportedMessageTotalCount

5.3.4  sourceIPv4Mask

   Description:
      The total number of IPFIX Messages contiguous bits that are relevant in the Exporting Process
      successfully sent since the Exporting Process (re-)initialization
      to the Collecting Process receiving a report that contains this
      sourceIPv4Prefix Information Element.
   Abstract Data Type: unsigned64
   Data Type Semantics: totalCounter octet
   ElementId: 41 9
   Status: current
   Units: messages

5.2.4  exportedOctetTotalCount bits
   Range: The valid range is 0-32.

5.3.5  sourceIPv6Mask





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


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

5.3.6  sourceIPv4Prefix

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

5.3.7  sourceIPv6Prefix

   Description:
      IPv6 source address prefix.
   Abstract Data Type: ipv4Address
   ElementId: 170
   Status: current

5.3.8  destinationIPv4Address

   Description:
      The IPv4 destination address in the IPFIX Message header length values IP packet header.
   Abstract Data Type: ipv4Address
   Data Type Semantics: identifier
   ElementId: 12
   Status: current
   Reference: See RFC 791 for the definition of
      all IPFIX messages that were successfully sent to the Collecting
      Process receiving a report that contains this Information Element. IPv4 destination
      address field.

5.3.9  destinationIPv6Address

   Description:
      The IPv6 destination address in the IP packet header.
   Abstract Data Type: unsigned64 ipv6Address
   Data Type Semantics: totalCounter identifier
   ElementId: 40 28
   Status: current
   Units: octets

5.2.5  exportedFlowTotalCount

5.3.10  destinationIPv4Mask





Quittek, et al.        Expires November 28, 2005       draft-ietf-ipfix-info-08.txt             [Page 20] 26]

Internet-Draft           IPFIX Information Model                 May               July 2005


   Description:
      The total number of Flows Records reported contiguous bits that are relevant in the Exporting
      Process successfully sent as Data Records since the Exporting
      Process (re-)initialization to the Collecting Process receiving a
      report that contains this
      destinationIPv4Prefix Information Element.
   Abstract Data Type: unsigned64
   Data Type Semantics: totalCounter octet
   ElementId: 42 13
   Status: current
   Units: Flows

5.2.6  observedFlowTotalCount bits
   Range: The valid range is 0-32.

5.3.11  destinationIPv6Mask

   Description:
      The total number of Flows observed contiguous bits that are relevant in the Observation Domain since
      the Metering Process (re-)initialization for this Observation
      Point.
      destinationIPv6Prefix Information Element.
   Abstract Data Type: unsigned64
   Data Type Semantics: totalCounter octet
   ElementId: 3 30
   Status: current
   Units: Flows

5.2.7  ignoredPacketTotalCount

   Description: bits
   Range: The total number of observed IP packets that the Metering Process
      did not process. valid range is 0-128.

5.3.12  destinationIPv4Prefix

   Description:
      IPv4 destination address prefix.
   Abstract Data Type: unsigned64
   Data Type Semantics: totalCounter ipv4Address
   ElementId: 163 45
   Status: current
   Units: packets

5.2.8  ignoredOctetTotalCount

5.3.13  destinationIPv6Prefix

   Description:
      The total number of octets in observed IP packets that the
      Metering Process did not process.
      IPv6 destination address prefix.
   Abstract Data Type: unsigned64
   Data Type Semantics: totalCounter ipv4Address
   ElementId: 164 169
   Status: current
   Units: octets

5.2.9  notSentFlowTotalCount





Quittek, et al.        Expires November 28, 2005               [Page 21]

Internet-Draft          IPFIX Information Model                 May 2005

5.3.14  ipTimeToLive

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







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


   ElementId: 165 192
   Status: current
   Units: Flows

5.2.10  notSentPacketTotalCount 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

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

5.2.11  notSentOctetTotalCount
   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 total number value of octets in  packets in Flow Records that were
      generated by the Metering Process and but dropped by Next Header field of the Metering
      Process or by IPv6 header.  The value
      identifies the Exporting Process instead type of sending it to the
      Collecting Process.  There following IPv6 extension header or of
      the following IP payload.  Valid values are several potential reasons for this
      including resource shortage and special Flow export policies. defined in the IANA
      Protocol Numbers registry.
   Abstract Data Type: unsigned64
   Data Type Semantics: totalCounter octet
   ElementId: 167 193
   Status: current
   Units: octets

5.2.12  flowKeyIndicator

   Description:
      This set of bit fields is used
   Reference: See RFC 2460 for marking the Information
      Elements definition 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
      value 1 indicates that IPv6 Next Header
      field.  See the corresponding Information element is a list of protocol numbers assigned by IANA at
      http://www.iana.org/assignments/protocol-numbers.

5.3.17  ipClassOfService

   Description:







Quittek, et al.        Expires November 28, 2005       draft-ietf-ipfix-info-08.txt             [Page 22] 28]

Internet-Draft           IPFIX Information Model                 May               July 2005


      Flow Key of


      For IPv4 packets, this is the reported Flow.  A value of 0 indicates that the TOS field in the IPv4
      packet header.  For IPv6 packets, this is not the case.  If value of the Traffic
      Class field in the IPv6 packet header.
   Abstract Data Record contains more than 64 Type: octet
   Data Type Semantics: identifier
   ElementId: 194
   Status: current
   Reference: See RFC 791 for the definition of the IPv4 TOS field.  See
      RFC 2460 for the definition of the IPv6 Traffic Class field.

5.3.18  ipDiffServeCodePoint

   Description:
      The value of a Differentiated Services Code Point (DSCP).  The
      DSCP value is encoded in the first 6 bits of the IPv4 TOS field or
      the IPv6 Traffic class field, respectively.
      For a particular Flow or packet, this Information Elements, Element may have
      the corresponding Template SHOULD be
      designed such same value as Information Element ipClassOfService.  However,
      the bits that all Flow Keys are among not used by the first 64
      Information Elements, because Differentiated Services Field
      for specifying a DiffServ Code Point (DSCP) are to be ignored.
      This is relevant when the flowKeyIndicator only contains
      64 bits.  If DSCP serves as flow key.  In this case
      the Data Record contains less than 64 Information
      Elements, then key consists of the first 6 bits.  The remaining 2 bits in the flowKeyIndicator for which no
      corresponding Information Element exists SHOULD have are
      not part of the value 0. flow key.
   Abstract Data Type: unsigned64 octet
   Data Type Semantics: flags identifier
   ElementId: 172 195
   Status: current

5.3  IP Header Fields

   Information Elements in this section indicate values
   Reference: See RFC 791 for the definition of the IPv4 TOS field.  See
      RFC 2460 for the definition of the IPv6 Traffic Class field.  See
      RFC 2474 for the definition of the Differentiated Services Field.

5.3.19  ipPrecedence

   Description:
      The value of the IP header
   fields or are derived from Precedence.  The IP header field values Precedence value is
      encoded in combination with
   further information.

   +-----+---------------------------+-----+---------------------------+
   |  ID | Name                      |  ID | Name                      |
   +-----+---------------------------+-----+---------------------------+
   |  60 | ipVersion                 |  45 | destinationIPv4Prefix     |
   |   8 | sourceIPv4Address         | 168 | destinationIPv6Prefix     |
   |  27 | sourceIPv6Address         | the first 3 bits of the IPv4 TOS field or the IPv6
      Traffic class field, respectively.
      For a particular Flow or packet, this Information Element may have
      the same value as Information Element ipClassOfService.  However,
      the last 5 | classOfServiceIPv4        |
   |   9 | sourceIPv4Mask            | 137 | classOfServiceIPv6        |
   |  29 | sourceIPv6Mask            |  55 | postClassOfServiceIPv4    |
   |  44 | sourceIPv4Prefix          | 138 | postClassOfServiceIPv6    |
   | 169 | sourceIPv6Prefix          |  31 | flowLabelIPv6             |
   |  12 | destinationIPv4Address    |  54 | identificationIPv4        |
   |  28 | destinationIPv6Address    |   4 | protocolIdentifier        |
   |  13 | destinationIPv4Mask       |  88 | fragmentOffsetIPv4        |
   |  30 | destinationIPv6Mask       |     |                           |
   +-----+---------------------------+-----+---------------------------+


5.3.1  ipVersion

   Description: bits are to be ignored.  This is relevant when the
      ipPrecedence serves as flow key.  In this case the key consists of
      the first 3 bits.  The remaining 5 bits are not part of the flow
      key.
   Abstract Data Type: octet







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


   Data Type Semantics: identifier
   ElementId: 196
   Status: current
   Reference: See RFC 791 for the definition of the IPv4 TOS field and
      the IP version Precedence.  See RFC 2460 for the definition of the IPv6
      Traffic Class field.

5.3.20  classOfServiceIPv4

   Description:
      The value of the TOS field in the IP IPv4 packet header.
   Abstract Data Type: octet
   Data Type Semantics: identifier
   ElementId: 60 5
   Status: current
   Reference: See RFC 791 for a the definition of the version IPv4 TOS field.

5.3.21  classOfServiceIPv6

   Description:
      The value of the Traffic Class field in the IPv4 IPv6 packet header.
   Abstract Data Type: octet
   Data Type Semantics: identifier
   ElementId: 137
   Status: current
   Reference: See RFC 2460 for a the definition of the version IPv6 Traffic Class
      field.

5.3.22  postClassOfServiceIPv4

   Description:
      The value of the IPv4 TOS field in the IPv6 IP packet header.  Additional information on defined
      version numbers header after
      packet treatment by a middlebox function.  This packet header can
      not necessarily be found observed at the Observation Point of this Flow.
   Abstract Data Type: octet
   Data Type Semantics: identifier
   ElementId: 55
   Status: current
   Reference: See RFC 791 for the definition of the IPv4 TOS field.  See
      RFC 3234 for the definition of middleboxes.

5.3.23  postClassOfServiceIPv6

   Description:







Quittek, et al.        Expires November 28, 2005       draft-ietf-ipfix-info-08.txt             [Page 23] 30]

Internet-Draft           IPFIX Information Model                 May               July 2005


      http://www.iana.org/assignments/version-numbers.

5.3.2  sourceIPv4Address


      The value of the IPv6 traffic class field in the IP packet header
      after packet treatment by a middlebox function.  This packet
      header can not necessarily be observed at the Observation Point of
      this Flow.
   Abstract Data Type: octet
   Data Type Semantics: identifier
   ElementId: 138
   Status: current
   Reference: See RFC 2460 for the definition of the IPv6 traffic class
      field.

5.3.24  flowLabelIPv6

   Description:
      The IPv4 source address value of the IPv6 Flow Label field in the IP packet header.
   Abstract Data Type: ipv4Address unsigned32
   Data Type Semantics: identifier
   ElementId: 8 31
   Status: current
   Reference: See RFC 791 2460 for the a definition of the IPv4 source address
      field.

5.3.3  sourceIPv6Address flow label field in
      the IPv6 packet header.

5.3.25  identificationIPv4

   Description:
      The IPv6 source address value of the IPv4 packet identification field in the IP packet
      header.
   Abstract Data Type: ipv6Address unsigned16
   Data Type Semantics: identifier
   ElementId: 27 54
   Status: current

5.3.4  sourceIPv4Mask

   Description:
      The number
   Reference: See RFC 791 for the definition of contiguous bits that are relevant in the
      sourceIPv4Prefix Information Element.
   Abstract Data Type: octet
   ElementId: 9
   Status: current
   Units: bits
   Range: The valid range is 0-32.

5.3.5  sourceIPv6Mask IPv4 identification
      field.

5.3.26  fragmentOffsetIPv4

   Description:
      The number value of contiguous bits that are relevant the IPv4 fragment offset field in the
      sourceIPv6Prefix Information Element. IP packet
      header.
   Abstract Data Type: octet unsigned16
   Data Type Semantics: identifier
   ElementId: 29 88
   Status: current
   Units: bits
   Range: The valid range is 0-128.

5.3.6  sourceIPv4Prefix
   Reference:







Quittek, et al.        Expires November 28, 2005       draft-ietf-ipfix-info-08.txt             [Page 24] 31]

Internet-Draft           IPFIX Information Model                 May               July 2005


      See RFC 791 for the specification of the IPv4 fragment offset.

5.3.27  fragmentFlagsIPv4

   Description:
      The value of the fragmentation bits in the IPv4 source address prefix. 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   6   7
           +---+---+---+---+---+---+---+---+
           |   | D | M | D | D | D | D | D |
           | 0 | F | F | C | C | C | C | C |
           +---+---+---+---+---+---+---+---+

   Abstract Data Type: ipv4Address
   ElementId: 44
   Status: current

5.3.7  sourceIPv6Prefix

   Description:
      IPv6 source address prefix.
   Abstract octet
   Data Type: ipv4Address Type Semantics: flags
   ElementId: 169 197
   Status: current

5.3.8  destinationIPv4Address
   Reference:
      See RFC 791 for the specification of the IPv4 fragment flags.

5.3.28  ipHeaderLength

   Description:
      The IPv4 destination address in length of the IP packet header.  For IPv6, the value of this
      Information Element is 40.
   Abstract Data Type: ipv4Address
   Data Type Semantics: identifier octet
   ElementId: 12 189
   Status: current
   Units: octets
   Reference:
      See RFC 791 791 for the specification of the IPv4 header.  See RFC
      2460 for the definition specification of the IPv4 destination
      address field.

5.3.9  destinationIPv6Address

   Description:
      The IPv6 destination address in the IP packet header.
   Abstract Data Type: ipv6Address
   Data Type Semantics: identifier
   ElementId: 28
   Status: current

5.3.10  destinationIPv4Mask

5.3.29  headerLengthIPv4

   Description:
      The number length of contiguous bits that are relevant in the
      destinationIPv4Prefix Information Element. IPv4 header.
   Abstract Data Type: octet
   ElementId: 13
   Status: current
   Units: bits
   Range: The valid range is 0-32.

5.3.11  destinationIPv6Mask 207







Quittek, et al.        Expires November 28, 2005       draft-ietf-ipfix-info-08.txt             [Page 25] 32]

Internet-Draft           IPFIX Information Model                 May               July 2005


   Description:
      The number of contiguous bits that are relevant in the
      destinationIPv6Prefix Information Element.
   Abstract Data Type: octet
   ElementId: 30


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

5.3.12  destinationIPv4Prefix

   Description: octets
   Reference:
      See RFC 791 for the specification of the IPv4 destination address prefix.
   Abstract Data Type: ipv4Address
   ElementId: 45
   Status: current

5.3.13  destinationIPv6Prefix

   Description:
      IPv6 destination address prefix.
   Abstract Data Type: ipv4Address
   ElementId: 168
   Status: current

5.3.14  classOfServiceIPv4 header.

5.3.30  packetLengthIPv4

   Description:
      The value total length of the IPv4 TOS field in the IP packet header. packet.
   Abstract Data Type: octet
   Data Type Semantics: identifier unsigned16
   ElementId: 5 190
   Status: current
   Units: octets
   Reference:
      See RFC 791 for the definition specification of the IPv4 TOS field.

5.3.15  classOfServiceIPv6 total length.

5.3.31  payloadLengthIPv6

   Description:
      The value length of the IPv6 traffic class field in payload, i.e., the rest of the IP 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.  For payload lengths up to 65535,
      the value of this Information Element is given by the payload
      length field of the IPv6 header.  For payload lengths greater than
      65535, the value of this Information Element is given by the
      content of the IPv6 jumbo payload option.
   Abstract Data Type: octet
   Data Type Semantics: identifier unsigned32
   ElementId: 137 191
   Status: current
   Reference:
      See RFC 2460 for the definition of specification of the IPv6 payload length.
      See RFC 2675 for the specification of the IPv6 jumbo payload
      length.

5.4  Transport Header Fields

   The set of Information Elements related to transport header fields
   and length includes the Information Elements listed in the IPv6 traffic class
      field. table
   below.











Quittek, et al.        Expires November 28, 2005       draft-ietf-ipfix-info-08.txt             [Page 26] 33]

Internet-Draft           IPFIX Information Model                 May               July 2005


5.3.16  postClassOfServiceIPv4


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


5.4.1  sourceTransportPort

   Description:
      The value of source port identifier in the IPv4 TOS field transport header.  For the
      transport protocols UDP, TCP and SCTP this is the source port
      number given in the IP packet header after
      packet treatment by a middlebox function. respective header.  This field MAY also be
      used for future transport protocols that have 16 bit source port
      identifiers.
   Abstract Data Type: octet unsigned16
   Data Type Semantics: identifier
   ElementId: 55 7
   Status: current
   Reference:
      See RFC 791 768 for the definition of the IPv4 TOS UDP source port field.  See
      RFC 3234 793 for the definition of middleboxes.

5.3.17  postClassOfServiceIPv6

   Description:
      The value of the IPv6 traffic class field in the IP packet header
      after packet treatment by a middlebox function.
   Abstract Data Type: octet
   Data Type Semantics: identifier
   ElementId: 138
   Status: current
   Reference: TCP source port field.  See RFC 2460
      2960 for the definition of the IPv6 traffic class
      field.

5.3.18  flowLabelIPv6 SCTP.
      Additional information on defined UDP and TCP port numbers can be
      found at http://www.iana.org/assignments/port-numbers.

5.4.2  destinationTransportPort

   Description:
      The value of destination port identifier in the IPv6 Flow Label field transport header.  For the
      transport protocols UDP, TCP and SCTP this is the destination port
      number given in the IP packet respective header.  This field MAY also be
      used for future transport protocols that have 16 bit destination
      port identifiers.
   Abstract Data Type: unsigned32 unsigned16
   Data Type Semantics: identifier







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


   ElementId: 31 11
   Status: current
   Reference:
      See RFC 2460 768 for a the definition of the flow label field in UDP source port field.  See
      RFC 793 for the IPv6 packet header.

5.3.19  identificationIPv4

   Description:
      The value definition of the IPv4 packet identification field TCP source port field.  See RFC
      2960 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.4.3  udpSourcePort

   Description: The source port identifier in the IP packet UDP header.
   Abstract Data Type: unsigned16
   Data Type Semantics: identifier
   ElementId: 54 180
   Status: current
   Reference: See RFC 791 768 for the definition of the IPv4 identification UDP source port
      field.





Quittek, et al.        Expires November 28, 2005               [Page 27]

Internet-Draft          IPFIX Information Model                 May 2005


5.3.20  protocolIdentifier  Additional information on defined UDP port numbers can be
      found at http://www.iana.org/assignments/port-numbers.

5.4.4  udpDestinationPort

   Description: The value of the protocol number destination port identifier in the IP packet UDP 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: octet unsigned16
   Data Type Semantics: identifier
   ElementId: 4 181
   Status: current
   Reference: See RFC 791 for the specification of the IPv4 protocol field.  See
      RFC 2460 768 for the specification definition of the IPv6 protocol UDP source port
      field.  See
      list of protocol  Additional information on defined UDP port numbers assigned by IANA can be
      found at
      http://www.iana.org/assignments/protocol-numbers.

5.3.21  fragmentOffsetIPv4 http://www.iana.org/assignments/port-numbers.

5.4.5  tcpSourcePort

   Description: The value of the IPv4 fragment offset field source port identifier in the IP packet TCP header.
   Abstract Data Type: unsigned16
   Data Type Semantics: identifier
   ElementId: 88 182
   Status: current
   Reference: See RFC 791 793 for the specification of the IPv4 fragment offset.

5.4  Transport Header Fields

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

   +-----+---------------------------+-----+---------------------------+
   |  ID | Name                      |  ID | Name                      |
   +-----+---------------------------+-----+---------------------------+
   |   7 | sourceTransportPort       |  32 | icmpTypeCodeIPv4          |
   |  11 | destinationTransportPort  | 139 | icmpTypeCodeIPv6          |
   |     |                           |  33 | igmpType                  |
   +-----+---------------------------+-----+---------------------------+ TCP source port
      field.  Additional information on defined TCP port numbers can be
      found at http://www.iana.org/assignments/port-numbers.

5.4.6  tcpDestinationPort








Quittek, et al.        Expires November 28, 2005       draft-ietf-ipfix-info-08.txt             [Page 28] 35]

Internet-Draft           IPFIX Information Model                 May               July 2005


5.4.1  sourceTransportPort


   Description: The source destination 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.
   Abstract Data Type: unsigned16
   Data Type Semantics: identifier
   ElementId: 7 183
   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 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.4.2  destinationTransportPort

5.4.7  tcpSequenceNumber

   Description: The destination port identifier sequence number in the transport TCP header.  For
   Abstract Data Type: unsigned32
   ElementId: 184
   Status: current
   Reference: See RFC 793 for the
      transport protocols UDP, TCP and SCTP this is definition of the destination port TCP sequence number.

5.4.8  tcpAcknowledgementNumber

   Description: The acknowledgement number given in the respective TCP header.  This
   Abstract Data Type: unsigned32
   ElementId: 185
   Status: current
   Reference: See RFC 793 for the definition of the TCP acknowledgement
      number.

5.4.9  tcpWindowSize

   Description: The window field MAY also be
      used in the TCP header.
   Abstract Data Type: unsigned16
   ElementId: 186
   Status: current
   Reference: See RFC 793 for future transport protocols that have 16 bit destination
      port identifiers. the definition of the TCP window field.

5.4.10  tcpUrgentPointer

   Description: The urgent pointer in the TCP header.
   Abstract Data Type: unsigned16
   Data Type Semantics: identifier
   ElementId: 11 187
   Status: current
   Reference: See RFC 768 793 for the definition of the UDP source port field.  See
      RFC 793 for the definition TCP urgent pointer.

5.4.11  tcpHeaderLength








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


   Description: The length of the TCP source port field. header.
   Abstract Data Type: unsigned16
   ElementId: 188
   Status: current
   Units: octets
   Reference: See RFC
      2960 793 for the definition of SCTP.
      Additional information on defined UDP and the TCP port numbers can be
      found at http://www.iana.org/assignments/port-numbers.

5.4.3 header.

5.4.12  icmpTypeCodeIPv4

   Description:
      Type and Code of the IPv4 ICMP message.  The combination of both
      values is reported as (ICMP type * 256) + ICMP code.
   Abstract Data Type: unsigned16
   Data Type Semantics: identifier






Quittek, et al.        Expires November 28, 2005               [Page 29]

Internet-Draft          IPFIX Information Model                 May 2005
   ElementId: 32
   Status: current
   Reference: See RFC 792 for a definition of the IPv4 ICMP type and
      code fields.

5.4.4

5.4.13  icmpTypeIPv4

   Description:
      Type of the IPv4 ICMP message.
   Abstract Data Type: octet
   Data Type Semantics: identifier
   ElementId: 176
   Status: current
   Reference: See RFC 792 for a definition of the IPv4 ICMP type field.

5.4.14  icmpCodeIPv4

   Description:
      Code of the IPv4 ICMP message.
   Abstract Data Type: octet
   Data Type Semantics: identifier
   ElementId: 177
   Status: current
   Reference: See RFC 792 for a definition of the IPv4 ICMP code field.

5.4.15  icmpTypeCodeIPv6

   Description:
      Type and Code of the IPv6 ICMP message.  The combination of both
      values is reported as (ICMP type * 256) + ICMP code.







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


   Abstract Data Type: unsigned16
   Data Type Semantics: identifier
   ElementId: 139
   Status: current
   Reference: See RFC 2463 for a definition of the IPv6 ICMP type and
      code fields.

5.4.5

5.4.16  icmpTypeIPv6

   Description:
      Type of the IPv6 ICMP message.
   Abstract Data Type: octet
   Data Type Semantics: identifier
   ElementId: 178
   Status: current
   Reference: See RFC 2463 for a definition of the IPv6 ICMP type field.

5.4.17  icmpCodeIPv6

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

5.4.18  igmpType

   Description: The type field of the IGMP message.
   Abstract Data Type: octet
   Data Type Semantics: identifier
   ElementId: 33
   Status: current
   Reference: See RFC 2236 for a definition of the IGMP type field.

5.5  Sub-IP Header Fields

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











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


   +-----+---------------------------+-----+---------------------------+
   |  ID | Name                      |  ID | Name                      |
   +-----+---------------------------+-----+---------------------------+
   |  56 | sourceMacAddress          |  70 | mplsLabelStackEntry1 mplsTopLabelEntry         |
   |  57 | postDestinationMacAddr    |  71 | mplsLabelStackEntry2      |
   |  58 | vlanId                    |  72 | mplsLabelStackEntry3      |
   |  59 | postVlanId                |  73 | mplsLabelStackEntry4      |
   |  80 | destinationMacAddress     |  74 | mplsLabelStackEntry5      |
   |  81 | postSourceMacAddress      |  75 | mplsLabelStackEntry6      |
   | 146 | wlanChannelId             |  76 | mplsLabelStackEntry7      |
   | 147 | wlanSsid                  |  77 | mplsLabelStackEntry8      |
   | 200 | mplsTopLabelTtl           |  78 | mplsLabelStackEntry9      |
   | 203 | mplsTopLabelExp           |  79 | mplsLabelStackEntry10     |
   | 201 | mplsLabelStackSize        |     |                           |
   | 202 | mplsLabelStackDepth       |     |                           |
   +-----+---------------------------+-----+---------------------------+






Quittek, et al.        Expires November 28, 2005               [Page 30]

Internet-Draft          IPFIX Information Model                 May 2005


5.5.1  sourceMacAddress

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

5.5.2  postDestinationMacAddr

   Description:
      The IEEE 802 destination MAC address field after processing by a
      middlebox function.  This MAC address can not necessarily be
      observed at the Observation Point of this Flow.
   Abstract Data Type: macAddress
   Data Type Semantics: identifier
   ElementId: 57
   Status: current
   Reference: See IEEE.802-3.2002.

5.5.3  vlanId

   Description:
      The IEEE 802.1Q VLAN identifier (VID) extracted from the Tag
      Control Information field that was attached to the IP packet.






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


   Abstract Data Type: unsigned16
   Data Type Semantics: identifier
   ElementId: 58
   Status: current
   Reference: See IEEE.802-1Q.2003.

5.5.4  postVlanId

   Description:
      The IEEE 802.1Q VLAN identifier (VID) extracted from the Tag
      Control Information field that was attached to the IP packet after
      processing by a middlebox function.  This VLAN identifier can not
      necessarily be observed at the Observation Point of this Flow.
   Abstract Data Type: unsigned16
   Data Type Semantics: identifier
   ElementId: 59
   Status: current
   Reference: See IEEE.802-1Q.2003.

5.5.5  destinationMacAddress






Quittek, et al.        Expires November 28, 2005               [Page 31]

Internet-Draft          IPFIX Information Model                 May 2005

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

5.5.6  postSourceMacAddress

   Description:
      The IEEE 802 source MAC address field. after processing by a
      middlebox function.  This MAC address can not necessarily be
      observed at the Observation Point of this Flow.
   Abstract Data Type: macAddress
   Data Type Semantics: identifier
   ElementId: 81
   Status: current
   Reference: See IEEE.802-3.2002.

5.5.7  wlanChannelId

   Description:







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


      The identifier of the 802.11 (WiFi) channel used.
   Abstract Data Type: octet
   Data Type Semantics: identifier
   ElementId: 146
   Status: current
   Reference: See IEEE.802-11.1999.

5.5.8  wlanSsid

   Description:
      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.
   Abstract Data Type: string
   ElementId: 147
   Status: current
   Reference: See IEEE.802-11.1999.

5.5.9  mplsLabelStackEntry1  mplsTopLabelTtl

   Description: The TTL field from the top MPLS label stack entry, i.e.
      the last label that was pushed.
   Abstract Data Type: unsigned32
   ElementId: 200
   Status: current
   Reference: See RFC 3032 for the specification of the TTL field.

5.5.10  mplsTopLabelExp

   Description:
      The Exp field from the top MPLS label stack entry, i.e. 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
   ElementId: 203







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


   Status: current
   Reference: See RFC 3032 for the specification of the Exp field.  See
      RFC 3270 for usage of the Exp field.

5.5.11  mplsLabelStackSize

   Description: The size of the MPLS label stack.
   Abstract Data Type: unsigned32
   ElementId: 201
   Status: current
   Units: octets
   Reference: See RFC 3032 for the specification of the MPLS label
      stack.

5.5.12  mplsLabelStackDepth

   Description: The number of labels in the MPLS label stack.
   Abstract Data Type: unsigned32
   ElementId: 202
   Status: current
   Units: label stack entries
   Reference: See RFC 3032 for the specification of the MPLS label
      stack.

5.5.13  mplsTopLabelEntry

   Description:
      The label, exp and s fields from the outermost top MPLS label stack entry,
      i.e. the last label that was pushed.

       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



Quittek, et al.        Expires November 28, 2005               [Page 32]

Internet-Draft          IPFIX Information Model                 May 2005
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Label                  | Exp |S|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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







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


   Reference: See RFC 3032.

5.5.10

5.5.14  mplsLabelStackEntry2

   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 mplsLabelStackEntry1. mplsTopLabelEntry.  See the definition of
      mplsLabelStackEntry1
      mplsTopLabelEntry for further details.
   Abstract Data Type: unsigned32
   Data Type Semantics: identifier
   ElementId: 71
   Status: current
   Reference: See RFC 3032.

5.5.11

5.5.15  mplsLabelStackEntry3

   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
      mplsLabelStackEntry1
      mplsTopLabelEntry for further details.
   Abstract Data Type: unsigned32
   Data Type Semantics: identifier
   ElementId: 72
   Status: current
   Reference: See RFC 3032.

5.5.12

5.5.16  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 definition of
      mplsLabelStackEntry1
      mplsTopLabelEntry for further details.




Quittek, et al.        Expires November 28, 2005               [Page 33]

Internet-Draft          IPFIX Information Model                 May 2005
   Abstract Data Type: unsigned32
   Data Type Semantics: identifier
   ElementId: 73
   Status: current
   Reference: See RFC 3032.

5.5.13

5.5.17  mplsLabelStackEntry5

   Description:







Quittek, et al.       draft-ietf-ipfix-info-08.txt             [Page 43]

Internet-Draft           IPFIX Information Model               July 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 mplsLabelStackEntry4.  See the definition of
      mplsLabelStackEntry1
      mplsTopLabelEntry for further details.
   Abstract Data Type: unsigned32
   Data Type Semantics: identifier
   ElementId: 74
   Status: current
   Reference: See RFC 3032.

5.5.14

5.5.18  mplsLabelStackEntry6

   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 of
      mplsLabelStackEntry1
      mplsTopLabelEntry for further details.
   Abstract Data Type: unsigned32
   Data Type Semantics: identifier
   ElementId: 75
   Status: current
   Reference: See RFC 3032.

5.5.15

5.5.19  mplsLabelStackEntry7

   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 mplsLabelStackEntry6.  See the definition of
      mplsLabelStackEntry1
      mplsTopLabelEntry for further details.
   Abstract Data Type: unsigned32
   Data Type Semantics: identifier
   ElementId: 76
   Status: current
   Reference: See RFC 3032.

5.5.16

5.5.20  mplsLabelStackEntry8





Quittek, et al.        Expires November 28, 2005               [Page 34]

Internet-Draft          IPFIX Information Model                 May 2005

   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
      mplsLabelStackEntry1
      mplsTopLabelEntry for further details.
   Abstract Data Type: unsigned32







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


   Data Type Semantics: identifier
   ElementId: 77
   Status: current
   Reference: See RFC 3032.

5.5.17

5.5.21  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
      mplsLabelStackEntry1
      mplsTopLabelEntry for further details.
   Abstract Data Type: unsigned32
   Data Type Semantics: identifier
   ElementId: 78
   Status: current
   Reference: See RFC 3032.

5.5.18

5.5.22  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
      mplsLabelStackEntry1
      mplsTopLabelEntry 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
   and further information includes the Information Elements listed in
   the table below.









Quittek, et al.        Expires November 28, 2005               [Page 35]

Internet-Draft          IPFIX Information Model                 May 2005

   +-----+---------------------------+-----+---------------------------+
   |  ID | Name                      |  ID | Name                      |
   +-----+---------------------------+-----+---------------------------+
   |  15 | ipNextHopIPv4Address      |  18 | bgpNextHopIPv4Address     |
   |  62 | ipNextHopIPv6Address      |  63 | bgpNextHopIPv6Address     |
   |  16 | bgpSourceAsNumber         |  46 | mplsTopLabelType          |
   |  17 | bgpDestinationAsNumber    |  47 | mplsTopLabelIPv4Address   |
   | 128 | bgpNextAdjacentAsNumber   | 140 | mplsTopLabelIPv6Address   |
   | 129 | bgpPrevAdjacentAsNumber   |     |                           |
   +-----+---------------------------+-----+---------------------------+




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


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

   Description:
      The IPv6 address of the next IPv6 hop.
   Abstract Data Type: ipv6Address
   Data Type Semantics: identifier
   ElementId: 62
   Status: current

5.6.3  bgpSourceAsNumber

   Description:
      The autonomous system (AS) number of the source 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.
   Abstract Data Type: unsigned16
   Data Type Semantics: identifier
   ElementId: 16
   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.4  bgpDestinationAsNumber

   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 the value
      of this Information Element is 0.
   Abstract Data Type: unsigned16
   Data Type Semantics: identifier
   ElementId: 17
   Status: current
   Reference: See RFC 1771 for a description of BGP-4 and see RFC 1930
      for a definition of the AS number.






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


5.6.5  bgpNextAdjacentAsNumber

   Description:
      The autonomous system (AS) number of the first AS in the AS path
      to the destination IP address.  The path is deduced by looking up
      the destination IP address. 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.
   Abstract Data Type: unsigned16
   Data Type Semantics: identifier
   ElementId: 16 128
   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.4  bgpDestinationAsNumber






Quittek, et al.        Expires November 28, 2005               [Page 36]

Internet-Draft          IPFIX Information Model                 May 2005

5.6.6  bgpPrevAdjacentAsNumber

   Description:
      The autonomous system (AS) number of the destination 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
      bgpSrcAdjacentASNumber might not be able to report the correct
      value.
   Abstract Data Type: unsigned16
   Data Type Semantics: identifier
   ElementId: 129
   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.7  bgpNextHopIPv4Address

   Description:
      The IPv4 address of the next (adjacent) BGP hop.
   Abstract Data Type: ipv4Address
   Data Type Semantics: identifier
   ElementId: 18
   Status: current
   Reference: See RFC 1771 for a description of BGP-4 and

5.6.8  bgpNextHopIPv6Address






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


   Description:
      The IPv6 address of the next (adjacent) BGP hop.
   Abstract Data Type: ipv6Address
   Data Type Semantics: identifier
   ElementId: 63
   Status: current
   Reference: See RFC 1771 for a description of BGP-4.

5.6.9  mplsTopLabelType

   Description:
      This field identifies the control protocol that allocated 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 label associated with BGP or BGP routing
        - 0x05 LDP: Any label associated with dynamically assigned
                    labels using LDP

   Abstract Data Type: unsigned16 octet
   Data Type Semantics: identifier
   ElementId: 17 46
   Status: current
   Reference: See RFC 1771 3031 for a description of BGP-4 and see the MPLS label structure.  See RFC 1930 2547
      for a definition of the AS number.

5.6.5  bgpNextAdjacentAsNumber

   Description:
      The autonomous system (AS) number association of the first AS in the AS path
      to the destination MPLS labels with VPNs.  See RFC 1771 for
      BGP and BGP routing.  See RFC 3036 for LDP. and IP address. addresses.

5.6.10  mplsTopLabelIPv4Address

   Description:
      The path is deduced by looking up
      the destination IP IPv4 address of the Flow in system that the BGP routing
      information base.  If AS path information for MPLS top label will cause
      this Flow is only
      available as unordered AS set (and not as ordered AS sequence),
      then the value of this Information Element is 0. to be forwarded to.
   Abstract Data Type: unsigned16 ipv4Address
   Data Type Semantics: identifier
   ElementId: 128 47
   Status: current
   Reference: See RFC 1771 for a description of BGP-4 and see RFC 1930 3031 for a definition of the AS number.

5.6.6  bgpPrevAdjacentAsNumber

   Description:
      The autonomous system (AS) number of the last AS in the AS path
      from the source association between MPLS labels and
      IP address. addresses.

5.6.11  mplsTopLabelIPv6Address

   Description:







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


      The path is deduced by looking up the
      source IP IPv6 address of the Flow in system that the BGP routing information base.
      If AS path information for MPLS top label will cause
      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
      bgpSrcAdjacentASNumber might not be able to report the correct
      value. be forwarded to.
   Abstract Data Type: unsigned16 ipv6Address
   Data Type Semantics: identifier
   ElementId: 129 140
   Status: current
   Reference: See RFC 1771 3031 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 of a description Flow.

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


5.7.1  minimumPacketLength

   Description:
      Length of BGP-4 and see RFC 1930 the smallest packet observed for a definition this Flow.
   Abstract Data Type: unsigned16
   ElementId: 25
   Status: current
   Units: octets

5.7.2  maximumPacketLength

   Description:
      Length of the AS number. largest packet observed for this Flow.
   Abstract Data Type: unsigned16
   ElementId: 26
   Status: current
   Units: octets

5.7.3  minimumTtl








Quittek, et al.        Expires November 28, 2005       draft-ietf-ipfix-info-08.txt             [Page 37] 49]

Internet-Draft           IPFIX Information Model                 May               July 2005


5.6.7  bgpNextHopIPv4Address


   Description:
      Minimum TTL value observed for any packet in this Flow.
   Abstract Data Type: octet
   ElementId: 52
   Status: current

5.7.4  maximumTtl

   Description:
      Maximum TTL value observed 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 IPv4 option there is a bit in
      this set.  The bit is set to 1 if any observed packet of this Flow
      contains the corresponding IPv4 address option.  Otherwise, if no observed
      packet of this Flow contained the next (adjacent) BGP hop. resepective IPv4 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. IPv4 option numbers are
      maintained by IANA.
   Abstract Data Type: ipv4Address unsigned64
   Data Type Semantics: identifier flags
   ElementId: 18 208
   Status: current
   Reference: See RFC 1771 791 for a description the definition of BGP-4 and

5.6.8  bgpNextHopIPv6Address IPv4 options.  See the
      list of IPv4 option numbers assigned by IANA at
      http://www.iana.org/assignments/ip-parameters.

5.7.6  ipv6OptionHeaders

   Description:
      IPv6 extension headers observed in packets of this Flow.  The
      information is encoded in a set of bit fields.  For each IPv6 address
      option header there is a bit in this set.  The bit is set to 1 if
      any observed packet of this Flow contains the next (adjacent) BGP hop.
   Abstract Data Type: ipv6Address
   Data Type Semantics: identifier
   ElementId: 63
   Status: current
   Reference: See RFC 1771 for a description corresponding IPv6
      extension header.  Otherwise, if no observed packet of BGP-4.

5.6.9  mplsTopLabelType

   Description:
      This field identifies this Flow
      contained the control protocol that allocated resepective IPv6 extension header, the top value 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 the
      corresponding bit is 0.







Quittek, et al.       draft-ietf-ipfix-info-08.txt             [Page 50]

Internet-Draft           IPFIX Information Model               July 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 - 0x04 BGP: Any label associated with BGP or BGP routing not first fragment
       2, ROU      43       Routing header
       3, FRA0     44       Fragment header - 0x05 LDP: Any label associated with dynamically assigned
                    labels using LDP 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: octet unsigned32
   Data Type Semantics: identifier flags
   ElementId: 46 64
   Status: current
   Reference: See RFC 3031 2460 for the MPLS label structure.  See RFC 2547 general definition of IPv6 extensions
      headers and for the association specification of MPLS labels with VPNs. the hop-by-hop options
      header, the routing header, the fragment header, and the
      destination options header.  See RFC 1771 2402 for
      BGP and BGP routing. the specification of
      the authentication header.  See RFC 3036 2406 for LDP.  and IP addresses.

5.6.10  mplsTopLabelIPv4Address

   Description:
      The IPv4 address of the system that specification of
      the MPLS top label will cause
      this Flow to be forwarded to. encapsulating security payload.





Quittek, et al.        Expires November 28, 2005       draft-ietf-ipfix-info-08.txt             [Page 38] 51]

Internet-Draft           IPFIX Information Model                 May               July 2005


5.7.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: ipv4Address octet
   Data Type Semantics: identifier flags
   ElementId: 47 6
   Status: current
   Reference: See RFC 3031 793 for a definition of the association between MPLS labels and
      IP addresses.

5.6.11  mplsTopLabelIPv6Address TCP control bits in
      the TCP header.

5.7.8  tcpOptions

   Description:
      TCP options in packets of this Flow.  The IPv6 address 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 system that the MPLS top label will cause corresponding TCP option.  Otherwise, if no observed
      packet of this Flow contained the resepective TCP option, the
      value of the corresponding bit is 0.
      Options are mapped to be forwarded 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: ipv6Address unsigned64
   Data Type Semantics: identifier flags







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


   ElementId: 140 209
   Status: current
   Reference: See RFC 3031 793 for the association between MPLS labels and
      IP addresses.

5.7  Min/Max definition of TCP options.  See the
      list of TCP option numbers assigned by IANA at
      http://www.iana.org/assignments/tcp-parameters.

5.8  Flow Properties Time Stamps

   Information Elements in this section 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.

   Time stamps flowStartSysUpTime and flowEndSysUpTime are results relative time
   stamps indicating the time relative to the last (re-)initialization
   of minimum or
   maximum operations over all packets the IPFIX Device.  For reporting the time of a flow. the last
   (re-)initialization, systemInitTimeMilliSeconds can be reported, for
   example, in Data Records defined by Option Templates.

   +-----+---------------------------+-----+---------------------------+
   |  ID | Name                      |  ID | Name                      |
   +-----+---------------------------+-----+---------------------------+
   |  25 150 | minimumPacketLength flowStartSeconds          |  64 156 | ipv6OptionHeaders flowStartNanoSeconds      |
   |  26 151 | maximumPacketLength flowEndSeconds            |   6 157 | tcpControlBits flowEndNanoSeconds        |
   |  52 152 | minimumTtl flowStartMilliSeconds     | 158 | flowStartDeltaMicroSeconds|
   | 153 | flowEndMilliSeconds       | 159 | flowEndDeltaMicroSeconds  |
   | 154 | flowStartMicroSeconds     | 160 | systemInitTimeMilliSeconds|
   | 155 | flowEndMicroSeconds       |  22 | flowStartSysUpTime        |  53
   | maximumTtl     |                           |  21 | flowEndSysUpTime          |
   +-----+---------------------------+-----+---------------------------+


5.7.1  minimumPacketLength


5.8.1  flowStartSeconds

   Description:
      Length The absolute timestamp of the smallest first packet observed for of this Flow.







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


   Abstract Data Type: dateTimeSeconds
   ElementId: 150
   Status: current
   Units: seconds

5.8.2  flowEndSeconds

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

5.7.2  maximumPacketLength seconds

5.8.3  flowStartMilliSeconds

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

5.8.4  flowEndMilliSeconds

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

5.8.5  flowStartMicroSeconds

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

5.8.6  flowEndMicroSeconds

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

5.8.7  flowStartNanoSeconds





Quittek, et al.        Expires November 28, 2005       draft-ietf-ipfix-info-08.txt             [Page 39] 54]

Internet-Draft           IPFIX Information Model                 May               July 2005


   Description:
      Length The absolute timestamp of the largest first packet observed for of this Flow.
   Abstract Data Type: unsigned16 dateTimeNanoSeconds
   ElementId: 26 156
   Status: current
   Units: octets

5.7.3  minimumTtl nanoseconds

5.8.8  flowEndNanoSeconds

   Description:
      Minimum TTL value observed for any The absolute timestamp of the last packet in of this Flow.
   Abstract Data Type: octet dateTimeNanoSeconds
   ElementId: 52 157
   Status: current

5.7.4  maximumTtl
   Units: nanoseconds

5.8.9  flowStartDeltaMicroSeconds

   Description:
      Maximum TTL value 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 for any packet in of this Flow. Flow relative to the
      export time specified in the IPFIX Message header.
   Abstract Data Type: octet unsigned32
   ElementId: 53 158
   Status: current

5.7.5  ipv6OptionHeaders

   Description:
      IPv6 options in
   Units: microseconds
   Reference: See [I-D.ietf-ipfix-protocol] for the IP packet headers definition of this Flow.  The
      information the
      IPFIX Message header.

5.8.10  flowEndDeltaMicroSeconds

   Description: This is encoded in a set relative time stamp only valid within the
      scope of bit fields.  For each IPv6
      option header there is a bit in this set.  The bit is set if any single IPFIX Message.  It contains the negative time
      offset of the last observed packet of this Flow contains the corresponding IPv6
      option header.

      bit      IPv6 Option    Definition

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




Quittek, et al.        Expires November 28, 2005               [Page 40]

Internet-Draft the
      export time specified in the IPFIX Information Model                 May 2005 Message header.
   Abstract Data Type: unsigned32
   Data Type Semantics: flags
   ElementId: 64 159
   Status: current
   Units: microseconds
   Reference: See RFC 2460 [I-D.ietf-ipfix-protocol] for the general definition of IPv6 extensions
      headers and for the specification
      IPFIX Message header.

5.8.11  systemInitTimeMilliSeconds

   Description: The absolute timestamp of the hop-by-hop options
      header, the routing header, the fragment header, and last (re-)initialization
      of the
      destination options header.  See RFC 2402 for IPFIX Device.







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


   Abstract Data Type: dateTimeMilliSeconds
   ElementId: 160
   Status: current
   Units: milliseconds

5.8.12  flowStartSysUpTime

   Description: The relative timestamp of the specification first packet of this Flow.
      It indicates the authentication header.  See RFC 2406 for number of milliseconds since the specification last
      (re-)initialization of the encapsulating security payload.

5.7.6  tcpControlBits IPFIX Device (sysUpTime).
   Abstract Data Type: unsigned32
   ElementId: 22
   Status: current
   Units: milliseconds

5.8.13  flowEndSysUpTime

   Description:
      TCP control bits observed for packets of this Flow. The
      information is encoded in a set relative timestamp of bit fields.  For each TCP
      control bit there is a bit in this set.  A bit is set to 1 if any
      observed the last packet of this Flow has the corresponding TCP control bit
      set to 1.  A value of 0 for a bit Flow.
      It indicates that the corresponding
      bit was not set in any number of milliseconds since the observed packets last
      (re-)initialization 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 IPFIX Device (sysUpTime).
   Abstract Data Type: octet
   Data Type Semantics: flags unsigned32
   ElementId: 6 21
   Status: current
   Reference: See RFC 793 for a definition of the TCP control bits in
      the TCP header.

5.8  Flow Time Stamps
   Units: milliseconds

5.9  Per-Flow Counters

   Information Elements in this section are time stamps of events.

   Time stamps flowStartSeconds, flowEndSeconds, flowStartMilliSeconds,
   flowEndMilliSeconds, flowStartMicroSeconds, flowEndMicroSeconds,
   flowStartNanoSeconds, flowEndNanoSeconds, and



Quittek, et al.        Expires November 28, 2005               [Page 41]

Internet-Draft          IPFIX Information Model                 May 2005


   systemInitTimeMilliSeconds counters all having integer
   values.  Their values may change for every report they are absolute and have used in.
   They cannot serve as part of a well defined fixed
   time base, such as, Flow Key used for mapping packets to
   Flows.  However, potentially they can be used for selecting exported
   Flows, for example, the by only exporting Flows with more than a
   threshold number of seconds since 0000 UTC
   Jan 1st 1970.

   Time stamps flowStartDeltaMicroSeconds observed octets.

   There are running counters and flowEndDeltaMicroSeconds delta counters.  Delta counters are relative
   reset to zero each time stamps only valid within the scope their values are exported.  Running counters
   continue counting independently of a single
   IPFIX message.  They contain the negative time offsets relative Exporting Process.

   There are per-Flow counters and counters related to the export time specified in Metering
   Process and/or the IPFIX Message header.

   Time stamps flowStartSysUpTime and flowEndSysUpTime Exporting Process.  Per-Flow counters are relative time
   stamps indicating the Flow
   properties that potentially change each time relative a packet belonging to
   the last (re-)initialization
   of the IPFIX device.  For reporting the time Flow is observed.  The set of per-Flow counters includes the last
   (re-)initialization, systemInitTimeMilliSeconds can be reported, for
   example,
   Information Elements listed in Data Records defined by Option Templates. the table below.








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


   +-----+---------------------------+-----+---------------------------+
   |  ID | Name                      |  ID | Name                      |
   +-----+---------------------------+-----+---------------------------+
   | 150 204 | flowStartSeconds octetDeltaCount           | 156 132 | flowStartNanoSeconds droppedOctetDeltaCount    |
   | 151 205 | flowEndSeconds postOctetDeltaCount       | 157 133 | flowEndNanoSeconds droppedPacketDeltaCount   |
   | 152 198 | flowStartMilliSeconds octetDeltaSumOfSquares    | 158 134 | flowStartDeltaMicroSeconds| droppedOctetTotalCount    | 153
   | flowEndMilliSeconds 206 | 159 octetTotalCount           | flowEndDeltaMicroSeconds 135 | droppedPacketTotalCount   | 154
   | flowStartMicroSeconds 171 | 160 postOctetTotalCount       | systemInitTimeMilliSeconds|  19 | 155 postMCastPacketDeltaCount | flowEndMicroSeconds
   |  22 199 | flowStartSysUpTime octetTotalSumOfSquares    |  20 | postMCastOctetDeltaCount  |
   |   2 | packetDeltaCount          | 174 | postMCastPacketTotalCount |
   |  24 | postPacketDeltaCount      | 175 | postMCastOctetTotalCount  |
   |  86 | packetTotalCount          |     |  21                           | flowEndSysUpTime
   | 172 | postPacketTotalCount      |     |                           |
   +-----+---------------------------+-----+---------------------------+


5.8.1  flowStartSeconds

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

5.8.2  flowEndSeconds

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

5.8.3  flowStartMilliSeconds






Quittek, et al.        Expires November 28, 2005               [Page 42]

Internet-Draft          IPFIX Information Model                 May 2005


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

5.8.4  flowEndMilliSeconds


5.9.1  octetDeltaCount

   Description:
      The absolute timestamp number of octets since the last packet of previous report (if any) in
      incoming packets for this Flow.
   Abstract Data Type: dateTimeMilliSeconds
   ElementId: 153
   Status: current
   Units: milliseconds

5.8.5  flowStartMicroSeconds

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

5.8.6  flowEndMicroSeconds

   Description: Observation Point.  The absolute timestamp of the last packet
      number of this Flow. octets include IP header(s) and IP payload.
   Abstract Data Type: dateTimeMicroSeconds
   ElementId: 155
   Status: current
   Units: microseconds

5.8.7  flowStartNanoSeconds

   Description: The absolute timestamp of the first packet of this Flow.
   Abstract unsigned64
   Data Type: dateTimeNanoSeconds Type Semantics: deltaCounter
   ElementId: 156 204
   Status: current
   Units: nanoseconds

5.8.8  flowEndNanoSeconds octets

5.9.2  postOctetDeltaCount

   Description:
      The absolute timestamp number of the last Octets after packet treatment by a middlebox
      function since the previous report (if any) in packets for this
      Flow.  These packets do not necessarily pass the Observation Point
      of this Flow.  The number of octets include IP header(s) and IP
      payload.
   Abstract Data Type: dateTimeNanoSeconds unsigned64
   Data Type Semantics: deltaCounter
   ElementId: 157 205
   Status: current
   Units: nanoseconds octets

5.9.3  octetDeltaSumOfSquares








Quittek, et al.        Expires November 28, 2005       draft-ietf-ipfix-info-08.txt             [Page 43] 57]

Internet-Draft           IPFIX Information Model                 May               July 2005


5.8.9  flowStartDeltaMicroSeconds


   Description: This is a relative time stamp only valid within the
      scope
      The sum of a single IPFIX message.  It contains the negative time
      offset squared numbers of the first observed octets per incoming packet of this Flow relative to the
      export time specified in since
      the IPFIX Message header.
   Abstract Data Type: unsigned32
   ElementId: 158
   Status: current
   Units: microseconds
   Reference: See [I-D.ietf-ipfix-protocol] previous report (if any) for the definition of the
      IPFIX Message header.

5.8.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.
   Abstract Data Type: unsigned32
   ElementId: 159
   Status: current
   Units: microseconds
   Reference: See [I-D.ietf-ipfix-protocol] for the definition of at the
      IPFIX Message header.

5.8.11  systemInitTimeMilliSeconds

   Description: Observation
      Point.  The absolute timestamp of the last (re-)initialization number of the IPFIX device. octets include IP header(s) and IP payload.
   Abstract Data Type: dateTimeMilliSeconds unsigned64
   ElementId: 160 198
   Status: current
   Units: milliseconds

5.8.12  flowStartSysUpTime

5.9.4  octetTotalCount

   Description:
      The relative timestamp of the first packet total number of octets in incoming packets for this Flow.
      It indicates Flow at
      the number of milliseconds Observation Point since the last Metering Process
      (re-)initialization of the IPFIX device (sysUpTime). for this Observation Point.  The number of
      octets include IP header(s) and IP payload.
   Abstract Data Type: unsigned32 unsigned64
   Data Type Semantics: totalCounter
   ElementId: 22 206
   Status: current
   Units: milliseconds

5.8.13  flowEndSysUpTime





Quittek, et al.        Expires November 28, 2005               [Page 44]

Internet-Draft          IPFIX Information Model                 May 2005 octets

5.9.5  postOctetTotalCount

   Description:
      The relative timestamp of the last packet number of this Flow.
      It indicates the octets include IP header(s) and IP payload.  The
      total number of milliseconds octets in packets for this Flow after packet
      treatment by a middlebox function since the last Metering Process
      (re-)initialization of for this Observation Point.  These packets do
      not necessarily pass the IPFIX device (sysUpTime). Observation Point of this Flow.  The
      number of octets include IP header(s) and IP payload.
   Abstract Data Type: unsigned32 unsigned64
   Data Type Semantics: totalCounter
   ElementId: 21 170
   Status: current
   Units: milliseconds

5.9  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 octets

5.9.6  octetTotalSumOfSquares

   Description:
      The total sum of a flow key used for mapping the squared numbers of octets in incoming 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.

   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 this Flow at the Exporting Process.

   There are per-flow counters and counters related to Observation Point since 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.
      (re-)initialization for this Observation Point.  The number of
      octets include IP header(s) and IP payload.
   Abstract Data Type: unsigned64







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


   ElementId: 199
   Status: current
   Units: octets

5.9.7  packetDeltaCount

   Description:
      The set number of per-flow counters includes incoming packets since the
   Information Elements listed in previous report (if any)
      for this Flow at the table below.

   +-----+---------------------------+-----+---------------------------+
   |  ID | Name                      |  ID | Name                      |
   +-----+---------------------------+-----+---------------------------+
   |   1 | octetDeltaCount           | 132 | droppedOctetDeltaCount    |
   |  23 | postOctetDeltaCount       | 133 | droppedPacketDeltaCount   |
   |  85 | octetTotalCount           | 134 | droppedOctetTotalCount    |
   | 170 | postOctetTotalCount       | 135 | droppedPacketTotalCount   |
   | Observation Point.
   Abstract Data Type: unsigned64
   Data Type Semantics: deltaCounter
   ElementId: 2 | packetDeltaCount          |  19 | postMulticastPacketCount  |
   |  24 |
   Status: current
   Units: packets

5.9.8  postPacketDeltaCount      |  20 | postMulticastOctetCount   |
   |  86 | packetTotalCount          |     |                           |
   | 161 | postPacketTotalCount      |     |                           |
   +-----+---------------------------+-----+---------------------------+


5.9.1  octetDeltaCount

   Description:
      The number of octets packets after packet treatment by a middlebox
      function since the previous report (if any) in for this Flow.  These
      packets do not necessarily pass the Observation Point of this
      Flow.
   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 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
   Units: packets

5.9.10  postPacketTotalCount

   Description:
      The total number of octets include IP header(s) and IP payload. packets for this Flow after packet treatment
      by a middlebox function since the Metering Process
      (re-)initialization for this Observation Point.  These packets do
      not necessarily pass the Observation Point of this Flow.




Quittek, et al.        Expires November 28, 2005       draft-ietf-ipfix-info-08.txt             [Page 45] 59]

Internet-Draft           IPFIX Information Model                 May               July 2005


   Abstract Data Type: unsigned64
   Data Type Semantics: deltaCounter totalCounter
   ElementId: 1 171
   Status: current
   Units: octets

5.9.2  postOctetDeltaCount packets

5.9.11  droppedOctetDeltaCount

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

5.9.3  octetTotalCount

5.9.12  droppedPacketDeltaCount

   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 previous report (if any) of
      octets include IP header(s) and IP payload. this
      Flow dropped by packet treatment.
   Abstract Data Type: unsigned64
   Data Type Semantics: totalCounter deltaCounter
   ElementId: 85 133
   Status: current
   Units: octets

5.9.4  postOctetTotalCount packets

5.9.13  droppedOctetTotalCount

   Description:
      The total number of octets in outgoing packets for of this Flow at
      the Observation Point 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.
   Abstract Data Type: unsigned64
   Data Type Semantics: totalCounter
   ElementId: 170 134
   Status: current
   Units: octets

5.9.5  packetDeltaCount

5.9.14  droppedPacketTotalCount








Quittek, et al.        Expires November 28, 2005       draft-ietf-ipfix-info-08.txt             [Page 46] 60]

Internet-Draft           IPFIX Information Model                 May               July 2005


   Description:
      The number of incoming 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.9.15  postMCastPacketDeltaCount

   Description:
      The number of outgoing multicast packets since the previous report
      (if any) sent for packets of this Flow at by an adjacent multicast
      daemon.  These packets do not necessarily pass the Observation Point.
      Point of this Flow.
   Abstract Data Type: unsigned64
   Data Type Semantics: deltaCounter
   ElementId: 2 19
   Status: current
   Units: packets

5.9.6  postPacketDeltaCount

5.9.16  postMCastOctetDeltaCount

   Description:
      The number of outgoing packets octets since the previous report (if any) in
      outgoing multicast packets sent for packets of this Flow at by an
      adjacent multicast daemon.  These packets do not necessarily pass
      the Observation Point. Point of this Flow.  The number of octets include
      IP header(s) and IP payload.
   Abstract Data Type: unsigned64
   Data Type Semantics: deltaCounter
   ElementId: 24 20
   Status: current
   Units: packets

5.9.7  packetTotalCount octets

5.9.17  postMCastPacketTotalCount

   Description:
      The total number of incoming outgoing multicast packets sent for packets of
      this Flow at by an adjacent multicast daemon since the Metering
      Process (re-)initialization.  These packets do not necessarily
      pass the Observation Point of this Flow.







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


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

5.9.18  postMCastOctetTotalCount

   Description:
      The total number of octets in outgoing multicast packets sent for
      packets of this Flow by an adjacent multicast daemon since the
      Metering Process (re-)initialization
      for this (re-)initialization.  These packets do not
      necessarily pass the Observation Point. Point of this Flow.  The number
      of octets include IP header(s) and IP payload.
   Abstract Data Type: unsigned64
   Data Type Semantics: totalCounter
   ElementId: 86 175
   Status: current
   Units: packets

5.9.8  postPacketTotalCount octets

5.10  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 | flowInactiveTimeout       | 162 | flowDurationMicroSeconds  |
   | 136 | flowEndReason             |     |                           |
   +-----+---------------------------+-----+---------------------------+


5.10.1  flowActiveTimeOut

   Description:
      The total number of outgoing packets for this seconds after which an active Flow at the
      Observation Point since the Metering Process (re-)initialization
      for this Observation Point. is timed out
      anyway, even if there is still a continuous flow of packets.
   Abstract Data Type: unsigned64
   Data Type Semantics: totalCounter unsigned16
   ElementId: 171 36
   Status: current
   Units: packets

5.9.9  droppedOctetDeltaCount seconds

5.10.2  flowInactiveTimeout





Quittek, et al.        Expires November 28, 2005       draft-ietf-ipfix-info-08.txt             [Page 47] 62]

Internet-Draft           IPFIX Information Model                 May               July 2005


   Description:
      The number of octets since the previous report (if any) in
      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.10.3  flowEndReason

   Description:
      The reason for Flow dropped by packet treatment. termination.  The number range of octets
      include IP header(s) and IP payload. values includes

      0x01: idle timeout
      0x02: active timeout
      0x03: end of Flow detected (e.g. TCP FIN)
      0x04: forced end
      0x05: cache full

   Abstract Data Type: unsigned64 octet
   Data Type Semantics: deltaCounter identifier
   ElementId: 132 136
   Status: current
   Units: octets

5.9.10  droppedPacketDeltaCount

5.10.4  flowDurationMilliSeconds

   Description: The number difference between in time between the observation
      of packets since the previous report (if any) first packet of this Flow dropped by and the observation of the last
      packet treatment. of this Flow.
   Abstract Data Type: unsigned64
   Data Type Semantics: deltaCounter unsigned32
   ElementId: 133 161
   Status: current
   Units: packets

5.9.11  droppedOctetTotalCount milliseconds

5.10.5  flowDurationMicroSeconds

   Description: The total number of octets difference between in packets time between the observation
      of the first packet of this Flow dropped by
      packet treatment since and the Metering Process (re-)initialization
      for this Observation Point.  The number observation of octets include IP
      header(s) and IP payload. the last
      packet of this Flow.
   Abstract Data Type: unsigned64
   Data Type Semantics: totalCounter unsigned32
   ElementId: 134 162
   Status: current
   Units: octets

5.9.12  droppedPacketTotalCount

   Description:
      The microseconds

5.11  Padding

   This section contains a single Information Element only, that can be



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


   used for padding of Flow Records.

   IPFIX Implementations may wish to pad Flow Records such that all of
   them are aligned inside an IPFIX message to 4 octet boundaries or to
   8 octet boundaries.  This can be achieved by including a sufficient
   number of packets padding Information Elements in the Flow Record.

   Flow Record padding can be particularly useful if very short Flow
   Records are used.  The IPFIX protocol requests that IPFIX Message
   padding at the end of this an IPFIX Message must be shorter than the
   shortest Flow dropped by packet treatment
      since Record in the Metering Process (re-)initialization IPFIX Message.  If there is a Flow Record
   with a length of just 1, 2 or 3 octets, then IPFIX Message padding to
   a 4 octet boundary is not always possible.

   If however, padding of the IPFIX Message is desired in combination
   with very short Flow Records, then the padding Information Element
   can be used for padding Flow Records such that their length is
   increased to 4 or 8 octets.

   +-----+---------------------------+-----+---------------------------+
   |  ID | Name                      |  ID | Name                      |
   +-----+---------------------------+-----+---------------------------+
   | 210 | paddingOneOctet           |     |                           |
   +-----+---------------------------+-----+---------------------------+


5.11.1  paddingOneOctet

   Description:
      The value of this
      Observation Point. Information Element is always 0.
   Abstract Data Type: unsigned64
   Data Type Semantics: totalCounter octet
   ElementId: 135 210
   Status: current
   Units: packets

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.



Quittek, et al.        Expires November 28, 2005       draft-ietf-ipfix-info-08.txt             [Page 48] 64]

Internet-Draft           IPFIX Information Model                 May               July 2005


5.9.13  postMulticastPacketCount

   Description:
      The number


   Names of outgoing multicast packets since new Information Elements SHOULD be chosen according to the previous report
      (if any) created
   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,
   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 of IPFIX Information Elements.
   For extending them in the future, IANA needs to create a new registry
   for IPFIX Information Element identifiers.

   New assignments for packets IPFIX Information Elements will bes administered
   by IANA, on a First Come First Served basis [RFC2434], subject to
   Expert Review [RFC2434], i.e. review by one of this Flow a group of experts
   designated by an adjacent multicast
      daemon.  Note that typically not all IETF Operations and Management Area Director.  The
   group of experts must double check the created packets can Information Elements
   definitions with already defined Information Elements for
   completeness, accuracy, redundancy, and correct naming following the
   naming conventions in section 2.3.  Those experts will initially be
      observed at
   drawn from the Observation Point of this Flow.
   Abstract Data Type: unsigned64
   Data Type Semantics: deltaCounter
   ElementId: 19
   Status: current
   Units: packets

5.9.14  postMulticastOctetCount

   Description:
      The number Working Group Chairs and document editors of octets since the previous report (if any) in
      outgoing multicast packets created for packets of this Flow by IPFIX
   and PSAMP Working Groups.

   Appendix B defines an
      adjacent multicast daemon.  Note that typically not all of XML schema which may be used to create
   consistent machine readable extensions to the
      created packets can IPFIX information
   model.  This schema introduces a new namespace, which will be observed at
   assigned by IANA according to RFC 3688.  Currently the Observation Point of name space for
   this
      Flow.  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.10  Miscellaneous Flow Properties

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


5.10.1  flowActiveTimeOut

   Description: schema is identified as http://www.ietf.org/ipfix.

8.  Security Considerations

   The number IPFIX information model itself does not directly introduce
   security issues.  Rather it defines a set of seconds after attributes which an active Flow is timed out
      anyway, even if there is still a continuous flow may for
   privacy or business issues be considered sensitive information.

   The underlying protocol used to exchange the information described
   here must therefore apply appropriate procedures to guarantee the
   integrity and confidentiality of packets.
   Abstract Data Type: unsigned16
   ElementId: 36 the exported information.  Such



Quittek, et al.        Expires November 28, 2005       draft-ietf-ipfix-info-08.txt             [Page 49] 65]

Internet-Draft           IPFIX Information Model                 May               July 2005


   Status: current
   Units: seconds

5.10.2  flowInactiveTimeout

   Description:
      A Flow is considered to be timed out if no packets belonging to


   protocols are defined in separate documents, specifically the Flow have been observed IPFIX
   protocol document [I-D.ietf-ipfix-protocol].

9.  Acknowledgements

   The editors thank Paul Callato for creating the number 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.  Open Issues

   o  Is the prefix "post" appropriate for packets leaving the
      observation domain?  What about packets generated in the
      observation domain?
   o  octet count including MPLS header: Does the octet count concern IP
      packets only or also sub-IP layers such as MPLS?

11.  References

11.1  Normative Reference

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

11.2  Informative Reference

   [I-D.ietf-ipfix-architecture]
              Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek,
              "Architecture for IP Flow 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 of seconds specified by
      this field.
   Abstract Data Type: unsigned16
   ElementId: 37
   Status: current
   Units: seconds

5.10.3  flowEndReason

   Description:
      The reason Electrical and Electronics Engineers,
              "Standard for flow termination.  The range of values includes
   Abstract Data Type: octet
   Data Type Semantics: identifier
   ElementId: 136
   Status: current

5.10.4  flowDurationMilliSeconds

   Description: The difference Binary Floating-Point Arithmetic",
              IEEE Standard 754, August 1985.

   [IEEE.802-11.1999]
              "Information technology - Telecommunications and



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


              information exchange between in time 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 the observation
      of the first packet 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 of this Flow 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 Message Protocol", STD 5,
              RFC 792, September 1981.

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

   [RFC1771]  Rekhter, Y. and the observation of the last
      packet of this Flow.
   Abstract Data Type: unsigned32
   ElementId: 161
   Status: current
   Units: milliseconds

5.10.5  flowDurationMicroSeconds

   Description: The difference between in time between the observation
      of the first packet of this Flow T. Li, "A Border Gateway Protocol 4
              (BGP-4)", RFC 1771, March 1995.

   [RFC1930]  Hawkinson, J. and the observation of the last
      packet T. Bates, "Guidelines for creation,
              selection, and registration of this Flow.
   Abstract Data Type: unsigned32
   ElementId: 162
   Status: current
   Units: microseconds an Autonomous System (AS)",



Quittek, et al.        Expires November 28, 2005       draft-ietf-ipfix-info-08.txt             [Page 50] 67]

Internet-Draft           IPFIX Information Model                 May               July 2005


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


              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 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 extending this set.

   Extension is done by defining new Information Elements.  Each new
   information item 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 Internet Protocol Version 6
              (IPv6) Specification", RFC 2463, December 1998.

   [RFC2547]  Rosen, E. and a consuming
   application.  For generally applicable Information Elements Y. Rekhter, "BGP/MPLS VPNs", RFC 2547,
              March 1999.

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

   [RFC2863]  McCloghrie, K. 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 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 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 4.

   However, before creating enterprise-specific Information Elements,
   the general applicability of such Information Elements should be
   considered.  IPFIX does not support enterprise-specific data types. 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.

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



Quittek, et al.        Expires November 28, 2005       draft-ietf-ipfix-info-08.txt             [Page 51] 68]

Internet-Draft           IPFIX Information Model                 May               July 2005


7.  IANA Considerations

   IANA has to create a new registry for IPFIX Information Element
   identifiers.  Names of new Information Elements MUST follow the
   naming conventions specified


   [RFC3667]  Bradner, S., "IETF Rights in section 2.3.

   Appendix B defines an XML schema which may be used to create
   consistent machine readable extensions to the IPFIX information
   model.  This schema introduces a new namespace, which will be
   assigned by IANA according to Contributions", RFC 3688.  Currently the name space for
   this schema is identified as http://www.ietf.org/ipfix. 3667,
              February 2004.

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

   [RFC3917]  Quittek, et al.        Expires November 28, 2005               [Page 52]

Internet-Draft          IPFIX Information Model                 May 2005


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 information described
   here must therefore apply appropriate procedures to guarantee the
   integrity J., Zseby, T., Claise, B., and confidentiality of the exported information.  Such
   protocols are defined in separate documents, specifically the IPFIX
   protocol document [I-D.ietf-ipfix-protocol]. 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.


Authors' Addresses

   Juergen Quittek
   NEC
   Kurfuersten-Anlage 36
   Heidelberg  69115
   Germany

   Phone: +49 6221 90511-15
   Email: quittek@netlab.nec.de
   URI:   http://www.netlab.nec.de/


   Stewart Bryant
   Cisco Systems
   250, Longwater, Green Park
   Reading  RG2 6GB
   United Kingdom

   Email: stbryant@cisco.com


   Benoit Claise
   Cisco Systems
   De Kleetlaan 6a b1
   Diegem  1831
   Belgium

   Phone: +32 2 704 5622
   Email: bclaise@cisco.com







Quittek, et al.        Expires November 28, 2005       draft-ietf-ipfix-info-08.txt             [Page 53] 69]

Internet-Draft           IPFIX Information Model                 May               July 2005


9.  Acknowledgements

   The editors thank Paul Callato for creating the initial version


   Jeff Meyer
   PayPal
   2211 N. First St.
   San Jose, CA  95131-2021
   US

   Phone: +1 408 976-9149
   Email: jemeyer@paypal.com
   URI:   http://www.paypal.com

Appendix A.  Formal Specification of IPFIX Information Element

   This appendix contains a formal description of
   this document, Thomas Dietz for developing the XSLT scripts IPFIX information
   model XML document.  Note that
   generate large portions this appendix is of informational
   nature, while the text part of this document in section 4 generated from the
   XML appendices, this appendix is
   normative.

   Using a formal and Paul Aitken machine readable syntax for a very detailed review that
   helped improving the document significantly.












































Quittek, et al.        Expires November 28, 2005               [Page 54]

Internet-Draft          IPFIX Information Model                 May 2005


10.  Open Issues

   o  Is model
   enables the prefix "post" appropriate creation of IPFIX aware tools which can automatically
   adapt to extensions to the information model, by simply reading
   updated information model specifications.

   The wide availability of XML aware tools and libraries for packets leaving client
   devices is a primary consideration for this choice.  In particular
   libraries for parsing XML documents are readily available.  Also
   mechanisms such as the
      observation domain?  What about packets generated Extensible Stylesheet Language (XSL) allow for
   transforming a source XML document into other documents.  This draft
   was authored in XML and transformed according to RFC2629.

   It should be noted that the
      observation domain?
   o  octet count including MPLS header: Does use of XML in Exporters, Collectors or
   other tools is not mandatory for the octet count concern IP
      packets only deployment of IPFIX.  In
   particular Exporting Processes do not produce or also sub-IP layers such consume XML as MPLS?












































Quittek, et al.        Expires November 28, 2005               [Page 55]

Internet-Draft part
   of their operation.  It is expected that IPFIX Collectors MAY take
   advantage of the machine readability of the Information Model                 May 2005


11.  References

11.1  Normative Reference

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

11.2  Informative Reference

   [I-D.ietf-ipfix-architecture]
              Sadasivan, G., Brownlee, N., Claise, B. and J. Quittek,
              "Architecture vs.
   hard coding their behavior or inventing proprietary means for
   accommodating extensions.




   <fieldDefinitions>

     <field name="ipVersion" dataType="octet"
            group="IpHeader"
            dataTypeSemantics="identifier"
            fieldId="60" applicability="all" status="current">
       <description>
         The IP Flow 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 version field in progress),
              February 2005.

   [IEEE.754.1985]
              Institute of Electrical and Electronics Engineers,
              "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-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 of Electrical and Electronics Engineers, "Local
              and Metropolitan Area Networks: Virtual Bridged Local Area
              Networks", IEEE Standard 802.1Q, March 2003. the IP packet header.



Quittek, et al.        Expires November 28, 2005       draft-ietf-ipfix-info-08.txt             [Page 56] 70]

Internet-Draft           IPFIX Information Model                 May               July 2005


   [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.

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


       </description>
       <reference>
         <paragraph>
         See RFC 1771, March 1995.

   [RFC1930]  Hawkinson, J. and T. Bates, "Guidelines 791 for creation,
              selection, and registration a definition 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.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", the version field in the
         IPv4 packet header.
         See RFC 2460, December 1998.

   [RFC2463]  Conta, A. and S. Deering, "Internet Control Message
              Protocol (ICMPv6) 2460 for a definition of the version field in the
         IPv6 packet header.
         Additional information on defined version numbers
         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" applicability="all" status="current">
       <description>
         <paragraph>
         The IPv4 source address in the Internet Protocol Version 6
              (IPv6) Specification", RFC 2463, December 1998.

   [RFC2547]  Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", IP packet header.
         </paragraph>
       </description>
       <reference>
         See RFC 2547, March
              1999. 791 for the definition of the IPv4 source address
         field.
       </reference>
     </field>

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

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



Quittek, et al.        Expires November 28, 2005       draft-ietf-ipfix-info-08.txt             [Page 57] 71]

Internet-Draft           IPFIX Information Model                 May               July 2005


   [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.

   [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.

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

   [RFC3668]  Bradner, S., "Intellectual Property Rights


       </description>
       <units>bits</units>
       <range>0-32</range>
     </field>

     <field name="sourceIPv6Mask" dataType="octet"
            group="IpHeader"
            fieldId="29" applicability="option" status="current">
       <description>
         <paragraph>
         The number of contiguous bits that are relevant in IETF
              Technology", RFC 3668, February 2004.

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

   [RFC3954]  Claise, B., "Cisco Systems NetFlow Services Export Version
              9", RFC 3954, October 2004. Element.
         </paragraph>
       </description>
       <units>bits</units>
       <range>0-128</range>
     </field>

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

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

     <field name="destinationIPv4Address" dataType="ipv4Address"
            group="IpHeader"
            dataTypeSemantics="identifier"
            fieldId="12" applicability="all" status="current">
       <description>
         <paragraph>
         The IPv4 destination address in the IP packet header.
         </paragraph>
       </description>
       <reference>



Quittek, et al.        Expires November 28, 2005       draft-ietf-ipfix-info-08.txt             [Page 58] 72]

Internet-Draft           IPFIX Information Model                 May               July 2005


Authors' Addresses

   Juergen Quittek
   NEC
   Kurfuersten-Anlage 36
   Heidelberg  69115
   Germany

   Phone: +49 6221 90511-15
   EMail: quittek@netlab.nec.de
   URI:   http://www.netlab.nec.de/


   Stewart Bryant
   Cisco Systems
   250, Longwater, Green Park
   Reading  RG2 6GB
   United Kingdom

   EMail: stbryant@cisco.com


   Benoit Claise
   Cisco Systems
   De Kleetlaan 6a b1
   Diegem  1831
   Belgium

   Phone: +32 2 704 5622
   EMail: bclaise@cisco.com


   Jeff Meyer
   PayPal
   2211 N. First St.
   San Jose, CA  95131-2021
   US

   Phone: +1 408 976-9149
   EMail: jemeyer@paypal.com
   URI:   http://www.paypal.com


         See RFC 791 for the definition of the IPv4 destination address
         field.
       </reference>
     </field>

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

     <field name="destinationIPv4Mask" dataType="octet"
            group="IpHeader"
            fieldId="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"
            group="IpHeader"
            fieldId="30" applicability="option" status="current">
       <description>
         <paragraph>
         The number of contiguous bits that are relevant in the
         destinationIPv6Prefix Information Element.
         </paragraph>
       </description>
       <units>bits</units>
       <range>0-128</range>
     </field>

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



Quittek, et al.        Expires November 28, 2005       draft-ietf-ipfix-info-08.txt             [Page 59] 73]

Internet-Draft           IPFIX Information Model                 May               July 2005


Appendix A.  Formal Specification


     </field>

     <field name="destinationIPv6Prefix" dataType="ipv4Address"
            group="IpHeader"
            fieldId="169" applicability="data" status="current">
       <description>
         <paragraph> IPv6 destination address prefix. </paragraph>
       </description>
     </field>

     <field name="ipTimeToLive" dataType="octet"
            group="IpHeader"
            fieldId="192" applicability="all" status="current">
       <description>
         <paragraph>
         For IPv4, the value of IPFIX the Information Element

   This appendix contains a formal description of matches
         the IPFIX information
   model XML document.  Note that this appendix is value of informational
   nature, while the text Time to Live field in section 4 generated from this appendix is
   normative.

   Using a formal and machine readable syntax for the IPv4 packet
         header.  For IPv6, the value of the Information model
   enables Element
         matches the creation value of IPFIX aware tools which can automatically
   adapt to extensions the Hop Limit field in the IPv6
         packet header.
         </paragraph>
       </description>
       <reference>
         See RFC 791 for the definition of the IPv4 Time to Live
         field.
         See RFC 2460 for the information model, by simply reading
   updated information model specifications. definition of the IPv6 Hop Limit
         field.
       </reference>
       <units>hops</units>
     </field>

     <field name="protocolIdentifier" dataType="octet"
            group="IpHeader"
            dataTypeSemantics="identifier"
            fieldId="4" applicability="all" status="current">
       <description>
         <paragraph>
         The wide availability value of XML aware tools and libraries for client
   devices is a primary consideration for this choice.  In particular
   libraries for parsing XML documents are readily available.  Also
   mechanisms such as the Extensible Stylesheet Language (XSL) allow for
   transforming a source XML document into other documents.  This draft
   was authored protocol number in XML and transformed according to RFC2629.

   It should be noted that the use of XML IP packet header.
         The protocol number identifies the IP packet payload type.
         Protocol numbers are defined in Exporters, Collectors or
   other tools the IANA Protocol Numbers
         registry.</paragraph>

         <paragraph>
         In Internet Protocol version 4 (IPv4) this is not mandatory for carried in the deployment of IPFIX.
         "Protocol" field. In
   particular Exporting Processes do not produce or consume XML as part
   of their operation.  It Internet Protocol version 6 (IPv6) this
         is expected that IPFIX Collectors MAY take
   advantage of carried in the machine readability "Next Header" field in the last extension
         header of the packet.</paragraph>
       </description>



Quittek, et al.       draft-ietf-ipfix-info-08.txt             [Page 74]

Internet-Draft           IPFIX Information Model vs.
   hard coding their behavior or inventing proprietary means               July 2005


       <reference>
         <paragraph>
         See RFC 791 for
   accommodating extensions.



   <fieldDefinitions> 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.
         </paragraph>
       </reference>
     </field>

     <field name="ipVersion" name="nextHeaderIPv6" dataType="octet"
            group="IpHeader"
            dataTypeSemantics="identifier"
            fieldId="60"
            fieldId="193" applicability="all" status="current">
       <description>
         <paragraph>
         The IP version value of the 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.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 791 2460 for a the definition of the version 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>
         For IPv4 packets, this is the value of the TOS field in
         the IPv4 packet header.
         See RFC 2460 for a definition For IPv6 packets, this is the
         value of the version Traffic Class field in the IPv6 packet header.
         Additional information on defined version numbers
         can be found at
         http://www.iana.org/assignments/version-numbers.
         </paragraph>
       </description>
       <reference>
         See 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="ipDiffServeCodePoint" dataType="octet"



Quittek, et al.        Expires November 28, 2005       draft-ietf-ipfix-info-08.txt             [Page 60] 75]

Internet-Draft           IPFIX Information Model                 May               July 2005


       </reference>
     </field>

     <field name="sourceIPv4Address" dataType="ipv4Address"


            group="IpHeader"
            dataTypeSemantics="identifier"
            fieldId="8"
            fieldId="195" applicability="all" status="current">
       <description>
         <paragraph>
         The IPv4 source address value of a Differentiated Services Code Point (DSCP).
         The DSCP value is encoded in the IP packet header. first 6 bits of the IPv4
         TOS field or the IPv6 Traffic class field, respectively.
         </paragraph>
         <paragraph>
         For a particular Flow or packet, this Information Element
         may have the same value as Information Element
         ipClassOfService. However, the bits that are not used
         by the Differentiated Services Field for specifying a
         DiffServ Code Point (DSCP) are to be ignored.
         This is relevant when the DSCP serves as flow key.
         In this case the key consists of the first 6 bits.
         The remaining 2 bits are not part of the flow key.
         </paragraph>
       </description>
       <reference>
         See RFC 791 for the definition of the IPv4 source address TOS field.
         See RFC 2460 for the definition of the IPv6 Traffic Class
         field.
         See RFC 2474 for the definition of the Differentiated
         Services Field.
       </reference>
     </field>

     <field name="sourceIPv6Address" dataType="ipv6Address" name="ipPrecedence" dataType="octet"
            group="IpHeader"
            dataTypeSemantics="identifier"
            fieldId="27"
            fieldId="196" applicability="all" status="current">
       <description>
         <paragraph>
         The IPv6 source address in value of the IP packet header.
         </paragraph>
       </description>
     </field>

     <field name="sourceIPv4Mask" dataType="octet"
            group="IpHeader"
            fieldId="9" applicability="option" status="current">
       <description>
         <paragraph> Precedence.  The number IP Precedence value
         is encoded in the first 3 bits of contiguous the IPv4 TOS field
         or the IPv6 Traffic class field, respectively.
         </paragraph>
         <paragraph>
         For a particular Flow or packet, this Information Element
         may have the same value as Information Element
         ipClassOfService. However, the last 5 bits that
         are to be ignored.
         This is relevant in when the
         sourceIPv4Prefix Information Element.
         </paragraph>
       </description>
       <units>bits</units>
       <range>0-32</range>
     </field>

     <field name="sourceIPv6Mask" dataType="octet"
            group="IpHeader"
            fieldId="29" applicability="option" status="current">
       <description>
         <paragraph>
         The number ipPrecedence serves as flow key.
         In this case the key consists of contiguous the first 3 bits.
         The remaining 5 bits that are relevant in not part of the flow key.
         </paragraph>



Quittek, et al.        Expires November 28, 2005       draft-ietf-ipfix-info-08.txt             [Page 61] 76]

Internet-Draft           IPFIX Information Model                 May               July 2005


         sourceIPv6Prefix Information Element.
         </paragraph>


       </description>
       <units>bits</units>
       <range>0-128</range>
     </field>

     <field name="sourceIPv4Prefix" dataType="ipv4Address"
            group="IpHeader"
            fieldId="44" applicability="data" status="current">
       <description>
         <paragraph>
       <reference>
         See RFC 791 for the definition of the IPv4 source address prefix.
         </paragraph>
       </description>
     </field>

     <field name="sourceIPv6Prefix" dataType="ipv4Address"
            group="IpHeader"
            fieldId="169" applicability="data" status="current">
       <description>
         <paragraph> TOS field and
         the IP Precedence.
         See RFC 2460 for the definition of the IPv6 source address prefix.
         </paragraph>
       </description> Traffic Class
         field.
       </reference>
     </field>

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

     <field name="destinationIPv6Address" dataType="ipv6Address" name="classOfServiceIPv6" dataType="octet"
            group="IpHeader"
            dataTypeSemantics="identifier"
            fieldId="28" applicability="all"
            fieldId="137" applicability="data" status="current">
       <description>
         <paragraph>



Quittek, et al.        Expires November 28, 2005               [Page 62]

Internet-Draft          IPFIX Information Model                 May 2005
         The IPv6 destination address value of the Traffic Class field in the IP
         IPv6 packet header.
         </paragraph>
       </description>
       <reference>
         See RFC 2460 for the definition of the IPv6 Traffic Class
         field.
       </reference>
     </field>

     <field name="destinationIPv4Mask" name="postClassOfServiceIPv4" dataType="octet"
            group="IpHeader"
            fieldId="13" applicability="option"
            dataTypeSemantics="identifier"
            fieldId="55" applicability="all" status="current">
       <description>
         <paragraph>
         The number value of contiguous bits that are relevant the IPv4 TOS field in the
         destinationIPv4Prefix IP packet header
         after packet treatment by a middlebox function.
         This packet header can not necessarily be observed at the



Quittek, et al.       draft-ietf-ipfix-info-08.txt             [Page 77]

Internet-Draft           IPFIX Information Element. Model               July 2005


         Observation Point of this Flow.
         </paragraph>
       </description>
       <units>bits</units>
       <range>0-32</range>
       <reference>
         See RFC 791 for the definition of the IPv4 TOS field.
         See RFC 3234 for the definition of middleboxes.
       </reference>
     </field>

     <field name="destinationIPv6Mask" name="postClassOfServiceIPv6" dataType="octet"
            group="IpHeader"
            fieldId="30" applicability="option"
            dataTypeSemantics="identifier"
            fieldId="138" applicability="data" status="current">
       <description>
         <paragraph>
         The number value of contiguous bits that are relevant the IPv6 traffic class field in the
         destinationIPv6Prefix Information Element. IP packet
         header after packet treatment by a middlebox function.
         This packet header can not necessarily be observed at the
         Observation Point of this Flow.
         </paragraph>
       </description>
       <units>bits</units>
       <range>0-128</range>
       <reference>
         See RFC 2460 for the definition of the IPv6 traffic class
         field.
       </reference>
     </field>

     <field name="destinationIPv4Prefix" dataType="ipv4Address" name="flowLabelIPv6" dataType="unsigned32"
            group="IpHeader"
            fieldId="45" applicability="data"
            dataTypeSemantics="identifier"
            fieldId="31" applicability="all" status="current">
       <description>
         <paragraph> IPv4 destination address prefix.
         The value of the IPv6 Flow Label field in the IP packet header.
         </paragraph>
       </description>
       <reference>
         See RFC 2460 for a definition of the flow label field in the
         IPv6 packet header.
       </reference>
     </field>

     <field name="destinationIPv6Prefix" dataType="ipv4Address" name="identificationIPv4" dataType="unsigned16"
            group="IpHeader"
            fieldId="168"
            dataTypeSemantics="identifier"
            fieldId="54" applicability="data" status="current">
       <description>
         <paragraph> IPv6 destination address prefix. </paragraph>
       </description>
     </field>

     <field name="classOfServiceIPv4" dataType="octet"



Quittek, et al.        Expires November 28, 2005       draft-ietf-ipfix-info-08.txt             [Page 63] 78]

Internet-Draft           IPFIX Information Model                 May               July 2005


            group="IpHeader"
            dataTypeSemantics="identifier"
            fieldId="5" applicability="all" status="current">
       <description>
         <paragraph>


         The value of the IPv4 TOS packet identification field
         in the IP packet header.
         </paragraph>
       </description>
       <reference>
         See RFC 791 for the definition of the IPv4 TOS identification
         field.
       </reference>
     </field>

       <field name="classOfServiceIPv6" dataType="octet" name="fragmentOffsetIPv4" dataType="unsigned16"
            group="IpHeader"
            dataTypeSemantics="identifier"
            fieldId="137" applicability="data"
            fieldId="88" applicability="all" status="current">
       <description>
         <paragraph>
         The value of the IPv6 traffic class IPv4 fragment offset field
         in the IP packet header.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 2460 791 for the definition specification of the IPv6 traffic class
         field. IPv4 fragment offset.
         </paragraph>
       </reference>
     </field>

       <field name="postClassOfServiceIPv4" name="fragmentFlagsIPv4" dataType="octet"
            group="IpHeader"
            dataTypeSemantics="identifier"
            fieldId="55"
            dataTypeSemantics="flags"
            fieldId="197" applicability="all" status="current">
       <description>
         <paragraph>
         The value of the IPv4 TOS field fragmentation bits
         in the IP packet header
         after IPv4 packet treatment by a middlebox function. header.
         </paragraph>
         <artwork>
         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   6   7
           +---+---+---+---+---+---+---+---+
           |   | D | M | D | D | D | D | D |
           | 0 | F | F | C | C | C | C | C |
           +---+---+---+---+---+---+---+---+
         </artwork>



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


       </description>
       <reference>
         <paragraph>
         See RFC 791 for the definition specification of the IPv4 TOS field. fragment flags.
         </paragraph>
       </reference>
     </field>

       <field name="ipHeaderLength" dataType="octet"
            group="IpHeader"
            fieldId="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 for the specification of the IPv4 header.
         See RFC 2460 for the specification of the IPv6 header.
         </paragraph>
       </reference>
       <units>octets</units>
     </field>

       <field name="headerLengthIPv4" dataType="octet"
            group="IpHeader"
            fieldId="207" applicability="all" status="current">
       <description>
         <paragraph>
         The length of the IPv4 header.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 3234 791 for the definition specification of middleboxes. the IPv4 header.
         </paragraph>
       </reference>
       <units>octets</units>
     </field>

       <field name="postClassOfServiceIPv6" dataType="octet" name="packetLengthIPv4" dataType="unsigned16"
            group="IpHeader"
            dataTypeSemantics="identifier"
            fieldId="138" applicability="data"
            fieldId="190" applicability="all" status="current">
       <description>
         <paragraph>
         The total length of the IPv4 packet.



Quittek, et al.        Expires November 28, 2005       draft-ietf-ipfix-info-08.txt             [Page 64] 80]

Internet-Draft           IPFIX Information Model                 May               July 2005


       <description>
         <paragraph>
         The value of the IPv6 traffic class field in the IP packet
         header after packet treatment by a middlebox function.


         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 2460 791 for the definition specification of the IPv6 traffic class
         field. IPv4 total length.
         </paragraph>
       </reference>
       <units>octets</units>
     </field>

       <field name="flowLabelIPv6" name="payloadLengthIPv6" dataType="unsigned32"
            group="IpHeader"
            dataTypeSemantics="identifier"
            fieldId="31"
            fieldId="191" applicability="all" status="current">
       <description>
         <paragraph>
         The value length of the IPv6 Flow Label field in payload, i.e., the rest of the IP
         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.
         For payload lengths up to 65535, the value of this
         Information Element is given by the payload length field
         of the IPv6 header.  For payload lengths greater than 65535,
         the value of this Information Element is given by the
         content of the IPv6 jumbo payload option.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 2460 for a definition the specification of the flow label field in IPv6 payload length.
         See RFC 2675 for the specification of the IPv6 packet header. jumbo payload
         length.
         </paragraph>
       </reference>
     </field>

     <field name="identificationIPv4" name="sourceTransportPort" dataType="unsigned16"
            group="IpHeader"
            group="transportHeader"
            dataTypeSemantics="identifier"
            fieldId="54" applicability="data"
            fieldId="7" applicability="all" status="current">
       <description>
         <paragraph>
         The value of source port identifier in the IPv4 packet identification field transport header.
         For the transport
         protocols UDP, TCP and SCTP this is the source port number
         given in the IP packet respective header.  This field MAY also be used
         for future transport protocols that have 16 bit source port
         identifiers.
         </paragraph>



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


       </description>
       <reference>
         <paragraph>
         See RFC 791 768 for the definition of the IPv4 identification UDP source port field.
         See RFC 793 for the definition of the TCP source port field.
         See RFC 2960 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="protocolIdentifier" dataType="octet"
            group="IpHeader" name="destinationTransportPort" dataType="unsigned16"
            group="transportHeader"
            dataTypeSemantics="identifier"
            fieldId="4"
            fieldId="11" applicability="all" status="current">
       <description>



Quittek, et al.        Expires November 28, 2005               [Page 65]

Internet-Draft          IPFIX Information Model                 May 2005
         <paragraph>
         The value of the protocol number destination port identifier in the IP packet transport header.
         The protocol number identifies the IP packet payload type.
         Protocol numbers are defined in
         For the IANA Protocol Numbers
         registry.</paragraph>

         <paragraph>
         In Internet Protocol version 4 (IPv4) transport protocols UDP, TCP and SCTP this is carried in the
         "Protocol" field. In Internet Protocol version 6 (IPv6) this
         is carried
         destination port number given in the "Next Header" respective header.
         This field in the last extension
         header of the packet.</paragraph> MAY also be used for future transport protocols
         that have 16 bit destination port identifiers.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 791 768 for the specification definition of the IPv4 protocol UDP source port field.
         See RFC 2460 793 for the specification definition of the IPv6 protocol TCP source port field.
         See list RFC 2960 for the definition of protocol SCTP.  </paragraph>

         <paragraph>
         Additional information on defined UDP and TCP port numbers assigned by IANA can
         be found at
         http://www.iana.org/assignments/protocol-numbers. http://www.iana.org/assignments/port-numbers.
         </paragraph>
       </reference>
     </field>

     <field name="fragmentOffsetIPv4" name="udpSourcePort" dataType="unsigned16"
            group="IpHeader"
            group="transportHeader"
            dataTypeSemantics="identifier"
            fieldId="88"
            fieldId="180" applicability="all" status="current">
       <description>
         <paragraph>
         The value source port identifier in the UDP header.
       </description>
       <reference>
         See RFC 768 for the definition of the IPv4 fragment offset field UDP source port field.



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


         Additional information on defined UDP port numbers can
         be found at http://www.iana.org/assignments/port-numbers.
       </reference>
     </field>

     <field name="udpDestinationPort" dataType="unsigned16"
            group="transportHeader"
            dataTypeSemantics="identifier"
            fieldId="181" applicability="all" status="current">
       <description>
         The destination port identifier in the IP packet UDP header.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 791 768 for the specification definition of the IPv4 fragment offset.
         </paragraph> UDP source port field.
         Additional information on defined UDP port numbers can
         be found at http://www.iana.org/assignments/port-numbers.
       </reference>
     </field>

     <field name="sourceTransportPort" name="tcpSourcePort" dataType="unsigned16"
            group="transportHeader"
            dataTypeSemantics="identifier"
            fieldId="7"
            fieldId="182" 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



Quittek, et al.        Expires November 28, 2005               [Page 66]

Internet-Draft          IPFIX Information Model                 May 2005


         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 793 for the definition of the UDP TCP source port field.
         Additional information on defined TCP port numbers can
         be found at http://www.iana.org/assignments/port-numbers.
       </reference>
     </field>

     <field name="tcpDestinationPort" dataType="unsigned16"
            group="transportHeader"
            dataTypeSemantics="identifier"
            fieldId="183" applicability="all" status="current">
       <description>
         The destination port identifier in the TCP header.
       </description>
       <reference>
         See RFC 793 for the definition of the TCP source port field.
         See RFC 2960 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="destinationTransportPort" dataType="unsigned16" name="tcpSequenceNumber" dataType="unsigned32"



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


            group="transportHeader"
            dataTypeSemantics="identifier"
            fieldId="11"
            fieldId="184" applicability="all" status="current">
       <description>
         <paragraph>
         The destination port identifier sequence number in the transport TCP header.
         For
       </description>
       <reference>
         See RFC 793 for the transport protocols UDP, TCP and SCTP this is definition of the
         destination port TCP sequence number.
       </reference>
     </field>

     <field name="tcpAcknowledgementNumber" dataType="unsigned32"
            group="transportHeader"
            fieldId="185" applicability="all" status="current">
       <description>
         The acknowledgement number given in the respective TCP header.
         This field MAY also be used for future transport protocols
         that have 16 bit destination port identifiers.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 768 793 for the definition of the UDP source port field. TCP acknowledgement
         number.
       </reference>
     </field>

     <field name="tcpWindowSize" dataType="unsigned16"
            group="transportHeader"
            fieldId="186" applicability="all" status="current">
       <description>
         The window field in the TCP header.
       </description>
       <reference>
         See RFC 793 for the definition of the TCP source port window field.
       </reference>
     </field>

     <field name="tcpUrgentPointer" dataType="unsigned16"
            group="transportHeader"
            fieldId="187" applicability="all" status="current">
       <description>
         The urgent pointer in the TCP header.
       </description>
       <reference>
         See RFC 2960 793 for the definition of SCTP.  </paragraph>

         <paragraph>
         Additional information on defined UDP and the TCP urgent pointer.
       </reference>
     </field>

     <field name="tcpHeaderLength" dataType="unsigned16"
            group="transportHeader"
            fieldId="188" applicability="all" status="current">
       <description>



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


         The length of the TCP header.
       </description>
       <reference>
         See RFC 793 for the definition of the TCP port numbers can
         be found at http://www.iana.org/assignments/port-numbers.
         </paragraph> header.
       </reference>
       <units>octets</units>
     </field>

     <field name="icmpTypeCodeIPv4" dataType="unsigned16"
            group="transportHeader"
            dataTypeSemantics="identifier"
            fieldId="32" applicability="all" status="current">
       <description>



Quittek, et al.        Expires November 28, 2005               [Page 67]

Internet-Draft          IPFIX Information Model                 May 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>
         See RFC 792 for a definition of the IPv4 ICMP type and code
         fields.
       </reference>
     </field>

     <field name="icmpTypeIPv4" dataType="octet"
            group="transportHeader"
            dataTypeSemantics="identifier"
            fieldId="176" applicability="all" status="current">
       <description>
         <paragraph>
         Type of the IPv4 ICMP message.
         </paragraph>
       </description>
       <reference>
         See RFC 792 for a definition of the IPv4 ICMP type field.
       </reference>
     </field>

     <field name="icmpCodeIPv4" dataType="octet"
            group="transportHeader"
            dataTypeSemantics="identifier"
            fieldId="177" applicability="all" status="current">
       <description>
         <paragraph>
         Code of the IPv4 ICMP message.
         </paragraph>
       </description>
       <reference>



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


         See RFC 792 for a definition of the IPv4 ICMP code field.
       </reference>
     </field>

     <field name="icmpTypeCodeIPv6" dataType="unsigned16"
            group="transportHeader"
            dataTypeSemantics="identifier"
            fieldId="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>
       </description>
       <reference>
         See RFC 2463 for a definition of the IPv6 ICMP type and code
         fields.
       </reference>
     </field>

     <field name="icmpTypeIPv6" dataType="octet"
            group="transportHeader"
            dataTypeSemantics="identifier"
            fieldId="178" applicability="all" status="current">
       <description>
         <paragraph>
         Type of the IPv6 ICMP message.
         </paragraph>
       </description>
       <reference>
         See RFC 2463 for a definition of the IPv6 ICMP type field.
       </reference>
     </field>

     <field name="icmpCodeIPv6" dataType="octet"
            group="transportHeader"
            dataTypeSemantics="identifier"
            fieldId="179" applicability="all" status="current">
       <description>
         <paragraph>
         Code of the IPv6 ICMP message.
         </paragraph>
       </description>
       <reference>
         See RFC 2463 for a definition of the IPv6 ICMP code field.
       </reference>
     </field>




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


     <field name="igmpType" dataType="octet"
            group="transportHeader"
            dataTypeSemantics="identifier"
            fieldId="33" applicability="all" status="current">
       <description>
         The type field of the IGMP message.
       </description>
       <reference>
         See RFC 2236 for a definition of the IGMP type field.
       </reference>
     </field>

     <field name="sourceMacAddress" dataType="macAddress"
            group="subIpHeader"
            dataTypeSemantics="identifier"
            fieldId="56" applicability="data" status="current">
       <description>
         <paragraph>
           The IEEE 802 source MAC address field.
         </paragraph>
       </description>



Quittek, et al.        Expires November 28, 2005               [Page 68]

Internet-Draft          IPFIX Information Model                 May 2005
       <reference>
         See IEEE.802-3.2002.
       </reference>
     </field>

     <field name="postDestinationMacAddr" dataType="macAddress"
            group="subIpHeader"
            dataTypeSemantics="identifier"
            fieldId="57" applicability="data" status="current">
       <description>
         <paragraph>
           The IEEE 802 destination MAC address field
           after processing by a middlebox function.
           This MAC address can not necessarily be observed
           at the Observation Point of this Flow.
         </paragraph>
       </description>
       <reference>
         See IEEE.802-3.2002.
       </reference>
     </field>

     <field name="vlanId" dataType="unsigned16"
            group="subIpHeader"
            dataTypeSemantics="identifier"
            fieldId="58" applicability="data" status="current">
       <description>



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


         <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"
            dataTypeSemantics="identifier"
            fieldId="59" 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
           after processing by a middlebox function.
           This VLAN identifier can not necessarily be observed
           at the Observation Point of this Flow.
          </paragraph>
       </description>
       <reference>
         See IEEE.802-1Q.2003.



Quittek, et al.        Expires November 28, 2005               [Page 69]

Internet-Draft          IPFIX Information Model                 May 2005
       </reference>
     </field>

     <field name="destinationMacAddress" dataType="macAddress"
            group="subIpHeader"
            dataTypeSemantics="identifier"
            fieldId="80" applicability="data" status="current">
       <description>
         <paragraph>
           The IEEE 802 destination MAC address field.
         </paragraph>
       </description>
       <reference>
         See IEEE.802-3.2002.
       </reference>
     </field>

     <field name="postSourceMacAddress" dataType="macAddress"
            group="subIpHeader"
            dataTypeSemantics="identifier"
            fieldId="81" applicability="data" status="current">
       <description>
         <paragraph>



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


           The IEEE 802 source MAC address field.
           after processing by a middlebox function.
           This MAC address can not necessarily be observed
           at the Observation Point of this Flow.
         </paragraph>
       </description>
       <reference>
         See IEEE.802-3.2002.
       </reference>
     </field>

     <field name="wlanChannelId" dataType="octet"
            group="subIpHeader"
            dataTypeSemantics="identifier"
            fieldId="146" applicability="data" status="current">
       <description>
         <paragraph>
           The identifier of the 802.11 (WiFi) channel used.
         </paragraph>
       </description>
       <reference>
         See IEEE.802-11.1999.
       </reference>
     </field>

     <field name="wlanSsid" dataType="string"
            group="subIpHeader"



Quittek, et al.        Expires November 28, 2005               [Page 70]

Internet-Draft          IPFIX Information Model                 May 2005
            fieldId="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>
         See IEEE.802-11.1999.
       </reference>
     </field>

     <field name="mplsLabelStackEntry1" 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>



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


         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,
         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="mplsLabelStackSize" dataType="unsigned32"
            group="subIpHeader"
            fieldId="201" applicability="all" status="current">
       <description>
         The size of the MPLS label stack.
       </description>
       <reference>
         See RFC 3032 for the specification of the MPLS label
         stack.
       </reference>
       <units>octets</units>
     </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>



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


       <reference>
         See RFC 3032 for the specification of the MPLS label
         stack.
       </reference>
       <units>label stack entries</units>
     </field>

     <field name="mplsTopLabelEntry" dataType="unsigned32"
            group="subIpHeader"
            dataTypeSemantics="identifier"
            fieldId="70" applicability="all" status="current">
       <description>
         <paragraph>
         The label, exp and s fields from the outermost 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 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>
         See RFC 3032.
       </reference>
     </field>

     <field name="mplsLabelStackEntry2" dataType="unsigned32"
            group="subIpHeader"
            dataTypeSemantics="identifier"
            fieldId="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 mplsLabelStackEntry1. mplsTopLabelEntry. See the definition of



Quittek, et al.        Expires November 28, 2005               [Page 71]

Internet-Draft          IPFIX Information Model                 May 2005


         mplsLabelStackEntry1
         mplsTopLabelEntry for further details.
         </paragraph>
       </description>
       <reference>
         See RFC 3032.
       </reference>



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


     </field>

     <field name="mplsLabelStackEntry3" dataType="unsigned32"
            group="subIpHeader"
            dataTypeSemantics="identifier"
            fieldId="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 mplsLabelStackEntry2. See the definition of
         mplsLabelStackEntry1
         mplsTopLabelEntry for further details.
         </paragraph>
       </description>
       <reference>
         See RFC 3032.
       </reference>
     </field>

     <field name="mplsLabelStackEntry4" dataType="unsigned32"
            group="subIpHeader"
            dataTypeSemantics="identifier"
            fieldId="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 mplsLabelStackEntry3. See the definition of
         mplsLabelStackEntry1
         mplsTopLabelEntry for further details.
         </paragraph>
       </description>
       <reference>
         See RFC 3032.
       </reference>
     </field>

     <field name="mplsLabelStackEntry5" dataType="unsigned32"
            group="subIpHeader"
            dataTypeSemantics="identifier"
            fieldId="74" applicability="all" status="current">
       <description>
         <paragraph>



Quittek, et al.        Expires November 28, 2005               [Page 72]

Internet-Draft          IPFIX Information Model                 May 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 mplsLabelStackEntry4. See the definition of
         mplsLabelStackEntry1
         mplsTopLabelEntry for further details.
         </paragraph>
       </description>



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


       <reference>
         See RFC 3032.
       </reference>
     </field>

     <field name="mplsLabelStackEntry6" dataType="unsigned32"
            group="subIpHeader"
            dataTypeSemantics="identifier"
            fieldId="75" 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 mplsLabelStackEntry5. See the definition of
         mplsLabelStackEntry1
         mplsTopLabelEntry for further details.
         </paragraph>
       </description>
       <reference>
         See RFC 3032.
       </reference>
     </field>

     <field name="mplsLabelStackEntry7" dataType="unsigned32"
            group="subIpHeader"
            dataTypeSemantics="identifier"
            fieldId="76" 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. See the definition of
         mplsLabelStackEntry1
         mplsTopLabelEntry for further details.
         </paragraph>
       </description>
       <reference>
         See RFC 3032.
       </reference>
     </field>

     <field name="mplsLabelStackEntry8" dataType="unsigned32"
            group="subIpHeader"
            dataTypeSemantics="identifier"



Quittek, et al.        Expires November 28, 2005               [Page 73]

Internet-Draft          IPFIX Information Model                 May 2005
            fieldId="77" 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 mplsLabelStackEntry7. See the definition of
         mplsLabelStackEntry1



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


         mplsTopLabelEntry for further details.
         </paragraph>
       </description>
       <reference>
         See RFC 3032.
       </reference>
     </field>

     <field name="mplsLabelStackEntry9" dataType="unsigned32"
            group="subIpHeader"
            dataTypeSemantics="identifier"
            fieldId="78" 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. See the definition of
         mplsLabelStackEntry1
         mplsTopLabelEntry for further details.
         </paragraph>
       </description>
       <reference>
         See RFC 3032.
       </reference>
     </field>

     <field name="mplsLabelStackEntry10" dataType="unsigned32"
            group="subIpHeader"
            dataTypeSemantics="identifier"
            fieldId="79" 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. See the definition of
         mplsLabelStackEntry1
         mplsTopLabelEntry for further details.
         </paragraph>
       </description>
       <reference>
         See RFC 3032.
       </reference>
     </field>




Quittek, et al.        Expires November 28, 2005               [Page 74]

Internet-Draft          IPFIX Information Model                 May 2005

     <field name="ipNextHopIPv4Address" dataType="ipv4Address"
            group="derived"
            dataTypeSemantics="identifier"
            fieldId="15" applicability="data" status="current">
       <description>
         <paragraph>



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


         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),



Quittek, et al.        Expires November 28, 2005               [Page 75]

Internet-Draft          IPFIX Information Model                 May 2005
         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.



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


       </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.
       </reference>
     </field>

     <field name="bgpNextAdjacentAsNumber" dataType="unsigned16"
            group="derived"
            dataTypeSemantics="identifier"
            fieldId="128" applicability="all" status="current">
       <description>
         <paragraph>
         The autonomous system (AS) number of the 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 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.
       </reference>
     </field>




Quittek, et al.        Expires November 28, 2005               [Page 76]

Internet-Draft          IPFIX Information Model                 May 2005

     <field name="bgpPrevAdjacentAsNumber" dataType="unsigned16"
            group="derived"
            dataTypeSemantics="identifier"
            fieldId="129" applicability="all" status="current">
       <description>
         <paragraph>



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


         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
         bgpSrcAdjacentASNumber might not 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 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 of the next (adjacent) BGP hop.
         </paragraph>
       </description>
       <reference>
         See RFC 1771 for a description of BGP-4 and
       </reference>
     </field>

     <field name="bgpNextHopIPv6Address" dataType="ipv6Address"
            group="derived"
            dataTypeSemantics="identifier"
            fieldId="63" applicability="all" status="current">
       <description>
         <paragraph>
         The IPv6 address of the next (adjacent) BGP hop.
         </paragraph>
       </description>
       <reference>
         See RFC 1771 for a description of BGP-4.
       </reference>
     </field>

     <field name="mplsTopLabelType" dataType="octet"
            group="derived"
            dataTypeSemantics="identifier"



Quittek, et al.        Expires November 28, 2005       draft-ietf-ipfix-info-08.txt             [Page 77] 97]

Internet-Draft           IPFIX Information Model                 May               July 2005


       </reference>
     </field>

     <field name="mplsTopLabelType" dataType="octet"
            group="derived"
            dataTypeSemantics="identifier"


            fieldId="46" applicability="data" status="current">
       <description>
         <paragraph>
         This field identifies the control protocol that allocated the
         top of stack label.  Defined values 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>
         </paragraph>
       </description>
       <reference>
         See RFC 3031 for the MPLS label structure.
         See RFC 2547 for the association of MPLS labels with VPNs.
         See RFC 1771 for BGP and BGP routing.
         See RFC 3036 for LDP.
         and IP addresses.
       </reference>
     </field>

     <field name="mplsTopLabelIPv4Address" dataType="ipv4Address"
            group="derived"
            dataTypeSemantics="identifier"
            fieldId="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>
         See RFC 3031 for the association between MPLS labels
         and IP addresses.
       </reference>
     </field>

     <field name="mplsTopLabelIPv6Address" dataType="ipv6Address"
            group="derived"



Quittek, et al.        Expires November 28, 2005               [Page 78]

Internet-Draft          IPFIX Information Model                 May 2005
            dataTypeSemantics="identifier"
            fieldId="140" applicability="data" status="current">
       <description>
         <paragraph>
           The IPv6 address of the system that the MPLS top label will
           cause this Flow to be forwarded to.



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


         </paragraph>
       </description>
       <reference>
         See RFC 3031 for the association between MPLS labels
         and IP addresses.
       </reference>
     </field>

     <field name="exporterIPv4Address" dataType="ipv4Address"
            dataTypeSemantics="identifier"
            group="config"
            fieldId="130" applicability="all" 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.
         </paragraph>
       </description>
     </field>

     <field name="exporterIPv6Address" dataType="ipv6Address"
            dataTypeSemantics="identifier"
            group="config"
            fieldId="131" applicability="all" 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.
         </paragraph>
       </description>
     </field>

     <field name="minimumPacketLength" dataType="unsigned16"
            group="minMax"
            fieldId="25" applicability="all" status="current">
       <description>
         <paragraph>
         Length of the smallest packet observed for this Flow.
         </paragraph>
       </description>
       <units>octets</units>
     </field>

     <field name="maximumPacketLength" dataType="unsigned16"



Quittek, et al.        Expires November 28, 2005       draft-ietf-ipfix-info-08.txt             [Page 79] 99]

Internet-Draft           IPFIX Information Model                 May               July 2005


         </paragraph>
       </description>
       <units>octets</units>
     </field>

     <field name="maximumPacketLength" dataType="unsigned16"


            group="minMax"
            fieldId="26" applicability="all" status="current">
       <description>
         <paragraph>
         Length of the largest packet observed for this Flow.
         </paragraph>
       </description>
       <units>octets</units>
     </field>

     <field name="minimumTtl" dataType="octet"
            group="minMax"
            fieldId="52" applicability="data" status="current">
       <description>
         <paragraph>
           Minimum TTL value observed for any packet in this Flow.
         </paragraph>
       </description>
     </field>

     <field name="maximumTtl" dataType="octet"
            group="minMax"
            fieldId="53" applicability="data" status="current">
       <description>
         <paragraph>
           Maximum TTL value observed for any packet in this Flow.
         </paragraph>
       </description>
     </field>

     <field name="ipv4Options" dataType="unsigned64"
            dataTypeSemantics="flags"
            group="minMax"
            fieldId="208" applicability="all" status="current">
       <description>
         <paragraph>
        IPv4 options in packets of this Flow.
        The information is encoded in a set of bit fields.  For
        each IPv4 option 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.
        Otherwise, if no observed packet of this Flow contained
        the resepective IPv4 option, the value of the
        corresponding bit is 0.
         </paragraph>
         <paragraph>
         Options are mapped to bits according to their option
         numbers.  Option number X is mapped to bit X.



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


         IPv4 option numbers are maintained by IANA.
         </paragraph>
       </description>
       <reference>
         See RFC 791 for the definition of IPv4 options.
         See the list of IPv4 option numbers assigned by IANA
         at http://www.iana.org/assignments/ip-parameters.
       </reference>
     </field>

     <field name="ipv6OptionHeaders" dataType="unsigned32"
            dataTypeSemantics="flags"
            group="minMax"
            fieldId="64" applicability="all" status="current">
       <description>
         <paragraph>
        IPv6 options in the IP packet 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 option extension header.
        Otherwise, if no observed packet of this Flow contained
        the resepective IPv6 extension header, the value of 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
          +-----+-----+-----+-----+-----+-----+-----+-----+
      ... | 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




Quittek, et al.        Expires November 28, 2005       draft-ietf-ipfix-info-08.txt            [Page 80] 101]

Internet-Draft           IPFIX Information Model                 May               July 2005


         <artwork>
      bit      IPv6 Option    Definition

       0


       0, Res               Reserved
       1
       1, FRA1     44       Fragmentation header - not first fragment
       2
       2, ROU      43       Routing header
       3
       3, FRA0     44       Fragment header - first fragment
       4
       4, UNK               Unknown Layer 4 header
                            (compressed, encrypted, not supported)
       5
       5, Res               Reserved
       6
       6, HOP       0       Hop-by-hop option header
       7
       7, DST      60       Destination option header
       8
       8, PAY     108       Payload compression header
       9
       9, AUT      51       Authentication Header
      10
      10, ENC      50       Encrypted security payload
      11 to 31              Reserved
         </artwork>
       </description>
       <reference>
        See RFC 2460 for the general definition of IPv6 extensions
        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 for the specification of the authentication
        header.
        See RFC 2406 for the specification of the encapsulating
        security payload.
       </reference>
     </field>

     <field name="tcpControlBits" dataType="octet"
            dataTypeSemantics="flags"
            group="minMax"
            fieldId="6" applicability="all" status="current">
       <description>
         <paragraph>
         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.
         </paragraph>
         <artwork>
          0     1     2     3     4     5     6     7
      +-----+-----+-----+-----+-----+-----+-----+-----+



Quittek, et al.        Expires November 28, 2005               [Page 81]

Internet-Draft          IPFIX Information Model                 May 2005
      |  Reserved | URG | ACK | PSH | RST | SYN | FIN |
      +-----+-----+-----+-----+-----+-----+-----+-----+




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


      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
         </artwork>
       </description>
       <reference>See RFC 793 for a definition of the TCP control bits
       in the TCP header.</reference> header.</reference>
     </field>

     <field name="tcpOptions" dataType="unsigned64"
            dataTypeSemantics="flags"
            group="minMax"
            fieldId="209" applicability="all" status="current">
       <description>
         <paragraph>
        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 resepective TCP option, the value of the
        corresponding bit is 0.
         </paragraph>
         <paragraph>
         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.
         </paragraph>
       </description>
       <reference>
         See RFC 793 for the definition of TCP options.
         See the list of TCP option numbers assigned by IANA
         at http://www.iana.org/assignments/tcp-parameters.
       </reference>
     </field>

     <field name="flowStartSeconds" dataType="dateTimeSeconds"
            group="timestamp"
            fieldId="150" applicability="data" status="current">
       <description>
         The absolute timestamp of the first packet of this Flow.
       </description>
       <units>seconds</units>



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


     </field>

     <field name="flowEndSeconds" dataType="dateTimeSeconds"
            group="timestamp"
            fieldId="151" applicability="data" status="current">
       <description>
         The absolute timestamp of the last packet of this Flow.
       </description>
       <units>seconds</units>
     </field>

     <field name="flowStartMilliSeconds" dataType="dateTimeMilliSeconds"
            group="timestamp"
            fieldId="152" applicability="data" status="current">
       <description>
         The absolute timestamp of the first packet of this Flow.
       </description>
       <units>milliseconds</units>
     </field>

     <field name="flowEndMilliSeconds" dataType="dateTimeMilliSeconds"
            group="timestamp"
            fieldId="153" applicability="data" status="current">
       <description>
         The absolute timestamp of the last packet of this Flow.



Quittek, et al.        Expires November 28, 2005               [Page 82]

Internet-Draft          IPFIX Information Model                 May 2005
       </description>
       <units>milliseconds</units>
     </field>

     <field name="flowStartMicroSeconds" dataType="dateTimeMicroSeconds"
            group="timestamp"
            fieldId="154" applicability="data" status="current">
       <description>
         The absolute timestamp of the first packet of this Flow.
       </description>
       <units>microseconds</units>
     </field>

     <field name="flowEndMicroSeconds" dataType="dateTimeMicroSeconds"
            group="timestamp"
            fieldId="155" applicability="data" status="current">
       <description>
         The absolute timestamp of the last packet of this Flow.
       </description>
       <units>microseconds</units>
     </field>

     <field name="flowStartNanoSeconds" dataType="dateTimeNanoSeconds"



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


            group="timestamp"
            fieldId="156" applicability="data" status="current">
       <description>
         The absolute timestamp of the first packet of this Flow.
       </description>
       <units>nanoseconds</units>
     </field>

     <field name="flowEndNanoSeconds" dataType="dateTimeNanoSeconds"
            group="timestamp"
            fieldId="157" applicability="data" status="current">
       <description>
         The absolute timestamp of the last packet of this Flow.
       </description>
       <units>nanoseconds</units>
     </field>

     <field name="flowStartDeltaMicroSeconds" dataType="unsigned32"
            group="timestamp"
            fieldId="158" applicability="data" status="current">
       <description>
         This is a relative time stamp only valid within the scope
         of a single IPFIX message. 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.



Quittek, et al.        Expires November 28, 2005               [Page 83]

Internet-Draft          IPFIX Information Model                 May 2005
       </description>
       <reference>
         See [I-D.ietf-ipfix-protocol] for the definition of the IPFIX
         Message header.
       </reference>
       <units>microseconds</units>
     </field>

     <field name="flowEndDeltaMicroSeconds" dataType="unsigned32"
            group="timestamp"
            fieldId="159" applicability="data" status="current">
       <description>
         This is a relative time stamp only valid within the scope
         of a single IPFIX message. 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.
       </description>
       <reference>
         See [I-D.ietf-ipfix-protocol] for the definition of the IPFIX
         Message header.
       </reference>
       <units>microseconds</units>
     </field>



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


     <field name="systemInitTimeMilliSeconds"
            dataType="dateTimeMilliSeconds"
            group="timestamp"
            fieldId="160" applicability="data" status="current">
       <description>
         The absolute timestamp of the last (re-)initialization of the
         IPFIX device. Device.
       </description>
       <units>milliseconds</units>
     </field>

     <field name="flowStartSysUpTime" dataType="unsigned32"
            group="timestamp"
            fieldId="22" applicability="data" status="current">
       <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 Device (sysUpTime).
       </description>
       <units>milliseconds</units>
     </field>

     <field name="flowEndSysUpTime" dataType="unsigned32"
            group="timestamp"
            fieldId="21" applicability="data" status="current">



Quittek, et al.        Expires November 28, 2005               [Page 84]

Internet-Draft          IPFIX Information Model                 May 2005
       <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 Device (sysUpTime).
       </description>
       <units>milliseconds</units>
     </field>

     <field name="flowActiveTimeOut" dataType="unsigned16"
            group="misc"
            fieldId="36" applicability="all" status="current">
       <description>
         <paragraph>
         The number of seconds after which an active Flow is timed out
         anyway, even if there is still a continuous flow of packets.
         </paragraph>
       </description>
       <units>seconds</units>
     </field>

     <field name="flowInactiveTimeout" dataType="unsigned16"
            group="misc"
            fieldId="37" applicability="all" status="current">



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


       <description>
         <paragraph>
          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.
         </paragraph>
       </description>
       <units>seconds</units>
     </field>

     <field name="flowEndReason" dataType="octet"
            group="misc"
            dataTypeSemantics="identifier"
            fieldId="136" applicability="data" status="current">
       <description>
         <paragraph>
         The reason for flow Flow termination. The range of values includes
         <itemlist>
         <item>0x01:
         <artwork>
      0x01: idle timeout</item>
         <item>0x02: timeout
      0x02: active timeout</item>
         <item>0x03: timeout
      0x03: end of flow Flow detected (e.g. TCP FIN)</item>
         <item>0x04: FIN)
      0x04: forced end</item>
         <item>0x05: end
      0x05: cache full</item>
         </itemlist> full
         </artwork>
         </paragraph>



Quittek, et al.        Expires November 28, 2005               [Page 85]

Internet-Draft          IPFIX Information Model                 May 2005
       </description>
     </field>

     <field name="flowDurationMilliSeconds" dataType="unsigned32"
            group="misc"
            fieldId="161" applicability="data" status="current">
       <description>
         The difference between in time between the observation of the
         first packet of this Flow and the observation of the last
         packet of this Flow.
       </description>
       <units>milliseconds</units>
     </field>

     <field name="flowDurationMicroSeconds" dataType="unsigned32"
            group="misc"
            fieldId="162" applicability="data" status="current">
       <description>
         The difference between in time between the observation of the
         first packet of this Flow and the observation of the last
         packet of this Flow.
       </description>
       <units>microseconds</units>



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


     </field>

     <field name="octetDeltaCount" dataType="unsigned64"
            dataTypeSemantics="deltaCounter"
            group="flowCounter"
            fieldId="1"
            fieldId="204" applicability="data" status="current">
       <description>
         <paragraph>
         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.
         </paragraph>
       </description>
       <units>octets</units>
     </field>

     <field name="postOctetDeltaCount" dataType="unsigned64"
            dataTypeSemantics="deltaCounter"
            group="flowCounter"
            fieldId="23"
            fieldId="205" applicability="data" status="current">
       <description>
         <paragraph>
         The number of octets Octets after packet treatment
         by a middlebox function since the previous report
         (if any) in outgoing packets for this Flow.
         These packets do not necessarily pass the
         Observation Point of this Flow.
         The number of octets include IP header(s) and IP payload.
         </paragraph>
       </description>
       <units>octets</units>
     </field>

     <field name="octetDeltaSumOfSquares" dataType="unsigned64"
            group="flowCounter"
            fieldId="198" applicability="data" status="current">
       <description>
         <paragraph>
         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.
         </paragraph>
       </description>
     </field>

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



Quittek, et al.        Expires November 28, 2005       draft-ietf-ipfix-info-08.txt            [Page 86] 108]

Internet-Draft           IPFIX Information Model                 May               July 2005


            group="flowCounter"
            fieldId="206" applicability="all" status="current">
       <description>
         <paragraph>
         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.
         </paragraph>
       </description>
       <units>octets</units>
     </field>

     <field name="octetTotalCount" name="postOctetTotalCount" dataType="unsigned64"
            dataTypeSemantics="totalCounter"
            group="flowCounter"
            fieldId="85"
            fieldId="170" applicability="all" status="current">
       <description>
         <paragraph>
         The number of octets include IP header(s) and IP payload.
         The total number of octets in incoming packets for this Flow at the Observation Point
         after packet treatment by a middlebox function
         since the Metering Process (re-)initialization
         for this Observation Point.
         These packets do not necessarily pass the
         Observation Point of this Flow.
         The number of octets include IP header(s) and IP payload.
         </paragraph>
       </description>
       <units>octets</units>
     </field>

     <field name="postOctetTotalCount" name="octetTotalSumOfSquares" dataType="unsigned64"
            dataTypeSemantics="totalCounter"
            group="flowCounter"
            fieldId="170"
            fieldId="199" applicability="all" status="current">
       <description>
         <paragraph>
         The total number sum of the squared numbers of octets in outgoing 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.
         </paragraph>
       </description>
       <units>octets</units>
     </field>

     <field name="packetDeltaCount" dataType="unsigned64"



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


            dataTypeSemantics="deltaCounter"
            group="flowCounter"
            fieldId="2" applicability="data" status="current">
       <description>
         <paragraph>
         The number of incoming packets since the previous report
         (if any) for this Flow at the Observation Point.
         </paragraph>
       </description>
       <units>packets</units>
     </field>




Quittek, et al.        Expires November 28, 2005               [Page 87]

Internet-Draft          IPFIX Information Model                 May 2005

     <field name="postPacketDeltaCount" dataType="unsigned64"
            dataTypeSemantics="deltaCounter"
            group="flowCounter"
            fieldId="24" applicability="data" status="current">
       <description>
         <paragraph>
         The number of outgoing packets after packet treatment
         by a middlebox function since the previous report
         (if any) for this Flow at Flow.
         These packets do not necessarily pass the
         Observation Point. Point of this Flow.
         </paragraph>
       </description>
       <units>packets</units>
     </field>

     <field name="packetTotalCount" dataType="unsigned64"
            dataTypeSemantics="totalCounter"
            group="flowCounter"
            fieldId="86" applicability="all" status="current">
       <description>
         <paragraph>
         The total number of incoming packets for this Flow
         at the Observation Point since the Metering Process
         (re-)initialization for this Observation Point.
         </paragraph>
       </description>
       <units>packets</units>
     </field>

     <field name="postPacketTotalCount" dataType="unsigned64"
            dataTypeSemantics="totalCounter"
            group="flowCounter"
            fieldId="171" applicability="all" status="current">
       <description>
         <paragraph>



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


         The total number of outgoing packets for this Flow
         at the Observation Point
         after packet treatment by a middlebox function
         since the Metering Process (re-)initialization
         for this Observation Point.
         These packets do not necessarily pass the
         Observation Point of this Flow.
         </paragraph>
       </description>
       <units>packets</units>
     </field>

     <field name="droppedOctetDeltaCount" dataType="unsigned64"
            dataTypeSemantics="deltaCounter"
            group="flowCounter"
            fieldId="132" applicability="data" status="current">
       <description>
         <paragraph>
         The number of octets since the previous report (if any)



Quittek, et al.        Expires November 28, 2005               [Page 88]

Internet-Draft          IPFIX Information Model                 May 2005
         in packets of this Flow dropped by packet treatment.
         The number of octets include IP header(s) and IP payload.
         </paragraph>
       </description>
       <units>octets</units>
     </field>

     <field name="droppedPacketDeltaCount" dataType="unsigned64"
            dataTypeSemantics="deltaCounter"
            group="flowCounter"
            fieldId="133" applicability="data" status="current">
       <description>
         <paragraph>
         The number of packets since the previous report (if any)
         of this Flow dropped by packet treatment.
         </paragraph>
       </description>
       <units>packets</units>
     </field>

     <field name="droppedOctetTotalCount" dataType="unsigned64"
            dataTypeSemantics="totalCounter"
            group="flowCounter"
            fieldId="134" applicability="data" status="current">
       <description>
         <paragraph>
         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-08.txt            [Page 111]

Internet-Draft           IPFIX Information Model               July 2005


         </paragraph>
       </description>
       <units>octets</units>
     </field>

     <field name="droppedPacketTotalCount" dataType="unsigned64"
            dataTypeSemantics="totalCounter"
            group="flowCounter"
            fieldId="135" applicability="data" status="current">
       <description>
         <paragraph>
         The number of packets of this Flow dropped by packet
         treatment since the Metering Process
         (re-)initialization for this Observation Point.
         </paragraph>
       </description>
       <units>packets</units>
     </field>

     <field name="postMCastPacketDeltaCount" dataType="unsigned64"
            dataTypeSemantics="deltaCounter"
            group="flowCounter"
            fieldId="19" applicability="data" status="current">
       <description>
         <paragraph>
         The number of outgoing multicast packets since the
         previous report (if any) sent for packets
         of this Flow by an adjacent multicast daemon.
         These packets do not necessarily pass the
         Observation Point of this Flow.
         </paragraph>
       </description>
       <units>packets</units>
     </field>

     <field name="postMCastOctetDeltaCount" dataType="unsigned64"
            dataTypeSemantics="deltaCounter"
            group="flowCounter"
            fieldId="20" applicability="data" status="current">
       <description>
         <paragraph>
         The number of octets since the previous report (if any)
         in outgoing multicast packets sent
         for packets of this Flow by an adjacent multicast daemon.
         These packets do not necessarily pass the Observation
         Point of this Flow.
         The number of octets include IP header(s) and IP payload.
         </paragraph>
       </description>
       <units>octets</units>
     </field>

     <field name="droppedPacketTotalCount" dataType="unsigned64"
            dataTypeSemantics="totalCounter"
            group="flowCounter"
            fieldId="135" applicability="data" status="current">
       <description>
         <paragraph>
         The number of packets of this Flow dropped by packet
         treatment since the Metering Process
         (re-)initialization for this Observation Point.
         </paragraph>
       </description>
       <units>packets</units>
     </field>



Quittek, et al.        Expires November 28, 2005       draft-ietf-ipfix-info-08.txt            [Page 89] 112]

Internet-Draft           IPFIX Information Model                 May               July 2005


       </description>
       <units>octets</units>
     </field>

     <field name="postMulticastPacketCount" name="postMCastPacketTotalCount" dataType="unsigned64"
            dataTypeSemantics="deltaCounter"
            dataTypeSemantics="totalCounter"
            group="flowCounter"
            fieldId="19"
            fieldId="174" applicability="data" status="current">
       <description>
         <paragraph>
         The total number of outgoing multicast packets since the
         previous report (if any) created sent for
         packets of this Flow by an adjacent multicast daemon.
         Note that typically not all of daemon since
         the created Metering Process (re-)initialization.
         These packets can be
         observed at do not necessarily pass the Observation
         Point of this Flow.
         </paragraph>
       </description>
       <units>packets</units>
     </field>

     <field name="postMulticastOctetCount" name="postMCastOctetTotalCount" dataType="unsigned64"
            dataTypeSemantics="deltaCounter"
            dataTypeSemantics="totalCounter"
            group="flowCounter"
            fieldId="20"
            fieldId="175" applicability="data" status="current">
       <description>
         <paragraph>
         The total number of octets since the previous report (if any) in outgoing multicast packets created
         sent for packets of this Flow by an adjacent multicast daemon.
         Note that typically not all of
         daemon since the created Metering Process (re-)initialization.
         These packets can be
         observed at do not necessarily pass the Observation
         Point of this Flow.
         The number of octets include IP header(s) and IP payload.
         </paragraph>
       </description>
       <units>octets</units>
     </field>

     <field name="exportedMessageTotalCount" dataType="unsigned64"
            dataTypeSemantics="totalCounter"
            group="processCounter"
            fieldId="41" applicability="data" status="current">
       <description>
         <paragraph>
         The total number of 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.
         </paragraph>
       </description>
       <units>messages</units>
     </field>



Quittek, et al.        Expires November 28, 2005       draft-ietf-ipfix-info-08.txt            [Page 90] 113]

Internet-Draft           IPFIX Information Model                 May               July 2005


       </description>
       <units>messages</units>
     </field>

     <field name="exportedOctetTotalCount" dataType="unsigned64"
            dataTypeSemantics="totalCounter"
            group="processCounter"
            fieldId="40" applicability="data" status="current">
       <description>
         <paragraph>
            The total number of 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 header length values of all IPFIX messages Messages
            that were successfully sent to the Collecting Process
            receiving a report that contains this Information Element.
         </paragraph>
       </description>
       <units>octets</units>
     </field>

     <field name="exportedFlowTotalCount" dataType="unsigned64"
            group="processCounter"
            dataTypeSemantics="totalCounter"
            fieldId="42" applicability="data" status="current">
       <description>
         <paragraph>
         The total number of Flows Records reported 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.
         </paragraph>
       </description>
       <units>Flows</units>
     </field>

     <field name="observedFlowTotalCount" dataType="unsigned64"
            dataTypeSemantics="totalCounter"
            group="processCounter"
            fieldId="3" applicability="data" status="current">
       <description>
         <paragraph>
         The total number of Flows observed in the Observation Domain
         since the Metering Process (re-)initialization for this
         Observation Point.
         </paragraph>
       </description>
       <units>Flows</units>
     </field>



Quittek, et al.        Expires November 28, 2005       draft-ietf-ipfix-info-08.txt            [Page 91] 114]

Internet-Draft           IPFIX Information Model                 May               July 2005


       </description>
       <units>Flows</units>
     </field>

     <field name="ignoredPacketTotalCount" dataType="unsigned64"
            dataTypeSemantics="totalCounter"
            group="processCounter"
            fieldId="163"
            fieldId="164" applicability="data" status="current">
       <description>
         <paragraph>
            The total number of observed IP packets that the
            Metering Process did not process. process since the
            (re-)initialization of the Metering Process.
         </paragraph>
       </description>
       <units>packets</units>
     </field>

     <field name="ignoredOctetTotalCount" dataType="unsigned64"
            dataTypeSemantics="totalCounter"
            group="processCounter"
            fieldId="164"
            fieldId="165" applicability="data" status="current">
       <description>
         <paragraph>
            The total number of octets in observed IP packets
            that the Metering Process did not process. process since the
            (re-)initialization of the Metering Process.
         </paragraph>
       </description>
       <units>octets</units>
     </field>

     <field name="notSentFlowTotalCount" dataType="unsigned64"
            dataTypeSemantics="totalCounter"
            group="processCounter"
            fieldId="165"
            fieldId="166" applicability="data" status="current">
       <description>
         <paragraph>
            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.
         </paragraph>
       </description>
       <units>Flows</units>
     </field>

     <field name="notSentPacketTotalCount" dataType="unsigned64"
            dataTypeSemantics="totalCounter"
            group="processCounter"
            fieldId="166" applicability="data" status="current">
       <description>



Quittek, et al.        Expires November 28, 2005       draft-ietf-ipfix-info-08.txt            [Page 92] 115]

Internet-Draft           IPFIX Information Model                 May               July 2005


     <field name="notSentPacketTotalCount" dataType="unsigned64"
            dataTypeSemantics="totalCounter"
            group="processCounter"
            fieldId="167" applicability="data" status="current">
       <description>
         <paragraph>
            The total number 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 Flow export policies.
         </paragraph>
       </description>
       <units>packets</units>
     </field>

     <field name="notSentOctetTotalCount" dataType="unsigned64"
            dataTypeSemantics="totalCounter"
            group="processCounter"
            fieldId="167"
            fieldId="168" applicability="data" status="current">
       <description>
         <paragraph>
            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 and special Flow export policies.
         </paragraph>
       </description>
       <units>octets</units>
     </field>

     <field name="flowKeyIndicator" dataType="unsigned64"
            dataTypeSemantics="flags"
            group="processCounter"
            fieldId="172"
            fieldId="173" applicability="all" status="current">
       <description>
         <paragraph>
         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 value 1 indicates that the corresponding
         Information element is a Flow Key of the reported Flow.
         A value of 0 indicates that this is not the case.  If the
         Data Record contains more than 64 Information Elements, the



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


         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



Quittek, et al.        Expires November 28, 2005               [Page 93]

Internet-Draft          IPFIX Information Model                 May 2005
         Element exists SHOULD have the value 0.
         </paragraph>
       </description>
     </field>

     <field name="lineCardId" dataType="unsigned32"
            group="scope"
            dataTypeSemantics="identifier"
            fieldId="141" applicability="option" status="current">
       <description>
         <paragraph>
           A locally unique identifier of a line card at an IPFIX
           Device hosting an Observation Point.  Typically, this
           Information Element is used for limiting the scope
           of other Information Elements.
         </paragraph>
       </description>
     </field>

     <field name="portId" dataType="unsigned32"
            group="scope"
            dataTypeSemantics="identifier"
            fieldId="142" applicability="option" status="current">
       <description>
         <paragraph>
           A locally unique identifier of a line port at an IPFIX
           Device hosting an Observation Point.  Typically, this
           Information Element is used for limiting the scope
           of other Information Elements.
         </paragraph>
       </description>
     </field>

     <field name="ingressInterface" dataType="unsigned32"
            group="scope"
            dataTypeSemantics="identifier"
            fieldId="10" applicability="all" status="current">
       <description>
         <paragraph>
           The index of the IP interface (ifIndex) where packets of
           this Flow are being received.
         </paragraph>
       </description>



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


       <reference>
         See RFC 2863 for the definition of the ifIndex object.
       </reference>
     </field>




Quittek, et al.        Expires November 28, 2005               [Page 94]

Internet-Draft          IPFIX Information Model                 May 2005

     <field name="egressInterface" dataType="unsigned32"
            group="scope"
            dataTypeSemantics="identifier"
            fieldId="14" applicability="all" status="current">
       <description>
         <paragraph>
           The index of the IP interface (ifIndex) where packets of
           this Flow are being sent.
         </paragraph>
       </description>
       <reference>
         See RFC 2863 for the definition of the ifIndex object.
       </reference>
     </field>

     <field name="meteringProcessId" dataType="unsigned32"
            group="scope"
            dataTypeSemantics="identifier"
            fieldId="143" applicability="option" status="current">
       <description>
         <paragraph>
           A locally unique identifier of a Metering Process
           at an IPFIX Device.  Typically, this
           Information Element is used for limiting the scope
           of other Information Elements.
         </paragraph>
       </description>
     </field>

     <field name="exportingProcessId" dataType="unsigned32"
            group="scope"
            dataTypeSemantics="identifier"
            fieldId="144" applicability="option" status="current">
       <description>
         <paragraph>
           A locally unique identifier of an Exporting Process
           at an IPFIX Device.  Typically, this
           Information Element is used for limiting the scope
           of other Information Elements.
         </paragraph>
       </description>
     </field>

     <field name="flowId" dataType="unsigned32"
            group="scope"
            dataTypeSemantics="identifier"
            fieldId="148" applicability="option" status="current">
       <description>




Quittek, et al.        Expires November 28, 2005       draft-ietf-ipfix-info-08.txt            [Page 95] 118]

Internet-Draft           IPFIX Information Model                 May               July 2005


     <field name="flowId" dataType="unsigned32"
            group="scope"
            dataTypeSemantics="identifier"
            fieldId="148" applicability="option" status="current">
       <description>
         <paragraph>
           An identifier of a Flow that is locally unique to an
           Exporting Process.  Typically, this Information Element is
           used for limiting the scope of other Information Elements.
         </paragraph>
       </description>
     </field>

     <field name="templateId" dataType="unsigned32"
            group="scope"
            dataTypeSemantics="identifier"
            fieldId="145" applicability="option" status="current">
       <description>
         <paragraph>
           An identifier of a Template that is locally unique to an
           Exporting Process.  Typically, this Information Element is
           used for limiting the scope of other Information Elements.
         </paragraph>
       </description>
     </field>

     <field name="sourceId" dataType="unsigned32"
            group="scope"
            dataTypeSemantics="identifier"
            fieldId="149" applicability="option" status="current">
       <description>
         <paragraph>
           An identifier of an Observation Domain that is locally
           unique to an Exporting Process.  Typically, this Information
           Element is used for limiting the scope of other Information
           Elements.
         </paragraph>
       </description>
     </field>

   </fieldDefinitions>

     <field name="paddingOneOctet" dataType="octet"
            group="padding"
            fieldId="210" applicability="option" status="current">
       <description>
         <paragraph>
           The value of this Information Element is always 0.
         </paragraph>
       </description>



Quittek, et al.        Expires November 28, 2005       draft-ietf-ipfix-info-08.txt            [Page 96] 119]

Internet-Draft           IPFIX Information Model                 May               July 2005


     </field>

   </fieldDefinitions>





Appendix B.  Formal Specification of Abstract Data Types

   This appendix containfs a formal description of the abstract data
   types to be used for IPFIX Information Elements and a formal
   description of the template used for defining IPFIX Information
   Elements.  Note that this appendix is of informational nature, while
   the text in sections 2 and 3 generated from this appendix is
   normative.



   <?xml version="1.0" encoding="UTF-8"?>
   <schema>
   <!-- <schema elementFormDefault="qualified"
           targetNamespace="http://www.ietf.org/ipfix"
           xmlns="http://www.w3.org/2001/XMLSchema"
           xmlns:ipfix="http://www.ietf.org/ipfix">  -->

     <simpleType name="dataType">
       <restriction base="string">
         <enumeration value="octet">
           <annotation>
             <documentation>The type "octet" represents a
               non-negative integer value in the range of 0 to 255.
             </documentation>
           </annotation>
         </enumeration>

         <enumeration value="unsigned16">
           <annotation>
             <documentation>The type "unsigned16" represents a
               non-negative integer value in the range of 0 to 65535.
             </documentation>
           </annotation>
         </enumeration>

         <enumeration value="unsigned32">
           <annotation>
             <documentation>The type "unsigned32" represents a
                non-negative integer value in the range of 0 to



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


                4294967295.
             </documentation>
           </annotation>
         </enumeration>

         <enumeration value="unsigned64">
           <annotation>
             <documentation>The type "unsigned64" represents a
               non-negative integer value in the range of 0 to



Quittek, et al.        Expires November 28, 2005               [Page 97]

Internet-Draft          IPFIX Information Model                 May 2005
               18446744073709551615.
             </documentation>
           </annotation>
         </enumeration>

         <enumeration value="float32">
           <annotation>
             <documentation>The type "float32" corresponds to an IEEE
               single-precision 32-bit floating point type as defined
               in [IEEE.754.1985].
             </documentation>
           </annotation>
         </enumeration>

         <enumeration value="boolean">
           <annotation>
             <documentation>The type "boolean" represents a binary
               value.  The only allowed values are "true" and false.
             </documentation>
           </annotation>
         </enumeration>

         <enumeration value="macAddress">
           <annotation>
             <documentation>The type "macAddress" represents a
               string of 6 octets.
             </documentation>
           </annotation>
         </enumeration>

         <enumeration value="octetArray">
           <annotation>
             <documentation>The type "octetArray" represents a finite
             length string of octets.
             </documentation>
           </annotation>
         </enumeration>

         <enumeration value="string">



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


           <annotation>
             <documentation>
               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



Quittek, et al.        Expires November 28, 2005               [Page 98]

Internet-Draft          IPFIX Information Model                 May 2005
               multi-byte characters.
             </documentation>
           </annotation>
         </enumeration>

         <enumeration value="dateTimeSeconds">
           <annotation>
             <documentation>
               The type "dateTimeSeconds" represents a time value
               having a precision of seconds and normalized to the
               GMT time zone.
             </documentation>
           </annotation>
         </enumeration>

         <enumeration value="dateTimeMilliSeconds">
           <annotation>
             <documentation>The type "dateTimeMilliSeconds" represents
               a time value having a precision of milliseconds and
               normalized to the GMT time zone.
             </documentation>
           </annotation>
         </enumeration>

         <enumeration value="dateTimeMicroSeconds">
           <annotation>
             <documentation>The type "dateTimeMicroSeconds" represents
               a time value having a precision of microseconds and
               normalized to the GMT time zone.
             </documentation>
           </annotation>
         </enumeration>

         <enumeration value="dateTimeNanoSeconds">
           <annotation>
             <documentation>The type "dateTimeNanoSeconds" represents a
               time value having a precision of nanoseconds and
               normalized to the GMT time zone.
             </documentation>



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


           </annotation>
         </enumeration>

         <enumeration value="ipv4Address">
           <annotation>
             <documentation>The type "ipv4Address" represents a value
               of an IPv4 address.
             </documentation>
           </annotation>



Quittek, et al.        Expires November 28, 2005               [Page 99]

Internet-Draft          IPFIX Information Model                 May 2005
         </enumeration>

         <enumeration value="ipv6Address">
           <annotation>
             <documentation>The type "ipv6Address" represents a value
               of an IPv6 address.
             </documentation>
           </annotation>
         </enumeration>
       </restriction>
     </simpleType>

     <simpleType name="dataTypeSemantics">
       <restriction base="string">
         <enumeration value="quantity">
           <annotation>
             <documentation>
               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.
             </documentation>
           </annotation>
         </enumeration>

         <enumeration value="totalCounter">
           <annotation>
             <documentation>
               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.  A running counter



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


               counts independently of the export of its value.
             </documentation>
           </annotation>
         </enumeration>

         <enumeration value="deltaCounter">
           <annotation>
             <documentation>
               An integral value reporting the value of a counter.



Quittek, et al.        Expires November 28, 2005              [Page 100]

Internet-Draft          IPFIX Information Model                 May 2005
               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.  A delta counter
               is reset to zero each time its value is exported.
             </documentation>
           </annotation>
         </enumeration>

         <enumeration value="identifier">
           <annotation>
             <documentation>
               An integral value which serves as an identifier.
               Specifically mathematical operations on two
               identifiers (aside from the equality operation) are
               meaningless. For example, Autonomous System ID 1 *
               Autonomous System ID 2 is meaningless.
             </documentation>
           </annotation>
         </enumeration>

         <enumeration value="flags">
           <annotation>
             <documentation>
               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.
             </documentation>
           </annotation>
         </enumeration>
       </restriction>
     </simpleType>

     <simpleType name="applicability">
       <restriction base="string">



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


         <enumeration value="data">
           <annotation>
             <documentation>
               Used for Information Elements that are applicable to
               flow records
               Flow Records only.
             </documentation>
           </annotation>
         </enumeration>




Quittek, et al.        Expires November 28, 2005              [Page 101]

Internet-Draft          IPFIX Information Model                 May 2005

         <enumeration value="option">
           <annotation>
             <documentation>
               Used for Information Elements that are applicable to
               option records only.
             </documentation>
           </annotation>
         </enumeration>

         <enumeration value="all">
           <annotation>
             <documentation>
               Used for Information Elements that are applicable to
               flow records
               Flow Records as well as to option records.
             </documentation>
           </annotation>
         </enumeration>
       </restriction>
     </simpleType>

     <simpleType name="status">
       <restriction base="string">
         <enumeration value="current">
           <annotation>
             <documentation>
               Indicates that the Information Element definition
               is that the definition is current and valid.
             </documentation>
           </annotation>
         </enumeration>

         <enumeration value="deprecated">
           <annotation>
             <documentation>
               Indicates that the Information Element definition is
               obsolete, but it permits new/continued implementation
               in order to foster interoperability with older/existing
               implementations.
             </documentation>



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


           </annotation>
         </enumeration>

         <enumeration value="obsolete">
           <annotation>
             <documentation>
               Indicates that the Information Element definition is
               obsolete and should not be implemented and/or can be
               removed if previously implemented.



Quittek, et al.        Expires November 28, 2005              [Page 102]

Internet-Draft          IPFIX Information Model                 May 2005
             </documentation>
           </annotation>
         </enumeration>
       </restriction>
     </simpleType>

   <!--
     <simpleType name="enumRange">
       <restriction base="string"/>
     </simpleType>
   -->

     <simpleType name="range">
       <restriction base="string"/>
     </simpleType>

     <complexType name="descriptionList">
       <sequence>
         <element maxOccurs="unbounded" minOccurs="1"
                  name="item" type="string">
           <annotation>
             <documentation>to be done ...</documentation>
           </annotation>
         </element>
       </sequence>
     </complexType>

     <complexType name="text" mixed="true">
       <sequence>
         <element maxOccurs="unbounded" minOccurs="0"
                  name="paragraph" type="string">
           <annotation>
             <documentation>to be done ...</documentation>
           </annotation>
         </element>
         <element maxOccurs="unbounded" minOccurs="0"
                  name="list" type="ipfix:descriptionList">
           <annotation>
             <documentation>to be done ...</documentation>



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


           </annotation>
         </element>
       </sequence>
     </complexType>

     <element name="fieldDefinitions">
       <complexType>
         <sequence>
           <element maxOccurs="unbounded" minOccurs="1" name="field">



Quittek, et al.        Expires November 28, 2005              [Page 103]

Internet-Draft          IPFIX Information Model                 May 2005
             <complexType>
               <sequence>
                 <element maxOccurs="1" minOccurs="1" name="description"
                          type="ipfix:text">
                   <annotation>
                     <documentation>
                       The semantics of this Information Element.
                       Describes how this Information Element is
                       derived from the flow Flow or other information
                       available to the observer.
                     </documentation>
                   </annotation>
                 </element>
   <!--
                 <element maxOccurs="1" minOccurs="0" name="usage"
                          type="ipfix:text">
                   <annotation>
                     <documentation>to be done ...</documentation>
                   </annotation>
                 </element>
   -->
                 <element maxOccurs="1" minOccurs="0" name="units"
                          type="string">
                   <annotation>
                     <documentation>
                       If the Information Element is a measure of some
                       kind, the units identify what the measure is.
                     </documentation>
                   </annotation>
                 </element>

                 <element maxOccurs="1" minOccurs="0" name="reference"
                          type="ipfix:text">
                   <annotation>
                     <documentation>
                       Identifies additional specifications which more
                       precisely define this item or provide additional
                       context for its use.
                     </documentation>



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


                   </annotation>
                 </element>

   <!--
                 <element maxOccurs="1" minOccurs="0"
                          name="enumeratedRange" type="ipfix:enumRange">
                   <annotation>
                     <documentation>
                       Some items may have a specific set of numeric



Quittek, et al.        Expires November 28, 2005              [Page 104]

Internet-Draft          IPFIX Information Model                 May 2005
                       identifiers associated with a set of discrete
                       values this Information Element may take. The
                       meaning of each discrete value and a human
                       readable name should be assigned.
                     </documentation>
                   </annotation>
                 </element>
   -->

                 <element maxOccurs="1" minOccurs="0" name="range"
                          type="ipfix:range">
                   <annotation>
                     <documentation>
                       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.
                     </documentation>
                   </annotation>
                 </element>
               </sequence>

               <attribute name="name" type="string" use="required">
                 <annotation>
                   <documentation>
                     A unique and meaningful name for the Information
                     Element.
                   </documentation>
                 </annotation>
               </attribute>

               <attribute name="dataType" type="ipfix:dataType"
                          use="required">
                 <annotation>
                   <documentation>
                     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



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


                     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.
                   </documentation>
                 </annotation>
               </attribute>



Quittek, et al.        Expires November 28, 2005              [Page 105]

Internet-Draft          IPFIX Information Model                 May 2005

               <attribute name="dataTypeSemantics"
                          type="ipfix:dataTypeSemantics" use="optional">
                 <annotation>
                   <documentation>
                     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.
                   </documentation>
                 </annotation>
               </attribute>

               <attribute name="elementId" type="nonNegativeInteger"
                          use="required">
                 <annotation>
                   <documentation>
                     A numeric identifier of the Information Element.
                     If this identifier is used without an enterprise
                     identifier (see 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.
                   </documentation>
                 </annotation>
               </attribute>

               <attribute name="enterpriseId" type="nonNegativeInteger"
                          use="optional">
                 <annotation>
                   <documentation>
                     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.



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


                     If specifications of enterprise-specific
                     Information Elements are 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.
                   </documentation>



Quittek, et al.        Expires November 28, 2005              [Page 106]

Internet-Draft          IPFIX Information Model                 May 2005
                 </annotation>
               </attribute>

               <attribute name="applicability"
                          type="ipfix:applicability" use="required">
                 <annotation>
                   <documentation>This propoerty of an Information
                   Element indicates in which kind of records the
                   Information Element can be used.
                   Allowed values for this property are 'data',
                   'option', and 'all'.</documentation>
                 </annotation>
               </attribute>

               <attribute name="status" type="ipfix:status"
                          use="required">
                 <annotation>
                   <documentation>The
                   <documentation>
                     The status of the specification of this
                     Information Element.  Allowed values are 'current',
                     'deprecated', and 'obsolete'.
                   </documentation>
                 </annotation>
               </attribute>

               <attribute name="group" type="string"
                          use="required">
                 <annotation>
                   <documentation>to be done ...</documentation>
                 </annotation>
               </attribute>

             </complexType>
           </element>
         </sequence>
       </complexType>




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


       <unique name="infoElementIdUnique">
         <selector xpath="field"/>

         <field xpath="infoElementId"/>
       </unique>
     </element>
   </schema>












































Quittek, et al.        Expires November 28, 2005       draft-ietf-ipfix-info-08.txt            [Page 107] 131]

Internet-Draft           IPFIX Information Model                 May               July 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Quittek, et al.        Expires November 28, 2005       draft-ietf-ipfix-info-08.txt            [Page 108] 132]

----