view Side-By-Side changes

Network Working Group                                           J. Meyer
Internet-Draft                                                    PayPal
Expires: January 17, April 25, 2005                                       J. Quittek
                                                                     NEC
                                                               S. Bryant
                                                       Cisco Systems Ltd
                                                           July 19,
                                                        October 25, 2004


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

Status of this Memo

   This document is an Internet-Draft and is in full conformance with subject to all provisions
   of Section 10 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 RFC2026.
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   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.
   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 January 17, April 25, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract

   This memo defines and 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



Meyer, et al.            Expires April 25, 2005                 [Page 1]

Internet-Draft          IPFIX Information Model             October 2004


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





Meyer, et al.           Expires January 17, 2005                [Page 1]

Internet-Draft          IPFIX Information Model                July 2004

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   5
   2.   Properties of IPFIX Protocol Fields Information Elements  . . . . .   6
   3.   Type Space . . . . . . .   6
   3.   Type Space . . . . . . . . . . . . . . . . . .   8
     3.1  Data Types . . . . . . .   8
   3.1  octet . . . . . . . . . . . . . . . . .   8
       3.1.1  octet  . . . . . . . . . .   8
   3.2  unsigned16 . . . . . . . . . . . . . .   8
       3.1.2  unsigned16 . . . . . . . . . . .   8
   3.3  unsigned32 . . . . . . . . . . .   8
       3.1.3  unsigned32 . . . . . . . . . . . . . .   8
   3.4  unsigned64 . . . . . . . .   8
       3.1.4  unsigned64 . . . . . . . . . . . . . . . . .   8
   3.5  float32 . . . . .   8
       3.1.5  float32  . . . . . . . . . . . . . . . . . . . . . . .   8
   3.6
       3.1.6  boolean  . . . . . . . . . . . . . . . . . . . . . . .   8
       3.1.7  octetArray . . .   8
   3.7  octetArray . . . . . . . . . . . . . . . . . . .   8
       3.1.8  string . . . . . .   8
   3.8  string . . . . . . . . . . . . . . . . . .   9
       3.1.9  dateTimeSeconds  . . . . . . . . .   8
   3.9  dateTimeSeconds . . . . . . . . . .   9
       3.1.10   dateTimeMicroSeconds . . . . . . . . . . . . . . . .   9
   3.10 dataTimeMicroSeconds
       3.1.11   ipv4Address  . . . . . . . . . . . . . . . . . . . .   9
   3.11 ipv4Address
       3.1.12   ipv6Address  . . . . . . . . . . . . . . . . . . . .   9
     3.2  Data Type Semantics  . . . .   9
   3.12 ipv6Address . . . . . . . . . . . . . . .   9
       3.2.1  quantity . . . . . . . . . .   9
   4.   Flow Attributes . . . . . . . . . . . . .   9
       3.2.2  runningCounter . . . . . . . . .  10
   4.1  deltaOctetCount . . . . . . . . . . .   9
       3.2.3  deltaCounter . . . . . . . . . . . .  10
   4.2  deltaPacketCount . . . . . . . . .  10
       3.2.4  identifier . . . . . . . . . . . . .  10
   4.3  totalFlowCount . . . . . . . . .  10
       3.2.5  flags  . . . . . . . . . . . . . .  10
   4.4  protocolIdentifier . . . . . . . . . .  10
   4.   Information Element Identifiers  . . . . . . . . . . . . . .  11
   4.5  classOfServiceV4
   5.   Information Elements . . . . . . . . . . . . . . . . . . . .  13
     5.1  Header Fields  . .  11
   4.6  tcpControlBits . . . . . . . . . . . . . . . . . . . .  13
       5.1.1  ipVersion  . . .  11
   4.7  transportSourcePort . . . . . . . . . . . . . . . . . . .  14
       5.1.2  sourceIPv4Address  .  12
   4.8  sourceAddressV4 . . . . . . . . . . . . . . . . .  15
       5.1.3  sourceIPv6Address  . . . . .  13
   4.9  sourceMaskV4 . . . . . . . . . . . . .  15
       5.1.4  sourceIPv4Mask . . . . . . . . . . .  13
   4.10 ingressInterface . . . . . . . . .  15
       5.1.5  sourceIPv6Mask . . . . . . . . . . . . .  13
   4.11 transportDestinationPort . . . . . . .  15
       5.1.6  sourceIPv4Prefix . . . . . . . . . . .  14
   4.12 destinationAddressV4 . . . . . . . .  16
       5.1.7  destinationIPv4Address . . . . . . . . . . . .  14
   4.13 destinationMaskV4 . . . .  16
       5.1.8  destinationIPv6Address . . . . . . . . . . . . . . . .  16
       5.1.9  destinationIPv4Mask  .  15
   4.14 egressInterface . . . . . . . . . . . . . . . .  16
       5.1.10   destinationIPv6Mask  . . . . . .  15
   4.15 ipNextHopAddressV4 . . . . . . . . . .  16
       5.1.11   destinationIPv4Prefix  . . . . . . . . . . .  15
   4.16 sourceAsNumber . . . .  17
       5.1.12   classOfServiceIPv4 . . . . . . . . . . . . . . . . .  17
       5.1.13   classOfServiceV6 . .  15
   4.17 destinationAsNumber . . . . . . . . . . . . . . . .  17
       5.1.14   flowLabelV6  . . . .  16
   4.18 bgpNextHopAddressV4 . . . . . . . . . . . . . . . .  17
       5.1.15   identificationV4 . . . .  16
   4.19 OutMulticastPacketCount . . . . . . . . . . . . . .  18
       5.1.16   protocolIdentifier . . . .  16
   4.20 OutMulticastOctetCount . . . . . . . . . . . . .  18
       5.1.17   sourceTransportPort  . . . . . .  17
   4.21 flowEndTime . . . . . . . . . .  18



Meyer, et al.            Expires April 25, 2005                 [Page 2]

Internet-Draft          IPFIX Information Model             October 2004


       5.1.18   destinationtransportPort . . . . . . . . . . . . . .  17
   4.22 flowCreationTime  19
       5.1.19   icmpTypeCode . . . . . . . . . . . . . . . . . . . .  19
       5.1.20   igmpType . .  17
   4.23 deltaOutOctetCount . . . . . . . . . . . . . . . . . . . .  19
       5.1.21   sourceMacAddress .  17
   4.24 deltaOutPacketCount . . . . . . . . . . . . . . . . .  20
       5.1.22   mplsLabelStackEntry1 . . .  18
   4.25 minPacketLength . . . . . . . . . . . . .  20
       5.1.23   mplsLabelStackEntry2 . . . . . . . . .  18
   4.26 maxPacketLength . . . . . . .  20
       5.1.24   mplsLabelStackEntry3 . . . . . . . . . . . . . . .  18
   4.27 sourceAddressV6 .  20
       5.1.25   mplsLabelStackEntry4 . . . . . . . . . . . . . . . .  21
       5.1.26   mplsLabelStackEntry5 . . . . .  18
   4.28 destinationAddressV6 . . . . . . . . . . .  21
       5.1.27   mplsLabelStackEntry6 . . . . . . . . .  19
   4.29 sourceMaskV6 . . . . . . .  21
       5.1.28   mplsLabelStackEntry7 . . . . . . . . . . . . . . . .  21
       5.1.29   mplsLabelStackEntry8 .  19
   4.30 destinationMaskV6 . . . . . . . . . . . . . . .  22
       5.1.30   mplsLabelStackEntry9 . . . . . .  19



Meyer, et al.           Expires January 17, 2005                [Page 2]

Internet-Draft          IPFIX Information Model                July 2004


   4.31 flowLabelV6 . . . . . . . . . .  22
       5.1.31   mplsLabelStackEntry10  . . . . . . . . . . . . . .  19
   4.32 icmpTypeCode .  22
       5.1.32   ipNextHopIPv4Address . . . . . . . . . . . . . . . .  22
       5.1.33   ipNextHopIPv6Address . . . . . . .  20
   4.33 igmpType . . . . . . . . .  23
       5.1.34   ingressInterface . . . . . . . . . . . . . . . . .  20
   4.34 flowActiveTimeOut .  23
       5.1.35   egressInterface  . . . . . . . . . . . . . . . . . .  23
       5.1.36   ipNextHopAsNumber  . .  20
   4.35 flowInactiveTimeout . . . . . . . . . . . . . . .  23
       5.1.37   bgpSourceAsNumber  . . . . .  21
   4.36 exportedOctetCount . . . . . . . . . . . .  24
       5.1.38   bgpDestinationAsNumber . . . . . . . . .  21
   4.37 exportedPacketCount . . . . . .  24
       5.1.39   bgpNextHopAsNumber . . . . . . . . . . . . . .  21
   4.38 exportedFlowCount . . .  24
       5.1.40   bgpNextHopIPv4Address  . . . . . . . . . . . . . . .  24
       5.1.41   bgpNextHopIPv6Address  . . .  21
   4.39 sourcePrefixV4 . . . . . . . . . . . .  25
       5.1.42   mplsTopLabelType . . . . . . . . . . .  22
   4.40 destinationPrefixV4 . . . . . . .  25
       5.1.43   mplsTopLabelIPv4Address  . . . . . . . . . . . . .  22
   4.41 mplsTopLabelType .  25
       5.1.44   mplsTopLabelIPv6Address  . . . . . . . . . . . . . .  25
     5.2  Properties of Metering/Exporting Process . . . . . . .  22
   4.42 mplsTopLabelIPAddressV4 . .  26
       5.2.1  exporterIPv4Address  . . . . . . . . . . . . . . . .  23
   4.43 minimumTTL .  26
       5.2.2  exporterIPv4Address  . . . . . . . . . . . . . . . . .  26
     5.3  Min/Max Flow Properties  . . . . . . .  23
   4.44 maximumTTL . . . . . . . . . .  26
       5.3.1  minPacketLength  . . . . . . . . . . . . . . .  23
   4.45 identificationV4 . . . .  27
       5.3.2  maxPacketLength  . . . . . . . . . . . . . . . . . .  23
   4.46 sourceMacAddress .  27
       5.3.3  minimumTTL . . . . . . . . . . . . . . . . . . . . .  24
   4.47 ipVersion .  27
       5.3.4  maximumTTL . . . . . . . . . . . . . . . . . . . . . .  27
       5.3.5  ipv6OptionHeaders  . .  24
   4.48 ipNextHopAddressV6 . . . . . . . . . . . . . . . .  28
       5.3.6  tcpControlBits . . . . .  24
   4.49 bgpNextHopAddressV6 . . . . . . . . . . . . . . .  28
       5.3.7  flowCreationTime . . . . .  25
   4.50 ipv6OptionHeaders . . . . . . . . . . . . . .  29
       5.3.8  flowEndTime  . . . . . . .  25
   4.51 partialMPLSLabelStackEntry1 . . . . . . . . . . . . . .  29
       5.3.9  flowActiveTimeOut  . .  26
   4.52 partialMPLSLabelStackEntry2 . . . . . . . . . . . . . . . .  26
   4.53 partialMPLSLabelStackEntry3  29
       5.3.10   flowInactiveTimeout  . . . . . . . . . . . . . . . .  27
   4.54 partialMPLSLabelStackEntry4  29
       5.3.11   flowEndReason  . . . . . . . . . . . . . . . .  27
   4.55 partialMPLSLabelStackEntry5 . . .  29
     5.4  Counters . . . . . . . . . . . . .  27
   4.56 partialMPLSLabelStackEntry6 . . . . . . . . . . . .  30
       5.4.1  inOctetDeltaCount  . . . .  28
   4.57 partialMPLSLabelStackEntry7 . . . . . . . . . . . . . .  31
       5.4.2  outOctetDeltaCount . .  28
   4.58 partialMPLSLabelStackEntry8 . . . . . . . . . . . . . . . .  28
   4.59 partialMPLSLabelStackEntry9  31
       5.4.3  octetDeltaCount  . . . . . . . . . . . . . . . .  29
   4.60 partialMPLSLabelStackEntry10 . . .  31
       5.4.4  octetTotalCount  . . . . . . . . . . . . .  29
   4.61 runningOctetCounter . . . . . .  31
       5.4.5  inPacketDeltaCount . . . . . . . . . . . . . .  29
   4.62 runningPacketCounter . . . .  32



Meyer, et al.            Expires April 25, 2005                 [Page 3]

Internet-Draft          IPFIX Information Model             October 2004


       5.4.6  outPacketDeltaCount  . . . . . . . . . . . . . . . . .  32
       5.4.7  packetDeltaCount .  30
   4.63 bgpNextHopAsNumber . . . . . . . . . . . . . . . . . .  32
       5.4.8  packetTotalCount . . .  30
   4.64 ipNextHopAsNumber . . . . . . . . . . . . . . . .  33
       5.4.9  droppedOctetDeltaCount . . . . .  30
   4.65 exporterAddressV4 . . . . . . . . . . .  33
       5.4.10   droppedOctetTotalCount . . . . . . . . . .  31
   4.66 exporterAddressV6 . . . . .  33
       5.4.11   droppedPacketDeltaCount  . . . . . . . . . . . . . .  33
       5.4.12   droppedPacketTotalCount  . .  31
   4.67 droppedOctetDeltaCount . . . . . . . . . . . .  34
       5.4.13   outMulticastPacketCount  . . . . . . .  31
   4.68 droppedPacketDeltaCount . . . . . . .  34
       5.4.14   outMulticastOctetCount . . . . . . . . . . .  32
   4.69 droppedOctetTotalCount . . . .  34
       5.4.15   observedFlowTotalCount . . . . . . . . . . . . . . .  32
   4.70 droppedPacketTotalCount  34
       5.4.16   exportedOctetTotalCount  . . . . . . . . . . . . . .  35
       5.4.17   exportedPacketTotalCount . . . .  32
   4.71 flowEndReason . . . . . . . . . .  35
       5.4.18   exportedFlowTotalCount . . . . . . . . . . . . .  32
   4.72 classOfServiceV6 . .  35
   6.   Extending the Information Model  . . . . . . . . . . . . . .  36
   7.   IANA Considerations  . . . . . .  33
   5.   Extending the Information Model . . . . . . . . . . . . . .  34
   6.   IANA  37
   8.   Security Considerations  . . . . . . . . . . . . . . . . . .  38
   9.   Acknowledgements . . .  35
   7.   Security Considerations . . . . . . . . . . . . . . . . . .  36
   8.   Acknowledgements .  39
   10.  Open Issues  . . . . . . . . . . . . . . . . . . . . .  37 . . .  40
   11.  References . . . . . . . . . . . . . . . . . . . . . . . . .  41
   11.1   Normative Reference  . . . . . . . . . . . . . . . . . . . .  38  41
   11.2   Informative Reference  . . . . . . . . . . . . . . . . . . .  39



Meyer, et al.           Expires January 17, 2005                [Page 3]

Internet-Draft          IPFIX Information Model                July 2004  41
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  40  42
   A.   Formal Specification of IPFIX Fields . . . . . . . . . . . .  41  44
   B.   Formal Specification of Abstract Data Types  . . . . . . . .  63  66
        Intellectual Property and Copyright Statements . . . . . . .  73  76


























Meyer, et al.            Expires January 17, April 25, 2005                 [Page 4]

Internet-Draft          IPFIX Information Model                July             October 2004


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 information elements, it
   specifies the encoding of a set of basic data types.  However, the
   list of fields 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, smapling rate, flow timeout interval, etc.), is
   not specified in [IPFIX-PROTO].

   This document complements the IPFIX protocol specification by
   providing the IPFIX information model.  The main part of this
   document is Section 5 defines defining the (extensible) list of fields to be
   transmitted by the IPFIX protcol.  Section 2 defines a template for
   specifying IPFIX fields that is used in Section 4.  Section 3 defines
   the set of abstract data types that are available for IPFIX fields.
   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 fields can be used for automatically checking
   syntactical correctness of the specification of IPFIX fields.
   Further it  It can
   further be used for generating IPFIX protocol implementation code
   that deals with processing IPFIX fields.  Also code for applications
   that further process traffic information transmitted via the IPFIX
   protocol can be generated with the XML specification of IPFIX fields.

   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.














