view Side-By-Side changes

Network Working Group                                         J. Quittek
Internet-Draft                                                       NEC
Expires: August 21, November 28, 2005                                     S. Bryant
                                                               B. Claise
                                                           Cisco Systems Ltd
                                                                J. Meyer
                                                                  PayPal
                                                       February 20,
                                                            May 30, 2005


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

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of 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 become becomes aware will be disclosed, in accordance with
   RFC 3668.
   Section 6 of BCP 79.

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

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

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

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

   This Internet-Draft will expire on August 21, November 28, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

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



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


   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 . . . . . . . . . . . . . . . . . . . . . . . .   5   6
   2.   Properties of IPFIX Protocol Information Elements  . . . . .   6   7
     2.1  Information Elements Specification Template  . . . . . . .   7
     2.2  Scope of Information Elements  . . . . . . . . . . . . . .   8
     2.3  Naming Conventions for Information Elements  . . . . . . .   8
   3.   Type Space . . . . . . . . . . . . . . . . . . . . . . . . .   8  10
     3.1  Data Types . . . . . . . . . . . . . . . . . . . . . . . .   8  10
       3.1.1  octet  . . . . . . . . . . . . . . . . . . . . . . . .   8  10
       3.1.2  unsigned16 . . . . . . . . . . . . . . . . . . . . . .   8  10
       3.1.3  unsigned32 . . . . . . . . . . . . . . . . . . . . . .   8  10
       3.1.4  unsigned64 . . . . . . . . . . . . . . . . . . . . . .   8  10
       3.1.5  float32  . . . . . . . . . . . . . . . . . . . . . . .   8  10
       3.1.6  boolean  . . . . . . . . . . . . . . . . . . . . . . .   8  10
       3.1.7  octetArray  macAddress . . . . . . . . . . . . . . . . . . . . . .   8  11
       3.1.8  string  octetArray . . . . . . . . . . . . . . . . . . . . . .  11
       3.1.9  string . . .   9
       3.1.9  dateTimeSeconds . . . . . . . . . . . . . . . . . . .   9
       3.1.10   dateTimeMicroSeconds . .  11
       3.1.10   dateTimeSeconds  . . . . . . . . . . . . . .   9
       3.1.11   ipv4Address . . . .  11
       3.1.11   dateTimeMilliSeconds . . . . . . . . . . . . . . . .   9  11
       3.1.12   ipv6Address  .   dateTimeMicroSeconds . . . . . . . . . . . . . . . .  11
       3.1.13   dateTimeNanoSeconds  . . .   9
     3.2  Data Type Semantics . . . . . . . . . . . . .  11
       3.1.14   ipv4Address  . . . . . .   9
       3.2.1  quantity . . . . . . . . . . . . . .  11
       3.1.15   ipv6Address  . . . . . . . . .   9
       3.2.2  totalCounter . . . . . . . . . . .  11
     3.2  Data Type Semantics  . . . . . . . . . .   9
       3.2.3  deltaCounter . . . . . . . . .  12
       3.2.1  quantity . . . . . . . . . . . .  10
       3.2.4  identifier . . . . . . . . . . .  12
       3.2.2  totalCounter . . . . . . . . . . .  10
       3.2.5  flags . . . . . . . . . .  12
       3.2.3  deltaCounter . . . . . . . . . . . . . .  10
   4.   Information Element Identifiers . . . . . . .  12
       3.2.4  identifier . . . . . . .  11
   5.   Information Elements . . . . . . . . . . . . . . .  12
       3.2.5  flags  . . . . .  13
     5.1  IP Header Fields . . . . . . . . . . . . . . . . . . .  12
   4.   Information Element Identifiers  . .  13
       5.1.1  ipVersion . . . . . . . . . . . .  13
   5.   Information Elements . . . . . . . . . .  13
       5.1.2  sourceIPv4Address . . . . . . . . . .  16
     5.1  Identifiers  . . . . . . . .  14
       5.1.3  sourceIPv6Address . . . . . . . . . . . . . . .  16
       5.1.1  lineCardId . . .  14
       5.1.4  sourceIPv4Mask . . . . . . . . . . . . . . . . . . .  17
       5.1.2  portId .  15
       5.1.5  sourceIPv6Mask . . . . . . . . . . . . . . . . . . . .  15
       5.1.6  sourceIPv4Prefix . . .  17
       5.1.3  ingressInterface . . . . . . . . . . . . . . . .  15
       5.1.7  destinationIPv4Address . . .  17
       5.1.4  egressInterface  . . . . . . . . . . . . .  16
       5.1.8  destinationIPv6Address . . . . . .  17
       5.1.5  meteringProcessId  . . . . . . . . . .  16
       5.1.9  destinationIPv4Mask . . . . . . . .  18
       5.1.6  exportingProcessId . . . . . . . . .  16
       5.1.10   destinationIPv6Mask . . . . . . . . .  18
       5.1.7  flowId . . . . . . .  16
       5.1.11   destinationIPv4Prefix . . . . . . . . . . . . . . .  17
       5.1.12   classOfServiceIPv4 . .  18
       5.1.8  templateId . . . . . . . . . . . . . . .  17
       5.1.13   classOfServiceV6 . . . . . . .  18
       5.1.9  sourceId . . . . . . . . . . .  18
       5.1.14   flowLabelV6 . . . . . . . . . . . .  19
     5.2  Metering and Exporting Process Properties  . . . . . . . .  18
       5.1.15   identificationV4 . .  19



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


       5.2.1  exporterIPv4Address  . . . . . . . . . . . . . . . .  18
       5.1.16   protocolIdentifier .  19
       5.2.2  exporterIPv6Address  . . . . . . . . . . . . . . . .  19
     5.2  Trandport Header Fields .  20
       5.2.3  exportedMessageTotalCount  . . . . . . . . . . . . . .  20
       5.2.4  exportedOctetTotalCount  . .  19



Quittek, et al.         Expires August 21, 2005                 [Page 2]

Internet-Draft          IPFIX Information Model            February 2005


       5.2.1  sourceTransportPort . . . . . . . . . . . . .  20
       5.2.5  exportedFlowTotalCount . . . .  19
       5.2.2  destinationtransportPort . . . . . . . . . . . .  20
       5.2.6  observedFlowTotalCount . . .  20
       5.2.3  icmpTypeCode . . . . . . . . . . . . .  21
       5.2.7  ignoredPacketTotalCount  . . . . . . . .  20
       5.2.4  igmpType . . . . . . .  21
       5.2.8  ignoredOctetTotalCount . . . . . . . . . . . . . . . .  21
     5.3  Sub-IP Header Fields
       5.2.9  notSentFlowTotalCount  . . . . . . . . . . . . . . . .  21
       5.2.10   notSentPacketTotalCount  . . .  21
       5.3.1  sourceMacAddress . . . . . . . . . . .  22
       5.2.11   notSentOctetTotalCount . . . . . . . .  21
       5.3.2  mplsLabelStackEntry1 . . . . . . .  22
       5.2.12   flowKeyIndicator . . . . . . . . . .  22
       5.3.3  mplsLabelStackEntry2 . . . . . . . .  22
     5.3  IP Header Fields . . . . . . . . .  22
       5.3.4  mplsLabelStackEntry3 . . . . . . . . . . . .  23
       5.3.1  ipVersion  . . . . .  22
       5.3.5  mplsLabelStackEntry4 . . . . . . . . . . . . . . . . .  23
       5.3.6  mplsLabelStackEntry5 .
       5.3.2  sourceIPv4Address  . . . . . . . . . . . . . . . .  23
       5.3.7  mplsLabelStackEntry6 . .  24
       5.3.3  sourceIPv6Address  . . . . . . . . . . . . . . .  23
       5.3.8  mplsLabelStackEntry7 . . .  24
       5.3.4  sourceIPv4Mask . . . . . . . . . . . . . .  24
       5.3.9  mplsLabelStackEntry8 . . . . . .  24
       5.3.5  sourceIPv6Mask . . . . . . . . . . .  24
       5.3.10   mplsLabelStackEntry9 . . . . . . . . .  24
       5.3.6  sourceIPv4Prefix . . . . . . .  24
       5.3.11   mplsLabelStackEntry10 . . . . . . . . . . . .  24
       5.3.7  sourceIPv6Prefix . . .  25
     5.4  Derived Packet Properties . . . . . . . . . . . . . . . .  25
       5.4.1  ipNextHopIPv4Address .
       5.3.8  destinationIPv4Address . . . . . . . . . . . . . . . .  25
       5.4.2  ipNextHopIPv6Address
       5.3.9  destinationIPv6Address . . . . . . . . . . . . . . . .  25
       5.3.10   destinationIPv4Mask  .  26
       5.4.3  ingressInterface . . . . . . . . . . . . . . .  25
       5.3.11   destinationIPv6Mask  . . . .  26
       5.4.4  egressInterface . . . . . . . . . . . .  25
       5.3.12   destinationIPv4Prefix  . . . . . . .  26
       5.4.5  ipNextHopAsNumber . . . . . . . .  26
       5.3.13   destinationIPv6Prefix  . . . . . . . . . .  27
       5.4.6  bgpSourceAsNumber . . . . .  26
       5.3.14   classOfServiceIPv4 . . . . . . . . . . . . .  27
       5.4.7  bgpDestinationAsNumber . . . .  26
       5.3.15   classOfServiceIPv6 . . . . . . . . . . . .  27
       5.4.8  bgpNextHopAsNumber . . . . .  26
       5.3.16   postClassOfServiceIPv4 . . . . . . . . . . . . .  28
       5.4.9  bgpNextHopIPv4Address . .  27
       5.3.17   postClassOfServiceIPv6 . . . . . . . . . . . . . .  28
       5.4.10   bgpNextHopIPv6Address .  27
       5.3.18   flowLabelIPv6  . . . . . . . . . . . . . .  28
       5.4.11   mplsTopLabelType . . . . .  27
       5.3.19   identificationIPv4 . . . . . . . . . . . . .  29
       5.4.12   mplsTopLabelIPv4Address . . . .  27
       5.3.20   protocolIdentifier . . . . . . . . . .  29
       5.4.13   mplsTopLabelIPv6Address . . . . . . .  28
       5.3.21   fragmentOffsetIPv4 . . . . . . .  29
     5.5  Properties of Metering/Exporting Process . . . . . . . . .  30
       5.5.1  exporterIPv4Address .  28
     5.4  Transport Header Fields  . . . . . . . . . . . . . . . .  30
       5.5.2  exporterIPv6Address .  28
       5.4.1  sourceTransportPort  . . . . . . . . . . . . . . . .  30
     5.6  Min/Max Flow Properties .  29
       5.4.2  destinationTransportPort . . . . . . . . . . . . . . .  29
       5.4.3  icmpTypeCodeIPv4 .  30
       5.6.1  minimumPacketLength . . . . . . . . . . . . . . . . .  31
       5.6.2  maximumPacketLength .  29
       5.4.4  icmpTypeCodeIPv6 . . . . . . . . . . . . . . . .  31
       5.6.3  minimumTTL . . .  30
       5.4.5  igmpType . . . . . . . . . . . . . . . . . . .  32
       5.6.4  maximumTTL . . . .  30
     5.5  Sub-IP Header Fields . . . . . . . . . . . . . . . . . .  32
       5.6.5  ipv6OptionHeaders .  30
       5.5.1  sourceMacAddress . . . . . . . . . . . . . . . . .  32
       5.6.6  tcpControlBits . .  31
       5.5.2  postDestinationMacAddr . . . . . . . . . . . . . . . .  31
       5.5.3  vlanId . .  33
       5.6.7  flowCreationTime . . . . . . . . . . . . . . . . . . .  33
       5.6.8  flowEndTime . . .  31
       5.5.4  postVlanId . . . . . . . . . . . . . . . . . .  34
       5.6.9  flowActiveTimeOut . . . .  31
       5.5.5  destinationMacAddress  . . . . . . . . . . . . . .  34
       5.6.10   flowInactiveTimeout . .  31
       5.5.6  postSourceMacAddress . . . . . . . . . . . . . .  34
       5.6.11   flowEndReason . . .  32
       5.5.7  wlanChannelId  . . . . . . . . . . . . . . . .  34
     5.7  Per-Flow Counters . . . .  32



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


       5.5.8  wlanSsid . . . . . . . . . . . . . . . .  35
       5.7.1  inOctetDeltaCount . . . . . . .  32
       5.5.9  mplsLabelStackEntry1 . . . . . . . . . . .  36
       5.7.2  outOctetDeltaCount . . . . . .  32
       5.5.10   mplsLabelStackEntry2 . . . . . . . . . . . .  36



Quittek, et al.         Expires August 21, 2005                 [Page 3]

Internet-Draft          IPFIX Information Model            February 2005


       5.7.3  octetDeltaCount . . . .  33
       5.5.11   mplsLabelStackEntry3 . . . . . . . . . . . . . . .  36
       5.7.4  inOctetTotalCount .  33
       5.5.12   mplsLabelStackEntry4 . . . . . . . . . . . . . . . .  33
       5.5.13   mplsLabelStackEntry5 .  37
       5.7.5  inPacketDeltaCount . . . . . . . . . . . . . . .  34
       5.5.14   mplsLabelStackEntry6 . . .  37
       5.7.6  outPacketDeltaCount . . . . . . . . . . . . .  34
       5.5.15   mplsLabelStackEntry7 . . . .  37
       5.7.7  packetDeltaCount . . . . . . . . . . . .  34
       5.5.16   mplsLabelStackEntry8 . . . . . . .  38
       5.7.8  inPacketTotalCount . . . . . . . . .  34
       5.5.17   mplsLabelStackEntry9 . . . . . . . . .  38
       5.7.9  droppedOctetDeltaCount . . . . . . .  35
       5.5.18   mplsLabelStackEntry10  . . . . . . . . .  38
       5.7.10   droppedOctetTotalCount . . . . . .  35
     5.6  Derived Packet Properties  . . . . . . . . .  39
       5.7.11   droppedPacketDeltaCount . . . . . . .  35
       5.6.1  ipNextHopIPv4Address . . . . . . .  39
       5.7.12   droppedPacketTotalCount . . . . . . . . . .  36
       5.6.2  ipNextHopIPv6Address . . . .  40
       5.7.13   outMulticastPacketCount . . . . . . . . . . . . .  36
       5.6.3  bgpSourceAsNumber  .  40
       5.7.14   outMulticastOctetCount . . . . . . . . . . . . . . .  40
     5.8  Process Counters . .  36
       5.6.4  bgpDestinationAsNumber . . . . . . . . . . . . . . . .  36
       5.6.5  bgpNextAdjacentAsNumber  . . .  41
       5.8.1  observedFlowTotalCount . . . . . . . . . . . .  37
       5.6.6  bgpPrevAdjacentAsNumber  . . . .  41
       5.8.2  exportedOctetTotalCount . . . . . . . . . . .  37
       5.6.7  bgpNextHopIPv4Address  . . . .  41
       5.8.3  exportedPacketTotalCount . . . . . . . . . . . .  38
       5.6.8  bgpNextHopIPv6Address  . . .  42
       5.8.4  exportedFlowTotalCount . . . . . . . . . . . . .  38
       5.6.9  mplsTopLabelType . . .  42
   6.   Extending the Information Model . . . . . . . . . . . . . .  43
   7.   IANA Considerations . .  38
       5.6.10   mplsTopLabelIPv4Address  . . . . . . . . . . . . . .  38
       5.6.11   mplsTopLabelIPv6Address  . . . .  44
   8.   Security Considerations . . . . . . . . . .  39
     5.7  Min/Max Flow Properties  . . . . . . . .  45
   9.   Acknowledgements . . . . . . . . .  39
       5.7.1  minimumPacketLength  . . . . . . . . . . . . .  46
   10.  References . . . .  39
       5.7.2  maximumPacketLength  . . . . . . . . . . . . . . . . .  39
       5.7.3  minimumTtl . . . .  47
   10.1   Normative Reference . . . . . . . . . . . . . . . . . .  40
       5.7.4  maximumTtl .  47
   10.2   Informative Reference . . . . . . . . . . . . . . . . . .  47
        Authors' Addresses . . .  40
       5.7.5  ipv6OptionHeaders  . . . . . . . . . . . . . . . . . .  48
   A.   Formal Specification of IPFIX Fields  40
       5.7.6  tcpControlBits . . . . . . . . . . . .  50
   B.   Formal Specification of Abstract Data Types . . . . . . . .  74
        Intellectual Property and Copyright Statements  41
     5.8  Flow Time Stamps . . . . . . .  85























Quittek, et al.         Expires August 21, 2005                 [Page 4]

Internet-Draft          IPFIX Information Model            February 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 [IPFIX-PROTO] defines how
   information elements are transmitted.  For . . . . . . . . . . . . . .  41
       5.8.1  flowStartSeconds . . . . . . . . . . . . . . . . . . .  42
       5.8.2  flowEndSeconds . . . . . . . . . . . . . . . . . . . .  42
       5.8.3  flowStartMilliSeconds  . . . . . . . . . . . . . . . .  42
       5.8.4  flowEndMilliSeconds  . . . . . . . . . . . . . . . . .  43
       5.8.5  flowStartMicroSeconds  . . . . . . . . . . . . . . . .  43
       5.8.6  flowEndMicroSeconds  . . . . . . . . . . . . . . . . .  43
       5.8.7  flowStartNanoSeconds . . . . . . . . . . . . . . . . .  43
       5.8.8  flowEndNanoSeconds . . . . . . . . . . . . . . . . . .  43
       5.8.9  flowStartDeltaMicroSeconds . . . . . . . . . . . . . .  44
       5.8.10   flowEndDeltaMicroSeconds . . . . . . . . . . . . . .  44
       5.8.11   systemInitTimeMilliSeconds . . . . . . . . . . . . .  44
       5.8.12   flowStartSysUpTime . . . . . . . . . . . . . . . . .  44
       5.8.13   flowEndSysUpTime . . . . . . . . . . . . . . . . . .  44
     5.9  Per-Flow Counters  . . . . . . . . . . . . . . . . . . . .  45
       5.9.1  octetDeltaCount  . . . . . . . . . . . . . . . . . . .  45
       5.9.2  postOctetDeltaCount  . . . . . . . . . . . . . . . . .  46
       5.9.3  octetTotalCount  . . . . . . . . . . . . . . . . . . .  46



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


       5.9.4  postOctetTotalCount  . . . . . . . . . . . . . . . . .  46
       5.9.5  packetDeltaCount . . . . . . . . . . . . . . . . . . .  46
       5.9.6  postPacketDeltaCount . . . . . . . . . . . . . . . . .  47
       5.9.7  packetTotalCount . . . . . . . . . . . . . . . . . . .  47
       5.9.8  postPacketTotalCount . . . . . . . . . . . . . . . . .  47
       5.9.9  droppedOctetDeltaCount . . . . . . . . . . . . . . . .  47
       5.9.10   droppedPacketDeltaCount  . . . . . . . . . . . . . .  48
       5.9.11   droppedOctetTotalCount . . . . . . . . . . . . . . .  48
       5.9.12   droppedPacketTotalCount  . . . . . . . . . . . . . .  48
       5.9.13   postMulticastPacketCount . . . . . . . . . . . . . .  49
       5.9.14   postMulticastOctetCount  . . . . . . . . . . . . . .  49
     5.10   Miscellaneous Flow Properties  . . . . . . . . . . . . .  49
       5.10.1   flowActiveTimeOut  . . . . . . . . . . . . . . . . .  49
       5.10.2   flowInactiveTimeout  . . . . . . . . . . . . . . . .  50
       5.10.3   flowEndReason  . . . . . . . . . . . . . . . . . . .  50
       5.10.4   flowDurationMilliSeconds . . . . . . . . . . . . . .  50
       5.10.5   flowDurationMicroSeconds . . . . . . . . . . . . . .  50
   6.   Extending the Information Model  . . . . . . . . . . . . . .  51
   7.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .  52
   8.   Security Considerations  . . . . . . . . . . . . . . . . . .  53
   9.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  54
   10.  Open Issues  . . . . . . . . . . . . . . . . . . . . . . . .  55
   11.  References . . . . . . . . . . . . . . . . . . . . . . . . .  56
   11.1   Normative Reference  . . . . . . . . . . . . . . . . . . .  56
   11.2   Informative Reference  . . . . . . . . . . . . . . . . . .  56
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  58
   A.   Formal Specification of IPFIX Information Element  . . . . .  60
   B.   Formal Specification of Abstract Data Types  . . . . . . . .  97
        Intellectual Property and Copyright Statements . . . . . . . 108






















Quittek, et al.        Expires November 28, 2005                [Page 5]

Internet-Draft          IPFIX Information Model                 May 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 attributes (source IP address, number of
   packets, etc.) and information about the Metering and Exporting
   Process (packet Observation Point, sampling rate, flow timeout
   interval, etc.), is not specified in [I-D.ietf-ipfix-protocol].

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

   The main part of this document is section 5 defining the (extensible)
   list of Information Elements to be transmitted by the IPFIX protocol.
   Section 2 defines a template for specifying IPFIX Information
   Elements in section 4.  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.







Quittek, et al.        Expires November 28, 2005                [Page 6]

Internet-Draft          IPFIX Information Model                 May 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 or other
      information available to the observer.

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

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


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

   enterpriseId - Enterprises may wish to define Information Elements
      without registering them with IANA, for example for
      enterprise-internal purposes.  For such Information Elements the
      Information Element identifier described above is not sufficient
      when the Information Element is used outside the enterprise.  If
      specifications of enterprise-specific Information Elements are
      made public and/or if enterprise-specific identifiers are used by
      the IPFIX protocol outside the enterprise, then the
      enterprise-specific identifier MUST be made globally unique by
      combining it with an enterprise identifier.  Valid values for the
      enterpriseId are defined by IANA as SMI network management private
      enterprise codes.  They are defined at
      http://www.iana.org/assignments/enterprise-numbers.



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




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

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

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

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

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


2.2  Scope of Information Elements

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

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

   Within Data Records defined by Option Templates, the IPFIX protocol
   allows further limiting of the Information Element scope.  The new
   scope is specified by one or more scope fields and defined as the
   combination of all specified scope values.

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.
   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, even for acronyms.  Exceptions are made for
      acronyms containing non-capitalized letter, such as 'IPv4' and
      'IPv6'.  Examples are sourceMacAddress and destinationIPv4Address.
   o  Middleboxes [RFC3234] may change flow properties, such as the DSCP
      value or the source IP address.  There are different Information
      Elements required for the original values of these properties and
      for the modified values.  As a general rule, it is recommended
      that names for Information Elements containing the original
      properties have no specific prefix while names of Information
      Elements containing the modified properties have the prefix
      "post", for example, postClassOfServiceIPv4.








































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


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.

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

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.

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.




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


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

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

   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.

   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]



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


   +-------+-------------------------+-------+-------------------------+
   |    ID | Name                    |    ID | Name                    |
   +-------+-------------------------+-------+-------------------------+
   |     1 | octetDeltaCount         |    43 | RESERVED                |
   |     2 | packetDeltaCount        |    44 | sourceIPv4Prefix        |
   |     3 | observedFlowTotalCount  |    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 | ipVersion               |
   |    16 | bgpSourceAsNumber       |    61 | RESERVED                |
   |    17 | bgpDestinationAsNumber  |    62 | ipNextHopIPv6Address    |
   |    18 | bgpNexthopIPv4Address   |    63 | bgpNexthopIPv6Address   |
   |    19 | postMulticastPacketCount|    64 | ipv6OptionHeaders       |
   |    20 | postMulticastOctetCount | 65-69 | RESERVED                |
   |    21 | flowEndSysUpTime        |    70 | mplsLabelStackEntry1    |
   |    22 | flowStartSysUpTime      |    71 | mplsLabelStackEntry2    |
   |    23 | postOctetDeltaCount     |    72 | mplsLabelStackEntry3    |
   |    24 | postPacketDeltaCount    |    73 | mplsLabelStackEntry4    |
   |    25 | minimumPacketLength     |    74 | mplsLabelStackEntry5    |
   |    26 | maximumPacketLength     |    75 | mplsLabelStackEntry6    |
   |    27 | sourceIPv6Address       |    76 | mplsLabelStackEntry7    |
   |    28 | destinationIPv6Address  |    77 | mplsLabelStackEntry8    |
   |    29 | sourceIPv6Mask          |    78 | mplsLabelStackEntry9    |
   |    30 | destinationIPv6Mask     |    79 | mplsLabelStackEntry10   |
   |    31 | flowLabelIPv6           |    80 | destinationMacAddress   |
   |    32 | icmpTypeCodeIPv4        |    81 | postSourceMacAddress    |
   |    33 | igmpType                | 82-84 | RESERVED                |
   | 34-35 | RESERVED                |    85 | octetTotalCount         |
   |    36 | flowActiveTimeOut       |    86 | packetTotalCount        |
   |    37 | flowInactiveTimeout     |    87 | RESERVED                |
   | 38-39 | RESERVED                |    88 | fragmentOffsetIPv4      |
   |    40 | exportedOctetTotalCount |89-127 | RESERVED                |
   |    41 | exportedMessageTotalCount|      |                         |
   |    42 | exportedFlowTotalCount  |       |                         |
   +-------+-------------------------+-------+-------------------------+

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



Quittek, et al.        Expires November 28, 2005               [Page 14]

Internet-Draft          IPFIX 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  |
   | 140 | mplsTopLabelIPv6Address   | 162 | flowDurationMicroSeconds  |
   | 141 | lineCardId                | 163 | ignoredPacketTotalCount   |
   | 142 | portId                    | 164 | ignoredOctetTotalCount    |
   | 143 | meteringProcessId         | 165 | notSentFLowTotalCount     |
   | 144 | exportingProcessId        | 166 | notSentPacketTotalCount   |
   | 145 | templateId                | 167 | notSentOctetTotalCount    |
   | 146 | wlanChannelId             | 168 | destinationIPv6Prefix     |
   | 147 | wlanSsid                  | 169 | sourceIPv6Prefix          |
   | 148 | flowId                    | 170 | postOctetTotalCount       |
   | 149 | sourceId                  | 171 | postPacketTotalCount      |
   |     |                           | 172 | flowKeyIndicator          |
   +-----+---------------------------+-----+---------------------------+
























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


5.  Information Elements

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

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

   The Information Elements that are derived from fields of packets or
   from packet treatment, such as the Information Elements in groups
   3.-6., can serve as Flow Keys used for mapping packets to flows.  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 Information Elements that are derived from fields of packets
   or from packet treatment, the IPFIX information elements, it model makes the
   general assumption that their value is determined by the first packet
   observed for the corresponding Flow, unless the description of the
   Information Element explicitly specifies a different semantics.  This
   simple rule allows writing all Information Elements related to header
   fields once when the first packet of the flow is observed.  For
   further observed packets of the same flow, only flow properties that
   depend on more than one packet, such as the Information Elements in
   groups 7.-9., need to be updated.

5.1  Identifiers

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


   +-----+---------------------------+-----+---------------------------+
   |  ID | Name                      |  ID | Name                      |
   +-----+---------------------------+-----+---------------------------+
   | 141 | lineCardId                | 143 | meteringProcessId         |
   | 142 | portId                    | 144 | exportingProcessId        |
   |  10 | ingressInterface          | 148 | flowId                    |
   |  14 | egressInterface           | 145 | templateId                |
   |     |                           | 149 | 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               [Page 17]

Internet-Draft          IPFIX Information Model                 May 2005


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

5.1.5  meteringProcessId

   Description:
      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.
   Abstract Data Type: unsigned32
   Data Type Semantics: identifier
   ElementId: 143
   Status: current

5.1.6  exportingProcessId

   Description:
      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.
   Abstract Data Type: unsigned32
   Data Type Semantics: identifier
   ElementId: 144
   Status: current

5.1.7  flowId

   Description:
      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.
   Abstract Data Type: unsigned32
   Data Type Semantics: identifier
   ElementId: 148
   Status: current

5.1.8  templateId

   Description:






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


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

5.1.9  sourceId

   Description:
      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.
   Abstract Data Type: unsigned32
   Data Type Semantics: identifier
   ElementId: 149
   Status: current

5.2  Metering and Exporting Process Properties

   Information Elements in this section describe static and dynamic
   properties of the Metering Process and/or the Exporting Process.  The
   set of basic data types.  However, these Information Elements is listed in the
   list table below

   +-----+---------------------------+-----+---------------------------+
   |  ID | Name                      |  ID | Name                      |
   +-----+---------------------------+-----+---------------------------+
   | 130 | exporterIPv4Address       | 163 | ignoredPacketTotalCount   |
   | 131 | exporterIPv6Address       | 164 | ignoredOctetTotalCount    |
   |  41 | exportedMessageTotalCount | 165 | notSentFLowTotalCount     |
   |  40 | exportedOctetTotalCount   | 166 | notSentPacketTotalCount   |
   |  42 | exportedFlowTotalCount    | 167 | notSentOctetTotalCount    |
   |   3 | observedFlowTotalCount    | 172 | flowKeyIndicator          |
   +-----+---------------------------+-----+---------------------------+


5.2.1  exporterIPv4Address

   Description:
      The IPv4 address used by the Exporting Process.  This is used by
      the Collector to identify the Exporter in cases where the identity
      of fields that can be transmitted the Exporter may have been obscured by the protocol, such as flow
   attributes (source IP address, use of a proxy.
   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
   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 packets, etc.) and
   information about IPFIX Messages that the Metering and Exporting Process (packet
   Observation Point, smapling rate, flow timeout interval, etc.), is
   not specified in [IPFIX-PROTO].

   This document complements
      successfully sent since the IPFIX protocol specification by
   providing Exporting Process (re-)initialization
      to the IPFIX information model.  IPFIX-specific terminology
   used in Collecting Process receiving a report that contains this document including terms such as 'IP Traffic Flow',
   'Observation Point', 'Metering Process', 'Exporting Process', and
   'Collecting Process' is defined in [IPFIX-PROTO].
      Information Element.
   Abstract Data Type: unsigned64
   Data Type Semantics: totalCounter
   ElementId: 41
   Status: current
   Units: messages

5.2.4  exportedOctetTotalCount

   Description:
      The main part total number of this document is Section 5 defining octets that the (extensible)
   list of fields Exporting Process successfully
      sent since the Exporting Process (re-)initialization to be transmitted by the IPFIX protcol.  Section 2
   defines
      Collecting Process receiving a template for specifying IPFIX fields report that contains this
      Information Element.  The value of this Information Element is used in
   Section 4.  Section 3 defines
      calculated by summing up the set of abstract data types that are
   available for IPFIX fields.  Section 5 discusses extensibility Message header length values of the
      all IPFIX information model.

   The main bodies of Sections 2, 3 and 4 messages that were generated from XML
   documents.  The XML-based specification of template, abstract data
   types and IPFIX fields can be used for automatically checking
   syntactical correctness of successfully sent to the specification of IPFIX fields.  It can
   further be used for generating IPFIX protocol implementation code
   that deals with processing IPFIX fields.  Also code for applications Collecting
      Process receiving a report that further process traffic information transmitted via the IPFIX
   protocol can be generated with the XML specification of contains this Information Element.
   Abstract Data Type: unsigned64
   Data Type Semantics: totalCounter
   ElementId: 40
   Status: current
   Units: octets

5.2.5  exportedFlowTotalCount







Quittek, et al.        Expires November 28, 2005               [Page 20]

Internet-Draft          IPFIX fields.

   For Information Model                 May 2005


   Description:
      The total number of Flows Records reported that reason, the XML document that served Exporting
      Process successfully sent as source for Section 4
   and Data Records since the XML schema that served as source for Sections 2 and 3 are
   attached Exporting
      Process (re-)initialization to the Collecting Process receiving a
      report that contains this document Information Element.
   Abstract Data Type: unsigned64
   Data Type Semantics: totalCounter
   ElementId: 42
   Status: current
   Units: Flows

5.2.6  observedFlowTotalCount

   Description:
      The total number of Flows observed in Appendices A and B.

   Note that although partially generated from the attached XML
   documents, Observation Domain since
      the main body of Metering Process (re-)initialization for this document is normative while Observation
      Point.
   Abstract Data Type: unsigned64
   Data Type Semantics: totalCounter
   ElementId: 3
   Status: current
   Units: Flows

5.2.7  ignoredPacketTotalCount

   Description:
      The total number of observed IP packets that the
   appendices are informational. Metering Process
      did not process.
   Abstract Data Type: unsigned64
   Data Type Semantics: totalCounter
   ElementId: 163
   Status: current
   Units: packets

5.2.8  ignoredOctetTotalCount

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

5.2.9  notSentFlowTotalCount





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


2.  Properties of IPFIX Protocol Information Elements

   Fields in messages


   Description:
      The total number of Flow Records that were generated by the IPFIX protocol carrying information about
   traffic measurement are modeled as elements
      Metering Process and but dropped by the Metering Process or by the
      Exporting Process instead of sending it to the IPFIX information
   model and specified in Section 4.  For defining these information
   elements, a template is used that is specified below.

   All information elements specified Collecting Process.
      There are several potential reasons for the IPFIX protocol either this including resource
      shortage and special Flow export policies.
   Abstract Data Type: unsigned64
   Data Type Semantics: totalCounter
   ElementId: 165
   Status: current
   Units: Flows

5.2.10  notSentPacketTotalCount

   Description:
      The total number of packets in
   this document or Flow Records that were generated by any future extension MUST have
      the following
   properties defined:
   name - A unique Metering Process and meaningful name for but dropped by the information element.  The
      preferred spelling for Metering Process or by
      the name is Exporting Process instead of sending it to use mixed case if the name
      is compound, with an initial lower case letter, e.g.,
      "sourceIpAddress".
   fieldId - A numeric identifier administered by IANA.  This is used Collecting
      Process.  There are several potential reasons for compact identification this including
      resource shortage and special flow export policies.
   Abstract Data Type: unsigned64
   Data Type Semantics: totalCounter
   ElementId: 166
   Status: current
   Units: packets

5.2.11  notSentOctetTotalCount

   Description:
      The total number of an information item when encoding
      templates octets in  packets in Flow Records that were
      generated by the protocol.
   description - The semantics of this information element.  Describes
      how this field is derived from Metering Process and but dropped by the flow Metering
      Process or other information
      available to the observer.
   dataType - One of by the types listed in section 3.1 of this document or
      in an extension Exporting Process instead of the information model.  The type space for
      attributes is constrained sending it 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 IPAddress) which the
      Collecting Process.  There are common to several potential reasons for this domain
      including resource shortage and useful to
      distinguish.
   applicability - special Flow export policies.
   Abstract Data Type: unsigned64
   Data Type Semantics: totalCounter
   ElementId: 167
   Status: current
   Units: octets

5.2.12  flowKeyIndicator

   Description:
      This propoerty 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 Information Element in the Data Record with the n-th
      bit representing the n-th Information Element.  A set bit with
      value 1 indicates in
      which kind of records that the corresponding Information element can be used.  Allowed values for
      this property are 'data', 'option', and 'all'.
   status - The status is a



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


      Flow Key of the specification reported Flow.  A value of 0 indicates that this information element.
      Allowed values
      is not the case.  If the Data Record contains more than 64
      Information Elements, the corresponding Template SHOULD be
      designed such that all Flow Keys are 'current', 'deprecated', and 'obsolete'.

   All information elements specified for among the IPFIX protocol either 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
   this document or by any future extension MAY the flowKeyIndicator for which no
      corresponding Information Element exists SHOULD have the following
   properties defined:
   enterpriseId - When extension is done outside value 0.
   Abstract Data Type: unsigned64
   Data Type Semantics: flags
   ElementId: 172
   Status: current

5.3  IP Header Fields

   Information Elements in this section indicate values of IP header
   fields or are derived from IP header field values in combination with
   further information.

   +-----+---------------------------+-----+---------------------------+
   |  ID | Name                      |  ID | Name                      |
   +-----+---------------------------+-----+---------------------------+
   |  60 | ipVersion                 |  45 | destinationIPv4Prefix     |
   |   8 | sourceIPv4Address         | 168 | destinationIPv6Prefix     |
   |  27 | sourceIPv6Address         |   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: The IP version field in the scope IP packet header.
   Abstract Data Type: octet
   Data Type Semantics: identifier
   ElementId: 60
   Status: current
   Reference:
      See RFC 791 for a definition of the
      IANA IPFIX fieldId range, a enterpriseId MUST be provided.  Valid
      values for version field in the enterpriseId are defined by IANA as SMI network
      management private enterprise code.  They are defined at
      http://www.iana.org/assignments/enterprise-numbers.
   dataTypeSemantics - The integral types may be qualified by additional
      semantic details.  Valid values IPv4
      packet header.  See RFC 2460 for the data type semantics are
      specified in section 3.2 a definition of this document or the version field
      in an extension of the IPv6 packet header.  Additional information model. on defined
      version numbers can be found at



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


   units - If


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

5.3.2  sourceIPv4Address

   Description:
      The IPv4 source address in the field is a measure IP packet header.
   Abstract Data Type: ipv4Address
   Data Type Semantics: identifier
   ElementId: 8
   Status: current
   Reference: See RFC 791 for the definition of some kind, the units identify
      what IPv4 source address
      field.

5.3.3  sourceIPv6Address

   Description:
      The IPv6 source address in the measure is.
   enumeratedRange - Some items may have a specific set of numeric
      identifiers associated with a set of discrete values this element
      may take. IP packet header.
   Abstract Data Type: ipv6Address
   Data Type Semantics: identifier
   ElementId: 27
   Status: current

5.3.4  sourceIPv4Mask

   Description:
      The meaning of each discrete value and a human readable
      name should be assigned.
   range - Some elements may only be able to take on a restricted set number of
      values which can be expressed as a contiguous bits that are relevant in the
      sourceIPv4Prefix Information Element.
   Abstract Data Type: octet
   ElementId: 9
   Status: current
   Units: bits
   Range: The valid range (e.g.  0 through 511
      inclusive).  If this is 0-32.

5.3.5  sourceIPv6Mask

   Description:
      The number of contiguous bits that are relevant in the case, the
      sourceIPv6Prefix Information Element.
   Abstract Data Type: octet
   ElementId: 29
   Status: current
   Units: bits
   Range: The valid inclusive range should
      be specified.
   reference - Identifies additional specifications which more precisely
      define this item or provide additional context for its use. is 0-128.

5.3.6  sourceIPv4Prefix






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


3.  Type Space

   This section describes the abstract data types that can be used for
   the specification of IPFIX fields in Section 4.  Section 3.1
   describes the set of data types.  For the integral data types octet,
   unsigned16, unsigned32, and unsigned64 also data type semantics can
   be specified, such as, for example, 'counter', 'identifier' or
   'flags'.


   Description:
      IPv4 source address prefix.
   Abstract Data type semantics are specified in section 3.2.

3.1 Type: ipv4Address
   ElementId: 44
   Status: current

5.3.7  sourceIPv6Prefix

   Description:
      IPv6 source address prefix.
   Abstract 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
   protocol extensions.

3.1.1  octet

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

3.1.2  unsigned16 Type: ipv4Address
   ElementId: 169
   Status: current

5.3.8  destinationIPv4Address

   Description:
      The type "unsigned16" represents a non-negative integer value IPv4 destination address in the
   range of 0 to 65535.

3.1.3  unsigned32

   The type "unsigned32" represents a non-negative integer value in IP packet header.
   Abstract Data Type: ipv4Address
   Data Type Semantics: identifier
   ElementId: 12
   Status: current
   Reference: See RFC 791 for the
   range definition of 0 to 4294967295.

3.1.4  unsigned64 the IPv4 destination
      address field.

5.3.9  destinationIPv6Address

   Description:
      The type "unsigned64" represents a non-negative integer value IPv6 destination address 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.

3.1.6  boolean

   The type "boolean" represents a binary value.

3.1.7  octetArray IP packet header.
   Abstract Data Type: ipv6Address
   Data Type Semantics: identifier
   ElementId: 28
   Status: current

5.3.10  destinationIPv4Mask

   Description:
      The type "octetArray" represents a finite length string number of octets. contiguous bits that are relevant in the
      destinationIPv4Prefix Information Element.
   Abstract Data Type: octet
   ElementId: 13
   Status: current
   Units: bits
   Range: The valid range is 0-32.

5.3.11  destinationIPv6Mask





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


3.1.8  string


   Description:
      The type "string" represents a finite length string number of valid
   characters from the Unicode character encoding set.  Unicode allows
   for ASCII and many other international character sets to be used.  It
   is expected contiguous bits that strings will be encoded in UTF-8 format, which is
   identical in encoding for USASCII characters, but also accomodates
   other Unicode multibyte characters.

3.1.9  dateTimeSeconds

   The type "dateTimeSeconds" represents a time value having a precision
   of seconds and normalized to the GMT timezone.  Such types are relevant in
   common use on many operating systems and have the advantage that they
   can be stored in 32-bit integers.

3.1.10  dateTimeMicroSeconds
      destinationIPv6Prefix Information Element.
   Abstract Data Type: octet
   ElementId: 30
   Status: current
   Units: bits
   Range: The type "dateTimeSeconds" represents a time value having a precision
   of microseconds and normalized to the GMT timezone.

3.1.11 valid range is 0-128.

5.3.12  destinationIPv4Prefix

   Description:
      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

   Description:
      The type "ipv4Addr" represents a value of an the IPv4 address.  These
   addresses are typically stored as 32-bit integers.

3.1.12  ipv6Address

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


3.2 TOS field in the IP packet header.
   Abstract Data Type: octet
   Data Type Semantics

   This section describes Semantics: identifier
   ElementId: 5
   Status: current
   Reference: See RFC 791 for the set of valid data type semantics definition of the
   IPFIX information model.  Note that further data type semantics may
   be specified by 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 IPv4 TOS field.

5.3.15  classOfServiceIPv6

   Description:
      The value whose "odometer" reading is captured as part of a given record.  If no semantic qualifier is given, the integral
   fields should behave as a quantity.

3.2.2  totalCounter

   A measurement which is ongoing from IPv6 traffic class field in the IP packet header.
   Abstract Data Type: octet
   Data Type Semantics: identifier
   ElementId: 137
   Status: current
   Reference: See RFC 2460 for the perspective definition of the Exporter. IPv6 traffic class
      field.






Quittek, et al.        Expires August 21, November 28, 2005               [Page 9] 26]

Internet-Draft          IPFIX Information Model            February                 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


5.3.16  postClassOfServiceIPv4

   Description:
      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 independent of IPv4 TOS field in the IP packet header after
      packet treatment by a middlebox function.
   Abstract Data Type: octet
   Data Type Semantics: identifier
   ElementId: 55
   Status: current
   Reference: See RFC 791 for the export definition of its
   value.