Meyer, et al.            Expires January 17, April 25, 2005                 [Page 5]

Internet-Draft          IPFIX Information Model                July             October 2004


2.  Properties of IPFIX Protocol Information Elements

   Fields

   Fields in messages of the IPFIX protocol carrying information about
   traffic measurement are modeled as elements of the IPFIX information
   model and specified in Section 4.  For defining the fields, these information
   elements, a template is used that is specified below.

   All fields information elements specified for the IPFIX protocol either in
   this document or by an any future extension MUST have the following
   properties defined:
   name - A unique and meaningful name for the field. information element.  The
      preferred spelling for the name is to use mixed case if the name
      is compound, with an initial lower case letter. (E.g.
      "sourceIpAddress").

   fieldType letter, e.g.,
      "sourceIpAddress".
   fieldId - A numeric identifier administered by IANA.  This is used
      for compact identification of an information item when encoding
      templates in the protocol.
   description - The semantics of this information element.  Describes
      how this field 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 an extension of the "Type Space" section. 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) which are common to this domain and useful to
      distinguish.
   dataTypeSemantics - The integral types may be qualified by additional
      semantic details. Qualifying  Valid values for the fields as 'quantity', 'counter',
      'identifier' data type semantics are
      specified in section 3.2 of this document or 'flags'. in an extension of
      the information model.
   applicability - to be done ...
   status - to be done ...

   All fields information elements specified for the IPFIX protocol either in
   this document or by an any future extension MAY have the following
   properties defined:
   vendorId - When extension is done outside of the scope of the IANA
      IPFIX fieldId range, a vendorId MUST be provided. This identifier
      is based on  Valid values
      for the vendorID are defined by IANA assigned as SMI network management
      private enterprise identifiers. code.  They are defined at
      http://www.iana.org/assignments/enterprise-numbers.
   usage - to be done ...





Meyer, et al.           Expires January 17, 2005                [Page 6]

Internet-Draft          IPFIX Information Model                July 2004
   units - If the field is a measure of some kind, the units identify
      what the measure is.






Meyer, et al.            Expires April 25, 2005                 [Page 6]

Internet-Draft          IPFIX Information Model             October 2004


   enumeratedRange - Some items may have a specific set of numeric
      identifiers associated with a set of discrete values this element
      may take.  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 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.









































Meyer, et al.            Expires January 17, April 25, 2005                 [Page 7]

Internet-Draft          IPFIX Information Model                July             October 2004


3.  Type Space

   The following subsections describe

   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'.  Data type semantics are specified in section 3.2.

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

3.1.1  octet

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

3.2

3.1.2  unsigned16

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

3.3

3.1.3  unsigned32

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

3.4

3.1.4  unsigned64

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

3.5

3.1.5  float32

   The type "float32" corresponds to an IEEE single-precision 32-bit
   floating point type.

3.6

3.1.6  boolean

   The type "boolean" represents a binary value.

3.7

3.1.7  octetArray

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

3.8




Meyer, et al.            Expires April 25, 2005                 [Page 8]

Internet-Draft          IPFIX Information Model             October 2004


3.1.8  string

   The type "string" represents a finite length string 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 that strings will be encoded in UTF-8 format, which is
   identical in encoding for USASCII characters, but also accomodates
   other Unicode multibyte characters.





Meyer, et al.           Expires January 17, 2005                [Page 8]

Internet-Draft          IPFIX Information Model                July 2004


3.9

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 in
   common use on many operating systems and have the advantage that they
   can be stored in 32-bit integers.

3.10 dataTimeMicroSeconds

3.1.10  dateTimeMicroSeconds

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

3.11

3.1.11  ipv4Address

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

3.12

3.1.12  ipv6Address

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































Meyer, et al.           Expires January 17, 2005                [Page 9]

Internet-Draft          IPFIX Information Model                July 2004


4. Flow Attributes

4.1 deltaOctetCount

   Description:

      The number of octets in (incoming) packets observed for this flow
      at the observation point since


3.2  Data Type Semantics

   This section describes the previous report (if any). The
      number set of octets include IP header(s) and valid data type semantics of the
   IPFIX information model.  Note that further data types 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 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  runningCounter

   A measurement which is ongoing from the perspective of the exporter.



Meyer, et al.            Expires April 25, 2005                 [Page 9]

Internet-Draft          IPFIX Information Model             October 2004


   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 of the export of its
   value.

3.2.3  deltaCounter

   A measurement which is ongoing from the perspective of the exporter.
   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.




















Meyer, et al.            Expires April 25, 2005                [Page 10]

Internet-Draft          IPFIX Information Model             October 2004


4.  Information Element Identifiers

   The elements of this information model are identified by the
   combination of a field identifier and an optional vendor identifier.

   Standardized information elements defined in section 5 of this
   document or in extensions of the IPFIX information model have their
   values assigned by IANA.  These values are in the range of 1 - 32767.
   In this range, the value of the most significant bit in a
   16-bit-representation always equals 0.

   Vendor-specific field IDs are in the range of 32768 - 65535.  In this
   range, the value of the most significant bit in a
   16-bit-representation always equals 1.  This choice of ranges allows
   a collecting process to clearly and easily distinguished standardized
   fields from vendor-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                   | vendor-defined field IDs        |
   +---------------------------------+---------------------------------+

   Vendor-specific IDs can be chosen by a vendor arbitrarily within the
   given range.  The same ID may be assigned by different vendors for
   different purposes.  In order to ensure that collecting processes can
   always identify information elements uniquely, vendor-specific
   information elements are identified by the combination of a field ID
   and a vendor ID.  Valid valuse for vendor 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 the set of
   valid numbers for vendor IDs.  Vendor IDs used for identifying IPFIX
   information elements MUST be registered as SMI network management
   private enterprise code numbers at IANA.

   The following list gives an overview of field IDs used as identifiers
   of the information elements specified in section 5.

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



Meyer, et al.            Expires April 25, 2005                [Page 11]

Internet-Draft          IPFIX Information Model             October 2004


   |    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 | destinationIPv4Address  |    60 | ipVersion               |
   |    13 | destinationIPv4Mask     |    61 | RESERVED                |
   |    14 | egressInterface         |    62 | ipNextHopIPv6Address    |
   |    15 | ipNextHopIPv4Address    |    63 | bgpNextHopIPv6Address   |
   |    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 | octetTotalCount         |
   |    30 | destinationIPv6Mask     |    86 | packetTotalCount        |
   |    31 | flowLabelIPv6           |87-127 | RESERVED                |
   |    32 | icmpTypeCode            |   128 | bgpNextHopAsNumber      |
   |    33 | igmpType                |   129 | ipNextHopAsNumber       |
   | 34-35 | RESERVED                |   130 | exporterIPv4Address     |
   |    36 | flowActiveTimeOut       |   131 | exporterIPv6Address     |
   |    37 | flowInactiveTimeout     |   132 | droppedOctetDeltaCount  |
   | 38-39 | RESERVED                |   133 | droppedPacketDeltaCount |
   |    40 | exportedOctetCount      |   134 | droppedOctetTotalCount  |
   |    41 | exportedPacketCount     |   135 | droppedPacketTotalCount |
   |    42 | exportedFlowCount       |   136 | flowEndReason           |
   |    43 | RESERVED                |   137 | classOfServiceIPv6      |
   |       |                         |   138 | octetDeltaCount         |
   |       |                         |   139 | packetDeltaCount        |
   |       |                         |   140 | mplsTopLabelIPv6Address |
   +-------+-------------------------+-------+-------------------------+




Meyer, et al.            Expires April 25, 2005                [Page 12]

Internet-Draft          IPFIX Information Model             October 2004


5.  Information Elements

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

5.1  Header Fields

   Information elements in this section indicate values of header fields
   or are derived from IP header field values in combination with
   further information.  These information elements can serve as part of
   a flow key used for mapping packets to flows.  But also they may
   contain values related to header 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 that are not constant for a flow, the value
   MUST be the value of the first packet observed 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 the same flow, just counters need to be
   increased.

   The set of information elements related to IP header fields includes
   the information elements listed in the table below.

   +-------+-------------------------+-------+-------------------------+
   |    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 | sourceIPv4Prefix        |       |                         |
   |    12 | destinationIPv4Address  |       |                         |
   |    28 | destinationIPv6Address  |       |                         |
   |    13 | destinationIPv4Mask     |       |                         |
   |    30 | destinationIPv6Mask     |       |                         |
   |    45 | destinationIPv4Prefix   |       |                         |
   +-------+-------------------------+-------+-------------------------+

   The set of information elements related to transport header fields
   includes the information elements listed in the table below.





Meyer, et al.            Expires April 25, 2005                [Page 13]

Internet-Draft          IPFIX Information Model             October 2004


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

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

   +-------+-------------------------+-------+-------------------------+
   |    ID | Field Name              |    ID | Field Name              |
   +-------+-------------------------+-------+-------------------------+
   |    56 | sourceMacAddress        |    75 | mplsLabelStackEntry6    |
   |    70 | mplsLabelStackEntry1    |    76 | mplsLabelStackEntry7    |
   |    71 | mplsLabelStackEntry2    |    77 | mplsLabelStackEntry8    |
   |    72 | mplsLabelStackEntry3    |    78 | mplsLabelStackEntry9    |
   |    73 | mplsLabelStackEntry4    |    79 | mplsLabelStackEntry10   |
   |    74 | mplsLabelStackEntry5    |       |                         |
   +-------+-------------------------+-------+-------------------------+

   The set of information elements derived from values of header fields
   and further information includes the information elements listed in
   the table below.

   +-------+-------------------------+-------+-------------------------+
   |    ID | Field Name              |    ID | Field Name              |
   +-------+-------------------------+-------+-------------------------+
   |    15 | ipNextHopIPv4Address    |   128 | bgpNextHopAsNumber      |
   |    62 | ipNextHopIPv6Address    |    18 | bgpNextHopIPv4Address   |
   |    14 | egressInterface         |    63 | bgpNextHopIPv6Address   |
   |   129 | ipNextHopAsNumber       |    46 | mplsTopLabelType        |
   |    16 | bgpSourceAsNumber       |    47 | mplsTopLabelIPv4Address |
   |    17 | bgpDestinationAsNumber  |   140 | mplsTopLabelIPv6Address |
   +-------+-------------------------+-------+-------------------------+


5.1.1  ipVersion
   Description: The IP payload. version field given in the IP header.

   Abstract Data Type: octet

   FieldId: 60

   Units: flows






Meyer, et al.            Expires April 25, 2005                [Page 14]

Internet-Draft          IPFIX Information Model             October 2004


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

5.1.2  sourceIPv4Address
   Description:
      IPv4 source address taken from the IP packet header of a packet of
      this flow.

   Abstract Data Type: unsigned64 ipv4Address

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

5.1.3  sourceIPv6Address
   Description:
      IPv6 source address taken from the IP packet header of a packet of
      this flow.

   Abstract Data Type Semantics: deltaCounter

   Field Id: 1

   Units: octets

4.2 deltaPacketCount Type: ipv6Address

   FieldId: 27

5.1.4  sourceIPv4Mask
   Description:
      The number of (incoming) packets observed for this flow at the
      observation point since contiguous bits that are relevant in the previous report (if any).
      sourceAddressV4 field.

   Abstract Data Type: unsigned64

   Data Type Semantics: deltaCounter

   Field Id: 2 octet

   FieldId: 9

   Units: packets

4.3 totalFlowCount bits

5.1.5  sourceIPv6Mask
   Description:
      The number of flows observed so far contiguous bits that are relevant in the observation domain.
      sourceAddressV6 field.

   Abstract Data Type: unsigned64

   Data Type Semantics: runningCounter

   Field Id: 3 octet

   FieldId: 29

   Units: flows bits



Meyer, et al.            Expires January 17, April 25, 2005                [Page 10] 15]

Internet-Draft          IPFIX Information Model                July             October 2004


4.4 protocolIdentifier


5.1.6  sourceIPv4Prefix
   Description:

      The protocol number observed for packets
      IPv4 source address prefix.
      EDITOR'S NOTE: to be discussed on ipfix mailing list

   Abstract Data Type: ipV4Address

   FieldId: 44

   Units: flows

5.1.7  destinationIPv4Address
   Description:
      IPv4 destination address taken from the IP packet header of a
      packet of this flow. The
      protocol number identifies

   Abstract Data Type: ipv4Address

   FieldId: 12
   Reference: See RFC 791 for the definition of the IPv4 destination
      address field.

5.1.8  destinationIPv6Address
   Description:
      IPv6 destination address taken from the IP packet payload. Protocol numbers
      are defined in the IANA Protocol Numbers registry.

      In Internet Protocol version 4 (IPv4) header of a
      packet of this is carried flow.

   Abstract Data Type: ipv6Address

   FieldId: 28

5.1.9  destinationIPv4Mask
   Description:
      The number of contiguous bits that are relevant in the
      "Protocol"
      destinationAddressV4 field. In Internet Protocol version 6 (IPv6) this is
      carried in the "Next Header" field in the last extension header

   Abstract Data Type: octet

   FieldId: 13

   Units: bits

5.1.10  destinationIPv6Mask
   Description:
      The number of contiguous bits that are relevant in the packet.
      destinationAddressV6 field.

   Abstract Data Type: octet

   Data Type Semantics: identifier

   Field Id: 4

   Reference:

      See RFC 791 for the specification of the



Meyer, et al.            Expires April 25, 2005                [Page 16]

Internet-Draft          IPFIX Information Model             October 2004


   FieldId: 30

   Units: bits

5.1.11  destinationIPv4Prefix
   Description:
      IPv4 protocol field. See
      RFC 2460 for the specification of the IPv6 protocol field. See destination address prefix.
      EDITOR'S NOTE: to be discussed on ipfix mailing list of protocol numbers assigned by IANA at http://www.iana.org/
      assignments/protocol-numbers.


4.5 classOfServiceV4

   Abstract Data Type: ipV4Address

   FieldId: 45

   Units: flows

5.1.12  classOfServiceIPv4
   Description:
      The value of the IPv4 TOS field observed for packets of this flow.

   Abstract Data Type: octet

   Data Type Semantics: identifier

   Field Id:

   FieldId: 5
   Reference: See RFC 791 for the definition of the IPv4 TOS field.


4.6 tcpControlBits

5.1.13  classOfServiceV6
   Description:






Meyer, et al.           Expires January 17, 2005               [Page 11]

Internet-Draft          IPFIX Information Model                July 2004


      TCP control bits observed for packets of this flow.
      The value of
      this field is the result of a logical OR operation over the flags IPv6 traffic class field observed in all packets of the flow. This implies that a 0 value for a bit indicates that the respective bit was not set in any of
      the observed packets of
      this flow.

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

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

   Abstract Data Type: octet

   Data Type Semantics: flags

   Field Id: 6

   FieldId: 137
   Reference: See RFC 793 2460 for a the definition of the TCP control bits in
      the TCP header.


4.7 transportSourcePort

   Description:

      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 that have 16 bit source port identifiers. IPv6 traffic class
      field.

5.1.14  flowLabelV6
   Description:
      The Flow Label of the IPv6 packet header observed in a packet of
      this flow.

   Abstract Data Type: unsigned16

   Data Type Semantics: identifier

   Field Id: 7 unsigned32

   FieldId: 31






Meyer, et al.            Expires January 17, April 25, 2005                [Page 12] 17]

Internet-Draft          IPFIX Information Model                July             October 2004


   Reference: See RFC 768 for the definition of the UDP source port field. See
      RFC 793 2460 for the a definition of the TCP source port field. See RFC
      2960 for flow label field 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.


4.8 sourceAddressV4 IPv6 packet header.

5.1.15  identificationV4
   Description:

      IPv4 source address taken
      Packet identification field from the first IP packet header of a packet of this flow.

   Abstract Data Type: ipv4Address

   Field Id: 8 octet

   Data Type Semantics: identifier

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


4.9 sourceMaskV4