3.2.3  deltaCounter

   A measurement which is ongoing from the perspective of IPv4 TOS field.  See
      RFC 3234 for the Exporter.
   Basically definition of middleboxes.

5.3.17  postClassOfServiceIPv6

   Description:
      The value of the same semantics as counters IPv6 traffic class field in SNMP.  Counters are
   unsigned and wrap back to zero the IP packet header
      after reaching packet treatment by a middlebox function.
   Abstract Data Type: octet
   Data Type Semantics: identifier
   ElementId: 138
   Status: current
   Reference: See RFC 2460 for the limit definition of the type.
   For example, an unsigned64 with counter semantics will continue to
   increment until reaching the IPv6 traffic class
      field.

5.3.18  flowLabelIPv6

   Description:
      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 IPv6 Flow Label field in the IP packet header.
   Abstract Data Type: unsigned32
   Data Type Semantics: identifier

   An integral value which serves as an identifier.  Specifically
   mathematical operations on two identifiers (aside from
   ElementId: 31
   Status: current
   Reference: See RFC 2460 for a definition of the equality
   operation) are meaningless.  For example, Autonomous System Id 1 *
   Autonomous System Id 2 is meaningless.

3.2.5  flags

   An integral flow label field in
      the IPv6 packet header.

5.3.19  identificationIPv4

   Description:
      The 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 the IPv4 packet identification field in the IP packet
      header.
   Abstract Data Type: unsigned16
   Data Type Semantics: identifier
   ElementId: 54
   Status: current
   Reference: See RFC 791 for the definition of an unsigned type. the IPv4 identification
      field.





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


4.  Information Element Identifiers


5.3.20  protocolIdentifier

   Description:
      The elements value of this information model are identified by the
   combination of a field identifier and an optional enterprise
   identifier.

   Standardized information elements defined in section 5 of this
   document or protocol number in extensions of the IPFIX information model have their
   values assigned by IANA.  These values IP packet header.  The
      protocol number identifies the IP packet payload type.  Protocol
      numbers are defined in the range of 1 - 32767. IANA Protocol Numbers registry.
      In Internet Protocol version 4 (IPv4) this range, the value of the most significant bit in a
   16-bit-representation always equals 0.

   Enterprise-specific field IDs are is carried in the range of 32768 - 65535.
      "Protocol" field.  In Internet Protocol version 6 (IPv6) this range, the value of is
      carried in the most significant bit "Next Header" field in a
   16-bit-representation always equals 1.  This choice the last extension header of ranges allows
   a Collecting Process to clearly and easily distinguished standardized
   fields from enterprise-specific fields by just checking a single bit.

   +---------------------------------+---------------------------------+
   | Field ID Range                  | Description                     |
   +---------------------------------+---------------------------------+
   | 0                               | reserved                        |
   |                                 |                                 |
   | 1 - 127                         | standardized field IDs          |
   |                                 | compatible to NetFlow version 9 |
   |                                 |                                 |
   | 128 - 32767                     | standardized field IDs assigned |
   |                                 | by IANA                         |
   |                                 |                                 |
   | 32768 - 65535                   | enterprise-defined field IDs    |
   +---------------------------------+---------------------------------+

   Enterprise-specific IDs can be chosen by an enterprise arbitrarily
   within
      the given range.  The same ID may be assigned by different
   enterprises for different purposes.  In order to ensure that
   Collecting Processes can always identify information elements
   uniquely, enterprise-specific information elements are identified by packet.
   Abstract Data Type: octet
   Data Type Semantics: identifier
   ElementId: 4
   Status: current
   Reference:
      See RFC 791 for the combination specification of a field ID and an enterprise ID.  Valid valuse the IPv4 protocol field.  See
      RFC 2460 for
   enterprise IDs are also assigned by IANA.  The IPFIX information
   model uses the SMI network management private enterprise code defined
   at http://www.iana.org/assignments/enterprise-numbers as specification of the set IPv6 protocol field.  See
      list of
   valid numbers for enterprise IDs.  Enterprise IDs used for
   identifying IPFIX information elements MUST be registered as SMI
   network management private enterprise code protocol numbers assigned by IANA at IANA.
      http://www.iana.org/assignments/protocol-numbers.

5.3.21  fragmentOffsetIPv4

   Description:
      The following list gives an overview value of the IPv4 fragment offset field IDs used as identifiers in the IP packet
      header.
   Abstract Data Type: unsigned16
   Data Type Semantics: identifier
   ElementId: 88
   Status: current
   Reference:
      See RFC 791 for the specification of the information elements specified in section 5.




Quittek, et al.         Expires August 21, 2005                [Page 11]

Internet-Draft          IPFIX IPv4 fragment offset.

5.4  Transport Header Fields

   The set of Information Model            February 2005


   +-------+-------------------------+-------+-------------------------+
   |    ID | Field Name              |    ID | Field Name              |
   +-------+-------------------------+-------+-------------------------+
   |     1 | inOctetDeltaCount       |    44 | sourceIPv4Prefix        |
   |     2 | inPacketDeltaCount      |    45 | destinationIPv4Prefix   |
   |     3 | totalFlowCount          |    46 | mplsTopLabelType        |
   |     4 | protocolIdentifier      |    47 | mplsTopLabelIPv4Address |
   |     5 | classOfServiceIPv4      | 48-51 | RESERVED                |
   |     6 | tcpControlBits          |    52 | minimumTTL              |
   |     7 | sourceTransportPort     |    53 | maximumTTL              |
   |     8 | sourceIPv4Address       |    54 | identificationIPv4      |
   |     9 | sourceIPv4Mask          |    55 | RESERVED                |
   |    10 | ingressInterface        |    56 | sourceMacAddress        |
   |    11 | destinationTransportPort| 57-59 | RESERVED                |
   |    12 Elements related to transport header fields
   includes the Information Elements listed in the table below.

   +-----+---------------------------+-----+---------------------------+
   | destinationIPv4Address  ID |    60 Name                      | ipVersion  ID | Name                      |    13
   +-----+---------------------------+-----+---------------------------+
   | destinationIPv4Mask   7 |    61 sourceTransportPort       | RESERVED  32 | icmpTypeCodeIPv4          |    14
   | egressInterface  11 |    62 destinationTransportPort  | ipNextHopIPv6Address 139 | icmpTypeCodeIPv6          |    15
   | ipNextHopIPv4Address     |    63                           | bgpNextHopIPv6Address  33 | igmpType                  |
   +-----+---------------------------+-----+---------------------------+







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


5.4.1  sourceTransportPort

   Description:
      The source port identifier in the transport header.  For the
      transport protocols UDP, TCP and SCTP this is the source port
      number given in the respective header.  This field MAY also be
      used for future transport protocols that have 16 | bgpSourceAsNumber       |    64 | ipv6OptionHeaders       |
   |    17 | bgpDestinationAsNumber  | 65-69 | RESERVED                |
   |    18 | bgpNextHopIPv4Address   |    70 | mplsLabelStackEntry1    |
   |    19 | OutMulticastPacketCount |    71 | mplsLabelStackEntry2    |
   |    20 | OutMulticastOctetCount  |    72 | mplsLabelStackEntry3    |
   |    21 | flowEndTime             |    73 | mplsLabelStackEntry4    |
   |    22 | flowCreationTime        |    74 | mplsLabelStackEntry5    |
   |    23 | outOctetDeltaCount      |    75 | mplsLabelStackEntry6    |
   |    24 | outPacketDeltaCount     |    76 | mplsLabelStackEntry7    |
   |    25 | minimumPacketLength     |    77 | mplsLabelStackEntry8    |
   |    26 | maximumPacketLength     |    78 | mplsLabelStackEntry9    |
   |    27 | sourceIPv6Address       |    79 | mplsLabelStackEntry10   |
   |    28 | destinationIPv6Address  | 80-84 | RESERVED                |
   |    29 | sourceIPv6Mask          |    85 | inOctetTotalCount       |
   |    30 | destinationIPv6Mask     |    86 | inPacketTotalCount      |
   |    31 | flowLabelIPv6           |87-127 | RESERVED                |
   | bit source port
      identifiers.
   Abstract Data Type: unsigned16
   Data Type Semantics: identifier
   ElementId: 7
   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

   Description:
      The destination port identifier in the transport header.  For the
      transport protocols UDP, TCP and SCTP this is the destination port
      number given in the respective header.  This field MAY also be
      used for future transport protocols that have 16 bit destination
      port identifiers.
   Abstract Data Type: unsigned16
   Data Type Semantics: identifier
   ElementId: 11
   Status: current
   Reference:
      See RFC 768 for the definition of the UDP source port field.  See
      RFC 793 for the definition of the TCP source port field.  See RFC
      2960 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  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 | icmpTypeCode            |   128 | bgpNextHopAsNumber      |
   |
   Status: current
   Reference: See RFC 792 for a definition of the IPv4 ICMP type and
      code fields.

5.4.4  icmpTypeCodeIPv6

   Description:
      Type and Code of the IPv6 ICMP message.  The combination of both
      values is reported as (ICMP type * 256) + ICMP code.
   Abstract Data Type: unsigned16
   Data Type Semantics: identifier
   ElementId: 139
   Status: current
   Reference: See RFC 2463 for a definition of the IPv6 ICMP type and
      code fields.

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

   +-----+---------------------------+-----+---------------------------+
   | igmpType                |   129 | ipNextHopAsNumber  ID | Name                      | 34-35  ID | RESERVED Name                      |   130
   +-----+---------------------------+-----+---------------------------+
   | exporterIPv4Address  56 | sourceMacAddress          |    36  70 | flowActiveTimeOut mplsLabelStackEntry1      |   131
   | exporterIPv6Address  57 | postDestinationMacAddr    |    37  71 | flowInactiveTimeout mplsLabelStackEntry2      |   132
   | droppedOctetDeltaCount  58 | vlanId                    | 38-39  72 | RESERVED mplsLabelStackEntry3      |   133
   | droppedPacketDeltaCount  59 | postVlanId                |    40  73 | exportedOctetCount mplsLabelStackEntry4      |   134
   | droppedOctetTotalCount  80 | destinationMacAddress     |    41  74 | exportedPacketCount mplsLabelStackEntry5      |   135
   | droppedPacketTotalCount  81 | postSourceMacAddress      |    42  75 | exportedFlowCount mplsLabelStackEntry6      |   136
   | flowEndReason 146 | wlanChannelId             |    43  76 | RESERVED mplsLabelStackEntry7      |   137
   | classOfServiceIPv6 147 | wlanSsid                  |  77 | mplsLabelStackEntry8      |   138
   | octetDeltaCount     |                           |  78 | mplsLabelStackEntry9      |   139
   | packetDeltaCount     |                           |  79 | mplsLabelStackEntry10     |   140
   +-----+---------------------------+-----+---------------------------+






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.
   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.
   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.
   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.
   Abstract Data Type: macAddress
   Data Type Semantics: identifier
   ElementId: 81
   Status: current
   Reference: See IEEE.802-3.2002.

5.5.7  wlanChannelId

   Description:
      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

   Description:
      The label, exp and s fields from the outermost 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


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | mplsTopLabelIPv6Address                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
   Reference: See RFC 3032.

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

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

5.5.12  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 for further details.




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


5.  Information Elements

   This section describes


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

5.5.13  mplsLabelStackEntry5

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

5.5.14  mplsLabelStackEntry6

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

5.5.15  mplsLabelStackEntry7

   Description:
      The elements are grouped into 8 groups according to their
   semantics label, exp, and their applicability.

5.1  IP Header Fields

   Information elements in this section indicate values 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 header
      mplsLabelStackEntry1 for further details.
   Abstract Data Type: unsigned32
   Data Type Semantics: identifier
   ElementId: 76
   Status: current
   Reference: See RFC 3032.

5.5.16  mplsLabelStackEntry8





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


   Description:
      The label, exp, and s fields
   or are derived from IP header field values in combination with
   further information.  These information elements can serve as part the label stack entry that was
      pushed immediately before the label stack entry that would be
      reported by mplsLabelStackEntry7.  See the definition of
   a flow key used
      mplsLabelStackEntry1 for mapping packets to flows.  But also they may
   contain values related to header further details.
   Abstract Data Type: unsigned32
   Data Type Semantics: identifier
   ElementId: 77
   Status: current
   Reference: See RFC 3032.

5.5.17  mplsLabelStackEntry9

   Description:
      The label, exp, and s fields that are not constant for a
   single flow.  For example a flow using a certain source IPv4 address
   as flow key has sourceAddressV4 as constant property but may have
   destinationAddressV4 as a property that changes from packet to
   packet.

   For information elements the label stack entry that are not constant for a flow, was
      pushed immediately before the value
   MUST label stack entry that would be
      reported by mplsLabelStackEntry8.  See the value definition of the first packet observed
      mplsLabelStackEntry1 for this flow.  This
   simple rule allows writing all information elements related to header
   fields once when the first packet of the flow is observed.  For further observed packets of details.
   Abstract Data Type: unsigned32
   Data Type Semantics: identifier
   ElementId: 78
   Status: current
   Reference: See RFC 3032.

5.5.18  mplsLabelStackEntry10

   Description:
      The label, exp, and s fields from the same flow, only label stack entry that was
      pushed immediately before the counters need to label stack entry that would be increased.
      reported by mplsLabelStackEntry9.  See the definition of
      mplsLabelStackEntry1 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 related to IP Information Elements derived from values of header fields
   and further information includes the information elements Information Elements listed in
   the table below.

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









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


   +-----+---------------------------+-----+---------------------------+
   |  ID | Field Name                      |  ID | Field Name                      |
   +-------+-------------------------+-------+-------------------------+
   |    60 | ipVersion               |     5 | classOfServiceIPv4      |
   |     8 | sourceIPv4Address       |   137 | classOfServiceIPv6      |
   |    27 | sourceIPv6Address       |    31 | flowLabelIPv6           |
   |     9 | sourceIPv4Mask          |    54 | identificationIPv4      |
   |    29
   +-----+---------------------------+-----+---------------------------+
   | sourceIPv6Mask          |     4 | protocolIdentifier      |
   |    44  15 | sourceIPv4Prefix ipNextHopIPv4Address      |  18 | bgpNextHopIPv4Address     |
   |    12  62 | destinationIPv4Address ipNextHopIPv6Address      |  63 | bgpNextHopIPv6Address     |
   |    28  16 | destinationIPv6Address bgpSourceAsNumber         |  46 | mplsTopLabelType          |
   |    13  17 | destinationIPv4Mask bgpDestinationAsNumber    |  47 | mplsTopLabelIPv4Address   |
   |    30 128 | destinationIPv6Mask bgpNextAdjacentAsNumber   | 140 | mplsTopLabelIPv6Address   |
   |    45 129 | destinationIPv4Prefix bgpPrevAdjacentAsNumber   |     |                           |
   +-------+-------------------------+-------+-------------------------+


5.1.1  ipVersion





Quittek, et al.         Expires August 21, 2005                [Page 13]

Internet-Draft          IPFIX Information Model            February 2005
   +-----+---------------------------+-----+---------------------------+


5.6.1  ipNextHopIPv4Address

   Description:
      The IP version field given in IPv4 address of the IP header. next IPv4 hop.
   Abstract Data Type: octet

   FieldId: 60

   Applicability: all ipv4Address
   Data Type Semantics: identifier
   ElementId: 15
   Status: current

   Units: flows
   Reference:
      See RFC 791 for a definition of the version field in the

5.6.2  ipNextHopIPv6Address

   Description:
      The IPv6
      packet header.  See RFC 2460 for a definition address of the version field
      in the next IPv6 packet header.  Additional information on defined
      version numbers can be found at
      http://www.iana.org/assignments/version-numbers.

5.1.2  sourceIPv4Address hop.
   Abstract Data Type: ipv6Address
   Data Type Semantics: identifier
   ElementId: 62
   Status: current

5.6.3  bgpSourceAsNumber

   Description:
      IPv4 source address taken from
      The autonomous system (AS) number of the source IP packet header of a packet address.  If AS
      path information for this Flow is only available as unordered AS
      set (and not as ordered AS sequence), then the value of this flow.
      Information Element is 0.
   Abstract Data Type: ipv4Address

   FieldId: 8

   Applicability: all unsigned16
   Data Type Semantics: identifier
   ElementId: 16
   Status: current
   Reference: See RFC 791 1771 for the definition of the IPv4 source address
      field.

5.1.3  sourceIPv6Address
   Description:
      IPv6 source address taken from the IP packet header a description of BGP-4 and see RFC 1930
      for a packet definition of
      this flow.

   Abstract Data Type: ipv6Address

   FieldId: 27

   Applicability: all

   Status: current the AS number.

5.6.4  bgpDestinationAsNumber






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


5.1.4  sourceIPv4Mask


   Description:
      The autonomous system (AS) number of contiguous bits that are relevant in the
      sourceAddressV4 field. 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: octet

   FieldId: 9

   Applicability: option unsigned16
   Data Type Semantics: identifier
   ElementId: 17
   Status: current

   Units: bits

   Range: The valid range is 0-32.

5.1.5  sourceIPv6Mask
   Reference: See RFC 1771 for a description of BGP-4 and see RFC 1930
      for a definition of the AS number.

5.6.5  bgpNextAdjacentAsNumber

   Description:
      The autonomous system (AS) number of contiguous bits that are relevant the first AS in the
      sourceAddressV6 field.

   Abstract Data Type: octet

   FieldId: 29

   Applicability: option

   Status: current

   Units: bits

   Range: The valid range is 0-128.

5.1.6  sourceIPv4Prefix
   Description:
      IPv4 source address prefix.
      EDITOR'S NOTE: AS path
      to be discussed on ipfix mailing list

   Abstract Data Type: ipV4Address

   FieldId: 44

   Applicability: data

   Status: current

   Units: flows



Quittek, et al.         Expires August 21, 2005                [Page 15]

Internet-Draft          IPFIX Information Model            February 2005


5.1.7  destinationIPv4Address
   Description:
      IPv4 the destination address taken from IP address.  The path is deduced by looking up
      the destination IP packet header address of a
      packet the Flow in the BGP routing
      information base.  If AS path information for this Flow is only
      available as unordered AS set (and not as ordered AS sequence),
      then the value of this flow. Information Element is 0.
   Abstract Data Type: ipv4Address

   FieldId: 12

   Applicability: all unsigned16
   Data Type Semantics: identifier
   ElementId: 128
   Status: current
   Reference: See RFC 791 1771 for a description of BGP-4 and see RFC 1930
      for the a definition of the IPv4 destination
      address field.

5.1.8  destinationIPv6Address AS number.

5.6.6  bgpPrevAdjacentAsNumber

   Description:
      IPv6 destination address taken
      The autonomous system (AS) number of the last AS in the AS path
      from the source IP packet header address.  The path is deduced by looking up the
      source IP address of a
      packet the Flow in the BGP routing information base.
      If AS path information for this Flow is only available as
      unordered AS set (and not as ordered AS sequence), then the value
      of this flow.

   Abstract Data Type: ipv6Address

   FieldId: 28

   Applicability: all

   Status: current

5.1.9  destinationIPv4Mask
   Description:
      The number Information Element is 0.  In case of contiguous bits that are relevant in BGP asymmetry, the
      destinationAddressV4 field.
      bgpSrcAdjacentASNumber might not be able to report the correct
      value.
   Abstract Data Type: octet

   FieldId: 13

   Applicability: option unsigned16
   Data Type Semantics: identifier
   ElementId: 129
   Status: current

   Units: bits

   Range: The valid range is 0-32.

5.1.10  destinationIPv6Mask
   Reference: See RFC 1771 for a description of BGP-4 and see RFC 1930
      for a definition of the AS number.






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


5.6.7  bgpNextHopIPv4Address

   Description:
      The number IPv4 address of contiguous bits that are relevant in the
      destinationAddressV6 field. next (adjacent) BGP hop.
   Abstract Data Type: octet

   FieldId: 30

   Applicability: option ipv4Address
   Data Type Semantics: identifier
   ElementId: 18
   Status: current

   Units: bits

   Range: The valid range is 0-128.

5.1.11  destinationIPv4Prefix
   Reference: See RFC 1771 for a description of BGP-4 and

5.6.8  bgpNextHopIPv6Address

   Description:
      IPv4 destination
      The IPv6 address prefix.
      EDITOR'S NOTE: to be discussed on ipfix mailing list of the next (adjacent) BGP hop.
   Abstract Data Type: ipV4Address

   FieldId: 45

   Applicability: data ipv6Address
   Data Type Semantics: identifier
   ElementId: 63
   Status: current

   Units: flows

5.1.12  classOfServiceIPv4
   Description:
      The value
   Reference: See RFC 1771 for a description of the IPv4 TOS BGP-4.

5.6.9  mplsTopLabelType

   Description:
      This field observed for packets identifies the control protocol that allocated the top
      of stack label.  Defined values for this flow. 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: octet
   Data Type Semantics: identifier

   FieldId: 5

   Applicability: all
   ElementId: 46
   Status: current
   Reference: See RFC 791 3031 for the definition of 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.

5.6.10  mplsTopLabelIPv4Address

   Description:
      The IPv4 TOS field. address of the system that the MPLS top label will cause
      this Flow to be forwarded to.





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


5.1.13  classOfServiceV6
   Description:
      The value of the IPv6 traffic class field observed for packets of
      this flow.


   Abstract Data Type: octet

   FieldId: 137

   Applicability: data ipv4Address
   Data Type Semantics: identifier
   ElementId: 47
   Status: current
   Reference: See RFC 2460 3031 for the definition of the IPv6 traffic class
      field.