5.1.16  protocolIdentifier
   Description:
      The protocol number observed for packets of contiguous bits that this flow.  The
      protocol number identifies the IP packet payload.  Protocol
      numbers are relevant defined in the
      sourceAddressV4 IANA Protocol Numbers registry.
      In Internet Protocol version 4 (IPv4) this is carried in the
      "Protocol" field.  In Internet Protocol version 6 (IPv6) this is
      carried in the "Next Header" field in the last extension header of
      the packet.

   Abstract Data Type: octet

   Field Id: 9

   Units: bits

4.10 ingressInterface

   Description:

      The index

   Data Type Semantics: identifier

   FieldId: 4
   Reference:
      See RFC 791 for the specification of the IP interface (ifIndex) where packets IPv4 protocol field.  See
      RFC 2460 for the specification of the IPv6 protocol field.  See
      list of protocol numbers assigned by IANA at
      http://www.iana.org/assignments/protocol-numbers.

5.1.17  sourceTransportPort
   Description:
      A source port identifier in the transport header.  For transport
      protocols UDP, TCP and SCTP this flow
      are being received. is the source port number given
      in the respective header.  This field MAY also be used for future
      transport protocols that have 16 bit source port identifiers.

   Abstract Data Type: unsigned32 unsigned16

   Data Type Semantics: identifier

   FieldId: 7



Meyer, et al.            Expires January 17, April 25, 2005                [Page 13] 18]

Internet-Draft          IPFIX Information Model                July             October 2004


   Field Id: 10


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


4.11 transportDestinationPort 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.1.18  destinationtransportPort
   Description:
      A destination port identifier in the transport header.  For
      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

   Field Id:

   FieldId: 11
   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.


4.12 destinationAddressV4

5.1.19  icmpTypeCode
   Description:

      IPv4 destination address taken from the IP packet header
      Type and Code of a
      packet the ICMP message.  The combination of this flow. both values
      is reported as (ICMP type * 256) + ICMP code.

   Abstract Data Type: ipv4Address

   Field Id: 12 unsigned16

   FieldId: 32
   Reference: See RFC 791 792 for the a definition of the IPv4 destination
      address field.







Meyer, et al.           Expires January 17, 2005               [Page 14]

Internet-Draft          IPFIX Information Model                July 2004


4.13 destinationMaskV4 ICMP type and code
      fields.

5.1.20  igmpType
   Description: The number type field of contiguous bits that are relevant in the
      destinationAddressV4 field. IGMP message.

   Abstract Data Type: octet

   Field Id: 13

   Units: bits

4.14 egressInterface

   Description:

      The index of the IP interface (ifIndex) where packets of this flow
      are being sent.

   Abstract Data Type: unsigned32

   Data Type Semantics: identifier

   Field Id: 14

   FieldId: 33
   Reference: See RFC 2863 2236 for the a definition of the ifIndex object.


4.15 ipNextHopAddressV4

   Description:

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

   Abstract Data Type: ipv4Address

   Field Id: 15

4.16 sourceAsNumber

   Description:

      The autonomous system (AS) number of the source address in the IP
      packet header in a packet of this flow.

   Abstract Data Type: unsigned16 IGMP type field.






Meyer, et al.            Expires January 17, April 25, 2005                [Page 15] 19]

Internet-Draft          IPFIX Information Model                July             October 2004


   Data Type Semantics: identifier

   Field Id: 16

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


4.17 destinationAsNumber


5.1.21  sourceMacAddress
   Description:

      The autonomous system (AS) number of the destination address in
      Packet identification field from the first IP packet header in a packet of this flow.

   Abstract Data Type: unsigned16

   Data Type Semantics: identifier

   Field Id: 17 octet

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


4.18 bgpNextHopAddressV4 IPv4 identification
      field.

5.1.22  mplsLabelStackEntry1
   Description:
      The IPv4 address of label, exp and s fields from the next BGP hop outermost MPLS label stack
      entry e.g.  the last label that was pushed last.
      to which packets of this flow
      are forwarded. be replaced by ASCII drawing
      to be replaced by ASCII drawing
      to be replaced by ASCII drawing
      to be replaced by ASCII drawing
      to be replaced by ASCII drawing

   Abstract Data Type: ipv4Address

   Field Id: 18 unsigned32

   FieldId: 70
   Reference: See RFC 1771 for a description of BGB-4 3032.

5.1.23  mplsLabelStackEntry2
   Description:
      The label, exp and see RFC 1930 a s fields from the LSE that was pushed
      immediately before the LSE that would be reported by
      mplsLabelStackEntry1.  See the definition of the AS number.


4.19 OutMulticastPacketCount mplsLabelStackEntry1
      for further details.

   Abstract Data Type: unsigned32

   FieldId: 71
   Reference: See RFC 3032.

5.1.24  mplsLabelStackEntry3
   Description:
      The number of outgoing multicast packets created for packets of
      this flow by an adjacent multicast daemon. Note label, exp and s fields from the LSE that typically not
      all of was pushed
      immediately before the created packets can LSE that would be observed at reported by
      mplsLabelStackEntry2.  See the observation
      point definition of this flow. mplsLabelStackEntry1
      for further details.

   Abstract Data Type: unsigned32

   FieldId: 72




Meyer, et al.            Expires January 17, April 25, 2005                [Page 16]

Internet-Draft          IPFIX Information Model                July 2004


   Abstract Data Type: unsigned64

   Field Id: 19

   Units: packets

4.20 OutMulticastOctetCount

   Description:

      The number of octets in outgoing multicast packets created for
      packets of this flow by an adjacent multicast daemon. Note 20]

Internet-Draft          IPFIX Information Model             October 2004


   Reference: See RFC 3032.

5.1.25  mplsLabelStackEntry4
   Description:
      The label, exp and s fields from the LSE that
      typically not all of was pushed
      immediately before the created packets can LSE that would be observed at reported by
      mplsLabelStackEntry3.  See the
      observation point definition of this flow. mplsLabelStackEntry1
      for further details.

   Abstract Data Type: unsigned64

   Field Id: 20

   Units: octets

4.21 flowEndTime unsigned32

   FieldId: 73
   Reference: See RFC 3032.

5.1.26  mplsLabelStackEntry5
   Description:
      The timestamp of label, exp and s fields from the last packet LSE that was pushed
      immediately before the LSE that would be reported by
      mplsLabelStackEntry4.  See the definition of this flow. mplsLabelStackEntry1
      for further details.

   Abstract Data Type: dateTimeSeconds

   Field Id: 21

4.22 flowCreationTime unsigned32

   FieldId: 74
   Reference: See RFC 3032.

5.1.27  mplsLabelStackEntry6
   Description:
      The timestamp of label, exp and s fields from the first packet LSE that was pushed
      immediately before the LSE that would be reported by
      mplsLabelStackEntry5.  See the definition of this flow. mplsLabelStackEntry1
      for further details.

   Abstract Data Type: dateTimeSeconds

   Field Id: 22

4.23 deltaOutOctetCount unsigned32

   FieldId: 75
   Reference: See RFC 3032.

5.1.28  mplsLabelStackEntry7
   Description:
      The number of octets in outgoing packets observed for this flow at label, exp and s fields from the observation point since LSE that was pushed
      immediately before the previous report (if any). The
      number LSE that would be reported by
      mplsLabelStackEntry6.  See the definition of octets include IP header(s) and IP payload. mplsLabelStackEntry1
      for further details.

   Abstract Data Type: unsigned64

   Data Type Semantics: deltaCounter unsigned32

   FieldId: 76



Meyer, et al.            Expires January 17, April 25, 2005                [Page 17] 21]

Internet-Draft          IPFIX Information Model                July             October 2004


   Field Id: 23

   Units: octets

4.24 deltaOutPacketCount


   Reference: See RFC 3032.

5.1.29  mplsLabelStackEntry8
   Description:
      The number label, exp and s fields from the LSE that was pushed
      immediately before the LSE that would be reported by
      mplsLabelStackEntry7.  See the definition of outgoing packets observed mplsLabelStackEntry1
      for this flow at further details.

   Abstract Data Type: unsigned32

   FieldId: 77
   Reference: See RFC 3032.

5.1.30  mplsLabelStackEntry9
   Description:
      The label, exp and s fields from the
      observation point since LSE that was pushed
      immediately before the previous report (if any). LSE that would be reported by
      mplsLabelStackEntry8.  See the definition of mplsLabelStackEntry1
      for further details.

   Abstract Data Type: unsigned64

   Data Type Semantics: deltaCounter

   Field Id: 24

   Units: packets

4.25 minPacketLength unsigned32

   FieldId: 78
   Reference: See RFC 3032.

5.1.31  mplsLabelStackEntry10
   Description:

      Length of
      The label, exp and s fields from the smallest packet observed LSE that was pushed
      immediately before the LSE that would be reported by
      mplsLabelStackEntry9.  See the definition of mplsLabelStackEntry1
      for this flow. further details.

   Abstract Data Type: unsigned16

   Field Id: 25

   Units: octets

4.26 maxPacketLength unsigned32

   FieldId: 79
   Reference: See RFC 3032.

5.1.32  ipNextHopIPv4Address
   Description:

      Length
      The IPv4 address of the largest packet observed for next IP hop to which packets of this flow. flow
      are forwarded.

   Abstract Data Type: unsigned16

   Field Id: 26

   Units: octets

4.27 sourceAddressV6

   Description: ipv4Address

   FieldId: 15





Meyer, et al.            Expires January 17, April 25, 2005                [Page 18] 22]

Internet-Draft          IPFIX Information Model                July             October 2004


5.1.33  ipNextHopIPv6Address
   Description:
      The IPv6 source address taken from the IP packet header of a packet the next BGP hop to which packets of this flow. flow
      are forwarded.

   Abstract Data Type: ipv6Address

   Field Id: 27

4.28 destinationAddressV6

   FieldId: 62

5.1.34  ingressInterface
   Description:

      IPv6 destination address taken from
      The index of the IP packet header of a
      packet interface (ifIndex) where packets of this flow. flow
      are being received.

   Abstract Data Type: ipv6Address

   Field Id: 28

4.29 sourceMaskV6 unsigned32

   Data Type Semantics: identifier

   FieldId: 10
   Reference: See RFC 2863 for the definition of the ifIndex object.

5.1.35  egressInterface
   Description:
      The number index of contiguous bits that are relevant in the
      sourceAddressV6 field. IP interface (ifIndex) where packets of this flow
      are being sent.

   Abstract Data Type: octet

   Field Id: 29

   Units: bits

4.30 destinationMaskV6 unsigned32

   Data Type Semantics: identifier

   FieldId: 14
   Reference: See RFC 2863 for the definition of the ifIndex object.

5.1.36  ipNextHopAsNumber
   Description:
      The autonomous system (AS) number of contiguous bits that are relevant in the
      destinationAddressV6 field. next IP hop to which
      packets of this flow are forwarded.

   Abstract Data Type: octet

   Field Id: 30

   Units: bits

4.31 flowLabelV6 unsigned16

   Data Type Semantics: identifier

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






Meyer, et al.            Expires January 17, April 25, 2005                [Page 19] 23]

Internet-Draft          IPFIX Information Model                July             October 2004


5.1.37  bgpSourceAsNumber
   Description:
      The Flow Label autonomous system (AS) number of the IPv6 source address in the IP
      packet header observed in a packet of this flow.

   Abstract Data Type: unsigned32

   Field Id: 31 unsigned16

   Data Type Semantics: identifier

   FieldId: 16
   Reference: See RFC 2460 1771 for a description of BGB-4 and see RFC 1930 a
      definition of the flow label field AS number.

5.1.38  bgpDestinationAsNumber
   Description:
      The autonomous system (AS) number of the destination address in
      the IPv6 IP packet header.


4.32 icmpTypeCode

   Description: header in a packet of this flow.

   Abstract Data Type: unsigned16

   Data Type Semantics: identifier

   FieldId: 17
   Reference: See RFC 1771 for a description of BGB-4 and Code see RFC 1930 a
      definition of the ICMP message. AS number.

5.1.39  bgpNextHopAsNumber
   Description:
      The combination autonomous system (AS) number of both values
      is reported as (ICMP type * 256) + ICMP code. the next BGP hop to which
      packets of this flow are forwarded.

   Abstract Data Type: unsigned16

   Field Id: 32

   Data Type Semantics: identifier

   FieldId: 128
   Reference: See RFC 792 1771 for a description of BGB-4 and see RFC 1930 a
      definition of the ICMP type AS number.

5.1.40  bgpNextHopIPv4Address
   Description:
      The IPv4 address of the next BGP hop to which packets of this flow
      are forwarded.

   Abstract Data Type: ipv4Address

   FieldId: 18




Meyer, et al.            Expires April 25, 2005                [Page 24]

Internet-Draft          IPFIX Information Model             October 2004


   Reference: See RFC 1771 for a description of BGB-4 and code
      fields.


4.33 igmpType see RFC 1930 a
      definition of the AS number.

5.1.41  bgpNextHopIPv6Address
   Description:
      The type field IPv6 address of the IGMP message. next BGP hop to which packets of this flow
      are forwarded.

   Abstract Data Type: octet

   Field Id: 33 ipv6Address

   Data Type Semantics: identifier

   FieldId: 63
   Reference: See RFC 2236 1771 for a definition of the IGMP type field.


4.34 flowActiveTimeOut

   Description:

      The number description of seconds after which an active flow is timed out
      anyway, even if there is still BGB-4.  See RFC 1930 a continuous flow
      definition of packets.

   Abstract Data Type: unsigned16




Meyer, et al.           Expires January 17, 2005               [Page 20]

Internet-Draft          IPFIX Information Model                July 2004


   Field Id: 36

   Units: seconds

4.35 flowInactiveTimeout the AS number.

5.1.42  mplsTopLabelType
   Description:

      A flow is considered to be timed out if not packet belonging to
      MPLS top label type:
      This field identifies the flow has been observed for control protocol that allocated the number top
      of seconds specified by
      this field. stack label.

   Abstract Data Type: unsigned16

   Field Id: 37

   Units: seconds

4.36 exportedOctetCount octet

   Data Type Semantics: identifier

   FieldId: 46

5.1.43  mplsTopLabelIPv4Address
   Description:
      The number IPv4 address of all octets reported by the exporting process to system that the MPLS top label will cause
      this
      collecting process. packet to be forwarded to.

   Abstract Data Type: unsigned64

   Field Id: 40

   Units: octets

4.37 exportedPacketCount ipV4Address

   FieldId: 47

5.1.44  mplsTopLabelIPv6Address
   Description:
      The number IPv4 address of all packets reported by the exporting process to system that the MPLS top label will cause
      this collecting process. packet to be forwarded to.

   Abstract Data Type: unsigned64

   Field Id: 41

   Units: packets

4.38 exportedFlowCount ipV4Address

   FieldId: 140






Meyer, et al.            Expires January 17, April 25, 2005                [Page 21] 25]

Internet-Draft          IPFIX Information Model                July             October 2004


5.2  Properties of Metering/Exporting Process

   Information elements in this section describe static properties of
   the metering process and/or the exporting process.  The set of these
   information elements is listed in the table below

   +-------+-------------------------+-------+-------------------------+
   |    ID | Field Name              |    ID | Field Name              |
   +-------+-------------------------+-------+-------------------------+
   |   130 | exporterIPv4Address     |   131 | exporterIPv6Address     |
   +-------+-------------------------+-------+-------------------------+


5.2.1  exporterIPv4Address
   Description:
      The number IPv4 address of all flows records reported the 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 exporting process
      to this collecting process. use of a
      proxy.

   Abstract Data Type: unsigned64

   Field Id: 42

   Units: flows

4.39 sourcePrefixV4

   Description:

      IPv4 source address prefix.

      EDITOR'S NOTE: to be discussed on ipfix mailing list

   Abstract ipv4Address

   Data Type: ipV4Address

   Field Id: 44

   Units: flows

4.40 destinationPrefixV4 Type Semantics: identifier

   FieldId: 130

5.2.2  exporterIPv4Address
   Description:

      IPv4 destination
      The IPv6 address prefix.

      EDITOR'S NOTE: of the used by the exporting process.  This is
      used by the collector to be discussed on ipfix mailing list identify the exporter in cases where the
      identity of the exporter may have been obscured by the use of a
      proxy.

   Abstract Data Type: ipV4Address

   Field Id: 45

   Units: flows

4.41 mplsTopLabelType

   Description:

      MPLS top label type:

      This field identifies the control protocol that allocated the top ipv6Address

   Data Type Semantics: identifier

   FieldId: 131

5.3  Min/Max Flow Properties

   Information elements in this section are results of stack label. minimum or
   maximum operations over multiple or all packets of a flow.  They
   cannot serve as flow keys, but their value can be used as trigger for
   selecting and/or exporting flows.

   The set of information elements resulting from minimum or maximum
   operations over all packets of a flow includes the information



Meyer, et al.            Expires January 17, April 25, 2005                [Page 22] 26]

Internet-Draft          IPFIX Information Model                July             October 2004


   Abstract Data Type: octet

   Data Type Semantics: identifier


   elements listed in the table below.

   +-------+-------------------------+-------+-------------------------+
   |    ID | Field Id: 46

4.42 mplsTopLabelIPAddressV4 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.3.1  minPacketLength
   Description:
      Length of the smallest packet observed for this flow.

   Abstract Data Type: unsigned16

   FieldId: 25

   Units: octets

5.3.2  maxPacketLength
   Description:

      The IPv4 address
      Length of the system that the MPLS top label will cause
      this largest packet to be forwarded to. observed for this flow.

   Abstract Data Type: ipV4Address

   Field Id: 47

4.43 unsigned16

   FieldId: 26

   Units: octets

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

   Abstract Data Type: octet

   Field Id:

   FieldId: 52

4.44

5.3.4  maximumTTL
   Description:
      Maximum TTL value observed for any packet in this flow.

   Abstract Data Type: octet

   Field Id: 53

4.45 identificationV4

   Description:

      Packet identification field from the first IP packet of this flow.

   Abstract Data Type: octet

   Data Type Semantics: identifier

   Field Id: 54



Meyer, et al.           Expires January 17, 2005               [Page 23]

Internet-Draft          IPFIX Information Model                July 2004


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


4.46 sourceMacAddress

   Description:

      Packet identification field from the first IP packet of this flow.

   Abstract Data Type: octet

   Field Id: 56

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


4.47 ipVersion

   Description: The IP version field given in the IP header.

   Abstract Data Type: octet

   Field Id: 60

   Units: flows

   Reference:

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


4.48 ipNextHopAddressV6

   Description:

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

   Abstract Data Type: ipv6Address

   Field Id: 62




Meyer, et al.           Expires January 17, 2005               [Page 24]

Internet-Draft          IPFIX Information Model                July 2004


4.49 bgpNextHopAddressV6

   Description:

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

   Abstract Data Type: ipv6Address

   Data Type Semantics: identifier

   Field Id: 63

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


4.50            Expires April 25, 2005                [Page 27]

Internet-Draft          IPFIX Information Model             October 2004


   FieldId: 53

5.3.5  ipv6OptionHeaders
   Description:
      IPv6 options in the IP packet headers of this flow.  This is
      encoded as 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
      to 31                 Reserved be replaced by ASCII drawing
      to be replaced by ASCII drawing
      to be replaced by ASCII drawing
      to be replaced by ASCII drawing
      to be replaced by ASCII drawing
      to be replaced by ASCII drawing
      to be replaced by ASCII drawing
      to be replaced by ASCII drawing
      to be replaced by ASCII drawing
      to be replaced by ASCII drawing
      to be replaced by ASCII drawing

   Abstract Data Type: unsigned32




Meyer, et al.           Expires January 17, 2005               [Page 25]

Internet-Draft          IPFIX Information Model                July 2004

   Data Type Semantics: flags

   Field Id:

   FieldId: 64
   Reference: To be done.


4.51 partialMPLSLabelStackEntry1

5.3.6  tcpControlBits
   Description:
      TCP control bits observed for packets of this flow.  The label, exp and s fields from value of
      this field is the outermost MPLS label stack
      entry e.g. result of a logical OR operation over the last label flags
      observed in all packets of the flow.  This implies 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 a 0 1 2 3 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Label                  | Exp |S|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      
      Label:  Label Value, 20 bits
      Exp:    Experimental Use, 3 bits
      S:      Bottom of Stack, 1 value
      for a bit

   Abstract Data Type: unsigned32

   Field Id: 70

   Reference: See RFC 3032.


4.52 partialMPLSLabelStackEntry2

   Description:

      The label, exp and s fields from the LSE indicates that the respective bit was pushed
      immediately before not set in any of
      the LSE that would observed packets of this flow.
      to be reported replaced by
      partialMplsLse1. See the definition of partialMplsLse1 for further
      details. ASCII drawing
      to be replaced by ASCII drawing
      to be replaced by ASCII drawing
      to be replaced by ASCII drawing
      to be replaced by ASCII drawing
      to be replaced by ASCII drawing
      to be replaced by ASCII drawing
      to be replaced by ASCII drawing

   Abstract Data Type: unsigned32

   Field Id: 71

   Reference: See RFC 3032. octet

   Data Type Semantics: flags

   FieldId: 6





Meyer, et al.            Expires January 17, April 25, 2005                [Page 26] 28]

Internet-Draft          IPFIX Information Model                July             October 2004


4.53 partialMPLSLabelStackEntry3

   Description:

      The label, exp and s fields from


   Reference: See RFC 793 for a definition of the LSE that was pushed
      immediately before TCP control bits in
      the LSE that would be reported by
      partialMplsLse2. See TCP header.

5.3.7  flowCreationTime
   Description: The timestamp of the definition first packet of partialMplsLse1 for further
      details. this flow.

   Abstract Data Type: unsigned32

   Field Id: 72

   Reference: See RFC 3032.


4.54 partialMPLSLabelStackEntry4 dateTimeSeconds

   FieldId: 22

5.3.8  flowEndTime
   Description: The label, exp and s fields from the LSE that was pushed
      immediately before the LSE that would be reported by
      partialMplsLse3. See timestamp of the definition last packet of partialMplsLse1 for further
      details. this flow.

   Abstract Data Type: unsigned32

   Field Id: 73

   Reference: See RFC 3032.


4.55 partialMPLSLabelStackEntry5 dateTimeSeconds

   FieldId: 21

5.3.9  flowActiveTimeOut
   Description:
      The label, exp and s fields from the LSE that was pushed
      immediately before the LSE that would 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

   Units: seconds

5.3.10  flowInactiveTimeout
   Description:
      A flow is considered to be reported by
      partialMplsLse4. See timed out if not packet belonging to
      the definition flow has been observed for the number of partialMplsLse1 seconds specified by
      this field.

   Abstract Data Type: unsigned16

   FieldId: 37

   Units: seconds

5.3.11  flowEndReason
   Description:
      The reason for further
      details. flow termination.
      EDITORS' NOTE: This needs to be defined as an enumerated range.

   Abstract Data Type: unsigned32

   Field Id: 74

   Reference: See RFC 3032. octet

   FieldId: 136



Meyer, et al.            Expires January 17, April 25, 2005                [Page 27] 29]

Internet-Draft          IPFIX Information Model                July             October 2004


4.56 partialMPLSLabelStackEntry6

   Description:

      The label, exp and s fields from the LSE that was pushed
      immediately before the LSE that would


5.4  Counters

   Information elements 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 of a flow key used for mapping packets to
   flows.  However, potentially they can be reported used for selecting exported
   flow, for example by
      partialMplsLse5. See the definition only exporting flows with more than a thresholh
   number of partialMplsLse1 observed octets.

   There are running counters and delta counters.  Delta counters are
   reset to zero for further
      details.

   Abstract Data Type: unsigned32

   Field Id: 75

   Reference: See RFC 3032.


4.57 partialMPLSLabelStackEntry7

   Description:

      The label, exp each time their values are exported.  Running
   counters continue counting independent of the exporting process.

   There are per-flow counters and s fields from counters related to the LSE metering
   process and/or the exporting process.  Per-flow counters are flow
   properites that was pushed
      immediately before potentially change each time a packets belonging to
   the LSE flow is observed.  Per-flow counters are flow properites that would be reported by
      partialMplsLse6. See
   potentially change each time a packet belonging to the definition flow is
   observed.  The set of partialMplsLse1 for further
      details.

   Abstract Data Type: unsigned32 per-flow counters includes the information
   elements listed in the table below.

   +-------+-------------------------+-------+-------------------------+
   |    ID | Field Id: 76

   Reference: See RFC 3032.


4.58 partialMPLSLabelStackEntry8

   Description: Name              |    ID | Field Name              |
   +-------+-------------------------+-------+-------------------------+
   |     1 | inOctetDeltaCount       |   132 | droppedOctetDeltaCount  |
   |    23 | outOctetDeltaCount      |   133 | droppedOctetTotalCount  |
   |   138 | octetDeltaCount         |   134 | droppedPacketDeltaCount |
   |    85 | octetTotalCount         |   135 | droppedPacketTotalCount |
   |     2 | inPacketDeltaCount      |    19 | outMulticastPacketCount |
   |    24 | outPacketDeltaCount     |    20 | outMulticastOctetCount  |
   |   139 | packetDeltaCount        |       |                         |
   |    86 | packetTotalCount        |       |                         |
   +-------+-------------------------+-------+-------------------------+

   The label, exp and s fields from set of counters related to the LSE that was pushed
      immediately before metering process and/or the LSE that would be reported by
      partialMplsLse7. See
   exporting process exported includes the definition of partialMplsLse1 for further
      details.

   Abstract Data Type: unsigned32 information elements listed
   in the table below.

   +-------+-------------------------+-------+-------------------------+
   |    ID | Field Id: 77

   Reference: See RFC 3032. Name              |    ID | Field Name              |
   +-------+-------------------------+-------+-------------------------+
   |     3 | observedFlowTotalCount  |    41 | exportedPacketTotalCount|
   |    40 | exportedOctetToalCount  |    42 | exportedFlowTotalCount  |
   +-------+-------------------------+-------+-------------------------+







Meyer, et al.            Expires January 17, April 25, 2005                [Page 28] 30]

Internet-Draft          IPFIX Information Model                July             October 2004


4.59 partialMPLSLabelStackEntry9


5.4.1  inOctetDeltaCount
   Description:
      The label, exp and s fields from the LSE that was pushed
      immediately before number of octets in incoming packets observed for this flow at
      the LSE that would be reported by
      partialMplsLse8. See observation point since the definition previous report (if any).  The
      number of partialMplsLse1 for further
      details. octets include IP header(s) and IP payload.

   Abstract Data Type: unsigned32

   Field Id: 78

   Reference: See RFC 3032.


4.60 partialMPLSLabelStackEntry10 unsigned64

   Data Type Semantics: deltaCounter

   FieldId: 1

   Units: octets

5.4.2  outOctetDeltaCount
   Description:
      The label, exp and s fields from the LSE that was pushed
      immediately before number of octets in outgoing packets observed for this flow at
      the LSE that would be reported by
      partialMplsLse9. See observation point since the definition previous report (if any).  The
      number of octets include IP header(s) and IP payload.

   Abstract Data Type: unsigned64

   Data Type Semantics: deltaCounter

   FieldId: 23

   Units: octets

5.4.3  octetDeltaCount
   Description:
      The number of partialMplsLse1 octets in all packets observed for further
      details. this flow at the
      observation point since the previous report (if any).  The number
      of octets include IP header(s) and IP payload.

   Abstract Data Type: unsigned32

   Field Id: 79

   Reference: See RFC 3032.


4.61 runningOctetCounter unsigned64

   Data Type Semantics: deltaCounter

   FieldId: 138

   Units: octets

5.4.4  octetTotalCount
   Description:
      Number of observed octets for a pre-defined permanent flow.

      EDITOR'S NOTE: clarification required.

   Abstract Data Type: unsigned64

   Data Type Semantics: runningCounter

   Field Id: 85

   Units: octets






Meyer, et al.            Expires January 17, April 25, 2005                [Page 29] 31]

Internet-Draft          IPFIX Information Model                July             October 2004


4.62 runningPacketCounter

   Description:

      Number of observed packets for a pre-defined permanent flow.


      EDITOR'S NOTE: clarification required.

   Abstract Data Type: unsigned64

   Data Type Semantics: runningCounter

   Field Id: 86

   FieldId: 85

   Units: packets

4.63 bgpNextHopAsNumber octets

5.4.5  inPacketDeltaCount
   Description:
      The autonomous system (AS) number of the next BGP hop to which incoming packets of observed for this flow are forwarded. at the
      observation point since the previous report (if any).

   Abstract Data Type: unsigned16 unsigned64

   Data Type Semantics: identifier

   Field Id: 128

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


4.64 ipNextHopAsNumber deltaCounter

   FieldId: 2

   Units: packets

5.4.6  outPacketDeltaCount
   Description:
      The autonomous system (AS) number of the next IP hop to which outgoing packets of observed for this flow are forwarded. at the
      observation point since the previous report (if any).

   Abstract Data Type: unsigned16 unsigned64

   Data Type Semantics: identifier

   Field Id: 129






Meyer, et al.           Expires January 17, 2005               [Page 30]

Internet-Draft          IPFIX Information Model                July 2004


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


4.65 exporterAddressV4 deltaCounter

   FieldId: 24

   Units: packets

5.4.7  packetDeltaCount
   Description:
      The IPv4 address of the used by the exporting process. This is
      used by the collector to identify the exporter in cases where the
      identity number of all packets observed for this flow at the exporter may have been obscured by
      observation point since the use of a
      proxy. previous report (if any).

   Abstract Data Type: ipv4Address unsigned64

   Data Type Semantics: identifier

   Field Id: 130

4.66 exporterAddressV6

   Description:

      The IPv6 address of the 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 deltaCounter

   FieldId: 139

   Units: packets



Meyer, et al.            Expires April 25, 2005                [Page 32]

Internet-Draft          IPFIX Information Model             October 2004


5.4.8  packetTotalCount
   Description:
      Number of observed packets for a
      proxy. pre-defined permanent flow.
      EDITOR'S NOTE: clarification required.

   Abstract Data Type: ipv6Address unsigned64

   Data Type Semantics: identifier

   Field Id: 131

4.67 runningCounter

   FieldId: 86

   Units: packets

5.4.9  droppedOctetDeltaCount
   Description:
      The number of octets in packets of this flow dropped by packet
      treatment.

   Abstract Data Type: unsigned64

   Data Type Semantics: deltaCounter

   Field Id:

   FieldId: 132

   Units: octets



Meyer, et al.           Expires January 17, 2005               [Page 31]

Internet-Draft          IPFIX Information Model                July 2004


4.68 droppedPacketDeltaCount

5.4.10  droppedOctetTotalCount
   Description:
      The number of octets in packets of this flow dropped by packet
      treatment.

   Abstract Data Type: unsigned64

   Data Type Semantics: deltaCounter

   Field Id: runningCounter

   FieldId: 133

   Units: packets

4.69 droppedOctetTotalCount octets

5.4.11  droppedPacketDeltaCount
   Description:
      The number of octets in packets of this flow dropped by packet treatment.

   Abstract Data Type: unsigned64

   Data Type Semantics: runningCounter

   Field Id: deltaCounter

   FieldId: 134



Meyer, et al.            Expires April 25, 2005                [Page 33]

Internet-Draft          IPFIX Information Model             October 2004


   Units: octets

4.70 packets

5.4.12  droppedPacketTotalCount
   Description:
      The number of packets of this flow dropped by packet treatment.

   Abstract Data Type: unsigned64

   Data Type Semantics: runningCounter

   Field Id:

   FieldId: 135

   Units: packets

4.71 flowEndReason

5.4.13  outMulticastPacketCount
   Description:
      The number of outgoing multicast packets created for packets of
      this 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.

   Abstract Data Type: unsigned64

   FieldId: 19

   Units: packets

5.4.14  outMulticastOctetCount
   Description:
      The number of octets in outgoing multicast packets created for
      packets of this 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.

   Abstract Data Type: unsigned64

   FieldId: 20

   Units: octets