5.1.14  flowLabelV6 association between MPLS labels and
      IP addresses.

5.6.11  mplsTopLabelIPv6Address

   Description:
      The Flow Label IPv6 address of the IPv6 packet header observed in system that the first
      packet of MPLS top label will cause
      this flow. Flow to be forwarded to.
   Abstract Data Type: unsigned32

   FieldId: 31

   Applicability: all ipv6Address
   Data Type Semantics: identifier
   ElementId: 140
   Status: current
   Reference: See RFC 2460 3031 for a definition of the flow label field association between MPLS labels and
      IP addresses.

5.7  Min/Max Flow Properties

   Information Elements in
      the IPv6 packet header.

5.1.15  identificationV4 this section are results of minimum or
   maximum operations over all packets of a flow.

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


5.7.1  minimumPacketLength

   Description:
      The IPv4 packet identification field from
      Length of the first smallest packet of observed for this
      flow. Flow.
   Abstract Data Type: unsigned16

   Data Type Semantics: identifier

   FieldId: 54

   Applicability: data
   ElementId: 25
   Status: current
   Reference: See RFC 791 for the definition of the IPv4 identification
      field.
   Units: octets

5.7.2  maximumPacketLength







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


5.1.16  protocolIdentifier


   Description:
      The protocol number
      Length of the largest packet observed for packets of this flow.  The
      protocol number identifies the IP Flow.
   Abstract Data Type: unsigned16
   ElementId: 26
   Status: current
   Units: octets

5.7.3  minimumTtl

   Description:
      Minimum TTL value observed for any packet payload.  Protocol
      numbers are defined in the IANA Protocol Numbers registry.
      In Internet Protocol version 4 (IPv4) this is carried Flow.
   Abstract Data Type: octet
   ElementId: 52
   Status: current

5.7.4  maximumTtl

   Description:
      Maximum TTL value observed for any packet 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. Flow.
   Abstract Data Type: octet

   Data Type Semantics: identifier

   FieldId: 4

   Applicability: all
   ElementId: 53
   Status: current
   Reference:
      See RFC 791 for the specification of the IPv4 protocol field.  See
      RFC 2460 for the specification of the

5.7.5  ipv6OptionHeaders

   Description:
      IPv6 protocol field.  See
      list options in the IP packet headers of protocol numbers assigned by IANA at
      http://www.iana.org/assignments/protocol-numbers.

5.2  Trandport Header Fields this Flow.  The
      information is encoded in a set of information elements related to transport bit fields.  For each IPv6
      option header fields
   includes the information elements listed in the table below.

   +-------+-------------------------+-------+-------------------------+
   |    ID | Field Name              |    ID | Field Name              |
   +-------+-------------------------+-------+-------------------------+
   |     7 | sourceTransportPort     |    32 | icmpTypeCode            |
   |    11 | destinationTransportPort|    33 | igmpType                |
   +-------+-------------------------+-------+-------------------------+


5.2.1  sourceTransportPort
   Description:
      A source port identifier there is a bit in the transport header.  For transport
      protocols UDP, TCP and SCTP this is the source port number given
      in set.  The bit is set if any
      observed packet of this Flow contains the respective corresponding IPv6
      option 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      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 to 31                 Reserved




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


   FieldId: 7

   Applicability: all


   Abstract Data Type: unsigned32
   Data Type Semantics: flags
   ElementId: 64
   Status: current
   Reference: See RFC 768 2460 for the general definition of IPv6 extensions
      headers and for the UDP source port field. specification of the hop-by-hop options
      header, the routing header, the fragment header, and the
      destination options header.  See RFC 793 2402 for the definition specification of
      the TCP source port field. authentication header.  See RFC
      2960 2406 for the definition specification of SCTP.
      Additional information on defined UDP and TCP port numbers can be
      found at http://www.iana.org/assignments/port-numbers.

5.2.2  destinationtransportPort
      the encapsulating security payload.

5.7.6  tcpControlBits

   Description:
      A destination port identifier
      TCP control bits observed for packets of this Flow.  The
      information is encoded in the transport header. a set of bit fields.  For
      transport protocols UDP, each TCP and SCTP
      control bit there is a bit in this set.  A bit is set to 1 if any
      observed packet of this Flow has the destination port
      number given in corresponding TCP control bit
      set to 1.  A value of 0 for a bit indicates that the respective header.  This field MAY also be
      used 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 transport protocols that have 16 bit destination
      port identifiers. 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: unsigned16 octet
   Data Type Semantics: identifier

   FieldId: 11

   Applicability: all flags
   ElementId: 6
   Status: current
   Reference: See RFC 768 for the definition of the UDP source port field.  See
      RFC 793 for the a definition of the TCP source port field.  See RFC
      2960 for control bits in
      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.2.3  icmpTypeCode
   Description:
      Type and Code of the ICMP message.  The combination header.

5.8  Flow Time Stamps

   Information Elements in this section are time stamps of both values
      is reported as (ICMP type * 256) + ICMP code.

   Abstract Data Type: unsigned16

   FieldId: 32

   Applicability: all

   Status: current events.

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



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


   Reference: See RFC 792 for


   systemInitTimeMilliSeconds are absolute and have a definition of well defined fixed
   time base, such as, for example, the ICMP type and code
      fields.

5.2.4  igmpType
   Description: The type field number of seconds since 0000 UTC
   Jan 1st 1970.

   Time stamps flowStartDeltaMicroSeconds and flowEndDeltaMicroSeconds
   are relative time stamps only valid within the IGMP message.

   Abstract Data Type: octet

   FieldId: 33

   Applicability: all

   Status: current
   Reference: See RFC 2236 for a definition scope of a single
   IPFIX message.  They contain the IGMP type field.

5.3  Sub-IP Header Fields

   The set of information elements related negative time offsets relative to
   the export time specified in the IPFIX Message header.

   Time stamps flowStartSysUpTime and flowEndSysUpTime are relative time
   stamps indicating the time relative to Sub-IP header fields
   includes the information elements listed in last (re-)initialization
   of the table below.

   +-------+-------------------------+-------+-------------------------+ IPFIX device.  For reporting the time of the last
   (re-)initialization, systemInitTimeMilliSeconds can be reported, for
   example, in Data Records defined by Option Templates.

   +-----+---------------------------+-----+---------------------------+
   |  ID | Field Name                      |  ID | Field Name                      |
   +-------+-------------------------+-------+-------------------------+
   +-----+---------------------------+-----+---------------------------+
   |    56 150 | sourceMacAddress flowStartSeconds          |    75 156 | mplsLabelStackEntry6 flowStartNanoSeconds      |
   |    70 151 | mplsLabelStackEntry1 flowEndSeconds            |    76 157 | mplsLabelStackEntry7 flowEndNanoSeconds        |
   |    71 152 | mplsLabelStackEntry2 flowStartMilliSeconds     |    77 158 | mplsLabelStackEntry8 flowStartDeltaMicroSeconds|
   | 153 |    72 flowEndMilliSeconds       | mplsLabelStackEntry3 159 |    78 flowEndDeltaMicroSeconds  | mplsLabelStackEntry9
   | 154 |    73 flowStartMicroSeconds     | mplsLabelStackEntry4 160 |    79 systemInitTimeMilliSeconds|
   | mplsLabelStackEntry10 155 | flowEndMicroSeconds       |    74  22 | mplsLabelStackEntry5 flowStartSysUpTime        |
   |     |
   +-------+-------------------------+-------+-------------------------+


5.3.1  sourceMacAddress
   Description:
      Packet identification field from the first IP packet of this flow.

   Abstract Data Type: octetArray

   FieldId: 56

   Applicability: data

   Status: current
   Reference: See RFC 791 for the definition of the IPv4 identification
      field.






Quittek, et al.         Expires August 21, 2005                [Page 21]

Internet-Draft          IPFIX Information Model            February 2005


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

       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  21 | Exp |S|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

   Abstract Data Type: unsigned32

   FieldId: 70

   Applicability: all

   Status: current
   Reference: See RFC 3032.

5.3.3  mplsLabelStackEntry2 flowEndSysUpTime          |
   +-----+---------------------------+-----+---------------------------+


5.8.1  flowStartSeconds

   Description: The label, exp and s fields from the LSE that was pushed
      immediately before the LSE that would be reported by
      mplsLabelStackEntry1.  See absolute timestamp of the definition first packet of mplsLabelStackEntry1
      for further details. this Flow.
   Abstract Data Type: unsigned32

   FieldId: 71

   Applicability: all dateTimeSeconds
   ElementId: 150
   Status: current
   Reference: See RFC 3032.

5.3.4  mplsLabelStackEntry3
   Units: seconds

5.8.2  flowEndSeconds

   Description:
      The label, exp and s fields from the LSE that was pushed
      immediately before the LSE that would be reported by
      mplsLabelStackEntry2.  See The absolute timestamp of the definition last packet of mplsLabelStackEntry1
      for further details. this Flow.
   Abstract Data Type: unsigned32 dateTimeSeconds
   ElementId: 151
   Status: current
   Units: seconds

5.8.3  flowStartMilliSeconds






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


   FieldId: 72

   Applicability: all


   Description: The absolute timestamp of the first packet of this Flow.
   Abstract Data Type: dateTimeMilliSeconds
   ElementId: 152
   Status: current
   Reference: See RFC 3032.

5.3.5  mplsLabelStackEntry4
   Units: milliseconds

5.8.4  flowEndMilliSeconds

   Description: The label, exp and s fields from the LSE that was pushed
      immediately before the LSE that would be reported by
      mplsLabelStackEntry3.  See absolute timestamp of the definition last packet of mplsLabelStackEntry1
      for further details. this Flow.
   Abstract Data Type: unsigned32

   FieldId: 73

   Applicability: all dateTimeMilliSeconds
   ElementId: 153
   Status: current
   Reference: See RFC 3032.

5.3.6  mplsLabelStackEntry5
   Units: milliseconds

5.8.5  flowStartMicroSeconds

   Description: The label, exp and s fields from the LSE that was pushed
      immediately before the LSE that would be reported by
      mplsLabelStackEntry4.  See absolute timestamp of the definition first packet of mplsLabelStackEntry1
      for further details. this Flow.
   Abstract Data Type: unsigned32

   FieldId: 74

   Applicability: all dateTimeMicroSeconds
   ElementId: 154
   Status: current
   Reference: See RFC 3032.

5.3.7  mplsLabelStackEntry6
   Units: microseconds

5.8.6  flowEndMicroSeconds

   Description: The label, exp and s fields from absolute timestamp of the LSE that was pushed
      immediately before last packet of this Flow.
   Abstract Data Type: dateTimeMicroSeconds
   ElementId: 155
   Status: current
   Units: microseconds

5.8.7  flowStartNanoSeconds

   Description: The absolute timestamp of the LSE that would be reported by
      mplsLabelStackEntry5.  See first packet of this Flow.
   Abstract Data Type: dateTimeNanoSeconds
   ElementId: 156
   Status: current
   Units: nanoseconds

5.8.8  flowEndNanoSeconds

   Description: The absolute timestamp of the definition last packet of mplsLabelStackEntry1
      for further details. this Flow.
   Abstract Data Type: unsigned32 dateTimeNanoSeconds
   ElementId: 157
   Status: current
   Units: nanoseconds






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


   FieldId: 75

   Applicability: all

   Status: current
   Reference: See RFC 3032.

5.3.8  mplsLabelStackEntry7


5.8.9  flowStartDeltaMicroSeconds

   Description:
      The label, exp and s fields from This is a relative time stamp only valid within the LSE that was pushed
      immediately before
      scope of a single IPFIX message.  It contains the LSE that would be reported by
      mplsLabelStackEntry6.  See negative time
      offset of the definition first observed packet of mplsLabelStackEntry1
      for further details. this Flow relative to the
      export time specified in the IPFIX Message header.
   Abstract Data Type: unsigned32

   FieldId: 76

   Applicability: all
   ElementId: 158
   Status: current
   Units: microseconds
   Reference: See RFC 3032.

5.3.9  mplsLabelStackEntry8 [I-D.ietf-ipfix-protocol] for the definition of the
      IPFIX Message header.

5.8.10  flowEndDeltaMicroSeconds

   Description:
      The label, exp and s fields from This is a relative time stamp only valid within the LSE that was pushed
      immediately before
      scope of a single IPFIX message.  It contains the LSE that would be reported by
      mplsLabelStackEntry7.  See negative time
      offset of the definition last observed packet of mplsLabelStackEntry1
      for further details. this Flow relative to the
      export time specified in the IPFIX Message header.
   Abstract Data Type: unsigned32

   FieldId: 77

   Applicability: all
   ElementId: 159
   Status: current
   Units: microseconds
   Reference: See RFC 3032.

5.3.10  mplsLabelStackEntry9 [I-D.ietf-ipfix-protocol] for the definition of the
      IPFIX Message header.

5.8.11  systemInitTimeMilliSeconds

   Description: The label, exp and s fields from absolute timestamp of the LSE that was pushed
      immediately before last (re-)initialization
      of the LSE that would be reported by
      mplsLabelStackEntry8.  See IPFIX device.
   Abstract Data Type: dateTimeMilliSeconds
   ElementId: 160
   Status: current
   Units: milliseconds

5.8.12  flowStartSysUpTime

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

5.8.13  flowEndSysUpTime





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


   FieldId: 78

   Applicability: all

   Status: current
   Reference: See RFC 3032.

5.3.11  mplsLabelStackEntry10


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

5.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 of a flow key used for mapping packets to
   flows.  However, potentially they can be used for selecting exported
   flows, for example, by only exporting flows with more than a
   threshold number of observed octets.

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

   There are per-flow counters and s fields from counters related to the LSE that was pushed
      immediately before Metering
   Process and/or the LSE Exporting Process.  Per-flow counters are flow
   properties that would be reported by
      mplsLabelStackEntry9.  See potentially change each time a packet belonging to
   the definition of mplsLabelStackEntry1
      for further details.

   Abstract Data Type: unsigned32

   FieldId: 79

   Applicability: all

   Status: current
   Reference: See RFC 3032.

5.4  Derived Packet Properties flow is observed.  The set of information elements derived from values of header fields
   and further information per-flow counters includes the information elements
   Information Elements listed in the table below.

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

   +-----+---------------------------+-----+---------------------------+
   |  ID | Field Name                      |  ID | Field Name                      |
   +-------+-------------------------+-------+-------------------------+
   |    15 | ipNextHopIPv4Address    |   128 | bgpNextHopAsNumber
   +-----+---------------------------+-----+---------------------------+
   |   1 |    62 octetDeltaCount           | ipNextHopIPv6Address 132 |    18 droppedOctetDeltaCount    | bgpNextHopIPv4Address
   |  23 |    10 postOctetDeltaCount       | ingressInterface 133 |    63 droppedPacketDeltaCount   | bgpNextHopIPv6Address
   |  85 |    14 octetTotalCount           | egressInterface 134 |    46 droppedOctetTotalCount    | mplsTopLabelType
   | 170 |   129 postOctetTotalCount       | ipNextHopAsNumber 135 |    47 droppedPacketTotalCount   | mplsTopLabelIPv4Address
   |   2 |    16 packetDeltaCount          | bgpSourceAsNumber  19 |   140 postMulticastPacketCount  | mplsTopLabelIPv6Address
   |  24 |    17 postPacketDeltaCount      | bgpDestinationAsNumber  20 | postMulticastOctetCount   |
   |
   +-------+-------------------------+-------+-------------------------+


5.4.1  ipNextHopIPv4Address
   Description:
      The IPv4 address of the next IP hop to which packets of this flow
      are forwarded.

   Abstract Data Type: ipv4Address



Quittek, et al.         Expires August 21, 2005                [Page 25]

Internet-Draft          IPFIX Information Model            February 2005


   FieldId: 15

   Applicability: data

   Status: current

5.4.2  ipNextHopIPv6Address
   Description:
      The IPv6 address of the next BGP hop to which packets of this flow
      are forwarded.

   Abstract Data Type: ipv6Address

   FieldId: 62

   Applicability: data

   Status: current

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

   FieldId: 10

   Applicability: all

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

5.4.4  egressInterface  86 | packetTotalCount          |     |                           |
   | 161 | postPacketTotalCount      |     |                           |
   +-----+---------------------------+-----+---------------------------+


5.9.1  octetDeltaCount

   Description:
      The index number of octets since the IP interface (ifIndex) where previous report (if any) in
      incoming packets of for this flow
      are being sent.

   Abstract Data Type: unsigned32

   Data Type Semantics: identifier

   FieldId: 14

   Applicability: all Flow at the Observation Point.  The
      number of octets include IP header(s) and IP payload.




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


   Abstract Data Type: unsigned64
   Data Type Semantics: deltaCounter
   ElementId: 1
   Status: current
   Reference: See RFC 2863 for the definition of the ifIndex object.

5.4.5  ipNextHopAsNumber
   Units: octets

5.9.2  postOctetDeltaCount

   Description:
      The autonomous system (AS) number of octets since the next IP hop to which previous report (if any) in
      outgoing packets of for this flow are forwarded. Flow at the Observation Point.  The
      number of octets include IP header(s) and IP payload.
   Abstract Data Type: unsigned16 unsigned64
   Data Type Semantics: identifier

   FieldId: 129

   Applicability: all deltaCounter
   ElementId: 23
   Status: current
   Reference: See RFC 1771 for a description of BGB-4 and see RFC 1930 a
      definition of the AS number.

5.4.6  bgpSourceAsNumber
   Units: octets

5.9.3  octetTotalCount

   Description:
      The autonomous system (AS) total number of the source address octets in incoming packets for this Flow at
      the IP
      packet header in a packet of Observation Point since the Metering Process
      (re-)initialization for this flow. Observation Point.  The number of
      octets include IP header(s) and IP payload.
   Abstract Data Type: unsigned16 unsigned64
   Data Type Semantics: identifier

   FieldId: 16

   Applicability: all totalCounter
   ElementId: 85
   Status: current
   Reference: See RFC 1771 for a description of BGB-4 and see RFC 1930 a
      definition of the AS number.

5.4.7  bgpDestinationAsNumber
   Units: octets

5.9.4  postOctetTotalCount

   Description:
      The autonomous system (AS) total number of the destination address octets in outgoing packets for this Flow at
      the IP packet header in a packet of Observation Point since the Metering Process
      (re-)initialization for this flow. Observation Point.  The number of
      octets include IP header(s) and IP payload.
   Abstract Data Type: unsigned16 unsigned64
   Data Type Semantics: identifier

   FieldId: 17 totalCounter
   ElementId: 170
   Status: current
   Units: octets

5.9.5  packetDeltaCount






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


   Applicability: all

   Status: current
   Reference: See RFC 1771 for a description of BGB-4 and see RFC 1930 a
      definition of the AS number.

5.4.8  bgpNextHopAsNumber


   Description:
      The autonomous system (AS) number of the next BGP hop to which incoming packets of since the previous report (if any)
      for this flow are forwarded. Flow at the Observation Point.
   Abstract Data Type: unsigned16 unsigned64
   Data Type Semantics: identifier

   FieldId: 128

   Applicability: all deltaCounter
   ElementId: 2
   Status: current
   Reference: See RFC 1771 for a description of BGB-4 and see RFC 1930 a
      definition of the AS number.

5.4.9  bgpNextHopIPv4Address
   Units: packets

5.9.6  postPacketDeltaCount

   Description:
      The IPv4 address number of the next BGP hop to which outgoing packets of since the previous report (if any)
      for this flow
      are forwarded. Flow at the Observation Point.
   Abstract Data Type: ipv4Address

   FieldId: 18

   Applicability: all unsigned64
   Data Type Semantics: deltaCounter
   ElementId: 24
   Status: current
   Reference: See RFC 1771 for a description of BGB-4 and see RFC 1930 a
      definition of the AS number.

5.4.10  bgpNextHopIPv6Address
   Units: packets

5.9.7  packetTotalCount

   Description:
      The IPv6 address total number of incoming packets for this Flow at the next BGP hop to which
      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.8  postPacketTotalCount

   Description:
      The total number of outgoing packets for this flow
      are forwarded. Flow at the
      Observation Point since the Metering Process (re-)initialization
      for this Observation Point.
   Abstract Data Type: ipv6Address unsigned64
   Data Type Semantics: identifier

   FieldId: 63 totalCounter
   ElementId: 171
   Status: current
   Units: packets

5.9.9  droppedOctetDeltaCount






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


   Applicability: all

   Status: current
   Reference: See RFC 1771 for a description of BGB-4.  See RFC 1930 a
      definition of the AS number.

5.4.11  mplsTopLabelType


   Description:
      MPLS top label type:
      This field identifies the control protocol that allocated
      The number of octets since the top previous report (if any) in packets
      of this Flow dropped by packet treatment.  The number of stack label. octets
      include IP header(s) and IP payload.
   Abstract Data Type: octet unsigned64
   Data Type Semantics: identifier

   FieldId: 46

   Applicability: data deltaCounter
   ElementId: 132
   Status: current

5.4.12  mplsTopLabelIPv4Address
   Units: octets

5.9.10  droppedPacketDeltaCount

   Description:
      The IPv4 address number of packets since the system that the MPLS top label will cause previous report (if any) of this
      Flow dropped by packet to be forwarded to. treatment.
   Abstract Data Type: ipV4Address

   FieldId: 47

   Applicability: data unsigned64
   Data Type Semantics: deltaCounter
   ElementId: 133
   Status: current

5.4.13  mplsTopLabelIPv6Address
   Units: packets