5.4.15  observedFlowTotalCount
   Description:
      The number of flows observed so far in the observation domain.

   Abstract Data Type: unsigned64

   Data Type Semantics: runningCounter




Meyer, et al.            Expires January 17, April 25, 2005                [Page 32] 34]

Internet-Draft          IPFIX Information Model                July             October 2004


   FieldId: 3

   Units: flows

5.4.16  exportedOctetTotalCount
   Description:
      The reason for flow termination.

      EDITORS' NOTE: This needs number of all octets reported by the exporting process to be defined as an enumerated range. this
      collecting process.

   Abstract Data Type: octet

   Field Id: 136

4.72 classOfServiceV6 unsigned64

   Data Type Semantics: runningCounter

   FieldId: 40

   Units: octets

5.4.17  exportedPacketTotalCount
   Description:
      The value number of all packets reported by the IPv6 traffic class field observed for exporting process to
      this collecting process.

   Abstract Data Type: unsigned64

   Data Type Semantics: runningCounter

   FieldId: 41

   Units: packets

5.4.18  exportedFlowTotalCount
   Description:
      The number of all flows records reported by the exporting process
      to this flow. collecting process.

   Abstract Data Type: octet

   Field Id: 135

   Reference: See RFC 2460 for the definition of the IPv6 traffic class
      field. unsigned64

   FieldId: 42

   Units: flows











Meyer, et al.            Expires January 17, April 25, 2005                [Page 33] 35]

Internet-Draft          IPFIX Information Model                July             October 2004


5.


6.  Extending the Information Model

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

   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 identifies the information items
   and their order.  The means of identification of information items in
   a template is via a field ID.  Field Id's are unique identifiers
   administered by IANA.

   Extension is done by defining new Information elements, including the
   set of necessary information and possibly additional optional
   information for each element.  Each new information item MUST be
   assigned a unique fieldId as part of its definition.  These unique
   field ids are the connection between the record structure
   communicated by the protocol using templates and a consuming
   application.

   Vendor specific extensions may be made by vendors with IANA an SMI network
   management private enterprise ID assignments, without registering specific code defined by IANA at
   http://www.iana.org/assignments/enterprise-numbers.  Vendor-specific
   field ID's
   with IDs do not need to be registered by IANA.  In these cases the field definiton must  The definition of a
   vendor-specific information element MUST specify the vendor ID as
   well as the vendor-specified field ID and other mandatory field
   properties.  Before creating vendor-specific fields, the general
   applicability of such information elements should be considered.  For
   generally applicable fields using IETF and IANA mechanisms for
   extendind the information model is recommended.




















Meyer, et al.            Expires January 17, April 25, 2005                [Page 34] 36]

Internet-Draft          IPFIX Information Model                July             October 2004


6.


7.  IANA Considerations

   IANA has to create a new registry for IPFIX fields ID's.

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










































Meyer, et al.            Expires January 17, April 25, 2005                [Page 35] 37]

Internet-Draft          IPFIX Information Model                July             October 2004


7.


8.  Security Considerations

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

   The underlying protocol used to exchange the information described
   here must therefor apply appropriate procedures to guarantee the
   integrity and confidentiality of the exported information.  Such
   protocols are defined in separate documents.  Specifically the IPFIX
   Protocol document.








































Meyer, et al.            Expires January 17, April 25, 2005                [Page 36] 38]

Internet-Draft          IPFIX Information Model                July             October 2004


8.


9.  Acknowledgements

   The editors thank Stewart Bryant Benoit Claise for a lot of useful input on the
   field definitions.  Also many thanks to Thomas Dietz for developing
   the XSLT scripts that generate large portions of the text part of
   this document from the XML appendices.













































Meyer, et al.            Expires January 17, April 25, 2005                [Page 37] 39]

Internet-Draft          IPFIX Information Model             October 2004


10.  Open Issues

   +-------------------------------------------------------------------+
   | Open Issues                                                       |
   +-------------------------------------------------------------------+
   | replace field with IE                                             |
   |                                                                   |
   | Are MCOctetCounters delta or running?                             |
   |                                                                   |
   | What about RTP-related IEs?                                       |
   |                                                                   |
   | Where to put ingressInterface?                                    |
   |                                                                   |
   | Different category for tcpControBits and ipv6OptionHeaders?       |
   |                                                                   |
   | identificationIPv4 also for IPv6?                                 |
   |                                                                   |
   | What is the difference between source/destinationIPv4Mask and     |
   | source/destinationIPv4Prefix?                                     |
   |                                                                   |
   | Add ASCII art to IE specification of tcpControlBits,              |
   | ipv6OptionHeaders, mplsLabelStackEntry1                           |
   +-------------------------------------------------------------------+




























Meyer, et al.            Expires April 25, 2005                [Page 40]

Internet-Draft          IPFIX Information Model                July             October 2004


11.  References

11.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-02.txt>.













































Meyer, et al.           Expires January 17, 2005               [Page 38]

Internet-Draft          IPFIX Information Model                July 2004
        <http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-0
        2.txt>.

11.2  Informative Reference

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

   [3]   Sadasivan, G. and N. Brownlee, "Architecture Model for IP Flow
         Information Export", IETF draft work in progress, October 2003,
         <http://www.ietf.org/internet-drafts/
         draft-ietf-ipfix-arch-02.txt>.
         <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>.
         <http://www.ietf.org/internet-drafts/draft-ietf-ipfix-as-01.txt
         >.

   [5]   Claise, B., "Cisco Systems NetFlow Services Export Version 9",
         IETF draft work in progress, June 2003, <http://www.ietf.org/
         internet-drafts/draft-claise-netflow-9-02.txt>.
         <http://www.ietf.org/internet-drafts/draft-claise-netflow-9-02.
         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>.
         <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/>.
         <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.html>.
         <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



Meyer, et al.            Expires April 25, 2005                [Page 41]

Internet-Draft          IPFIX Information Model             October 2004


         3.1.1", October 2002, <http://www.ipdr.org/documents/
         NDM-U_3.1.1.pdf>.
         <http://www.ipdr.org/documents/NDM-U_3.1.1.pdf>.

   [10]  Brownlee, N. and A. Blount, "Accounting Attributes and Record
         Formats", RFC 2924, Sept. 2000, <http://www.ietf.org/rfc/
         rfc2924.txt>.
         <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. and L. Masinter, "Guidelines for the
         Use of Extensible Markup Language (XML) within IETF Protocols",
         RFC 3470, January 2003, <http://www.ietf.org/rfc/rfc3470.txt>.



Meyer, et al.           Expires January 17, 2005               [Page 39]

Internet-Draft          IPFIX Information Model                July 2004

   [13]  Pras, A. and J. Schoenwaelder, "On 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

   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


   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/







Meyer, et al.            Expires April 25, 2005                [Page 42]

Internet-Draft          IPFIX Information Model             October 2004


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

   EMail: stbryant@cisco.com












































Meyer, et al.            Expires January 17, April 25, 2005                [Page 40] 43]

Internet-Draft          IPFIX Information Model                July             October 2004


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 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 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 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 XML in exporters, collectors or
   other tools is not mandatory for the deployment of IPFIX.  In
   particular exporting processes do not produce or consume XML as part
   of their operation.  It is expected that IPFIX collectors MAY take
   advantage of the machine readability of the Information Model vs.
   hardcoding their behavior or inventing proprietary means for
   accomodating extensions.


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

     <field name="deltaOctetCount" dataType="unsigned64"
            dataTypeSemantics="deltaCounter"
            fieldType="1" applicability="data" name="ipVersion" dataType="octet"
            fieldId="60" applicability="all" status="current">
       <description>
         <paragraph>
         The number IP version field given in the IP header.
       </description>
       <units>flows</units>
       <reference>
         <paragraph>
         See RFC 791 for a definition of octets the version field in (incoming) packets observed the
         IPv6 packet header.
         See RFC 2460 for this
         flow at a definition of the observation point since version field in the previous report (if any).
         The number of octets include IP header(s) and IP payload.
         IPv6 packet header.
         Additional information on defined version numbers
         can be found at
         http://www.iana.org/assignments/version-numbers.
         </paragraph>
       </description>
       <units>octets</units>
     </field>

     <field name="deltaPacketCount" dataType="unsigned64"
            dataTypeSemantics="deltaCounter"
            fieldType="2" applicability="data" status="current">
       <description>
       </reference>



Meyer, et al.            Expires January 17, April 25, 2005                [Page 41] 44]

Internet-Draft          IPFIX Information Model                July             October 2004


     </field>

     <field name="sourceIPv4Address" dataType="ipv4Address"
            fieldId="8" applicability="all" status="current">
       <description>
         <paragraph>
         The number
         IPv4 source address taken from the IP packet header of a
         packet of (incoming) packets observed for this flow at flow.
         </paragraph>
       </description>
       <reference>
         See RFC 791 for the observation point since definition of the previous report (if any). IPv4 source address
         field.
       </reference>
     </field>

     <field name="sourceIPv6Address" dataType="ipv6Address"
            fieldId="27" applicability="all" status="current">
       <description>
         <paragraph>
         IPv6 source address taken from the IP packet header of a
         packet of this flow.
         </paragraph>
       </description>
       <units>packets</units>
     </field>

     <field name="totalFlowCount" dataType="unsigned64"
            dataTypeSemantics="runningCounter"
            fieldType="3" applicability="data" name="sourceIPv4Mask" dataType="octet"
            fieldId="9" applicability="option" status="current">
       <description>
         <paragraph>
         The number of flows observed so far contiguous bits that are relevant in the observation domain.
         sourceAddressV4 field.
         </paragraph>
       </description>
       <units>flows</units>
       <units>bits</units>
       <range>0-32</range>
     </field>

     <field name="protocolIdentifier" name="sourceIPv6Mask" dataType="octet"
            dataTypeSemantics="identifier"
            fieldType="4" applicability="all"
            fieldId="29" applicability="option" status="current">
       <description>
         <paragraph>
         The protocol number observed for packets of this flow.
         The protocol number identifies the IP packet payload.
         Protocol numbers contiguous bits that are defined in the IANA Protocol Numbers
         registry.</paragraph>

         <paragraph>
         In Internet Protocol version 4 (IPv4) this is carried relevant in the "Protocol"
         sourceAddressV6 field. In Internet Protocol version 6 (IPv6)
         this is carried in the "Next Header" field in
         </paragraph>
       </description>
       <units>bits</units>
       <range>0-128</range>



Meyer, et al.            Expires April 25, 2005                [Page 45]

Internet-Draft          IPFIX Information Model             October 2004


     </field>

     <field name="sourceIPv4Prefix" dataType="ipV4Address"
            fieldId="44" applicability="data" status="current">
       <description>
         <paragraph> IPv4 source address prefix. </paragraph>
         <paragraph>
         EDITOR'S NOTE: to be discussed on ipfix mailing list
         </paragraph>
       </description>
       <units>flows</units>
     </field>

     <field name="destinationIPv4Address" dataType="ipv4Address"
            fieldId="12" applicability="all" status="current">
       <description>
         <paragraph>
         IPv4 destination address taken from the last
         extension IP packet header of the packet.</paragraph> a
         packet of this flow.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 791 for the specification definition of the IPv4 protocol destination address
         field.
         See RFC 2460 for
       </reference>
     </field>

     <field name="destinationIPv6Address" dataType="ipv6Address"
            fieldId="28" applicability="all" status="current">
       <description>
         <paragraph>
         IPv6 destination address taken from the specification IP packet header of the IPv6 protocol field.
         See list a
         packet of protocol numbers assigned by IANA at
         http://www.iana.org/assignments/protocol-numbers. this flow.
         </paragraph>
       </reference>
       </description>
     </field>

     <field name="classOfServiceV4" name="destinationIPv4Mask" dataType="octet"
            dataTypeSemantics="identifier"
            fieldType="5" applicability="all"
            fieldId="13" applicability="option" status="current">
       <description>
         <paragraph>
         The number of contiguous bits that are relevant in the
         destinationAddressV4 field.
         </paragraph>
       </description>
       <units>bits</units>
       <range>0-32</range>
     </field>



Meyer, et al.            Expires January 17, April 25, 2005                [Page 42] 46]

Internet-Draft          IPFIX Information Model                July             October 2004


     <field name="destinationIPv6Mask" dataType="octet"
            fieldId="30" applicability="option" status="current">
       <description>
         <paragraph>
         The value number of contiguous bits that are relevant in the IPv4 TOS field observed for packets of this flow.
         destinationAddressV6 field.
         </paragraph>
       </description>
       <reference>
         See RFC 791 for the definition of the
       <units>bits</units>
       <range>0-128</range>
     </field>

     <field name="destinationIPv4Prefix" dataType="ipV4Address"
            fieldId="45" applicability="data" status="current">
       <description>
         <paragraph> IPv4 TOS field.
       </reference> destination address prefix. </paragraph>
         <paragraph>
         EDITOR'S NOTE: to be discussed on ipfix mailing list
         </paragraph>
       </description>
       <units>flows</units>
     </field>

     <field name="tcpControlBits" name="classOfServiceIPv4" dataType="octet"
            dataTypeSemantics="flags"
            fieldType="6"
            dataTypeSemantics="identifier"
            fieldId="5" applicability="all" status="current">
       <description>
         <paragraph>
         TCP control bits observed for packets of this flow.
         The value of this field is the result of a logical OR operation
         over the flags IPv4 TOS field observed in all packets of the flow.
         This implies that a 0 value for a bit indicates that the
         respective bit was not set in any of the observed packets of this flow.</paragraph>

         <paragraph>to be replaced by ASCII drawing</paragraph>
         <paragraph>to be replaced by ASCII drawing</paragraph>
         <paragraph>to be replaced by ASCII drawing</paragraph>
         <paragraph>to be replaced by ASCII drawing</paragraph>
         <paragraph>to be replaced by ASCII drawing</paragraph>
         <paragraph>to be replaced by ASCII drawing</paragraph>
         <paragraph>to be replaced by ASCII drawing</paragraph>
         <paragraph>to be replaced by ASCII drawing</paragraph> flow.
         </paragraph>
       </description>
       <reference>See
       <reference>
         See RFC 793 791 for a the definition of the TCP control bits
       in the TCP header.</reference> IPv4 TOS field.
       </reference>
     </field>

     <field name="transportSourcePort" dataType="unsigned16"
            dataTypeSemantics="identifier"
            fieldType="7" applicability="all" name="classOfServiceV6" dataType="octet"
            fieldId="137" 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 value of the respective header. This IPv6 traffic class field MAY also be used observed
         for future transport protocols that have 16 bit source port
         identifiers. packets of this flow.
         </paragraph>
       </description>
       <reference>
         See RFC 2460 for the definition of the IPv6 traffic class field.
       </reference>
     </field>



Meyer, et al.            Expires January 17, April 25, 2005                [Page 43] 47]

Internet-Draft          IPFIX Information Model                July             October 2004


     <field name="flowLabelV6" dataType="unsigned32"
            fieldId="31" applicability="all" status="current">
       <description>
         <paragraph>
         See RFC 768 for the definition
         The Flow Label of the UDP source port field. IPv6 packet header observed in a packet
         of this flow.
         </paragraph>
       </description>
       <reference>
         See RFC 793 2460 for the a definition of the TCP source port field.
         See RFC 2960 for flow label field in 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>
         IPv6 packet header.
       </reference>
     </field>

     <field name="sourceAddressV4" dataType="ipv4Address"
            fieldType="8" applicability="all" name="identificationV4" dataType="octet"
            dataTypeSemantics="identifier"
            fieldId="54" applicability="data" status="current">
       <description>
         <paragraph>
         IPv4 source address taken
           Packet identification field from the first IP packet header of a
         packet of this flow.
         </paragraph>
       </description>
       <reference>
         See RFC 791 for the definition of the IPv4 source address identification field.
       </reference>
     </field>

     <field name="sourceMaskV4" name="protocolIdentifier" dataType="octet"
            fieldType="9" applicability="option"
            dataTypeSemantics="identifier"
            fieldId="4" applicability="all" status="current">
       <description>
         <paragraph>
         The protocol number observed for packets of contiguous bits that this flow.
         The protocol number identifies the IP packet payload.
         Protocol numbers are relevant defined in the
         sourceAddressV4 field.
         </paragraph>
       </description>
       <units>bits</units>
       <range>0-32</range>
     </field>

     <field name="ingressInterface" dataType="unsigned32"
            dataTypeSemantics="identifier"
            fieldType="10" applicability="all" status="current">
       <description> IANA Protocol Numbers
         registry.</paragraph>

         <paragraph>
         The index
         In Internet Protocol version 4 (IPv4) this is carried in
         the "Protocol" field. In Internet Protocol version 6 (IPv6)
         this is carried in the "Next Header" field in the last
         extension header of the IP interface (ifIndex) where packets of
         this flow are being received.
         </paragraph> packet.</paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 2863 791 for the definition specification of the ifIndex object. IPv4 protocol field.
         See RFC 2460 for the specification of the IPv6 protocol field.
         See list of protocol numbers assigned by IANA at