5.9.11  droppedOctetTotalCount

   Description:
      The IPv4 address total number of octets in packets of this Flow dropped by
      packet treatment since the system that the MPLS top label will cause 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: 134
   Status: current
   Units: octets

5.9.12  droppedPacketTotalCount

   Description:
      The number of packets of this Flow dropped by packet to be forwarded to. treatment
      since the Metering Process (re-)initialization for this
      Observation Point.
   Abstract Data Type: ipV6Address

   FieldId: 140

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






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


5.5  Properties


5.9.13  postMulticastPacketCount

   Description:
      The number of outgoing multicast packets since the previous report
      (if any) created for packets of Metering/Exporting Process

   Information elements in this section describe static properties Flow by an adjacent multicast
      daemon.  Note that typically not all of the Metering Process and/or created packets can be
      observed at the Exporting Process. 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 set number of these
   information elements is listed octets since the previous report (if any) in
      outgoing multicast packets created for packets of this Flow by an
      adjacent multicast daemon.  Note that typically not all of the table below

   +-------+-------------------------+-------+-------------------------+
      created packets can be observed at the Observation Point of 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 | Field Name                      |  ID | Field Name                      |
   +-------+-------------------------+-------+-------------------------+
   +-----+---------------------------+-----+---------------------------+
   |   130  36 | exporterIPv4Address flowActiveTimeOut         |   131 161 | exporterIPv6Address flowDurationMilliSeconds  |
   +-------+-------------------------+-------+-------------------------+


5.5.1  exporterIPv4Address
   |  37 | flowInactiveTimeout       | 162 | flowDurationMicroSeconds  |
   | 136 | flowEndReason             |     |                           |
   +-----+---------------------------+-----+---------------------------+


5.10.1  flowActiveTimeOut

   Description:
      The IPv4 address used by the Exporting Process.  This number of seconds after which an active Flow is used by
      the Collector to identify the Exporter in cases where the identity timed out
      anyway, even if there is still a continuous flow of packets.
   Abstract Data Type: unsigned16
   ElementId: 36






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


   Status: current
   Units: seconds

5.10.2  flowInactiveTimeout

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

5.10.3  flowEndReason

   Description:
      The reason for flow termination.  The range of values includes
   Abstract Data Type: octet
   Data Type Semantics: identifier

   FieldId: 130

   Applicability: all
   ElementId: 136
   Status: current

5.5.2  exporterIPv6Address

5.10.4  flowDurationMilliSeconds

   Description: The IPv6 address used by the Exporting Process.  This is used by
      the Collector to identify the Exporter difference between in cases where time between the identity observation
      of the Exporter may have been obscured by first packet of this Flow and the use observation of a proxy. the last
      packet of this Flow.
   Abstract Data Type: ipv6Address

   Data Type Semantics: identifier

   FieldId: 131

   Applicability: all unsigned32
   ElementId: 161
   Status: current

5.6  Min/Max Flow Properties

   Information elements
   Units: milliseconds

5.10.5  flowDurationMicroSeconds

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









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


   maximum operations over multiple or all packets of a flow.  They
   cannot serve as flow keys, but their value can be used as trigger


6.  Extending the Information Model

   A key requirement for
   selecting and/or exporting flows.

   The 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 elements resulting from minimum or maximum
   operations over all packets 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 and a flow includes consuming
   application.  For generally applicable Information Elements using
   IETF and IANA mechanisms for extending the information
   elements listed model is
   recommended.

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

   For extensions, the table below.

   +-------+-------------------------+-------+-------------------------+
   |    ID | Field Name              |    ID | Field Name              |
   +-------+-------------------------+-------+-------------------------+
   |    25 | minimumPacketLength     |    22 | flowCreationTime        |
   |    26 | maximumPacketLength     |    21 | flowEndTime             |
   |    52 | minimumTTL              |    36 | flowActiveTimeOut       |
   |    53 | maximumTTL              |    37 | flowInactiveTimeOut     |
   |    64 | ipv6OptionHeaders       |   136 | flowEndReason           |
   |     6 | tcpControlBits          |       |                         |
   +-------+-------------------------+-------+-------------------------+


5.6.1  minimumPacketLength
   Description:
      Length of 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 smallest packet observed for this flow.

   Abstract Data Type: unsigned16

   FieldId: 25

   Applicability: all

   Status: current

   Units: octets

5.6.2  maximumPacketLength
   Description:
      Length general applicability of the largest packet observed for this flow.

   Abstract Data Type: unsigned16

   FieldId: 26

   Applicability: all

   Status: current

   Units: octets such Information Elements should be
   considered.  IPFIX does not support enterprise-specific data types.





















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


5.6.3  minimumTTL
   Description:
      Minimum TTL value observed for any packet in this flow.

   Abstract Data Type: octet

   FieldId: 52

   Applicability: data

   Status: current

5.6.4  maximumTTL
   Description:
      Maximum TTL value observed


7.  IANA Considerations

   IANA has to create a new registry for any packet in this flow.

   Abstract Data Type: octet

   FieldId: 53

   Applicability: data

   Status: current

5.6.5  ipv6OptionHeaders
   Description:
      IPv6 options IPFIX Information Element
   identifiers.  Names of new Information Elements MUST follow the
   naming conventions specified in section 2.3.

   Appendix B defines an XML schema which may be used to create
   consistent machine readable extensions to the IP packet headers of this flow. IPFIX information
   model.  This is
      encoded as schema introduces a bit field.

      bit      IPv6 Option    Definition

       0                       Reserved
       1        44             Fragmentation header - not first fragment
       2        43             Routing header
       3        44             Fragmentation 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 new namespace, which will be
   assigned by IANA according to 31                 Reserved

   Abstract Data Type: unsigned32

   Data Type Semantics: flags RFC 3688.  Currently the name space for
   this schema is identified as http://www.ietf.org/ipfix.








































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


   FieldId: 64

   Applicability: all

   Status: current
   Reference: To be done.

5.6.6  tcpControlBits
   Description:
      TCP control bits observed for packets of this flow.


8.  Security Considerations

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

   The underlying protocol used to exchange the result information described
   here must therefore apply appropriate procedures to guarantee the
   integrity and confidentiality of a logical OR operation over the flags
      observed exported information.  Such
   protocols are defined in all packets of separate documents, specifically the flow.  This implies that a 0 value IPFIX
   protocol document [I-D.ietf-ipfix-protocol].








































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


9.  Acknowledgements

   The editors thank Paul Callato for a bit indicates that the respective bit was not set in any of creating the observed packets initial version 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: octet

   Data Type Semantics: flags

   FieldId: 6

   Applicability: all

   Status: current
   Reference: See RFC 793 document, Thomas Dietz for a definition of the TCP control bits in developing the TCP header.

5.6.7  flowCreationTime
   Description: The timestamp XSLT scripts that
   generate large portions of the first packet text part of this flow.

   Abstract Data Type: dateTimeSeconds

   FieldId: 22

   Applicability: data document from the
   XML appendices, and Paul Aitken for a very detailed review that
   helped improving the document significantly.












































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


   Status: current

5.6.8  flowEndTime
   Description: The timestamp of


10.  Open Issues

   o  Is the last packet of this flow.

   Abstract Data Type: dateTimeSeconds

   FieldId: 21

   Applicability: data

   Status: current

5.6.9  flowActiveTimeOut
   Description:
      The number of seconds after which an active flow is timed out
      anyway, even if there is still a continuous flow of packets.

   Abstract Data Type: unsigned16

   FieldId: 36

   Applicability: all

   Status: current

   Units: seconds

5.6.10  flowInactiveTimeout
   Description:
      A flow is considered to be timed out if no prefix "post" appropriate for packets belonging to leaving the flow have been observed for
      observation domain?  What about packets generated in the number of seconds specified by
      this field.

   Abstract Data Type: unsigned16

   FieldId: 37

   Applicability: all

   Status: current

   Units: seconds

5.6.11  flowEndReason
      observation domain?
   o  octet count including MPLS header: Does the octet count concern IP
      packets only or also sub-IP layers such as MPLS?












































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


   Description:
      The reason


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 flow termination.
      EDITORS' NOTE: This needs to be defined as an enumerated range.

   Abstract Data Type: octet

   FieldId: 136

   Applicability: data

   Status: current

5.7  Per-Flow Counters IP Flow Information elements Export",
              draft-ietf-ipfix-architecture-07 (work in this section are counters all having integral
   values.  Their values may change for every report they are used in.
   They cannot serve as part 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 a flow key used for mapping packets to
   flows.  However, potentially they can be used 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.



Quittek, et al.        Expires November 28, 2005               [Page 56]

Internet-Draft          IPFIX Information Model                 May 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 selecting exported
   flow, Standardization,
              "Information technology - ISO 7-bit coded character set
              for example by only exporting flows with more than a thresholh
   number of observed octets.

   There are running counters 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)", RFC 1771, March 1995.

   [RFC1930]  Hawkinson, J. and delta counters.  Delta counters are
   reset to zero T. Bates, "Guidelines for each time their values are exported.  Running
   counters continue counting independent of the Exporting Process.

   There are per-flow counters creation,
              selection, and counters related to the Metering
   Process and/or the Exporting Process.  Per-flow counters are flow
   properites that potentially change each time a packets belonging to
   the flow is observed.  Per-flow counters are flow properites that
   potentially change each time a packet belonging to the flow is
   observed.  The set registration of per-flow counters includes the information
   elements listed in 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", RFC 2460, December 1998.

   [RFC2463]  Conta, A. and S. Deering, "Internet Control Message
              Protocol (ICMPv6) for the table below.

   +-------+-------------------------+-------+-------------------------+
   |    ID | Field Name              |    ID | Field Name              |
   +-------+-------------------------+-------+-------------------------+
   |     1 | inOctetDeltaCount       |   132 | droppedOctetDeltaCount  |
   |    23 | outOctetDeltaCount      |   133 | droppedOctetTotalCount  |
   |   138 | octetDeltaCount         |   134 | droppedPacketDeltaCount |
   |    85 | inOctetTotalCount       |   135 | droppedPacketTotalCount |
   |     2 | inPacketDeltaCount      |    19 | outMulticastPacketCount |
   |    24 | outPacketDeltaCount     |    20 | outMulticastOctetCount  |
   |   139 | packetDeltaCount        |       |                         |
   |    86 | inPacketTotalCount      |       |                         |
   +-------+-------------------------+-------+-------------------------+ Internet Protocol Version 6
              (IPv6) Specification", RFC 2463, December 1998.

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



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


5.7.1  inOctetDeltaCount
   Description:
      The number of octets in incoming packets observed for this flow at
      the Observation Point since the previous report (if any).  The
      number of octets include IP header(s)


   [RFC2629]  Rose, M., "Writing I-Ds and IP payload.

   Abstract Data Type: unsigned64

   Data Type Semantics: deltaCounter

   FieldId: 1

   Applicability: data

   Status: current

   Units: octets

5.7.2  outOctetDeltaCount
   Description:
      The number of octets in outgoing packets observed for this flow at
      the Observation Point since the previous report (if any).  The
      number of octets include IP header(s) RFCs using XML", RFC 2629,
              June 1999.

   [RFC2863]  McCloghrie, K. and IP payload.

   Abstract Data Type: unsigned64

   Data Type Semantics: deltaCounter

   FieldId: 23

   Applicability: data

   Status: current

   Units: octets

5.7.3  octetDeltaCount
   Description:
      The number of octets 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 all packets observed for this flow at the
      Observation Point since the previous report (if any).  The number
      of octets include IP header(s) Contributions", RFC 3667,
              February 2004.

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

   [RFC3917]  Quittek, J., Zseby, T., Claise, B. and S. Zander,
              "Requirements for IP payload.

   Abstract Data Type: unsigned64

   Data Type Semantics: deltaCounter

   FieldId: 138 Flow Information Export (IPFIX)", RFC
              3917, October 2004.

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















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










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


   Applicability: data

   Status: current

   Units: octets

5.7.4  inOctetTotalCount
   Description:


Appendix A.  Formal Specification of IPFIX Information Element

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

   Using a formal and machine readable syntax for the Information model
   enables the creation of IPFIX aware tools which can automatically
   adapt to extensions to the information model, by simply reading
   updated information model specifications.

   The running counter wide availability of XML aware tools and libraries for client
   devices is a primary consideration for this choice.  In particular
   libraries for parsing XML documents are readily available.  Also
   mechanisms such as the number 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 use of octets XML in incoming packets
      observed Exporters, Collectors or
   other tools is not mandatory for this flow at the Observation Point since deployment of IPFIX.  In
   particular Exporting Processes do not produce or consume XML as part
   of their operation.  It is expected that IPFIX Collectors MAY take
   advantage of the Metering
      Process initialization machine readability of the Information Model vs.
   hard coding their behavior or inventing proprietary means for this Observation Point.
   accommodating extensions.



   <fieldDefinitions>

     <field name="ipVersion" dataType="octet"
            group="IpHeader"
            dataTypeSemantics="identifier"
            fieldId="60" applicability="all" status="current">
       <description>
         The number of
      octets include IP header(s) and version field in the IP payload.

   Abstract Data Type: unsigned64

   Data Type Semantics: totalCounter

   FieldId: 85

   Applicability: all

   Status: current

   Units: octets

5.7.5  inPacketDeltaCount
   Description:
      The number of incoming packets observed packet header.
       </description>
       <reference>
         <paragraph>
         See RFC 791 for this flow at a definition of the
      Observation Point since version field in the previous report (if any).

   Abstract Data Type: unsigned64

   Data Type Semantics: deltaCounter

   FieldId: 2

   Applicability: data

   Status: current

   Units: packets

5.7.6  outPacketDeltaCount
   Description:
      The number of outgoing packets observed
         IPv4 packet header.
         See RFC 2460 for this flow at a definition of the
      Observation Point since version field in the previous report (if any).

   Abstract Data Type: unsigned64
         IPv6 packet header.
         Additional information on defined version numbers
         can be found at
         http://www.iana.org/assignments/version-numbers.
         </paragraph>



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


   Data Type Semantics: deltaCounter

   FieldId: 24

   Applicability: data

   Status: current

   Units: packets

5.7.7  packetDeltaCount
   Description:


       </reference>
     </field>

     <field name="sourceIPv4Address" dataType="ipv4Address"
            group="IpHeader"
            dataTypeSemantics="identifier"
            fieldId="8" applicability="all" status="current">
       <description>
         <paragraph>
         The number of all packets observed IPv4 source address in the IP packet header.
         </paragraph>
       </description>
       <reference>
         See RFC 791 for this flow at the
      Observation Point since definition of the previous report (if any).

   Abstract Data Type: unsigned64

   Data Type Semantics: deltaCounter

   FieldId: 139

   Applicability: data

   Status: current

   Units: packets

5.7.8  inPacketTotalCount
   Description: 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>
       </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 running counter for the number of incoming packets observed
      for this flow at the Observation Point since contiguous bits that are relevant in the Metering Process
      initialization for this Observation Point.

   Abstract Data Type: unsigned64

   Data Type Semantics: totalCounter

   FieldId: 86

   Applicability: all

   Status: current

   Units: packets

5.7.9  droppedOctetDeltaCount



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


   Description:


         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>
         IPv4 source address prefix.
         </paragraph>
       </description>
     </field>

     <field name="sourceIPv6Prefix" dataType="ipv4Address"
            group="IpHeader"
            fieldId="169" 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 number of octets IPv4 destination address in packets of this flow dropped by the IP packet
      treatment.

   Abstract Data Type: unsigned64

   Data Type Semantics: deltaCounter

   FieldId: 132

   Applicability: data

   Status: current

   Units: octets

5.7.10  droppedOctetTotalCount
   Description:
      The number header.
         </paragraph>
       </description>
       <reference>
         See RFC 791 for the definition of octets the IPv4 destination address
         field.
       </reference>
     </field>

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



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


         The IPv6 destination address in packets of this flow dropped by the IP packet
      treatment.

   Abstract Data Type: unsigned64

   Data Type Semantics: totalCounter

   FieldId: 133

   Applicability: data

   Status: current

   Units: octets

5.7.11  droppedPacketDeltaCount
   Description: header.
         </paragraph>
       </description>
     </field>

     <field name="destinationIPv4Mask" dataType="octet"
            group="IpHeader"
            fieldId="13" applicability="option" status="current">
       <description>
         <paragraph>
         The number of packets of this flow dropped by packet treatment.

   Abstract Data Type: unsigned64

   Data Type Semantics: deltaCounter

   FieldId: 134

   Applicability: data

   Status: current

   Units: packets 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>
     </field>

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

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



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


5.7.12  droppedPacketTotalCount
   Description:


            group="IpHeader"
            dataTypeSemantics="identifier"
            fieldId="5" applicability="all" status="current">
       <description>
         <paragraph>
         The number of packets value of this flow dropped by the IPv4 TOS field in the IP packet treatment.

   Abstract Data Type: unsigned64

   Data Type Semantics: totalCounter

   FieldId: 135

   Applicability: data

   Status: current

   Units: packets

5.7.13  outMulticastPacketCount
   Description:
      The number of outgoing multicast packets created header.
         </paragraph>
       </description>
       <reference>
         See RFC 791 for packets the definition of
      this flow by an adjacent multicast daemon.  Note that typically
      not all the IPv4 TOS field.
       </reference>
     </field>

     <field name="classOfServiceIPv6" dataType="octet"
            group="IpHeader"
            dataTypeSemantics="identifier"
            fieldId="137" applicability="data" status="current">
       <description>
         <paragraph>
         The value of the created packets can be observed at IPv6 traffic class field in the Observation
      Point IP packet header.
         </paragraph>
       </description>
       <reference>
         See RFC 2460 for the definition of this flow.

   Abstract Data Type: unsigned64

   FieldId: 19

   Applicability: data

   Status: current

   Units: packets

5.7.14  outMulticastOctetCount
   Description: the IPv6 traffic class
         field.
       </reference>
     </field>

     <field name="postClassOfServiceIPv4" dataType="octet"
            group="IpHeader"
            dataTypeSemantics="identifier"
            fieldId="55" applicability="all" status="current">
       <description>
         <paragraph>
         The number value of octets the IPv4 TOS field in outgoing multicast packets created for
      packets of this flow the IP packet header
         after packet treatment by an adjacent multicast daemon.  Note that
      typically not all of a middlebox function.
         </paragraph>
       </description>
       <reference>
         See RFC 791 for the created packets can be observed at definition of the
      Observation Point IPv4 TOS field.
         See RFC 3234 for the definition of this flow.

   Abstract Data Type: unsigned64

   FieldId: 20

   Applicability: data

   Status: current middleboxes.
       </reference>
     </field>

     <field name="postClassOfServiceIPv6" dataType="octet"
            group="IpHeader"
            dataTypeSemantics="identifier"
            fieldId="138" applicability="data" status="current">



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


   Units: octets

5.8  Process Counters


       <description>
         <paragraph>
         The set value of counters related to the Metering Process and/or IPv6 traffic class field in the
   Exporting Process exported includes IP packet
         header after packet treatment by a middlebox function.
         </paragraph>
       </description>
       <reference>
         See RFC 2460 for the information elements listed
   in definition of the table below.

   +-------+-------------------------+-------+-------------------------+
   |    ID | Field Name              |    ID | Field Name              |
   +-------+-------------------------+-------+-------------------------+
   |     3 | observedFlowTotalCount  |    41 | exportedPacketTotalCount|
   |    40 | exportedOctetToalCount  |    42 | exportedFlowTotalCount  |
   +-------+-------------------------+-------+-------------------------+


5.8.1  observedFlowTotalCount
   Description: IPv6 traffic class
         field.
       </reference>
     </field>

     <field name="flowLabelIPv6" dataType="unsigned32"
            group="IpHeader"
            dataTypeSemantics="identifier"
            fieldId="31" applicability="all" status="current">
       <description>
         <paragraph>
         The number value of flows observed so far the IPv6 Flow Label field in the Observation Domain.

   Abstract Data Type: unsigned64

   Data Type Semantics: totalCounter

   FieldId: 3

   Applicability: data

   Status: current

   Units: flows

5.8.2  exportedOctetTotalCount
   Description:
      The number IP packet header.
         </paragraph>
       </description>
       <reference>
         See RFC 2460 for a definition of all octets reported by the Exporting Process to this
      Collecting Process.

   Abstract Data Type: unsigned64

   Data Type Semantics: totalCounter

   FieldId: 40

   Applicability: data

   Status: current

   Units: octets



Quittek, et al.         Expires August 21, 2005                [Page 41]

Internet-Draft          IPFIX Information Model            February 2005


5.8.3  exportedPacketTotalCount
   Description: flow label field in the
         IPv6 packet header.
       </reference>
     </field>

     <field name="identificationIPv4" dataType="unsigned16"
            group="IpHeader"
            dataTypeSemantics="identifier"
            fieldId="54" applicability="data" status="current">
       <description>
         <paragraph>
         The number value of all packets reported by the Exporting Process to
      this Collecting Process.

   Abstract Data Type: unsigned64

   Data Type Semantics: totalCounter

   FieldId: 41

   Applicability: data

   Status: current

   Units: packets

5.8.4  exportedFlowTotalCount
   Description:
      The number IPv4 packet identification field
         in the IP packet header.
         </paragraph>
       </description>
       <reference>
         See RFC 791 for the definition of all flows records reported by the Exporting Process
      to this Collecting Process.

   Abstract Data Type: unsigned64

   FieldId: 42

   Applicability: data

   Status: current

   Units: flows IPv4 identification
         field.
       </reference>
     </field>

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



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


6.  Extending the Information Model

   A key requirement for IPFIX is to allow for extending the set


         <paragraph>
         The value of
   information items which are reported for flows.  This section defines the mechanism for extending this set. protocol number in the IP packet header.
         The IPFIX protocol carries flow records defined by a template.
   Multiple templates may be defined for a dialog between an Exporter
   and a Collector.  A given template number identifies the information items
   and their order.  The means of identification of information items IP packet payload type.
         Protocol numbers are defined in
   a template the IANA Protocol Numbers
         registry.</paragraph>

         <paragraph>
         In Internet Protocol version 4 (IPv4) this is via a field ID.  Field Id's are unique identifiers
   administered by IANA.

   Extension carried in the
         "Protocol" field. In Internet Protocol version 6 (IPv6) this
         is done by defining new Information elements, including carried in the
   set "Next Header" field in the last extension
         header of necessary information and possibly additional optional
   information the packet.</paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 791 for each element.  Each new information item MUST be
   assigned a unique fieldId as part the specification of its definition.  These unique
   field ids are the connection between IPv4 protocol field.
         See RFC 2460 for the record structure
   communicated by specification of the protocol using templates and a consuming
   application.

   Enterprise-specific extensions may be made by enterprises with an SMI
   network management private enterprise code defined IPv6 protocol field.
         See list of protocol numbers assigned by IANA at
   http://www.iana.org/assignments/enterprise-numbers.
   Enterprise-specific field IDs do not need to be registered by IANA.
         http://www.iana.org/assignments/protocol-numbers.
         </paragraph>
       </reference>
     </field>

       <field name="fragmentOffsetIPv4" dataType="unsigned16"
            group="IpHeader"
            dataTypeSemantics="identifier"
            fieldId="88" applicability="all" status="current">
       <description>
         <paragraph>
         The definition value of a enterprise-specific information element MUST
   specify the enterprise ID as well as the enterprise-specified field
   ID and other mandatory IPv4 fragment offset field properties.  Before creating
   enterprise-specific fields,
         in the general applicability IP packet header.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 791 for the specification of such
   information elements should be considered. the IPv4 fragment offset.
         </paragraph>
       </reference>
     </field>

     <field name="sourceTransportPort" dataType="unsigned16"
            group="transportHeader"
            dataTypeSemantics="identifier"
            fieldId="7" applicability="all" status="current">
       <description>
         <paragraph>
         The source port identifier in the transport header.
         For generally applicable
   fields using IETF and IANA mechanisms for extending the information
   model transport
         protocols UDP, TCP and SCTP this is recommended. the source port number



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


7.  IANA Considerations

   IANA has to create a new registry for IPFIX


         given in the respective header.  This field ID's.

   Appendix B defines an XML schema which may MAY also be used to create
   consistent machine readable extensions to
         for future transport protocols that have 16 bit source port
         identifiers.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         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.</paragraph>
         <paragraph>
         Additional information on defined UDP and TCP port numbers can
         be found at http://www.iana.org/assignments/port-numbers.
         </paragraph>
       </reference>
     </field>

     <field name="destinationTransportPort" dataType="unsigned16"
            group="transportHeader"
            dataTypeSemantics="identifier"
            fieldId="11" applicability="all" status="current">
       <description>
         <paragraph>
         The destination port identifier in the transport header.
         For the transport protocols UDP, TCP and SCTP this is the IPFIX information
   model.
         destination port number given in the respective header.
         This schema introduces a new namespace, which will field MAY also be
   assigned by IANA according to used for future transport protocols
         that have 16 bit destination port identifiers.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 3688.  Currently 768 for the name space definition of the UDP source port field.
         See RFC 793 for
   this schema is identified as http://www.ietf.org/ipfix. 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="icmpTypeCodeIPv4" dataType="unsigned16"
            group="transportHeader"
            dataTypeSemantics="identifier"
            fieldId="32" applicability="all" status="current">
       <description>



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


8.  Security Considerations


         <paragraph>
         Type and Code of the IPv4 ICMP message. The IPFIX information model itself does not directly introduce
   security issues.  Rather it defines a set combination of attributes which may
         both values is reported as (ICMP type * 256) + ICMP code.
         </paragraph>
       </description>
       <reference>
         See RFC 792 for
   privacy or business issues be considered sensitive information.

   The underlying protocol used to exchange a definition of the information described
   here must therefore apply appropriate procedures to guarantee IPv4 ICMP type and code
         fields.
       </reference>
     </field>

     <field name="icmpTypeCodeIPv6" dataType="unsigned16"
            group="transportHeader"
            dataTypeSemantics="identifier"
            fieldId="139" applicability="all" status="current">
       <description>
         <paragraph>
         Type and Code of the
   integrity 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 confidentiality code
         fields.
       </reference>
     </field>

     <field name="igmpType" dataType="octet"
            group="transportHeader"
            dataTypeSemantics="identifier"
            fieldId="33" applicability="all" status="current">
       <description>
         The type field of the exported information.  Such
   protocols are defined in separate documents, specifically IGMP message.
       </description>
       <reference>
         See RFC 2236 for a definition of the IPFIX
   Protocol document [IPFIX-PROTO]. 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 August 21, November 28, 2005               [Page 45] 68]

Internet-Draft          IPFIX Information Model            February                 May 2005


9.  Acknowledgements


       <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 editors thank Benoit Claise for IEEE 802 destination MAC address field
           after processing by a lot of useful input on middlebox function.
         </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>
         <paragraph>
           The IEEE 802.1Q VLAN identifier (VID) extracted from the Tag
           Control Information field definitions.  Also many thanks to Thomas Dietz for developing
   the XSLT scripts that generate large portions of was attached to the text part of
   this document 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 XML appendices.













































Quittek, et al.         Expires August 21, 2005                [Page 46]

Internet-Draft          IPFIX Information Model            February 2005


10.  References

10.1  Normative Reference

   [1]  Claise, B., Fullmer, M., Calato, P. and R. Penno, "IPFIX
        Protocol Specification", IETF draft work in progress, January
        2004,
        <http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-0
        2.txt>.

10.2  Informative Reference

   [2]   Quittek, J., Zseby, T., Claise, B. and S. Zander, "Requirements
         for IP Flow Tag
           Control Information Export", IETF draft work in progress,
         January 2004,
         <http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reqs-15.t
         xt>.

   [3]   Sadasivan, G. and N. Brownlee, "Architecture Model for field that was attached to the IP Flow
         Information Export", IETF draft work in progress, October 2003,
         <http://www.ietf.org/internet-drafts/draft-ietf-ipfix-arch-02.t
         xt>.

   [4]   Zseby, T., Penno, R., Claise, B. and N. Brownlee, "IPFIX
         Applicability", IETF draft work in progress, October 2003,
         <http://www.ietf.org/internet-drafts/draft-ietf-ipfix-as-01.txt
         >.

   [5]   Claise, B., "Cisco Systems NetFlow Services Export Version 9",
         RFC 3954, October 2004, <http://www.ietf.org/rfc/rfc3954.txt>.

   [6]   World Wide Web Consortium, "Extensible Markup Language (XML)
         1.0", W3C XML, February 1998,
         <http://www.w3.org/TR/1998/REC-xml-19980210>.

   [7]   World Wide Web Consortium, "XML Schema Part 1: Structures", W3C
         XML, May 2001,
         <http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/>.

   [8]   World Wide Web Consortium, "XML Schema Part 2: Datatypes", W3C
         XML, May 2001,
         <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes.h
         tml>.

   [9]   Internet Protocol Detail Record Organization, "Network Data
         Management - Usage (NDM-U) For IP-Based Services Version
         3.1.1", October 2002,
         <http://www.ipdr.org/documents/NDM-U_3.1.1.pdf>. packet
           after processing by a middlebox function.
          </paragraph>
       </description>
       <reference>
         See IEEE.802-1Q.2003.



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


   [10]  Brownlee, N. and A. Blount, "Accounting Attributes and Record
         Formats", RFC 2924, Sept. 2000,
         <http://www.ietf.org/rfc/rfc2924.txt>.

   [11]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June
         1999, <http://xml.resource.org/public/rfc/html/rfc2629.html>.

   [12]  Hollenbeck, S., Rose, M.


       </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>
           The IEEE 802 source MAC address field.
           after processing by a middlebox function.
         </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" dataType="unsigned32"
            group="subIpHeader"
            dataTypeSemantics="identifier"
            fieldId="70" applicability="all" status="current">
       <description>
         <paragraph>
         The label, exp and L. Masinter, "Guidelines for s fields from the outermost MPLS label
         stack entry, i.e. the
         Use 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 Extensible Markup Language (XML) within IETF Protocols", Stack, 1 bit
         </artwork>
       </description>
       <reference>
         See RFC 3470, January 2003, <http://www.ietf.org/rfc/rfc3470.txt>.

   [13]  Pras, A. 3032.
       </reference>
     </field>

     <field name="mplsLabelStackEntry2" dataType="unsigned32"
            group="subIpHeader"
            dataTypeSemantics="identifier"
            fieldId="71" applicability="all" status="current">
       <description>
         <paragraph>
         The label, exp, and J. Schoenwaelder, "On s fields from the label stack entry that
         was pushed immediately before the label stack entry that would
         be reported by mplsLabelStackEntry1. See the Difference between
         Information Models and Data Models", RFC 3444, January 2003,
         <http://www.ietf.org/rfc/rfc3444.txt>.

   [14]  Mealling, M., "The IETF XML Registry", RFC 3688, January 2004,
         <http://www.ietf.org/rfc/rfc3688.txt>.


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 Ltd
   250, Longwater, Green Park
   Reading  RG2 6GB
   United Kingdom

   EMail: stbryant@cisco.com












Quittek, et al.         Expires August 21, 2005                [Page 48]

Internet-Draft          IPFIX Information Model            February 2005


   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 definition of



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


Appendix A.  Formal Specification of IPFIX Fields

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

   Using a formal and machine readable syntax


         mplsLabelStackEntry1 for the Information model
   enables the creation of IPFIX aware tools which can automatically
   adapt to extensions to the information model, by simply reading
   updated information model specifications. further details.
         </paragraph>
       </description>
       <reference>
         See RFC 3032.
       </reference>
     </field>

     <field name="mplsLabelStackEntry3" dataType="unsigned32"
            group="subIpHeader"
            dataTypeSemantics="identifier"
            fieldId="72" applicability="all" status="current">
       <description>
         <paragraph>
         The wide availability of XML aware tools label, exp, 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 s fields from the 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 label stack entry that
         was pushed immediately before the label stack entry that would
         be reported by mplsLabelStackEntry2. See the use definition of XML in Exporters, Collectors or
   other tools is not mandatory
         mplsLabelStackEntry1 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 deployment of IPFIX.  In
   particular Exporting Processes do not produce or consume XML as part
   of their operation.  It is expected label stack entry that IPFIX Collectors MAY take
   advantage of
         was pushed immediately before the machine readability of label stack entry that would
         be reported by mplsLabelStackEntry3. See the Information Model vs.
   hardcoding their behavior or inventing proprietary means definition of
         mplsLabelStackEntry1 for
   accomodating extensions.


   <?xml version="1.0" encoding="UTF-8"?>
   <fieldDefinitions> further details.
         </paragraph>
       </description>
       <reference>
         See RFC 3032.
       </reference>
     </field>

     <field name="ipVersion" dataType="octet"
            group="IpHeader"
            fieldId="60" 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 IP version field given in label, exp, and s fields from the IP header. label stack entry that
         was pushed immediately before the label stack entry that would
         be reported by mplsLabelStackEntry4. See the definition of
         mplsLabelStackEntry1 for further details.
         </paragraph>
       </description>
       <units>flows</units>
       <reference>
         <paragraph>
         See RFC 791 for a 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 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 version field in label stack entry that
         was pushed immediately before the
         IPv6 packet header. label stack entry that would
         be reported by mplsLabelStackEntry6. See RFC 2460 for a the 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.
         mplsLabelStackEntry1 for further details.
         </paragraph>
       </description>
       <reference>
         See RFC 3032.
       </reference>
     </field>

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



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


       </reference>
     </field>

     <field name="sourceIPv4Address" dataType="ipv4Address"
            group="IpHeader"
            fieldId="8"


            fieldId="77" applicability="all" status="current">
       <description>
         <paragraph>
         IPv4 source address taken
         The label, exp, and s fields from the IP packet header of a
         packet label stack entry that
         was pushed immediately before the label stack entry that would
         be reported by mplsLabelStackEntry7. See the definition of this flow.
         mplsLabelStackEntry1 for further details.
         </paragraph>
       </description>
       <reference>
         See RFC 791 for the definition of the IPv4 source address
         field. 3032.
       </reference>
     </field>

     <field name="sourceIPv6Address" dataType="ipv6Address"
            group="IpHeader"
            fieldId="27" name="mplsLabelStackEntry9" dataType="unsigned32"
            group="subIpHeader"
            dataTypeSemantics="identifier"
            fieldId="78" applicability="all" status="current">
       <description>
         <paragraph>
         IPv6 source address taken
         The label, exp, and s fields from the IP packet header of a
         packet label stack entry that
         was pushed immediately before the label stack entry that would
         be reported by mplsLabelStackEntry8. See the definition of this flow.
         mplsLabelStackEntry1 for further details.
         </paragraph>
       </description>
       <reference>
         See RFC 3032.
       </reference>
     </field>

     <field name="sourceIPv4Mask" dataType="octet"
            group="IpHeader"
            fieldId="9" applicability="option" name="mplsLabelStackEntry10" dataType="unsigned32"
            group="subIpHeader"
            dataTypeSemantics="identifier"
            fieldId="79" applicability="all" status="current">
       <description>
         <paragraph>
         The number of contiguous bits label, exp, and s fields from the label stack entry that are relevant in
         was pushed immediately before the
         sourceAddressV4 field.
         </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 of contiguous bits label stack entry that are relevant in would
         be reported by mplsLabelStackEntry9. See the definition of
         mplsLabelStackEntry1 for further details.
         </paragraph>
       </description>
       <reference>
         See RFC 3032.
       </reference>
     </field>




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


         sourceAddressV6 field.
         </paragraph>
       </description>
       <units>bits</units>
       <range>0-128</range>
     </field>


     <field name="sourceIPv4Prefix" dataType="ipV4Address"
            group="IpHeader"
            fieldId="44" name="ipNextHopIPv4Address" dataType="ipv4Address"
            group="derived"
            dataTypeSemantics="identifier"
            fieldId="15" applicability="data" status="current">
       <description>
         <paragraph>
         The IPv4 source address prefix. 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>
         EDITOR'S NOTE: to be discussed on ipfix mailing list
         The IPv6 address of the next IPv6 hop.
         </paragraph>
       </description>
       <units>flows</units>
     </field>

   <!--
     <field name="destinationIPv4Address" dataType="ipv4Address"
            group="IpHeader"
            fieldId="12" name="ipNextHopAsNumber" dataType="unsigned16"
            group="derived"
            dataTypeSemantics="identifier"
            fieldId="162" applicability="all" status="current">
       <description>
         <paragraph>
         IPv4 destination address taken from
         The autonomous system (AS) number of the next IP packet header of a
         packet of this flow. hop.
         </paragraph>
       </description>
       <reference>
         See RFC 791 1771 for the a description of BGP-4 and
         see RFC 1930 for a definition of the IPv4 destination address
         field. AS number.
       </reference>
     </field>
   -->

     <field name="destinationIPv6Address" dataType="ipv6Address"
            group="IpHeader"
            fieldId="28" name="bgpSourceAsNumber" dataType="unsigned16"
            group="derived"
            dataTypeSemantics="identifier"
            fieldId="16" applicability="all" status="current">
       <description>
         <paragraph>
         IPv6 destination address taken from
         The autonomous system (AS) number of the source IP packet header of a
         packet of address.
         If AS path information for this flow.
         </paragraph>
       </description>
     </field>

     <field name="destinationIPv4Mask" dataType="octet"
            group="IpHeader"
            fieldId="13" applicability="option" status="current"> Flow is only available as
         unordered AS set (and not as ordered AS sequence),



Quittek, et al.        Expires August 21, November 28, 2005               [Page 52] 75]

Internet-Draft          IPFIX Information Model            February                 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.
       </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 contiguous bits that are relevant in the
         destinationAddressV4 field. 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>
       <units>bits</units>
       <range>0-32</range>
       <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="destinationIPv6Mask" dataType="octet"
            group="IpHeader"
            fieldId="30" applicability="option" name="bgpNextAdjacentAsNumber" dataType="unsigned16"
            group="derived"
            dataTypeSemantics="identifier"
            fieldId="128" applicability="all" status="current">
       <description>
         <paragraph>
         The autonomous system (AS) number of contiguous bits that are relevant the first AS in the
         destinationAddressV6 field.
         </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>
         <paragraph>
         EDITOR'S NOTE: AS
         path to be discussed on ipfix mailing list
         </paragraph>
       </description>
       <units>flows</units>
     </field>

     <field name="classOfServiceIPv4" dataType="octet"
            group="IpHeader"
            dataTypeSemantics="identifier"
            fieldId="5" applicability="all" status="current">
       <description>
         <paragraph> the destination IP address.  The value path is deduced
         by looking up the destination IP address of the IPv4 TOS field observed Flow in the
         BGP routing information base.  If AS path information for packets
         this Flow is only available as unordered AS set (and not as
         ordered AS sequence),
         then the value of this flow. Information Element is 0.
         </paragraph>
       </description>
       <reference>
         See RFC 791 1771 for the a description of BGP-4 and
         see RFC 1930 for a definition of the IPv4 TOS field. AS number.
       </reference>
     </field>




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


     <field name="classOfServiceV6" dataType="octet"
            group="IpHeader"
            fieldId="137" applicability="data" name="bgpPrevAdjacentAsNumber" dataType="unsigned16"
            group="derived"
            dataTypeSemantics="identifier"
            fieldId="129" applicability="all" status="current">
       <description>
         <paragraph>
         The value autonomous system (AS) number of the IPv6 traffic class field observed
         for packets of this flow.
         </paragraph>
       </description>
       <reference>
         See RFC 2460 for last AS in the definition of AS
         path from the IPv6 traffic class field.
       </reference>
     </field>

     <field name="flowLabelV6" dataType="unsigned32"
            group="IpHeader"
            fieldId="31" applicability="all" status="current">
       <description>
         <paragraph> source IP address.  The Flow Label path is deduced
         by looking up the source IP address of the IPv6 packet header observed Flow in the first packet BGP
         routing information base.  If AS path information for this
         Flow is only available as unordered AS set (and not as
         ordered AS sequence), then the value of this flow. 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 2460 1771 for a description of BGP-4 and
         see RFC 1930 for a definition of the flow label field in the
         IPv6 packet header. AS number.
       </reference>
     </field>

     <field name="identificationV4" dataType="unsigned16"
            group="IpHeader" name="bgpNextHopIPv4Address" dataType="ipv4Address"
            group="derived"
            dataTypeSemantics="identifier"
            fieldId="54" applicability="data"
            fieldId="18" applicability="all" status="current">
       <description>
         <paragraph>
         The IPv4 packet identification field from the first
           packet address of this flow. the next (adjacent) BGP hop.
         </paragraph>
       </description>
       <reference>
         See RFC 791 1771 for the definition a description of the IPv4 identification field. BGP-4 and
       </reference>
     </field>

     <field name="protocolIdentifier" dataType="octet"
            group="IpHeader" name="bgpNextHopIPv6Address" dataType="ipv6Address"
            group="derived"
            dataTypeSemantics="identifier"
            fieldId="4"
            fieldId="63" applicability="all" status="current">



Quittek, et al.         Expires August 21, 2005                [Page 54]

Internet-Draft          IPFIX Information Model            February 2005
       <description>
         <paragraph>
         The protocol number observed for packets of this flow.
         The protocol number identifies the IP packet payload.
         Protocol numbers are defined in the IANA Protocol Numbers
         registry.</paragraph>

         <paragraph>
         In Internet Protocol version 4 (IPv4) this is carried in
         the "Protocol" field. In Internet Protocol version 6 (IPv6)
         this is carried in the "Next Header" field in the last
         extension header IPv6 address of the packet.</paragraph> next (adjacent) BGP hop.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 791 for the specification of the IPv4 protocol field.
         See RFC 2460 1771 for the specification of the IPv6 protocol field.
         See list a description of protocol numbers assigned by IANA at
         http://www.iana.org/assignments/protocol-numbers.
         </paragraph> BGP-4.



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


       </reference>
     </field>

     <field name="sourceTransportPort" dataType="unsigned16"
            group="transportHeader" name="mplsTopLabelType" dataType="octet"
            group="derived"
            dataTypeSemantics="identifier"
            fieldId="7" applicability="all"
            fieldId="46" applicability="data" status="current">
       <description>
         <paragraph>
         A source port identifier in the transport header. For 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 identifies the control protocol that have 16 bit source port
         identifiers. 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>
         <paragraph>
         See RFC 768 3031 for the definition of the UDP source port field. MPLS label structure.
         See RFC 793 2547 for the definition association of the TCP source port field. MPLS labels with VPNs.
         See RFC 2960 1771 for the definition of SCTP.</paragraph>
         <paragraph>
         Additional information on defined UDP BGP and TCP port numbers
         can 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 found at http://www.iana.org/assignments/port-numbers. 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 August 21, November 28, 2005               [Page 55] 78]