Meyer, et al.            Expires January 17, April 25, 2005                [Page 44] 48]

Internet-Draft          IPFIX Information Model                July             October 2004


         http://www.iana.org/assignments/protocol-numbers.
         </paragraph>
       </reference>
     </field>

     <field name="transportDestinationPort" name="sourceTransportPort" dataType="unsigned16"
            dataTypeSemantics="identifier"
            fieldType="11"
            fieldId="7" applicability="all" status="current">
       <description>
         <paragraph>
         A destination source port identifier in the transport header. For transport
         protocols UDP, TCP and SCTP this is the
         destination source port number
         given in the respective header. This field MAY also be used
         for future transport protocols that have 16 bit destination 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> 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="destinationAddressV4" dataType="ipv4Address"
            fieldType="12" name="destinationtransportPort" dataType="unsigned16"
            dataTypeSemantics="identifier"
            fieldId="11" applicability="all" status="current">
       <description>
         <paragraph>
         IPv4
         A destination address taken from port identifier in the IP packet header of a
         packet of transport header.
         For transport protocols UDP, TCP and SCTP this flow. is the
         destination port number given in the respective header.
         This field MAY also be used for future transport protocols
         that have 16 bit destination port identifiers.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 791 768 for the definition of the IPv4 destination address UDP source port field.
       </reference>
     </field>

     <field name="destinationMaskV4" dataType="octet"
            fieldType="13" applicability="option" status="current">
       <description>
         <paragraph>
         The number
         See RFC 793 for the definition of contiguous bits that are relevant in the
         destinationAddressV4 TCP source port field.
         See RFC 2960 for the definition of SCTP.  </paragraph>

         <paragraph>



Meyer, et al.            Expires January 17, April 25, 2005                [Page 45] 49]

Internet-Draft          IPFIX Information Model                July             October 2004


         Additional information on defined UDP and TCP port numbers can
         be found at http://www.iana.org/assignments/port-numbers.
         </paragraph>
       </description>
       <units>bits</units>
       <range>0-32</range>
       </reference>
     </field>

     <field name="egressInterface" dataType="unsigned32"
            dataTypeSemantics="identifier"
            fieldType="14" name="icmpTypeCode" dataType="unsigned16"
            fieldId="32" applicability="all" status="current">
       <description>
         <paragraph>
         The index
         Type and Code of the IP interface (ifIndex) where packets ICMP message. The combination of this
         flow are being sent. both values
         is reported as (ICMP type * 256) + ICMP code.
         </paragraph>
       </description>
       <reference>
         See RFC 2863 792 for the a definition of the ifIndex object. ICMP type and code fields.
       </reference>
     </field>

     <field name="ipNextHopAddressV4" dataType="ipv4Address"
            fieldType="15" applicability="data" name="igmpType" dataType="octet"
            fieldId="33" applicability="all" status="current">
       <description>
         <paragraph>
         The IPv4 address type field of the next IP hop to which packets of
         this flow are forwarded.
         </paragraph> IGMP message.
       </description>
       <reference>
         See RFC 2236 for a definition of the IGMP type field.
       </reference>
     </field>

     <field name="sourceAsNumber" dataType="unsigned16"
            dataTypeSemantics="identifier"
            fieldType="16" applicability="all" name="sourceMacAddress" dataType="octet"
            fieldId="56" applicability="data" status="current">
       <description>
         <paragraph>
         The autonomous system (AS) number of the source address in
           Packet identification field from the first IP packet header in a packet of this flow.
         </paragraph>
       </description>
       <reference>
         See RFC 1771 791 for a description of BGB-4 and
         see RFC 1930 a the definition of the AS number. IPv4 identification field.
       </reference>
     </field>

     <field name="destinationAsNumber" dataType="unsigned16"
            dataTypeSemantics="identifier"
            fieldType="17" name="mplsLabelStackEntry1" dataType="unsigned32"
            fieldId="70" applicability="all" 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>



Meyer, et al.            Expires January 17, April 25, 2005                [Page 46] 50]

Internet-Draft          IPFIX Information Model                July             October 2004


       <description>


         <paragraph>
         The autonomous system (AS) number of the destination address
         in the IP packet header in a packet of this flow. to be replaced by ASCII drawing </paragraph>
         <paragraph> to be replaced by ASCII drawing </paragraph>
         <paragraph> to be replaced by ASCII drawing </paragraph>
         <paragraph> to be replaced by ASCII drawing </paragraph>
         <paragraph> to be replaced by ASCII drawing </paragraph>
       </description>
       <reference>
         See RFC 1771 for a description of BGB-4 and
         see RFC 1930 a definition of the AS number. 3032.
       </reference>
     </field>

     <field name="bgpNextHopAddressV4" dataType="ipv4Address"
            fieldType="18" name="mplsLabelStackEntry2" dataType="unsigned32"
            fieldId="71" applicability="all" status="current">
       <description>
         <paragraph>
         The IPv4 address of label, exp and s fields from the next BGP hop to which packets LSE that was pushed
         immediately before the LSE that would be reported by
         mplsLabelStackEntry1. See the definition of
         this flow are forwarded. mplsLabelStackEntry1 for
         further details.
         </paragraph>
       </description>
       <reference>
         See RFC 1771 for a description of BGB-4 and
         see RFC 1930 a definition of the AS number. 3032.
       </reference>
     </field>

     <field name="OutMulticastPacketCount" dataType="unsigned64"
            fieldType="19" applicability="data" name="mplsLabelStackEntry3" dataType="unsigned32"
            fieldId="72" applicability="all" status="current">
       <description>
         <paragraph>
         The number of outgoing multicast packets created for packets
         of this flow by an adjacent multicast daemon.
         Note label, exp and s fields from the LSE that typically not all of was pushed
         immediately before the created packets can LSE that would be
         observed at reported by
         mplsLabelStackEntry2. See the observation point definition of this flow. mplsLabelStackEntry1 for
         further details.
         </paragraph>
       </description>
       <units>packets</units>
       <reference>
         See RFC 3032.
       </reference>
     </field>

     <field name="OutMulticastOctetCount" dataType="unsigned64"
            fieldType="20" applicability="data" name="mplsLabelStackEntry4" dataType="unsigned32"
            fieldId="73" applicability="all" status="current">
       <description>
         <paragraph>
         The number of octets in outgoing multicast packets created
         for packets of this flow by an adjacent multicast daemon.
         Note label, exp and s fields from the LSE that typically not all of was pushed
         immediately before the created packets can LSE that would be
         observed at reported by
         mplsLabelStackEntry3. See the observation point definition of this flow.
         </paragraph> mplsLabelStackEntry1 for



Meyer, et al.            Expires January 17, April 25, 2005                [Page 47] 51]

Internet-Draft          IPFIX Information Model                July             October 2004


         further details.
         </paragraph>
       </description>
       <units>octets</units>
     </field>

     <field name="flowEndTime" dataType="dateTimeSeconds"
            fieldType="21" applicability="data" status="current">
       <description>
         The timestamp of the last packet of this flow.
       </description>
     </field>

     <field name="flowCreationTime" dataType="dateTimeSeconds"
            fieldType="22" applicability="data" status="current">
       <description>
         The timestamp of the first packet of this flow.
       </description>
       <reference>
         See RFC 3032.
       </reference>
     </field>

     <field name="deltaOutOctetCount" dataType="unsigned64"
            dataTypeSemantics="deltaCounter"
            fieldType="23" applicability="data" name="mplsLabelStackEntry5" dataType="unsigned32"
            fieldId="74" applicability="all" status="current">
       <description>
         <paragraph>
         The number of octets in outgoing packets observed for this
         flow at label, exp and s fields from the observation point since LSE that was pushed
         immediately before the previous report (if any).
         The number LSE that would be reported by
         mplsLabelStackEntry4. See the definition of octets include IP header(s) and IP payload. mplsLabelStackEntry1 for
         further details.
         </paragraph>
       </description>
       <units>octets</units>
       <reference>
         See RFC 3032.
       </reference>
     </field>

     <field name="deltaOutPacketCount" dataType="unsigned64"
            dataTypeSemantics="deltaCounter"
            fieldType="24" applicability="data" name="mplsLabelStackEntry6" dataType="unsigned32"
            fieldId="75" applicability="all" status="current">
       <description>
         <paragraph>
         The number of outgoing packets observed for this flow at label, exp and s fields from the observation point since LSE that was pushed
         immediately before the previous report (if any). LSE that would be reported by
         mplsLabelStackEntry5. See the definition of mplsLabelStackEntry1 for
         further details.
         </paragraph>
       </description>
       <units>packets</units>
       <reference>
         See RFC 3032.
       </reference>
     </field>

     <field name="minPacketLength" dataType="unsigned16"
            fieldType="25" name="mplsLabelStackEntry7" dataType="unsigned32"
            fieldId="76" applicability="all" status="current">
       <description>
         <paragraph>
         Length of
         The label, exp and s fields from the LSE that was pushed
         immediately before the smallest packet observed LSE that would be reported by
         mplsLabelStackEntry6. See the definition of mplsLabelStackEntry1 for this flow.
         further details.
         </paragraph>
       </description>



Meyer, et al.            Expires January 17, April 25, 2005                [Page 48] 52]

Internet-Draft          IPFIX Information Model                July             October 2004


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


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

     <field name="maxPacketLength" dataType="unsigned16"
            fieldType="26" name="mplsLabelStackEntry8" dataType="unsigned32"
            fieldId="77" applicability="all" status="current">
       <description>
         <paragraph>
         Length of
         The label, exp and s fields from the largest packet observed LSE that was pushed
         immediately before the LSE that would be reported by
         mplsLabelStackEntry7. See the definition of mplsLabelStackEntry1 for this flow.
         further details.
         </paragraph>
       </description>
       <units>octets</units>
       <reference>
         See RFC 3032.
       </reference>
     </field>

     <field name="sourceAddressV6" dataType="ipv6Address"
            fieldType="27" name="mplsLabelStackEntry9" dataType="unsigned32"
            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 LSE that was pushed
         immediately before the LSE 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="destinationAddressV6" dataType="ipv6Address"
            fieldType="28" name="mplsLabelStackEntry10" dataType="unsigned32"
            fieldId="79" applicability="all" status="current">
       <description>
         <paragraph>
         IPv6 destination address taken
         The label, exp and s fields from the IP packet header of a
         packet of this flow.
         </paragraph>
       </description>
     </field>

     <field name="sourceMaskV6" dataType="octet"
            fieldType="29" applicability="option" status="current">
       <description>
         <paragraph>
         The number of contiguous bits LSE that are relevant in was pushed
         immediately before the
         sourceAddressV6 field. LSE that would be reported by
         mplsLabelStackEntry9. See the definition of mplsLabelStackEntry1 for
         further details.
         </paragraph>
       </description>
       <units>bits</units>
       <range>0-128</range>
     </field>

     <field name="destinationMaskV6" dataType="octet"
       <reference>
         See RFC 3032.
       </reference>



Meyer, et al.            Expires January 17, April 25, 2005                [Page 49] 53]

Internet-Draft          IPFIX Information Model                July             October 2004


            fieldType="30" applicability="option"


     </field>

     <field name="ipNextHopIPv4Address" dataType="ipv4Address"
            fieldId="15" applicability="data" status="current">
       <description>
         <paragraph>
         The number IPv4 address of contiguous bits that are relevant in the
         destinationAddressV6 field. next IP hop to which packets of
         this flow are forwarded.
         </paragraph>
       </description>
       <units>bits</units>
       <range>0-128</range>
     </field>

     <field name="flowLabelV6" dataType="unsigned32"
            fieldType="31" applicability="all" name="ipNextHopIPv6Address" dataType="ipv6Address"
            fieldId="62" applicability="data" status="current">
       <description>
         <paragraph>
         The Flow Label of the IPv6 packet header observed in a packet
         of this flow.
         </paragraph>
       </description>
       <reference>
         See RFC 2460 for a definition address of the next BGP hop to which packets of
         this flow label field in the
         IPv6 packet header.
       </reference> are forwarded.
         </paragraph>
       </description>
     </field>

     <field name="icmpTypeCode" dataType="unsigned16"
            fieldType="32" name="ingressInterface" dataType="unsigned32"
            dataTypeSemantics="identifier"
            fieldId="10" applicability="all" status="current">
       <description>
         <paragraph>
         Type and Code
         The index of the ICMP message. The combination IP interface (ifIndex) where packets of both values
         is reported as (ICMP type * 256) + ICMP code.
         this flow are being received.
         </paragraph>
       </description>
       <reference>
         See RFC 792 2863 for a the definition of the ICMP type and code fields. ifIndex object.
       </reference>
     </field>

     <field name="igmpType" dataType="octet"
            fieldType="33" name="egressInterface" dataType="unsigned32"
            dataTypeSemantics="identifier"
            fieldId="14" applicability="all" status="current">
       <description>
         <paragraph>
         The type field index of the IGMP message. IP interface (ifIndex) where packets of this
         flow are being sent.
         </paragraph>
       </description>
       <reference>
         See RFC 2236 2863 for a the definition of the IGMP type field. ifIndex object.
       </reference>
     </field>



Meyer, et al.            Expires January 17, April 25, 2005                [Page 50] 54]

Internet-Draft          IPFIX Information Model                July             October 2004


     </field>

     <field name="flowActiveTimeOut" name="ipNextHopAsNumber" dataType="unsigned16"
            fieldType="36"
            dataTypeSemantics="identifier"
            fieldId="129" applicability="all" status="current">
       <description>
         <paragraph>
         The autonomous system (AS) number of seconds after the next IP hop to
         which an active flow is timed out
         anyway, even if there is still a continuous flow packets of packets. this flow are forwarded.
         </paragraph>
       </description>
       <units>seconds</units>
       <reference>
         See RFC 1771 for a description of BGB-4 and
         see RFC 1930 a definition of the AS number.
       </reference>
     </field>

     <field name="flowInactiveTimeout" name="bgpSourceAsNumber" dataType="unsigned16"
            fieldType="37"
            dataTypeSemantics="identifier"
            fieldId="16" applicability="all" status="current">
       <description>
         <paragraph>
          A flow is considered to be timed out if not packet belonging
          to
         The autonomous system (AS) number of the flow has been observed for source address in
         the number IP packet header in a packet of seconds
          specified by this field. flow.
         </paragraph>
       </description>
       <units>seconds</units>
     </field>

     <field name="exportedOctetCount" dataType="unsigned64"
            fieldType="40" applicability="data" status="current">
       <description>
         <paragraph>
         The number
       <reference>
         See RFC 1771 for a description of BGB-4 and
         see RFC 1930 a definition of all octets reported by the exporting process
         to this collecting process.
         </paragraph>
       </description>
       <units>octets</units> AS number.
       </reference>
     </field>

     <field name="exportedPacketCount" dataType="unsigned64"
            fieldType="41" applicability="data" name="bgpDestinationAsNumber" dataType="unsigned16"
            dataTypeSemantics="identifier"
            fieldId="17" applicability="all" status="current">
       <description>
         <paragraph>
         The autonomous system (AS) number of all packets reported by the exporting process
         to destination address
         in the IP packet header in a packet of this collecting process. flow.
         </paragraph>
       </description>
       <units>packets</units>
       <reference>
         See RFC 1771 for a description of BGB-4 and
         see RFC 1930 a definition of the AS number.
       </reference>
     </field>

     <field name="exportedFlowCount" dataType="unsigned64"
            fieldType="42" applicability="data" status="current">
       <description> name="bgpNextHopAsNumber" dataType="unsigned16"