Internet-Draft          IPFIX Information Model            February                 May 2005


     <field name="destinationtransportPort" dataType="unsigned16"
            group="transportHeader"


            dataTypeSemantics="identifier"
            fieldId="11" applicability="all"
            fieldId="140" applicability="data" status="current">
       <description>
         <paragraph>
         A destination port identifier in the transport header.
         For transport protocols UDP, TCP and SCTP this is
           The IPv6 address of the
         destination port number given in system that the respective header.
         This field MAY also MPLS top label will
           cause this Flow to be used for future transport protocols
         that have 16 bit destination port identifiers. forwarded to.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 768 3031 for the definition of the UDP source port field.
         See RFC 793 for 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 definition of Exporting Process.  This is used
         by the TCP source port field.
         See RFC 2960 for Collector to identify 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. Exporter in cases where the
         identity of the Exporter may have been obscured by the use of
         a proxy.
         </paragraph>
       </reference>
       </description>
     </field>

     <field name="icmpTypeCode" dataType="unsigned16"
            group="transportHeader"
            fieldId="32" name="exporterIPv6Address" dataType="ipv6Address"
            dataTypeSemantics="identifier"
            group="config"
            fieldId="131" applicability="all" status="current">
       <description>
         <paragraph>
         Type and Code
         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 ICMP message. The combination Exporter may have been obscured by the use of both values
         is reported as (ICMP type * 256) + ICMP code.
         a proxy.
         </paragraph>
       </description>
       <reference>
         See RFC 792 for a definition of the ICMP type and code fields.
       </reference>
     </field>

     <field name="igmpType" dataType="octet"
            group="transportHeader"
            fieldId="33" name="minimumPacketLength" dataType="unsigned16"
            group="minMax"
            fieldId="25" applicability="all" status="current">
       <description>
         The type field
         <paragraph>
         Length of the IGMP message.
       </description>
       <reference>
         See RFC 2236 smallest packet observed for a definition of the IGMP type field. this Flow.



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


       </reference>


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

     <field name="sourceMacAddress" dataType="octetArray"
            group="subIpHeader"
            fieldId="56" applicability="data" name="maximumPacketLength" dataType="unsigned16"
            group="minMax"
            fieldId="26" applicability="all" status="current">
       <description>
         <paragraph>
           Packet identification field from
         Length of the first IP largest packet of observed for this flow. Flow.
         </paragraph>
       </description>
       <reference>
         See RFC 791 for the definition of the IPv4 identification field.
       </reference>
       <units>octets</units>
     </field>

     <field name="mplsLabelStackEntry1" dataType="unsigned32"
            group="subIpHeader"
            fieldId="70" applicability="all" name="minimumTtl" dataType="octet"
            group="minMax"
            fieldId="52" applicability="data" status="current">
       <description>
         <paragraph>
         The label, exp and s fields from the outermost MPLS label
         stack entry e.g. the last label that was pushed last.
         </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>
           Minimum TTL value observed for any packet in this Flow.
         </paragraph>
       </description>
       <reference>
         See RFC 3032.
       </reference>
     </field>

     <field name="mplsLabelStackEntry2" 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="ipv6OptionHeaders" dataType="unsigned32"
            group="subIpHeader"
            fieldId="71"
            dataTypeSemantics="flags"
            group="minMax"
            fieldId="64" applicability="all" status="current">
       <description>
         <paragraph>
         The label, exp and s fields from
         IPv6 options in the LSE that was pushed
         immediately before IP packet headers 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 if any observed packet of this
         Flow contains the LSE that would be reported by corresponding IPv6 option header.
         </paragraph>



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


         mplsLabelStackEntry1. See the definition of mplsLabelStackEntry1 for
         further details.
         </paragraph>


         <artwork>
      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 to 31                 Reserved
         </artwork>
       </description>
       <reference>
        See RFC 3032.
       </reference>
     </field>

     <field name="mplsLabelStackEntry3" dataType="unsigned32"
            group="subIpHeader"
            fieldId="72" applicability="all" status="current">
       <description>
         <paragraph>
         The label, exp and s fields from the LSE that was pushed
         immediately before the LSE that would be reported by
         mplsLabelStackEntry2. See 2460 for the general definition of mplsLabelStackEntry1 for
         further details.
         </paragraph>
       </description>
       <reference>
         See RFC 3032.
       </reference>
     </field>

     <field name="mplsLabelStackEntry4" dataType="unsigned32"
            group="subIpHeader"
            fieldId="73" applicability="all" status="current">
       <description>
         <paragraph>
         The label, exp IPv6 extensions
        headers and s fields from for the LSE that was pushed
         immediately before specification of the hop-by-hop options
        header, the LSE that would be reported by
         mplsLabelStackEntry3. routing header, the fragment header, and the
        destination options header.
        See RFC 2402 for the definition specification of mplsLabelStackEntry1 for
         further details.
         </paragraph>
       </description>
       <reference> the authentication
        header.
        See RFC 3032. 2406 for the specification of the encapsulating
        security payload.
       </reference>
     </field>

     <field name="mplsLabelStackEntry5" dataType="unsigned32"
            group="subIpHeader"
            fieldId="74" 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 label, exp and s fields from 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 LSE corresponding TCP control bit set to 1.
         A value of 0 for a bit indicates that the corresponding
         bit was pushed
         immediately before not set in any of the LSE that would be reported by observed packets
         of this Flow.
         </paragraph>
         <artwork>
          0     1     2     3     4     5     6     7
      +-----+-----+-----+-----+-----+-----+-----+-----+



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


         mplsLabelStackEntry4. See the definition of mplsLabelStackEntry1


      |  Reserved | URG | ACK | PSH | RST | SYN | FIN |
      +-----+-----+-----+-----+-----+-----+-----+-----+

      Reserved:  Reserved for
         further details.
         </paragraph> 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
       <reference>See RFC 3032.
       </reference> 793 for a definition of the TCP control bits
       in the TCP header.</reference>
     </field>

     <field name="mplsLabelStackEntry6" dataType="unsigned32"
            group="subIpHeader"
            fieldId="75" applicability="all" name="flowStartSeconds" dataType="dateTimeSeconds"
            group="timestamp"
            fieldId="150" applicability="data" status="current">
       <description>
         <paragraph>
         The label, exp and s fields from the LSE that was pushed
         immediately before absolute timestamp of the LSE that would be reported by
         mplsLabelStackEntry5. See first packet of this Flow.
       </description>
       <units>seconds</units>
     </field>

     <field name="flowEndSeconds" dataType="dateTimeSeconds"
            group="timestamp"
            fieldId="151" applicability="data" status="current">
       <description>
         The absolute timestamp of the definition last packet of mplsLabelStackEntry1 for
         further details.
         </paragraph> this Flow.
       </description>
       <reference>
         See RFC 3032.
       </reference>
       <units>seconds</units>
     </field>

     <field name="mplsLabelStackEntry7" dataType="unsigned32"
            group="subIpHeader"
            fieldId="76" applicability="all" name="flowStartMilliSeconds" dataType="dateTimeMilliSeconds"
            group="timestamp"
            fieldId="152" applicability="data" status="current">
       <description>
         <paragraph>
         The label, exp and s fields from the LSE that was pushed
         immediately before the LSE that would be reported by
         mplsLabelStackEntry6. See absolute timestamp of the definition first packet of mplsLabelStackEntry1 for
         further details.
         </paragraph> this Flow.
       </description>
       <reference>
         See RFC 3032.
       </reference>
       <units>milliseconds</units>
     </field>

     <field name="mplsLabelStackEntry8" dataType="unsigned32"
            group="subIpHeader"
            fieldId="77" applicability="all" name="flowEndMilliSeconds" dataType="dateTimeMilliSeconds"
            group="timestamp"
            fieldId="153" applicability="data" status="current">
       <description>
         <paragraph>
         The label, exp and s fields from the LSE that was pushed
         immediately before absolute timestamp of the LSE that would be reported by last packet of this Flow.



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


         mplsLabelStackEntry7. See


       </description>
       <units>milliseconds</units>
     </field>

     <field name="flowStartMicroSeconds" dataType="dateTimeMicroSeconds"
            group="timestamp"
            fieldId="154" applicability="data" status="current">
       <description>
         The absolute timestamp of the definition first packet of mplsLabelStackEntry1 for
         further details.
         </paragraph> this Flow.
       </description>
       <reference>
         See RFC 3032.
       </reference>
       <units>microseconds</units>
     </field>

     <field name="mplsLabelStackEntry9" dataType="unsigned32"
            group="subIpHeader"
            fieldId="78" applicability="all" name="flowEndMicroSeconds" dataType="dateTimeMicroSeconds"
            group="timestamp"
            fieldId="155" applicability="data" status="current">
       <description>
         <paragraph>
         The label, exp and s fields from the LSE that was pushed
         immediately before the LSE that would be reported by
         mplsLabelStackEntry8. See absolute timestamp of the definition last packet of mplsLabelStackEntry1 for
         further details.
         </paragraph> this Flow.
       </description>
       <reference>
         See RFC 3032.
       </reference>
       <units>microseconds</units>
     </field>

     <field name="mplsLabelStackEntry10" dataType="unsigned32"
            group="subIpHeader"
            fieldId="79" applicability="all" name="flowStartNanoSeconds" dataType="dateTimeNanoSeconds"
            group="timestamp"
            fieldId="156" applicability="data" status="current">
       <description>
         <paragraph>
         The label, exp and s fields from the LSE that was pushed
         immediately before the LSE that would be reported by
         mplsLabelStackEntry9. See absolute timestamp of the definition first packet of mplsLabelStackEntry1 for
         further details.
         </paragraph> this Flow.
       </description>
       <reference>
         See RFC 3032.
       </reference>
       <units>nanoseconds</units>
     </field>

     <field name="ipNextHopIPv4Address" dataType="ipv4Address"
            group="derived"
            fieldId="15" name="flowEndNanoSeconds" dataType="dateTimeNanoSeconds"
            group="timestamp"
            fieldId="157" applicability="data" status="current">
       <description>
         <paragraph>
         The IPv4 address absolute timestamp of the next IP hop to which packets 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.  It contains the negative time
         offset of the first observed packet of this flow are forwarded. Flow relative
         to the export time specified in the IPFIX Message header.



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


         </paragraph>


       </description>
     </field>

     <field name="ipNextHopIPv6Address" dataType="ipv6Address"
            group="derived"
            fieldId="62" applicability="data" status="current">
       <description>
         <paragraph>
         The IPv6 address of
       <reference>
         See [I-D.ietf-ipfix-protocol] for the next BGP hop to which packets definition of
         this flow are forwarded.
         </paragraph>
       </description> the IPFIX
         Message header.
       </reference>
       <units>microseconds</units>
     </field>

     <field name="ingressInterface" name="flowEndDeltaMicroSeconds" dataType="unsigned32"
            group="derived"
            dataTypeSemantics="identifier"
            fieldId="10" applicability="all"
            group="timestamp"
            fieldId="159" applicability="data" status="current">
       <description>
         <paragraph>
         The index
         This is a relative time stamp only valid within the scope
         of a single IPFIX message.  It contains the IP interface (ifIndex) where packets negative time
         offset of the last observed packet of this flow are being received.
         </paragraph> Flow relative
         to the export time specified in the IPFIX Message header.
       </description>
       <reference>
         See RFC 2863 [I-D.ietf-ipfix-protocol] for the definition of the ifIndex object. IPFIX
         Message header.
       </reference>
       <units>microseconds</units>
     </field>

     <field name="egressInterface" 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.
       </description>
       <units>milliseconds</units>
     </field>

     <field name="flowStartSysUpTime" dataType="unsigned32"
            group="derived"
            dataTypeSemantics="identifier"
            fieldId="14" applicability="all"
            group="timestamp"
            fieldId="22" applicability="data" status="current">
       <description>
         <paragraph>
         The index relative timestamp of the IP interface (ifIndex) where packets first packet of this
         flow are being sent.
         </paragraph>
       </description>
       <reference>
         See RFC 2863 for Flow.
         It indicates the definition number of milliseconds since the ifIndex object.
       </reference>
         last (re-)initialization of the IPFIX device (sysUpTime).
       </description>
       <units>milliseconds</units>
     </field>

     <field name="ipNextHopAsNumber" dataType="unsigned16"
            group="derived"
            dataTypeSemantics="identifier" name="flowEndSysUpTime" dataType="unsigned32"
            group="timestamp"
            fieldId="21" applicability="data" status="current">



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


            fieldId="129" applicability="all" status="current">


       <description>
         <paragraph>
         The autonomous system (AS) number relative timestamp of the next IP hop to
         which packets last packet of this flow are forwarded.
         </paragraph>
       </description>
       <reference>
         See RFC 1771 for a description Flow.
         It indicates the number of BGB-4 and
         see RFC 1930 a definition milliseconds since the
         last (re-)initialization of the AS number.
       </reference> IPFIX device (sysUpTime).
       </description>
       <units>milliseconds</units>
     </field>

     <field name="bgpSourceAsNumber" name="flowActiveTimeOut" dataType="unsigned16"
            group="derived"
            dataTypeSemantics="identifier"
            fieldId="16"
            group="misc"
            fieldId="36" applicability="all" status="current">
       <description>
         <paragraph>
         The autonomous system (AS) number of the source address in
         the IP packet header in seconds after which an active Flow is timed out
         anyway, even if there is still a packet continuous flow of this flow. packets.
         </paragraph>
       </description>
       <reference>
         See RFC 1771 for a description of BGB-4 and
         see RFC 1930 a definition of the AS number.
       </reference>
       <units>seconds</units>
     </field>

     <field name="bgpDestinationAsNumber" name="flowInactiveTimeout" dataType="unsigned16"
            group="derived"
            dataTypeSemantics="identifier"
            fieldId="17"
            group="misc"
            fieldId="37" applicability="all" status="current">
       <description>
         <paragraph>
         The autonomous system (AS) number of
          A Flow is considered to be timed out if no packets belonging
          to the destination address
         in Flow have been observed for the IP packet header in a packet number of seconds
          specified by this flow. field.
         </paragraph>
       </description>
       <reference>
         See RFC 1771 for a description of BGB-4 and
         see RFC 1930 a definition of the AS number.
       </reference>
       <units>seconds</units>
     </field>

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



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


            fieldId="128" applicability="all"


       </description>
     </field>

     <field name="flowDurationMilliSeconds" dataType="unsigned32"
            group="misc"
            fieldId="161" applicability="data" status="current">
       <description>
         <paragraph>
         The autonomous system (AS) number difference between in time between the observation of the next BGP hop to
         which packets
         first packet of this flow are forwarded.
         </paragraph> Flow and the observation of the last
         packet of this Flow.
       </description>
       <reference>
         See RFC 1771 for a 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 BGB-4 this Flow and
         see RFC 1930 a definition the observation of the AS number.
       </reference> last
         packet of this Flow.
       </description>
       <units>microseconds</units>
     </field>

     <field name="bgpNextHopIPv4Address" dataType="ipv4Address"
            group="derived"
            fieldId="18" applicability="all" name="octetDeltaCount" dataType="unsigned64"
            dataTypeSemantics="deltaCounter"
            group="flowCounter"
            fieldId="1" applicability="data" status="current">
       <description>
         <paragraph>
         The IPv4 address number of octets since the next BGP hop to which previous report (if any)
         in incoming packets of
         this flow are forwarded.
         </paragraph>
       </description>
       <reference>
         See RFC 1771 for a description of BGB-4 and
         see RFC 1930 a definition of this Flow at the AS number.
       </reference> Observation Point.
         The number of octets include IP header(s) and IP payload.
         </paragraph>
       </description>
       <units>octets</units>
     </field>

     <field name="bgpNextHopIPv6Address" dataType="ipv6Address"
            group="derived"
            dataTypeSemantics="identifier"
            fieldId="63" applicability="all" name="postOctetDeltaCount" dataType="unsigned64"
            dataTypeSemantics="deltaCounter"
            group="flowCounter"
            fieldId="23" applicability="data" status="current">
       <description>
         <paragraph>
         The IPv6 address number of octets since the next BGP hop to which previous report (if any)
         in outgoing packets of
         this flow are forwarded.
         </paragraph>
       </description>
       <reference>
         See RFC 1771 for a description of BGB-4.
         See RFC 1930 a definition of this Flow at the AS number.
       </reference>
     </field>

     <field name="mplsTopLabelType" dataType="octet"
            group="derived"
            dataTypeSemantics="identifier"
            fieldId="46" applicability="data" status="current"> Observation Point.
         The number of octets include IP header(s) and IP payload.



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


       <description>
         <paragraph>
         MPLS top label type:
         <list>
         <item> 0x01 TE-MIDPT: Any TE tunnel mid-point or tail label</item>
         <item> 0x02 Pseudowire: Any PWE3 or Cisco AToM based label</item>
         <item> 0x03 VPN: Any label associated with VPN</item>
         <item> 0x04 BGP: Any label associated with BGP or BGP routing</item>
         <item> 0x05 LDP: Any label associated with dynamically assigned
                labels using LDP</item>
         </list>
         This field identifies the control protocol that allocated the
         top of stack label.


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

     <field name="mplsTopLabelIPv4Address" dataType="ipV4Address"
            group="derived"
            fieldId="47" applicability="data" name="octetTotalCount" dataType="unsigned64"
            dataTypeSemantics="totalCounter"
            group="flowCounter"
            fieldId="85" applicability="all" status="current">
       <description>
         <paragraph>
         The IPv4 address total number of octets in incoming packets
         for this Flow at the system that Observation Point since the MPLS top label will
           cause Metering
         Process (re-)initialization for this packet to be forwarded to. Observation Point. The
         number of octets include IP header(s) and IP payload.
         </paragraph>
       </description>
       <units>octets</units>
     </field>

     <field name="mplsTopLabelIPv6Address" dataType="ipV6Address"
            group="derived"
            fieldId="140" applicability="data" name="postOctetTotalCount" dataType="unsigned64"
            dataTypeSemantics="totalCounter"
            group="flowCounter"
            fieldId="170" applicability="all" status="current">
       <description>
         <paragraph>
         The IPv4 address total number of octets in outgoing packets
         for this Flow at the system that Observation Point since the MPLS top label will
           cause Metering
         Process (re-)initialization for this packet to be forwarded to.
         </paragraph>
       </description>
     </field>

     <field name="exporterIPv4Address" dataType="ipv4Address"
            dataTypeSemantics="identifier"
            group="config"
            fieldId="130" applicability="all" Observation Point. The
         number of octets include IP header(s) and IP payload.
         </paragraph>
       </description>
       <units>octets</units>
     </field>

     <field name="packetDeltaCount" dataType="unsigned64"
            dataTypeSemantics="deltaCounter"
            group="flowCounter"
            fieldId="2" applicability="data" status="current">
       <description>
         <paragraph>
         The IPv4 address used by the Exporting Process.
         This is used by the Collector to identify the Exporter
         in cases where the identity number of incoming packets since the Exporter may have been previous report
         (if any) for this Flow at the Observation Point.
         </paragraph>
       </description>
       <units>packets</units>
     </field>




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


         obscured by the use


     <field name="postPacketDeltaCount" dataType="unsigned64"
            dataTypeSemantics="deltaCounter"
            group="flowCounter"
            fieldId="24" applicability="data" status="current">
       <description>
         <paragraph>
         The number of a proxy. outgoing packets since the previous report
         (if any) for this Flow at the Observation Point.
         </paragraph>
       </description>
       <units>packets</units>
     </field>

     <field name="exporterIPv6Address" dataType="ipv6Address"
            dataTypeSemantics="identifier"
            group="config"
            fieldId="131" name="packetTotalCount" dataType="unsigned64"
            dataTypeSemantics="totalCounter"
            group="flowCounter"
            fieldId="86" 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 total number of incoming packets for this Flow
         at the Exporter may have been
         obscured by Observation Point since the use of a proxy. Metering Process
         (re-)initialization for this Observation Point.
         </paragraph>
       </description>
       <units>packets</units>
     </field>

     <field name="minimumPacketLength" dataType="unsigned16"
            group="minMax"
            fieldId="25" name="postPacketTotalCount" dataType="unsigned64"
            dataTypeSemantics="totalCounter"
            group="flowCounter"
            fieldId="171" applicability="all" status="current">
       <description>
         <paragraph>
         Length
         The total number of outgoing packets for this Flow
         at the smallest packet observed Observation Point since the Metering Process
         (re-)initialization for this flow. Observation Point.
         </paragraph>
       </description>
       <units>octets</units>
       <units>packets</units>
     </field>

     <field name="maximumPacketLength" dataType="unsigned16"
            group="minMax"
            fieldId="26" applicability="all" name="droppedOctetDeltaCount" dataType="unsigned64"
            dataTypeSemantics="deltaCounter"
            group="flowCounter"
            fieldId="132" applicability="data" status="current">
       <description>
         <paragraph>
         Length
         The number of octets since the largest packet observed for 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. Flow dropped by packet treatment.
         The number of octets include IP header(s) and IP payload.
         </paragraph>
       </description>
       <units>octets</units>
     </field>

     <field name="minimumTTL" dataType="octet"
            group="minMax"
            fieldId="52" name="droppedPacketDeltaCount" dataType="unsigned64"
            dataTypeSemantics="deltaCounter"
            group="flowCounter"
            fieldId="133" applicability="data" status="current">
       <description>
         <paragraph>
           Minimum TTL value observed for any packet in
         The number of packets since the previous report (if any)
         of this flow. Flow dropped by packet treatment.
         </paragraph>