Meyer, et al.            Expires January 17, April 25, 2005                [Page 51] 55]

Internet-Draft          IPFIX Information Model                July             October 2004


            dataTypeSemantics="identifier"
            fieldId="128" applicability="all" status="current">
       <description>
         <paragraph>
         The autonomous system (AS) number of all flows records reported by the exporting
         process next BGP hop to
         which packets of this collecting process. flow are forwarded.
         </paragraph>
       </description>
       <units>flows</units>
       <reference>
         See RFC 1771 for a description of BGB-4 and
         see RFC 1930 a definition of the AS number.
       </reference>
     </field>

     <field name="sourcePrefixV4" dataType="ipV4Address"
            fieldType="44" applicability="data" name="bgpNextHopIPv4Address" dataType="ipv4Address"
            fieldId="18" applicability="all" status="current">
       <description>
         <paragraph>
         The IPv4 source address prefix. </paragraph>
         <paragraph>
         EDITOR'S NOTE: of the next BGP hop to be discussed on ipfix mailing list which packets of
         this flow are forwarded.
         </paragraph>
       </description>
       <units>flows</units>
       <reference>
         See RFC 1771 for a description of BGB-4 and
         see RFC 1930 a definition of the AS number.
       </reference>
     </field>

     <field name="destinationPrefixV4" dataType="ipV4Address"
            fieldType="45" applicability="data" name="bgpNextHopIPv6Address" dataType="ipv6Address"
            dataTypeSemantics="identifier"
            fieldId="63" applicability="all" status="current">
       <description>
         <paragraph> IPv4 destination
         The IPv6 address prefix. </paragraph>
         <paragraph>
         EDITOR'S NOTE: of the next BGP hop to be discussed on ipfix mailing list which packets of
         this flow are forwarded.
         </paragraph>
       </description>
       <units>flows</units>
       <reference>
         See RFC 1771 for a description of BGB-4.
         See RFC 1930 a definition of the AS number.
       </reference>
     </field>

     <field name="mplsTopLabelType" dataType="octet"
            dataTypeSemantics="identifier"
            fieldType="46"
            fieldId="46" applicability="data" status="current">
       <description>
         <paragraph>



Meyer, et al.            Expires April 25, 2005                [Page 56]

Internet-Draft          IPFIX Information Model             October 2004


         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>



Meyer, et al.           Expires January 17, 2005               [Page 52]

Internet-Draft          IPFIX Information Model                July 2004
     </field>

     <field name="mplsTopLabelIPAddressV4" name="mplsTopLabelIPv4Address" dataType="ipV4Address"
            fieldType="47"
            fieldId="47" applicability="data" status="current">
       <description>
         <paragraph>
           The IPv4 address of the system that the MPLS top label will
           cause this packet to be forwarded to.
         </paragraph>
       </description>
     </field>

     <field name="minimumTTL" dataType="octet"
            fieldType="52" applicability="data" status="current">
       <description>
         <paragraph>
           Minimum TTL value observed for any packet in this flow.
         </paragraph>
       </description>
     </field>

     <field name="maximumTTL" dataType="octet"
            fieldType="53" name="mplsTopLabelIPv6Address" dataType="ipV4Address"
            fieldId="140" applicability="data" status="current">
       <description>
         <paragraph>
           Maximum TTL value observed for any packet in
           The IPv4 address of the system that the MPLS top label will
           cause this flow. packet to be forwarded to.
         </paragraph>
       </description>
     </field>

     <field name="identificationV4" dataType="octet" name="exporterIPv4Address" dataType="ipv4Address"
            dataTypeSemantics="identifier"
            fieldType="54" applicability="data"
            fieldId="130" applicability="all" status="current">
       <description>
         <paragraph>
           Packet identification field from the first IP packet
         The IPv4 address of this flow.
         </paragraph>
       </description>
       <reference>
         See RFC 791 for the definition used by the exporting process.
         This is used by the collector to identify the exporter
         in cases where the identity of the IPv4 identification field.
       </reference>
     </field>

     <field name="sourceMacAddress" dataType="octet"
            fieldType="56" applicability="data" status="current">
       <description>
         <paragraph>
           Packet identification field from exporter may have been
         obscured by the first IP packet use of this flow. a proxy.
         </paragraph>
       </description>
     </field>




Meyer, et al.            Expires January 17, April 25, 2005                [Page 53] 57]

Internet-Draft          IPFIX Information Model                July             October 2004


         </paragraph>
       </description>
       <reference>
         See RFC 791 for the definition of the IPv4 identification field.
       </reference>
     </field>


     <field name="ipVersion" dataType="octet"
            fieldType="60" name="exporterIPv4Address" dataType="ipv6Address"
            dataTypeSemantics="identifier"
            fieldId="131" applicability="all" status="current">
       <description>
         The IP version field given in the IP header.
       </description>
       <units>flows</units>
       <reference>
         <paragraph>
         See RFC 791 for a definition
         The IPv6 address of the version field used by the exporting process.
         This is used by the collector to identify the exporter
         in cases where the
         IPv6 packet header.
         See RFC 2460 for a definition identity of the version field in exporter may have been
         obscured by the
         IPv6 packet header.
         Additional information on defined version numbers
         can be found at
         http://www.iana.org/assignments/version-numbers. use of a proxy.
         </paragraph>
       </reference>
       </description>
     </field>

     <field name="ipNextHopAddressV6" dataType="ipv6Address"
            fieldType="62" applicability="data" name="minPacketLength" dataType="unsigned16"
            fieldId="25" applicability="all" status="current">
       <description>
         <paragraph>
         The IPv6 address
         Length of the next BGP hop to which packets of smallest packet observed for this flow are forwarded. flow.
         </paragraph>
       </description>
       <units>octets</units>
     </field>

     <field name="bgpNextHopAddressV6" dataType="ipv6Address"
            dataTypeSemantics="identifier"
            fieldType="63" name="maxPacketLength" dataType="unsigned16"
            fieldId="26" applicability="all" status="current">
       <description>
         <paragraph>
         The IPv6 address
         Length of the next BGP hop to which packets of largest packet observed for this flow are forwarded. flow.
         </paragraph>
       </description>
       <units>octets</units>
     </field>

     <field name="minimumTTL" dataType="octet"
            fieldId="52" applicability="data" status="current">
       <description>
         <paragraph>
           Minimum TTL value observed for any packet in this flow.
         </paragraph>
       </description>
       <reference>
         See RFC 1771
     </field>

     <field name="maximumTTL" dataType="octet"
            fieldId="53" applicability="data" status="current">
       <description>
         <paragraph>
           Maximum TTL value observed for a description of BGB-4.
         See RFC 1930 a definition of the AS number. any packet in this flow.
         </paragraph>



Meyer, et al.            Expires January 17, April 25, 2005                [Page 54] 58]

Internet-Draft          IPFIX Information Model                July             October 2004


       </reference>


       </description>
     </field>

     <field name="ipv6OptionHeaders" dataType="unsigned32"
            dataTypeSemantics="flags"
            fieldType="64"
            fieldId="64" applicability="all" status="current">
       <description>
         <paragraph>
         IPv6 options in the IP packet headers of this flow.
         This is encoded as a bit field.
         </paragraph>
         <paragraph> to be replaced by ASCII drawing </paragraph>
         <paragraph> to be replaced by ASCII drawing </paragraph>
         <paragraph> to be replaced by ASCII drawing </paragraph>
         <paragraph> to be replaced by ASCII drawing </paragraph>
         <paragraph> to be replaced by ASCII drawing </paragraph>
         <paragraph> to be replaced by ASCII drawing </paragraph>
         <paragraph> to be replaced by ASCII drawing </paragraph>
         <paragraph> to be replaced by ASCII drawing </paragraph>
         <paragraph> to be replaced by ASCII drawing </paragraph>
         <paragraph> to be replaced by ASCII drawing </paragraph>
         <paragraph> to be replaced by ASCII drawing </paragraph>
       </description>
       <reference>
         To be done.
       </reference>
     </field>

     <field name="partialMPLSLabelStackEntry1" dataType="unsigned32"
            fieldType="70" applicability="all" 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>
         <paragraph> to be replaced by ASCII drawing </paragraph>
         <paragraph> to be replaced by ASCII drawing </paragraph>
         <paragraph> to be replaced by ASCII drawing </paragraph>
         <paragraph> to be replaced by ASCII drawing </paragraph>
         <paragraph> to be replaced by ASCII drawing </paragraph>
       </description>
       <reference>
         See RFC 3032.
       </reference>
     </field>

     <field name="partialMPLSLabelStackEntry2" dataType="unsigned32"
            fieldType="71" name="tcpControlBits" dataType="octet"
            dataTypeSemantics="flags"
            fieldId="6" applicability="all" status="current">



Meyer, et al.           Expires January 17, 2005               [Page 55]

Internet-Draft          IPFIX Information Model                July 2004
       <description>
         <paragraph>
         The label, exp and s fields from the LSE that was pushed
         immediately before the LSE that would be reported by
         partialMplsLse1. See the definition of partialMplsLse1
         TCP control bits observed for
         further details.
         </paragraph>
       </description>
       <reference>
         See RFC 3032.
       </reference>
     </field>

     <field name="partialMPLSLabelStackEntry3" dataType="unsigned32"
            fieldType="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
         partialMplsLse2. See the definition packets of partialMplsLse1 for
         further details.
         </paragraph>
       </description>
       <reference>
         See RFC 3032.
       </reference>
     </field>

     <field name="partialMPLSLabelStackEntry4" dataType="unsigned32"
            fieldType="73" applicability="all" status="current">
       <description>
         <paragraph> this flow.
         The label, exp and s fields from the LSE that was pushed
         immediately before value of this field is the LSE that would be reported by
         partialMplsLse3. See result of a logical OR operation
         over the definition flags observed in all packets of partialMplsLse1 for
         further details.
         </paragraph>
       </description>
       <reference>
         See RFC 3032.
       </reference>
     </field>

     <field name="partialMPLSLabelStackEntry5" dataType="unsigned32"
            fieldType="74" applicability="all" status="current">
       <description>
         <paragraph>
         The label, exp and s fields from the LSE flow.
         This implies that a 0 value for a bit indicates that the
         respective bit was pushed not set in any of the observed packets
         of this flow.</paragraph>

         <paragraph>to be replaced by ASCII drawing</paragraph>
         <paragraph>to be replaced by ASCII drawing</paragraph>
         <paragraph>to be replaced by ASCII drawing</paragraph>
         <paragraph>to be replaced by ASCII drawing</paragraph>
         <paragraph>to be replaced by ASCII drawing</paragraph>
         <paragraph>to be replaced by ASCII drawing</paragraph>
         <paragraph>to be replaced by ASCII drawing</paragraph>
         <paragraph>to be replaced by ASCII drawing</paragraph>



Meyer, et al.            Expires January 17, April 25, 2005                [Page 56] 59]

Internet-Draft          IPFIX Information Model                July             October 2004


         immediately before


       </description>
       <reference>See RFC 793 for a definition of the LSE that would be reported by
         partialMplsLse4. See TCP control bits
       in the definition TCP header.</reference>
     </field>

     <field name="flowCreationTime" dataType="dateTimeSeconds"
            fieldId="22" applicability="data" status="current">
       <description>
         The timestamp of partialMplsLse1 for
         further details.
         </paragraph> the first packet of this flow.
       </description>
       <reference>
         See RFC 3032.
       </reference>
     </field>

     <field name="partialMPLSLabelStackEntry6" dataType="unsigned32"
            fieldType="75" name="flowEndTime" dataType="dateTimeSeconds"
            fieldId="21" applicability="data" status="current">
       <description>
         The timestamp of the last packet of this flow.
       </description>
     </field>

     <field name="flowActiveTimeOut" dataType="unsigned16"
            fieldId="36" 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
         partialMplsLse5. See the definition number of partialMplsLse1 for
         further details. seconds after which an active flow is timed out
         anyway, even if there is still a continuous flow of packets.
         </paragraph>
       </description>
       <reference>
         See RFC 3032.
       </reference>
       <units>seconds</units>
     </field>

     <field name="partialMPLSLabelStackEntry7" dataType="unsigned32"
            fieldType="76" name="flowInactiveTimeout" dataType="unsigned16"
            fieldId="37" applicability="all" status="current">
       <description>
         <paragraph>
         The label, exp and s fields from the LSE that was pushed
         immediately before the LSE that would
          A flow is considered to be reported by
         partialMplsLse6. See timed out if not packet belonging
          to the definition of partialMplsLse1 flow has been observed for
         further details. the number of seconds
          specified by this field.
         </paragraph>
       </description>
       <reference>
         See RFC 3032.
       </reference>
       <units>seconds</units>
     </field>

     <field name="partialMPLSLabelStackEntry8" dataType="unsigned32"
            fieldType="77" applicability="all" name="flowEndReason" dataType="octet"
            fieldId="136" 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
         partialMplsLse7. See the definition of partialMplsLse1 reason for
         further details. flow termination.
         <list>



Meyer, et al.            Expires January 17, April 25, 2005                [Page 57] 60]

Internet-Draft          IPFIX Information Model                July             October 2004


           <item>idle timeout</item>
           <item>end of flow detected (e.g. TCP FIN)</item>
           <item>forced end</item>
           <item>cache full</item>
         </list>
         EDITORS' NOTE: This needs to be defined as an
         enumerated range.
         </paragraph>
       </description>
       <reference>
         See RFC 3032.
       </reference>
     </field>

     <field name="partialMPLSLabelStackEntry9" dataType="unsigned32"
            fieldType="78" applicability="all" name="inOctetDeltaCount" dataType="unsigned64"
            dataTypeSemantics="deltaCounter"
            fieldId="1" applicability="data" status="current">
       <description>
         <paragraph>
         The label, exp and s fields from the LSE that was pushed
         immediately before number of octets in incoming packets observed for this
         flow at the LSE that would be reported by
         partialMplsLse8. See observation point since the definition previous report (if any).
         The number of partialMplsLse1 for
         further details. octets include IP header(s) and IP payload.
         </paragraph>
       </description>
       <reference>
         See RFC 3032.
       </reference>
       <units>octets</units>
     </field>

     <field name="partialMPLSLabelStackEntry10" dataType="unsigned32"
            fieldType="79" applicability="all" name="outOctetDeltaCount" dataType="unsigned64"
            dataTypeSemantics="deltaCounter"
            fieldId="23" applicability="data" status="current">
       <description>
         <paragraph>
         The label, exp and s fields from the LSE that was pushed
         immediately before number of octets in outgoing packets observed for this
         flow at the LSE that would be reported by
         partialMplsLse9. See observation point since the definition previous report (if any).
         The number of partialMplsLse1 for
         further details. octets include IP header(s) and IP payload.
         </paragraph>
       </description>
       <reference>
         See RFC 3032.
       </reference>
       <units>octets</units>
     </field>

     <field name="runningOctetCounter" name="octetDeltaCount" dataType="unsigned64"
            dataTypeSemantics="runningCounter"
            fieldType="85" applicability="all"
            dataTypeSemantics="deltaCounter"
            fieldId="138" applicability="data" status="current">
       <description>
         <paragraph>
         Number
         The number of observed octets in all packets observed for a pre-defined permanent flow.
         </paragraph>
         <paragraph>
         EDITOR'S NOTE: clarification required. this
         flow at the observation point since the previous report (if any).
         The number of octets include IP header(s) and IP payload.
         </paragraph>
       </description>
       <units>octets</units>



Meyer, et al.            Expires January 17, April 25, 2005                [Page 58] 61]

Internet-Draft          IPFIX Information Model                July             October 2004


       <units>octets</units>


     </field>

     <field name="runningPacketCounter" name="octetTotalCount" dataType="unsigned64"
            dataTypeSemantics="runningCounter"
            fieldType="86"
            fieldId="85" applicability="all" status="current">
       <description>
         <paragraph>
         Number of observed packets octets for a pre-defined permanent flow.
         </paragraph>
         <paragraph>
         EDITOR'S NOTE: clarification required.
         </paragraph>
       </description>
       <units>packets</units>
       <units>octets</units>
     </field>

     <field name="bgpNextHopAsNumber" dataType="unsigned16"
            dataTypeSemantics="identifier"
            fieldType="128" applicability="all" name="inPacketDeltaCount" dataType="unsigned64"
            dataTypeSemantics="deltaCounter"
            fieldId="2" applicability="data" status="current">
       <description>
         <paragraph>
         The autonomous system (AS) number of the next BGP hop to
         which incoming packets of observed for this flow are forwarded. at
         the observation point since the previous report (if any).
         </paragraph>
       </description>
       <reference>
         See RFC 1771 for a description of BGB-4 and
         see RFC 1930 a definition of the AS number.
       </reference>
       <units>packets</units>
     </field>

     <field name="ipNextHopAsNumber" dataType="unsigned16"
            dataTypeSemantics="identifier"
            fieldType="129" applicability="all" name="outPacketDeltaCount" dataType="unsigned64"
            dataTypeSemantics="deltaCounter"
            fieldId="24" applicability="data" status="current">
       <description>
         <paragraph>
         The autonomous system (AS) number of the next IP hop to
         which outgoing packets of observed for this flow are forwarded. at
         the observation point since the previous report (if any).
         </paragraph>
       </description>
       <reference>
         See RFC 1771 for a description of BGB-4 and
         see RFC 1930 a definition of the AS number.
       </reference>
       <units>packets</units>
     </field>

     <field name="exporterAddressV4" dataType="ipv4Address" name="packetDeltaCount" dataType="unsigned64"
            dataTypeSemantics="deltaCounter"
            fieldId="139" applicability="data" status="current">
       <description>
         <paragraph>
         The number of all packets observed for this flow at
         the observation point since the previous report (if any).
         </paragraph>



Meyer, et al.            Expires January 17, April 25, 2005                [Page 59] 62]

Internet-Draft          IPFIX Information Model                July             October 2004


            dataTypeSemantics="identifier"
            fieldType="130"


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

     <field name="packetTotalCount" dataType="unsigned64"
            dataTypeSemantics="runningCounter"
            fieldId="86" applicability="all" status="current">
       <description>
         <paragraph>
         The IPv4 address of the 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
         Number of observed packets for a proxy. pre-defined permanent flow.
         </paragraph>
         <paragraph>
         EDITOR'S NOTE: clarification required.
         </paragraph>
       </description>
       <units>packets</units>
     </field>

     <field name="exporterAddressV6" dataType="ipv6Address"
            dataTypeSemantics="identifier"
            fieldType="131" applicability="all" name="droppedOctetDeltaCount" dataType="unsigned64"
            dataTypeSemantics="deltaCounter"
            fieldId="132" applicability="data" status="current">
       <description>
         <paragraph>
         The IPv6 address of the used by the exporting process.
         This is used by the collector to identify the exporter
         in cases where the identity number of the exporter may have been
         obscured by the use octets in packets of a proxy. this flow dropped by packet treatment.
         </paragraph>
       </description>
       <units>octets</units>
     </field>

     <field name="droppedOctetDeltaCount" name="droppedOctetTotalCount" dataType="unsigned64"
            dataTypeSemantics="deltaCounter"
            fieldType="132"
            dataTypeSemantics="runningCounter"
            fieldId="133" applicability="data" status="current">
       <description>
         <paragraph>
         The number of octets in packets of this flow dropped by packet treatment.
         </paragraph>
       </description>
       <units>octets</units>
     </field>

     <field name="droppedPacketDeltaCount" dataType="unsigned64"
            dataTypeSemantics="deltaCounter"
            fieldType="133"
            fieldId="134" applicability="data" status="current">
       <description>
         <paragraph>
         The number of packets of this flow dropped by packet treatment.
         </paragraph>
       </description>
       <units>packets</units>
     </field>

     <field name="droppedOctetTotalCount" dataType="unsigned64"



Meyer, et al.            Expires January 17, April 25, 2005                [Page 60] 63]

Internet-Draft          IPFIX Information Model                July             October 2004


       <units>packets</units>
     </field>

     <field name="droppedPacketTotalCount" dataType="unsigned64"
            dataTypeSemantics="runningCounter"
            fieldType="134"
            fieldId="135" applicability="data" status="current">
       <description>
         <paragraph>
         The number of octets in packets of this flow dropped by packet treatment.
         </paragraph>
       </description>
       <units>octets</units>
       <units>packets</units>
     </field>

     <field name="droppedPacketTotalCount" name="outMulticastPacketCount" dataType="unsigned64"
            dataTypeSemantics="runningCounter"
            fieldType="135"
            fieldId="19" applicability="data" status="current">
       <description>
         <paragraph>
         The number of outgoing multicast packets created for packets
         of this flow dropped by packet treatment. an adjacent multicast daemon.
         Note that typically not all of the created packets can be
         observed at the observation point of this flow.
         </paragraph>
       </description>
       <units>packets</units>
     </field>

     <field name="flowEndReason" dataType="octet"
            fieldType="136" name="outMulticastOctetCount" dataType="unsigned64"
            fieldId="20" applicability="data" status="current">
       <description>
         <paragraph>
         The reason number of octets in outgoing multicast packets created
         for flow termination.
         <list>
           <item>idle timeout</item>
           <item>end packets of this flow detected (e.g. TCP FIN)</item>
           <item>forced end</item>
           <item>cache full</item>
         </list>
         EDITORS' NOTE: This needs to be defined as by an
         enumerated range. adjacent multicast daemon.
         Note that typically not all of the created packets can be
         observed at the observation point of this flow.
         </paragraph>
       </description>
       <units>octets</units>
     </field>

     <field name="classOfServiceV6" dataType="octet"
            fieldType="135" name="observedFlowTotalCount" dataType="unsigned64"
            dataTypeSemantics="runningCounter"
            fieldId="3" applicability="data" status="current">
       <description>
         <paragraph>
         The value number of the IPv6 traffic class field flows observed
         for packets of this flow. so far in the observation domain.
         </paragraph>
       </description>
       <reference>
         See RFC 2460 for the definition of the IPv6 traffic class field.



Meyer, et al.            Expires January 17, April 25, 2005                [Page 61] 64]

Internet-Draft          IPFIX Information Model                July             October 2004


       </reference>


       <units>flows</units>
     </field>

     <field name="exportedOctetTotalCount" dataType="unsigned64"
            dataTypeSemantics="runningCounter"
            fieldId="40" applicability="data" status="current">
       <description>
         <paragraph>
         The number of all octets reported by the exporting process
         to this collecting process.
         </paragraph>
       </description>
       <units>octets</units>
     </field>

     <field name="exportedPacketTotalCount" dataType="unsigned64"
            dataTypeSemantics="runningCounter"
            fieldId="41" applicability="data" status="current">
       <description>
         <paragraph>
         The number of all packets reported by the exporting process
         to this collecting process.
         </paragraph>
       </description>
       <units>packets</units>
     </field>

     <field name="exportedFlowTotalCount" dataType="unsigned64"
            fieldId="42" applicability="data" status="current">
       <description>
         <paragraph>
         The number of all flows records reported by the exporting
         process to this collecting process.
         </paragraph>
       </description>
       <units>flows</units>
     </field>

   </fieldDefinitions>












Meyer, et al.            Expires January 17, April 25, 2005                [Page 62] 65]

Internet-Draft          IPFIX Information Model                July             October 2004


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 and a formal description of the
   template used for defining IPFIX fields.  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 elementFormDefault="qualified"
           targetNamespace="http://www.ietf.org/ipfix"
           xmlns:ipfix="http://www.ietf.org/ipfix">

     <simpleType name="dataType">
       <restriction base="string">
         <enumeration value="octet">
           <annotation>
             <documentation>The type "unsignedByte" "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.
             </documentation>
           </annotation>



Meyer, et al.            Expires January 17, April 25, 2005                [Page 63] 66]

Internet-Draft          IPFIX Information Model                July             October 2004


         </enumeration>

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

         <enumeration value="boolean">
           <annotation>
             <documentation>The type "boolean" represents a binary
               value.
             </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.  Unicode allows for ASCII 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
               characters, but also accomodates other Unicode
               multibyte characters.
             </documentation>
           </annotation>
         </enumeration>

         <enumeration value="dateTimeSeconds">
           <annotation>
             <documentation>
               The type "dateTimeSeconds" represents a time value
               having a precision of seconds and normalized to the
               GMT timezone.  Such types are in common use on many
               operating systems and have the advantage that they



Meyer, et al.            Expires January 17, April 25, 2005                [Page 64] 67]

Internet-Draft          IPFIX Information Model                July             October 2004


               can be stored in 32-bit integers.
             </documentation>
           </annotation>
         </enumeration>

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

         <enumeration value="ipv4Address">
           <annotation>
             <documentation>The type "ipv4Addr" represents a value of
               an IPv4 address. These addresses are typically stored
               as 32-bit integers.
             </documentation>
           </annotation>
         </enumeration>

         <enumeration value="ipv6Address">
           <annotation>
             <documentation>The type "ipv6Addr" 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 integral fields should behave as a quantity.
             </documentation>
           </annotation>
         </enumeration>




Meyer, et al.            Expires January 17, April 25, 2005                [Page 65] 68]

Internet-Draft          IPFIX Information Model                July             October 2004


         <enumeration value="counter"> value="runningCounter">
           <annotation>
             <documentation>
               A measurement which is ongoing from the perspective
               of the exporter.  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 of the export
               of its value.
             </documentation>
           </annotation>
         </enumeration>

         <enumeration value="deltaCounter">
           <annotation>
             <documentation>
               A measurement which is ongoing from the perspective
               of the exporter.  Basically the same semantics as
               counters in SNMP.  Counters are unsigned and wrap back
               to zero after reaching the limit of the type. E.g. 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. E.g. For example, Autonomous System Id 1 * Autonomous
               System Id 2 is meaningless.
             </documentation>
           </annotation>
         </enumeration>

         <enumeration value="flags">
           <annotation>



Meyer, et al.            Expires April 25, 2005                [Page 69]

Internet-Draft          IPFIX Information Model             October 2004


             <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 that are applicable to flow records
               only.
             </documentation>



Meyer, et al.           Expires January 17, 2005               [Page 66]

Internet-Draft          IPFIX Information Model                July 2004
           </annotation>
         </enumeration>

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

         <enumeration value="all">
           <annotation>
             <documentation>
               Used for fields 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>
             <documentation>
               Indicates that the field definition is that the



Meyer, et al.            Expires April 25, 2005                [Page 70]

Internet-Draft          IPFIX Information Model             October 2004


               definition is current and valid.
             </documentation>
           </annotation>
         </enumeration>

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



Meyer, et al.           Expires January 17, 2005               [Page 67]

Internet-Draft          IPFIX Information Model                July 2004
               Indicates that the field definition is obsolete and
               should not be implemented and/or can be removed if
               previously implemented.
             </documentation>
           </annotation>
         </enumeration>
       </restriction>
     </simpleType>

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

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

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

     <complexType name="text" mixed="true">



Meyer, et al.            Expires April 25, 2005                [Page 71]

Internet-Draft          IPFIX Information Model             October 2004


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



Meyer, et al.           Expires January 17, 2005               [Page 68]

Internet-Draft          IPFIX Information Model                July 2004
           <element maxOccurs="unbounded" minOccurs="1" name="field">
             <complexType>
               <sequence>
                 <element maxOccurs="1" minOccurs="1" name="description"
                          type="ipfix:text">
                   <annotation>
                     <documentation>
                       The semantics of this information element.
                       Describes how this field 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 is a measure of some kind, the
                       units identify what the measure is.
                     </documentation>



Meyer, et al.            Expires April 25, 2005                [Page 72]

Internet-Draft          IPFIX Information Model             October 2004


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



Meyer, et al.           Expires January 17, 2005               [Page 69]

Internet-Draft          IPFIX Information Model                July 2004
                       identifiers associated with a set of discrete
                       values this 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 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 field. information element.
                     The preferred spelling for the name is to use mixed
                     case if the name is compound, with an initial
                     lower case letter. (E.g. "sourceIpAddress"). letter, e.g., "sourceIpAddress".



Meyer, et al.            Expires April 25, 2005                [Page 73]

Internet-Draft          IPFIX Information Model             October 2004


                   </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 extension of the "Type Space"
                     section. 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) which are common to this
                     domain and useful to distinguish.
                   </documentation>
                 </annotation>
               </attribute>



Meyer, et al.           Expires January 17, 2005               [Page 70]

Internet-Draft          IPFIX Information Model                July 2004 to this domain and useful
                     to distinguish.
                   </documentation>
                 </annotation>
               </attribute>

               <attribute name="dataTypeSemantics"
                          type="ipfix:dataTypeSemantics" use="optional">
                 <annotation>
                   <documentation>
                     The integral types may be qualified by additional
                     semantic details. Qualifying Valid values for the fields as
                     'quantity', 'counter', 'identifier' data type
                     semantics are specified in section 3.2 of this
                     document or 'flags'. in an extension of the information model.
                   </documentation>
                 </annotation>
               </attribute>

               <attribute name="fieldType" name="fieldId" type="nonNegativeInteger"
                          use="required">
                 <annotation>
                   <documentation>
                     A numeric identifier administered by IANA.
                     This is used for compact identification of an
                     information item when encoding templates in the
                     protocol.
                   </documentation>
                 </annotation>
               </attribute>

               <attribute name="vendorId" type="nonNegativeInteger"
                          use="optional">
                 <annotation>
                   <documentation>



Meyer, et al.            Expires April 25, 2005                [Page 74]

Internet-Draft          IPFIX Information Model             October 2004


                     When extension is done outside of the scope of
                     the IANA IPFIX fieldId range, a vendorId MUST
                     be provided.  This identifier is based on  Valid values for the vendorID are
                     defined by IANA
                     assigned as SMI network management private
                     enterprise identifiers. code. They are defined at
                     http://www.iana.org/assignments/enterprise-numbers.
                   </documentation>
                 </annotation>
               </attribute>

               <attribute name="applicability"
                          type="ipfix:applicability" use="required">
                 <annotation>
                   <documentation>to be done ...</documentation>
                 </annotation>
               </attribute>

               <attribute name="status" type="ipfix:status"
                          use="required">
                 <annotation>
                   <documentation>to be done ...</documentation>
                 </annotation>
               </attribute>



Meyer, et al.           Expires January 17, 2005               [Page 71]

Internet-Draft          IPFIX Information Model                July 2004
             </complexType>
           </element>
         </sequence>
       </complexType>

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

         <field xpath="fieldType"/> xpath="fieldId"/>
       </unique>
     </element>
   </schema>
















Meyer, et al.            Expires January 17, April 25, 2005                [Page 72] 75]

Internet-Draft          IPFIX Information Model                July             October 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property
   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; neither nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation RFC documents can be
   found in BCP-11. BCP 78 and BCP 79.

   Copies of
   claims of rights IPR disclosures made available for publication 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 implementors implementers or users of this
   specification can be obtained from the IETF Secretariat. 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 which that may cover technology that may be required to practice implement
   this standard.  Please address the information to the IETF Executive
   Director.


Full Copyright Statement

   Copyright (C) The Internet Society (2004). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose at
   ietf-ipr@ietf.org.


Disclaimer of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees. Validity

   This document and the information contained herein is 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 DISCLAIMS DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION



Meyer, et al.           Expires January 17, 2005               [Page 73]

Internet-Draft          IPFIX Information Model                July 2004 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 (2004).  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.




Meyer, et al.            Expires January 17, April 25, 2005                [Page 74] 76]

----