Quittek, et al.         Expires August 21, 2005                [Page 65]

Internet-Draft          IPFIX Information Model            February 2005
       </description>
       <units>packets</units>
     </field>

     <field name="maximumTTL" dataType="octet"
            group="minMax"
            fieldId="53" name="droppedOctetTotalCount" dataType="unsigned64"
            dataTypeSemantics="totalCounter"
            group="flowCounter"
            fieldId="134" applicability="data" status="current">
       <description>
         <paragraph>
           Maximum TTL value observed for any packet
         The total number of octets in packets of this flow. 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.
         </paragraph>
       </description>
       <units>octets</units>
     </field>

     <field name="ipv6OptionHeaders" dataType="unsigned32"
            dataTypeSemantics="flags"
            group="minMax"
            fieldId="64" applicability="all" name="droppedPacketTotalCount" dataType="unsigned64"
            dataTypeSemantics="totalCounter"
            group="flowCounter"
            fieldId="135" applicability="data" status="current">
       <description>
         <paragraph>
         IPv6 options in the IP packet headers
         The number of packets of this flow.
         This is encoded as a bit field. Flow dropped by packet
         treatment since the Metering Process
         (re-)initialization for this Observation Point.
         </paragraph>
         <artwork>
      bit      IPv6 Option    Definition

       0                       Reserved
       1        44             Fragmentation header - not first fragment
       2        43             Routing header
       3        44             Fragmentation 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 to 31                 Reserved
         </artwork>
       </description>
       <reference>
         To be done.
       </reference>
       <units>packets</units>
     </field>

     <field name="tcpControlBits" dataType="octet"
            dataTypeSemantics="flags"
            group="minMax"



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


            fieldId="6" applicability="all"


     <field name="postMulticastPacketCount" dataType="unsigned64"
            dataTypeSemantics="deltaCounter"
            group="flowCounter"
            fieldId="19" applicability="data" status="current">
       <description>
         <paragraph>
         TCP control bits observed for packets of this flow.
         The value of this field is the result number of a logical OR operation
         over the flags observed in all outgoing multicast packets of since the flow.
         This implies that a 0 value
         previous report (if any) created for a bit indicates that the
         respective bit was packets
         of this Flow by an adjacent multicast daemon.
         Note that typically not set in any all of the observed created packets can be
         observed at the Observation Point of this flow. Flow.
         </paragraph>
         <artwork>
          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
         </artwork>
       </description>
       <reference>See RFC 793 for a definition of the TCP control bits
       in the TCP header.</reference>
       <units>packets</units>
     </field>

     <field name="flowCreationTime" dataType="dateTimeSeconds"
            group="minMax"
            fieldId="22" name="postMulticastOctetCount" dataType="unsigned64"
            dataTypeSemantics="deltaCounter"
            group="flowCounter"
            fieldId="20" applicability="data" status="current">
       <description>
         <paragraph>
         The timestamp number of octets since the first packet previous report (if any)
         in outgoing multicast packets created
         for packets of this flow. Flow by an adjacent multicast daemon.
         Note that typically not all of the created packets can be
         observed at 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="flowEndTime" dataType="dateTimeSeconds"
            group="minMax"
            fieldId="21" name="exportedMessageTotalCount" dataType="unsigned64"
            dataTypeSemantics="totalCounter"
            group="processCounter"
            fieldId="41" applicability="data" status="current">
       <description>
         <paragraph>
         The timestamp total number of IPFIX Messages that the last packet of Exporting Process
         successfully sent since the Exporting Process (re-)initialization
         to the Collecting Process receiving a report that contains
         this flow. Information Element.
         </paragraph>
       </description>
       <units>messages</units>
     </field>

     <field name="flowActiveTimeOut" dataType="unsigned16"
            group="minMax"
            fieldId="36" applicability="all" status="current">




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


     <field name="exportedOctetTotalCount" dataType="unsigned64"
            dataTypeSemantics="totalCounter"
            group="processCounter"
            fieldId="40" applicability="data" status="current">
       <description>
         <paragraph>
            The total 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="minMax"
            fieldId="37" applicability="all" status="current">
       <description>
         <paragraph>
          A flow is considered to be timed out if no packets belonging
          to octets that the Exporting Process
            successfully sent since the flow have been observed for Exporting Process
            (re-)initialization to the number Collecting Process receiving a report
            that contains this Information Element.  The value of seconds
          specified this
            Information Element is calculated by summing up the IPFIX
            Message header length values of all IPFIX messages that
            were successfully sent to the Collecting Process receiving
            a report that contains this field. Information Element.
         </paragraph>
       </description>
       <units>seconds</units>
       <units>octets</units>
     </field>

     <field name="flowEndReason" dataType="octet"
            group="minMax"
            fieldId="136" name="exportedFlowTotalCount" dataType="unsigned64"
            group="processCounter"
            dataTypeSemantics="totalCounter"
            fieldId="42" applicability="data" status="current">
       <description>
         <paragraph>
         The reason for flow termination.
         <list>
           <item>idle timeout</item>
           <item>end total number of flow detected (e.g. TCP FIN)</item>
           <item>forced end</item>
           <item>cache full</item>
         </list>
         EDITORS' NOTE: This needs to be defined Flows Records reported that the Exporting
         Process successfully sent as an
         enumerated range. 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="inOctetDeltaCount" name="observedFlowTotalCount" dataType="unsigned64"
            dataTypeSemantics="deltaCounter"
            group="flowCounter"
            fieldId="1"
            dataTypeSemantics="totalCounter"
            group="processCounter"
            fieldId="3" applicability="data" status="current">
       <description>
         <paragraph>
         The total number of octets in incoming packets Flows observed for this
         flow at in the Observation Point Domain
         since the previous report (if any). Metering Process (re-)initialization for this
         Observation Point.
         </paragraph>
       </description>
       <units>Flows</units>
     </field>




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


         The number of octets include IP header(s) and IP payload.
         </paragraph>
       </description>
       <units>octets</units>
     </field>


     <field name="outOctetDeltaCount" name="ignoredPacketTotalCount" dataType="unsigned64"
            dataTypeSemantics="deltaCounter"
            group="flowCounter"
            fieldId="23"
            dataTypeSemantics="totalCounter"
            group="processCounter"
            fieldId="163" applicability="data" status="current">
       <description>
         <paragraph>
            The total number of octets in outgoing packets observed for this
         flow at the Observation Point since the previous report (if any).
         The number of octets include IP header(s) and IP payload. packets that the
            Metering Process did not process.
         </paragraph>
       </description>
       <units>octets</units>
       <units>packets</units>
     </field>

     <field name="octetDeltaCount" name="ignoredOctetTotalCount" dataType="unsigned64"
            dataTypeSemantics="deltaCounter"
            group="flowCounter"
            fieldId="138"
            dataTypeSemantics="totalCounter"
            group="processCounter"
            fieldId="164" applicability="data" status="current">
       <description>
         <paragraph>
            The total number of octets in all packets observed for this
         flow at the Observation Point since the previous report (if any).
         The number of octets include IP header(s) and IP payload. packets
            that the Metering Process did not process.
         </paragraph>
       </description>
       <units>octets</units>
     </field>

     <field name="inOctetTotalCount" name="notSentFlowTotalCount" dataType="unsigned64"
            dataTypeSemantics="totalCounter"
            group="flowCounter"
            fieldId="85" applicability="all"
            group="processCounter"
            fieldId="165" applicability="data" status="current">
       <description>
         <paragraph>
            The running counter for the total number of octets in incoming packets
         observed for this flow at Flow Records that were generated by the Observation Point since
            Metering Process and but dropped by the Metering Process initialization or
            by the Exporting Process
            instead of sending it to the Collecting Process.
            There are several potential reasons for this Observation Point. The
         number of octets include IP header(s) including
            resource shortage and IP payload. special Flow export policies.
         </paragraph>
       </description>
       <units>octets</units>
       <units>Flows</units>
     </field>

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



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


     <field name="inPacketDeltaCount" dataType="unsigned64"
            dataTypeSemantics="deltaCounter"
            group="flowCounter"
            fieldId="2" applicability="data" status="current">
       <description>


         <paragraph>
            The total number of incoming packets observed for this flow at in Flow Records that were
            generated by the Observation Point since Metering Process and but dropped
            by the previous report (if any).
         </paragraph>
       </description>
       <units>packets</units>
     </field>

     <field name="outPacketDeltaCount" dataType="unsigned64"
            dataTypeSemantics="deltaCounter"
            group="flowCounter"
            fieldId="24" applicability="data" status="current">
       <description>
         <paragraph>
         The number Metering Process or by the Exporting Process
            instead of outgoing packets observed sending it to the Collecting Process.
            There are several potential reasons for this including
            resource shortage and special flow at
         the Observation Point since the previous report (if any). export policies.
         </paragraph>
       </description>
       <units>packets</units>
     </field>

     <field name="packetDeltaCount" name="notSentOctetTotalCount" dataType="unsigned64"
            dataTypeSemantics="deltaCounter"
            group="flowCounter"
            fieldId="139"
            dataTypeSemantics="totalCounter"
            group="processCounter"
            fieldId="167" applicability="data" status="current">
       <description>
         <paragraph>
            The total number of all octets in  packets observed for this flow at in Flow Records
            that were generated by the Observation Point since Metering Process and but
            dropped by the previous report (if any). 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>packets</units>
       <units>octets</units>
     </field>

     <field name="inPacketTotalCount" name="flowKeyIndicator" dataType="unsigned64"
            dataTypeSemantics="totalCounter"
            group="flowCounter"
            fieldId="86"
            dataTypeSemantics="flags"
            group="processCounter"
            fieldId="172" applicability="all" status="current">
       <description>
         <paragraph>
         The running counter
         This set of bit fields is used for marking the number Information
         Elements of incoming packets observed for 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 flow at is not the case.  If the
         Data Record contains more than 64 Information Elements, the
         corresponding Template SHOULD be designed such that all Flow
         Keys are among the first 64 Information Elements, because the Observation Point since
         flowKeyIndicator only contains 64 bits.  If the Metering Process
         initialization Data Record
         contains less than 64 Information Elements, then the bits in
         the flowKeyIndicator for this Observation Point. which no corresponding Information



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


         Element exists SHOULD have the value 0.
         </paragraph>
       </description>
       <units>packets</units>
     </field>

     <field name="droppedOctetDeltaCount" dataType="unsigned64"
            dataTypeSemantics="deltaCounter"
            group="flowCounter"
            fieldId="132" applicability="data" name="lineCardId" dataType="unsigned32"
            group="scope"
            dataTypeSemantics="identifier"
            fieldId="141" applicability="option" status="current">
       <description>
         <paragraph>
         The number of octets in packets
           A locally unique identifier of a line card at an IPFIX
           Device hosting an Observation Point.  Typically, this flow dropped by packet treatment.
           Information Element is used for limiting the scope
           of other Information Elements.
         </paragraph>
       </description>
       <units>octets</units>
     </field>

     <field name="droppedOctetTotalCount" dataType="unsigned64"
            dataTypeSemantics="totalCounter"
            group="flowCounter"
            fieldId="133" applicability="data" name="portId" dataType="unsigned32"
            group="scope"
            dataTypeSemantics="identifier"
            fieldId="142" applicability="option" status="current">
       <description>
         <paragraph>
         The number of octets in packets
           A locally unique identifier of a line port at an IPFIX
           Device hosting an Observation Point.  Typically, this flow dropped by packet treatment.
           Information Element is used for limiting the scope
           of other Information Elements.
         </paragraph>
       </description>
       <units>octets</units>
     </field>

     <field name="droppedPacketDeltaCount" dataType="unsigned64"
            dataTypeSemantics="deltaCounter"
            group="flowCounter"
            fieldId="134" applicability="data" name="ingressInterface" dataType="unsigned32"
            group="scope"
            dataTypeSemantics="identifier"
            fieldId="10" applicability="all" status="current">
       <description>
         <paragraph>
           The number index of the IP interface (ifIndex) where packets of
           this flow dropped by packet treatment. Flow are being received.
         </paragraph>
       </description>
       <units>packets</units>
     </field>

     <field name="droppedPacketTotalCount" dataType="unsigned64"
            dataTypeSemantics="totalCounter"
            group="flowCounter"
            fieldId="135" applicability="data" status="current">
       <description>
         <paragraph>
         The number of packets
       <reference>
         See RFC 2863 for the definition of this flow dropped by packet treatment. the ifIndex object.
       </reference>
     </field>




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


         </paragraph>
       </description>
       <units>packets</units>
     </field>


     <field name="outMulticastPacketCount" dataType="unsigned64"
            group="flowCounter"
            fieldId="19" applicability="data" name="egressInterface" dataType="unsigned32"
            group="scope"
            dataTypeSemantics="identifier"
            fieldId="14" applicability="all" status="current">
       <description>
         <paragraph>
           The number of outgoing multicast packets created for packets
         of this flow by an adjacent multicast daemon.
         Note that typically not all index of the created IP interface (ifIndex) where packets can be
         observed at the Observation Point of
           this flow. Flow are being sent.
         </paragraph>
       </description>
       <units>packets</units>
       <reference>
         See RFC 2863 for the definition of the ifIndex object.
       </reference>
     </field>

     <field name="outMulticastOctetCount" dataType="unsigned64"
            group="flowCounter"
            fieldId="20" applicability="data" name="meteringProcessId" dataType="unsigned32"
            group="scope"
            dataTypeSemantics="identifier"
            fieldId="143" applicability="option" status="current">
       <description>
         <paragraph>
         The number of octets in outgoing multicast packets created
         for packets of this flow by an adjacent multicast daemon.
         Note that typically not all
           A locally unique identifier of the created packets can be
         observed a Metering Process
           at an IPFIX Device.  Typically, this
           Information Element is used for limiting the Observation Point scope
           of this flow. other Information Elements.
         </paragraph>
       </description>
       <units>octets</units>
     </field>

     <field name="observedFlowTotalCount" dataType="unsigned64"
            dataTypeSemantics="totalCounter"
            group="processCounter"
            fieldId="3" applicability="data" name="exportingProcessId" dataType="unsigned32"
            group="scope"
            dataTypeSemantics="identifier"
            fieldId="144" applicability="option" status="current">
       <description>
         <paragraph>
         The number
           A locally unique identifier of flows observed so far in an Exporting Process
           at an IPFIX Device.  Typically, this
           Information Element is used for limiting the Observation Domain. scope
           of other Information Elements.
         </paragraph>
       </description>
       <units>flows</units>
     </field>

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



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


            fieldId="40" applicability="data" status="current">
       <description>


         <paragraph>
         The number
           An identifier of all octets reported by the Exporting Process a Flow that is locally unique to this Collecting an
           Exporting Process.  Typically, this Information Element is
           used for limiting the scope of other Information Elements.
         </paragraph>
       </description>
       <units>octets</units>
     </field>

     <field name="exportedPacketTotalCount" dataType="unsigned64"
            dataTypeSemantics="totalCounter"
            group="processCounter"
            fieldId="41" applicability="data" name="templateId" dataType="unsigned32"
            group="scope"
            dataTypeSemantics="identifier"
            fieldId="145" applicability="option" status="current">
       <description>
         <paragraph>
         The number
           An identifier of all packets reported by the Exporting Process a Template that is locally unique to this Collecting an
           Exporting Process.  Typically, this Information Element is
           used for limiting the scope of other Information Elements.
         </paragraph>
       </description>
       <units>packets</units>
     </field>

     <field name="exportedFlowTotalCount" dataType="unsigned64"
            group="processCounter"
            fieldId="42" applicability="data" name="sourceId" dataType="unsigned32"
            group="scope"
            dataTypeSemantics="identifier"
            fieldId="149" applicability="option" status="current">
       <description>
         <paragraph>
         The number
           An identifier of all flows records reported by the Exporting
         Process an Observation Domain that is locally
           unique to this Collecting an Exporting Process.  Typically, this Information
           Element is used for limiting the scope of other Information
           Elements.
         </paragraph>
       </description>
       <units>flows</units>
     </field>

   </fieldDefinitions>















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


Appendix B.  Formal Specification of Abstract Data Types

   This appendix containfs a formal description of the abstract data
   types to be used for IPFIX fields Information Elements and a formal
   description of the template used for defining IPFIX fields. 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
                4294967295.
             </documentation>
           </annotation>
         </enumeration>

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



Quittek, et al.        Expires August 21, November 28, 2005               [Page 74] 97]

Internet-Draft          IPFIX Information Model            February                 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. 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">
           <annotation>
             <documentation>
               The type "string" represents a finite length string
               of valid characters from the Unicode character encoding set.
               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 USASCII ASCII characters, but also accomodates accommodates other Unicode
               multibyte



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



Quittek, et al.         Expires August 21, 2005                [Page 75]

Internet-Draft          IPFIX Information Model            February 2005
               GMT timezone.  Such types are in common use on many
               operating systems time zone.
             </documentation>
           </annotation>
         </enumeration>

         <enumeration value="dateTimeMilliSeconds">
           <annotation>
             <documentation>The type "dateTimeMilliSeconds" represents
               a time value having a precision of milliseconds and have
               normalized to the advantage that they
               can be stored in 32-bit integers. GMT time zone.
             </documentation>
           </annotation>
         </enumeration>

         <enumeration value="dateTimeMicroSeconds">
           <annotation>
             <documentation>The type "dateTimeSeconds" "dateTimeMicroSeconds" represents
               a time value having a precision of microseconds and
               normalized to the GMT timezone. 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>
           </annotation>
         </enumeration>

         <enumeration value="ipv4Address">
           <annotation>
             <documentation>The type "ipv4Addr" "ipv4Address" represents a value
               of an IPv4 address. These addresses are typically stored
               as 32-bit integers.
             </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 "ipv6Addr" "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 fields
               data type should behave as a quantity.
             </documentation>
           </annotation>



Quittek, et al.         Expires August 21, 2005                [Page 76]

Internet-Draft          IPFIX Information Model            February 2005
         </enumeration>

         <enumeration value="totalCounter">
           <annotation>
             <documentation>
               A measurement which is ongoing from
               An integral value reporting the perspective value of the Exporter. 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 independent independently of the export of its value.
             </documentation>
           </annotation>
         </enumeration>

         <enumeration value="deltaCounter">
           <annotation>
             <documentation>
               A measurement which is ongoing from
               An integral value reporting the perspective value of the Exporter. 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 ID 1 *
               Autonomous System Id ID 2 is meaningless.
             </documentation>
           </annotation>
         </enumeration>




Quittek, et al.         Expires August 21, 2005                [Page 77]

Internet-Draft          IPFIX Information Model            February 2005

         <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">
         <enumeration value="data">
           <annotation>
             <documentation>
               Used for fields Information Elements that are applicable to
               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 fields Information Elements that are applicable to
               option records only.
             </documentation>
           </annotation>
         </enumeration>

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

     <simpleType name="status">
       <restriction base="string">
         <enumeration value="current">
           <annotation>



Quittek, et al.         Expires August 21, 2005                [Page 78]

Internet-Draft          IPFIX Information Model            February 2005
             <documentation>
               Indicates that the field Information Element definition
               is that the definition is current and valid.
             </documentation>
           </annotation>
         </enumeration>

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

         <enumeration value="obsolete">
           <annotation>
             <documentation>
               Indicates that the field 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>



Quittek, et al.         Expires August 21, 2005                [Page 79]

Internet-Draft          IPFIX Information Model            February 2005
             <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>
           </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. Information Element.
                       Describes how this field Information Element is
                       derived from the 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 field Information Element is a measure of some
                       kind, the units identify what the measure is.



Quittek, et al.         Expires August 21, 2005                [Page 80]

Internet-Draft          IPFIX Information Model            February 2005
                     </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>
                   </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 element 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 elements 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.
                     The preferred spelling for the name is to use mixed
                     case if the name is compound, with an initial



Quittek, et al.         Expires August 21, 2005                [Page 81]

Internet-Draft          IPFIX Information Model            February 2005


                     lower case letter, e.g., "sourceIpAddress".
                     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 an 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
                     IPAddress) 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 an a future extension of the
                     information model.
                   </documentation>
                 </annotation>
               </attribute>

               <attribute name="fieldId" 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.
                     This
                     It is used for compact identification of an
                     information item
                     Information Element when encoding templates in the
                     protocol.
                   </documentation>
                 </annotation>
               </attribute>

               <attribute name="enterpriseId" type="nonNegativeInteger"
                          use="optional">
                 <annotation>



Quittek, et al.         Expires August 21, 2005                [Page 82]

Internet-Draft          IPFIX Information Model            February 2005
                   <documentation>
                     When extension
                     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 done not sufficient when the Information Element
                     is used outside of the scope enterprise.  If specifications
                     of enterprise-specific Information Elements are made
                     public and/or if enterprise-specific identifiers are
                     used by the IANA IPFIX fieldId range, a enterpriseId protocol outside the enterprise,
                     then the enterprise-specific identifier MUST be provided. 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 code. 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 Information
                   Element indicates in which kind of records the element
                   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 status of the specification of this
                     information element.
                     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>

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

         <field xpath="fieldId"/> xpath="infoElementId"/>
       </unique>



Quittek, et al.         Expires August 21, 2005                [Page 83]

Internet-Draft          IPFIX Information Model            February 2005
     </element>
   </schema>








Quittek, et al.        Expires August 21, November 28, 2005              [Page 84] 107]

Internet-Draft          IPFIX Information Model            February                 May 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 August 21, November 28, 2005              [Page 85] 108]

----