view Side-By-Side changes

Network Working Group                                          P. Calato
Internet-Draft                                   Riverstone Networks Inc
Expires: May 21, August 16, 2004                                        J. Meyer
                                                         Hewlett-Packard
                                                                  PayPal
                                                              J. Quittek
                                                         NEC Europe Ltd.
                                                       November 21, 2003
                                                       February 16, 2004


            Information Model for IP Flow Information Export
                        draft-ietf-ipfix-info-02
                        draft-ietf-ipfix-info-03

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

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

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

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

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

   This Internet-Draft will expire on May 21, August 16, 2004.

Copyright Notice

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

Abstract

   This document memo defines and information and data model for the IP Flow Information export
   eXport (IPFIX) protocol. It is used by the IPFIX protocol for
   encoding measured traffic information and information related to the
   traffic measurement observation point, the traffic metering process and the
   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.





Calato, et al.          Expires May 21, August 16, 2004                 [Page 1]

Internet-Draft          IPFIX Information Model            November 2003            February 2004


Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.     Scope  .   Properties of IPFIX Protocol Fields  . . . . . . . . . . . .   5
   3.   Type Space . . . . . . . . . . . . .   5
   3.     Properties of an IPFIX Flow Attribute . . . . . . . . . .   6
   4.     Type Space . .   7
   3.1  octet  . . . . . . . . . . . . . . . . . . . . . .   8
   4.1    int . . . . .   7
   3.2  unsigned16 . . . . . . . . . . . . . . . . . . . . . .   8
   4.2    unsignedInt . . .   7
   3.3  unsigned32 . . . . . . . . . . . . . . . . . . . .   8
   4.3    long . . . . .   7
   3.4  unsigned64 . . . . . . . . . . . . . . . . . . . . . .   8
   4.4    unsignedLong . . .   7
   3.5  float32  . . . . . . . . . . . . . . . . . . . .   8
   4.5    float . . . . . .   7
   3.6  boolean  . . . . . . . . . . . . . . . . . . . .   9
   4.6    double . . . . . .   7
   3.7  octetArray . . . . . . . . . . . . . . . . . . . .   9
   4.7    hexBinary . . . . .   7
   3.8  string . . . . . . . . . . . . . . . . . . .   9
   4.8    string . . . . . . . .   7
   3.9  dateTimeSeconds  . . . . . . . . . . . . . . . . . .   9
   4.9    boolean . . . .   8
   3.10 dataTimeMicroSeconds . . . . . . . . . . . . . . . . . . . .   8
   3.11 ipv4Address  .   9
   4.10   byte . . . . . . . . . . . . . . . . . . . . . . .   8
   3.12 ipv6Address  . . . .   9
   4.11   unsignedByte . . . . . . . . . . . . . . . . . . . .   8
   4.   Flow Attributes  . . .   9
   4.12   short . . . . . . . . . . . . . . . . . . .   9
   4.1  octetCount . . . . . . .   9
   4.13   unsignedShort . . . . . . . . . . . . . . . . . .   9
   4.2  packetCount  . . . .  10
   4.14   dateTime . . . . . . . . . . . . . . . . . . . .   9
   4.3  flowCount  . . . . .  10
   4.15   ipdr:dateTimeMsec . . . . . . . . . . . . . . . . . . . .  10
   4.16   ipdr:ipV4Addr   9
   4.4  protocolIdentifier . . . . . . . . . . . . . . . . . . . . .   9
   4.5  classOfService .  10
   4.17   ipdr:ipV6Addr . . . . . . . . . . . . . . . . . . . . . .  10
   4.18   ipdr:UUID
   4.6  tcpControlBits . . . . . . . . . . . . . . . . . . . . . . .  11
   4.7  sourcePort . . . . .  10
   4.19   ipdr:dateTimeUsec . . . . . . . . . . . . . . . . . . . .  11
   4.20   ipfix:dateTimeNsec
   4.8  sourceAddressV4  . . . . . . . . . . . . . . . . . . . . . .  11
   4.21   Integral Type Semantics
   4.9  sourceMask . . . . . . . . . . . . . . . . .  11
   4.21.1 Quantity . . . . . . . .  12
   4.10 ingressInterface . . . . . . . . . . . . . . . . .  11
   4.21.2 Counter . . . . .  12
   4.11 destinationPort  . . . . . . . . . . . . . . . . . . . .  11
   4.21.3 Identifier . .  12
   4.12 destinationAddressV4 . . . . . . . . . . . . . . . . . . . .  13
   4.13 destinationMask  . .  12
   4.21.4 Flags . . . . . . . . . . . . . . . . . . . .  13
   4.14 egressInterface  . . . . . . . . .  12
   5.     Extending the Information Model . . . . . . . . . . . . .  13
   6.     Flow Attributes
   4.15 ipNextHopAddressV4 . . . . . . . . . . . . . . . . . . . . .  14
   6.1    sourceAddress  13
   4.16 sourceAsNumber . . . . . . . . . . . . . . . . . . . . . .  14
   6.2    sourceAddressV6 .  14
   4.17 destinationAsNumber  . . . . . . . . . . . . . . . . . . . .  14
   6.3    destinationAddress
   4.18 bgpNextHopAddressV4  . . . . . . . . . . . . . . . . . . . .  14
   6.4    destinationAddressV6
   4.19 mcPacketsSent  . . . . . . . . . . . . . . . . . . .  14
   6.5    protocolIdentifier . . . .  15
   4.20 mcOctetsSent . . . . . . . . . . . . . . . .  14
   6.6    sourcePort . . . . . . . .  15
   4.21 flowEndTime  . . . . . . . . . . . . . . . .  15
   6.7    destinationPort . . . . . . . .  15
   4.22 flowCreationTime . . . . . . . . . . . . .  15
   6.8    ingressPort . . . . . . . . .  15
   4.23 sourceAddressV6  . . . . . . . . . . . . . .  15
   6.9    egressPort . . . . . . . .  15
   4.24 destinationAddressV6 . . . . . . . . . . . . . . . .  16
   6.10   packetCount . . . .  15
   4.25 anotherSourceMask  . . . . . . . . . . . . . . . . . . .  16
   6.11   byteCount . .  16
   4.26 destinationMask  . . . . . . . . . . . . . . . . . . . . . .  16
   6.12   classOfService
   4.27 flowLabel  . . . . . . . . . . . . . . . . . . . . . .  17
   6.13   flowLabel . . .  16
   4.28 icmpTypeCode . . . . . . . . . . . . . . . . . . . . . . . .  17
   6.14   flowCreationTime
   4.29 igmpType . . . . . . . . . . . . . . . . . . . . .  17
   6.15   flowEndTime . . . . .  17
   4.30 samplingInterval . . . . . . . . . . . . . . . . . .  18 . . . .  17



Calato, et al.          Expires May 21, August 16, 2004                 [Page 2]

Internet-Draft          IPFIX Information Model            November 2003


   6.16   sourceAS .            February 2004


   4.31 samplingAlgorithm  . . . . . . . . . . . . . . . . . . . . .  17
   4.32 flowReportingInterval  . . .  18
   6.17   destinationAS . . . . . . . . . . . . . . . .  18
   4.33 flowIdleTimeout  . . . . . .  18
   6.18   nextHopAS . . . . . . . . . . . . . . . .  18
   4.34 exportedOctetCount . . . . . . . .  18
   6.19   tcpControlBits . . . . . . . . . . . . .  18
   4.35 exportedPacketCount  . . . . . . . . .  19
   6.20   ipV4SourceExporterAddress . . . . . . . . . . .  18
   4.36 exportedFlowCount  . . . . .  19
   6.21   ipV6SourceExporterAddress . . . . . . . . . . . . . . . .  19
   6.22   droppedPacketCount
   4.37 ipVersion  . . . . . . . . . . . . . . . . . . . .  20
   6.23   samplingInterval . . . . .  19
   4.38 ipNextHopAddressV6 . . . . . . . . . . . . . . . .  20
   6.24   samplingAlgorithm . . . . .  19
   4.39 bgpNextHopAddressV6  . . . . . . . . . . . . . . .  21
   6.25   flowEndState . . . . .  20
   4.40 bgpNextHopAsNumber . . . . . . . . . . . . . . . . . .  21
   6.26   droppedByteCount . . .  20
   4.41 ipNextHopAsNumber  . . . . . . . . . . . . . . . . . .  21
   7.     The Benefits of a Formal Machine Readable Information
          Model . . .  20
   4.42 exporterAddressV4  . . . . . . . . . . . . . . . . . . . . .  20
   4.43 exporterAddressV6  . .  22
   8.     Security Considerations . . . . . . . . . . . . . . . . .  23
          References . .  21
   4.44 droppedOctetCount  . . . . . . . . . . . . . . . . . . . . .  21
   4.45 droppedPacketCount . . . . . . . . . . . . . . . . . . . . .  21
   4.46 flowEndReason  . . . . . . . . . . . . . . . . . . . . . . .  21
   5.   Extending the Information Model  . . . . . . . . . . . . . .  23
   6.   IANA Considerations  . . . . . . .  24
          Authors' Addresses . . . . . . . . . . . . .  24
   7.   Security Considerations  . . . . . . . . . . . . . . . . . .  25
   A.     IPFIX IPDR Service Definition
   8.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  26
   B.     Change History
        Normative Reference  . . . . . . . . . . . . . . . . . . . .  27
        Informative Reference  . .  37
   B.1    Changes Since -01 Revision . . . . . . . . . . . . . . . .  37
   B.2    Changes Since -00 Revision .  28
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  29
   A.   Formal Specification of IPFIX Fields . . . . . . . . . . . .  30
   B.   Formal Specification of Abstract Data Types  . . . . . . .  39 .  43
        Intellectual Property and Copyright Statements . . . . . .  41 .  53

























Calato, et al.          Expires May 21, August 16, 2004                 [Page 3]

Internet-Draft          IPFIX Information Model            November 2003            February 2004


1. Introduction

   Many applications e.g., intrusion detection, traffic engineering, and
   accounting among others require the monitoring, measuring of

   The IP
   traffic flows. It is hence important to have a standard way of
   exporting Flow Information eXport (IPFIX) protocol serves for
   transmitting information related to measured IP flows. This document traffic over the
   Internet.  The protocol specification in [IPFIX-PROTO] defines how
   information elements are transmitted.  For information elements, it
   specifies the
   base encoding of a set of attributes which may basic data types.  However, the
   list of fields that can be used when exporting 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
   information. It also defines timeout interval, etc.), is
   not specified in [IPFIX-PROTO].

   This document complements the mechanism IPFIX protocol specification by which new data items
   may be added without changing
   providing the underlying exchange protocol.










































Calato, et al.            Expires May 21, 2004                  [Page 4]

Internet-Draft IPFIX Information Model            November 2003


2. Scope

   This information model.  The main part of this
   document is Section 5 defines an information model 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 IP Flow
   Information eXport (IPFIX) protocol. set of abstract data types that are available for IPFIX fields.
   Section 5 discusses extensibility of the IPFIX information model.

   The model consists 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 a set the specification of IPFIX fields.
   Further it can be used for generating IPFIX protocol implementation
   code that deals with processing IPFIX fields.  Also code for
   applications that further process traffic information elements, each one defining a single attribute transmitted via
   the IPFIX protocol can be generated with the XML specification of a
   flow.
   IPFIX fields.

   For each individual attribute, that reason, the semantics is clearly
   specified XML document that served as source for Section 4
   and a data type is assigned the XML schema that served as source for Sections 2 and 3 are
   attached to it. 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.













Calato, et al.          Expires May 21, August 16, 2004                 [Page 5] 4]

Internet-Draft          IPFIX Information Model            November 2003


3.            February 2004


2. Properties of an IPFIX Flow Attribute

   Flow attributes Protocol Fields

   Fields of the IPFIX protocol carrying information about traffic
   measurement are modeled as information elements of the IPFIX information model. Each information element models a single flow
   attribute. model
   and specified in Section 4.  For defining flow attributes, the fields, a template is used.

   Information elements defined
   used that is specified below.

   All fields specified for the IPFIX protocol either in this specification, document
   or by an extension MUST have the following properties defined:

      Name

   name - a A unique and meaningful name for the field. 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").

      Description

   fieldType - the semantics of this information element. Describes
      how this field is 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.

      Type

   dataType - one One of the types listed in the following section, "The Type
      Space". "Type Space" section. 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.

      FieldId

   dataTypeSemantics - a numeric identifier administered The integral types may be qualified by IANA. This is used additional
      semantic details. Qualifying the fields as 'quantity', 'counter',
      'identifier' or 'flags'.

   applicability - to be done ...

   status - to be done ...

   All fields specified for compact identification of an information item when encoding
      templates in the protocol.

   Information elements defined IPFIX protocol either in this specification, document
   or by an extension MAY have the following properties defined:

      Vendor ID

   vendorId - when When extension is done outside of the scope of the IANA
      IPFIX fieldId range, a vendorId MUST be provided. This identifier
      is based on IANA assigned enterprise identifiers.

      Reference

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

      Units to be done ...





Calato, et al.          Expires August 16, 2004                 [Page 5]

Internet-Draft          IPFIX Information Model            February 2004


   units - if If the field is a measure of some kind, the units identify
      what the measure is.

      Enumerated range

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



Calato, et al.            Expires May 21, 2004                  [Page 6]

Internet-Draft          IPFIX Information Model            November 2003
      name should be assigned.

      Range

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




































Calato, et al.          Expires May 21, August 16, 2004                 [Page 7] 6]

Internet-Draft          IPFIX Information Model            November 2003


4.            February 2004


3. Type Space

   The following subsections describe the basic abstract data types from which that can
   be used for the
   types specification of all IPFIX attributes should be constructed.

   By describing attributes fields in terms of a well defined Section 4.

3.1 octet

   The type space,
   versus describing these details "unsignedByte" represents a non-negative integer value in each element declaration, greater
   consistency of the existing information model is expected. This
   should also simplify
   the process range of extending the information model
   over time, and maintain this consistency.

   Still any attribute is free to restrict the type assigned 0 to it
   further than the general 255.

3.2 unsigned16

   The type description in this section does.

   Please note that "unsigned16" represents a protocol implementation may based on local
   configuration, chose to carry non-negative integer values in network byte order
   encodings in a byte size which differs (greater or smaller) than the
   size implied by the information elements type.

   For instance although byteCount is defined as an unsignedLong, which
   would require 8 bytes for each reported value.  An implementation may
   send only a 4 byte quantity, if it knows that it will not exceed this
   amount for an individual flow

   The type names used are copied from the namespace defined by
   XML-Schema Datatypes.  There are a few types which are useful to
   distinguish in the context of IPFIX, which do not exist in the
   XML-Schema namespace.  The type extensions used by IPDR.org's NDM-U
   Specification, addresses these gaps and is called out in the list
   with the "ipdr:" namespace qualifier.

4.1 int

   The type "int" represents a integer numeric value in the
   range of
   -2147483648 0 to 2147483647. (i.e. a 32-bit integer)

4.2 unsignedInt 65535.

3.3 unsigned32

   The type "unsignedInt" "unsigned32" represents an a non-negative integer value in the
   range of 0 to 4294967295. (i.e. a 32-bit unsigned integer)

4.3 long

3.4 unsigned64

   The type "long" "unsigned64" represents an integer value in the range of
   9223372036854775807 to -9223372036854775808. (i.e. a 64-bit integer)

4.4 unsignedLong




Calato, et al.            Expires May 21, 2004                  [Page 8]

Internet-Draft          IPFIX Information Model            November 2003


   The type "unsignedLong" represents an non-negative integer value in the
   range of 0 to 18446744073709551615. (i.e. a 64-bit unsigned integer)

4.5 float

3.5 float32

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

4.6 double

3.6 boolean

   The double datatype corresponds to IEEE double-precision 64-bit
   floating point type

4.7 hexBinary "boolean" represents a binary value.

3.7 octetArray

   The type "hexBinary" "octetArray" represents a finite length string of octets.
   Note the name reflects the mechanism used in XML documents to
   represent the value using ASCII characters.

4.8

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

4.9 boolean

   The type "boolean" represents the values for binary logic. (i.e.
   "true/false" or "1/0").

4.10 byte





Calato, et al.          Expires August 16, 2004                 [Page 7]

Internet-Draft          IPFIX Information Model            February 2004


3.9 dateTimeSeconds

   The type "byte" "dateTimeSeconds" represents a integer numeric time value in the range having a precision
   of
   -128 seconds and normalized to 127. (i.e. an 8-bit integer)

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

   The type "unsignedByte" "dateTimeSeconds" represents a non-negative integer numeric time value in the range having a precision
   of 0 microseconds and normalized to 255. (i.e. an 8-bit unsigned integer)

4.12 short the GMT timezone.

3.11 ipv4Address

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

3.12 ipv6Address

   The type "ipv6Addr" represents a integer numeric value in the range of
   32767 to 32768. (i.e. an 16-bit integer) IPv6 address.































Calato, et al.          Expires May 21, August 16, 2004                 [Page 9] 8]

Internet-Draft          IPFIX Information Model            November 2003


4.13 unsignedShort            February 2004


4. Flow Attributes

4.1 octetCount

   Description: The type "unsignedShort" represents a non-negative integer numeric
   value in the range number of 0 to 65535. (i.e. an 16-bit unsigned integer)

4.14 dateTime observed octets.

   Abstract Data Type: unsigned64

   Field Id: 1

   Units: octets

4.2 packetCount

   Description: The "dateTime" type represents a specific instant number of time. It is
   further restricted from the basic XML dateTime type to having a
   precision observed packets.

   Abstract Data Type: unsigned64

   Field Id: 2

   Units: packets

4.3 flowCount

   Description: The number of seconds and normalized to (aggregated) flows.

   Abstract Data Type: unsigned64

   Field Id: 3

   Units: flows

4.4 protocolIdentifier

   Description:

      The protocol number that identifies the GMT timezone. Such types IP packet payload.
      Protocol numbers are defined in common use on many Operating Systems and have the advantage
   that they can be stored in 32-bit integers.

4.15 ipdr:dateTimeMsec

   The "dateTimeMsec" type IANA Protocol Numbers
      registry.

      In Internet Protocol version 4 (IPv4) this is defined carried in the IPDR namespace. It
   represents a specific instant of time. It
      "Protocol" field. In Internet Protocol version 6 (IPv6) this is further restricted from
      carried in the basic XML dateTime type to having a precision "Next Header" field.

   Abstract Data Type: octet

   Data Type Semantics: identifier




Calato, et al.          Expires August 16, 2004                 [Page 9]

Internet-Draft          IPFIX Information Model            February 2004


   Field Id: 4

   Reference:

      See RFC 791 for the specification of milliseconds and
   normalized to the GMT timezone.

   Such types are in common use on many Operating Systems and have IPv4 protocol field. See
      RFC 1883 for the
   advantage that they can be stored in 64-bit integers.

4.16 ipdr:ipV4Addr

   The "ipV4Addr" type indicates specification of the value is an IP version 4 address.
   These addresses are typically stored as 32-bit integers on systems.

4.17 ipdr:ipV6Addr

   The "ipV6Addr" type indicates the value is an IP version 6 address. IPv6 addresses are octet strings protocol field. See
      list of length 16.

4.18 ipdr:UUID protocol numbers assigned by IANA at http://www.iana.org/
      assignments/protocol-numbers.


4.5 classOfService

   Description:

      The class of service.

      The "UUID" type represents a universal unique id as defined in the
   OSF specification for Distributed Computing Environment (DCE). It's definition can be found in of classOfService is dependent on the OSF CAE Specification, Document C706,
   1997, Appendix A, located at: http://www.opengroup.org/onlinepubs/
   009629399/

   UUIDs are equivalent to Globally Unique Identifiers (GUIDs) used by
   Microsoft.

   UUIDs are 16 byte quantities which are generated in such a way that
   systems can independently generate their values, but still have a
   guarantee protocol
      being observed. Those considered here are:

      *  For IPv4 packets the class of global uniqueness service is given by the value of
         the generated value.




Calato, et al.            Expires May 21, 2004                 [Page 10]

Internet-Draft          IPFIX Information Model            November 2003


   UUID's are typically written type of service field in the form
   f81d4fae-7dec-11d0-a765-00a0c91e6bf6. Which merely shows in
   hexadecimal IPv4 packet header.

      *  For IPv6 packets the 16 byte value. Separators are introduced to segment class of service is given by the hex value into groupings of 4, 2, 2, 2 and 6 bytes.

   An open source C implementation of UUID generation is available
         the traffic class field in the appendix of IPv6 packet header.

      *  For MPLS the IETF draft, draftleach-uuids-guids-01.txt. This
   draft has expired, but an archived copy class of service is available at: http://
   www.ipdr.org/public/draft-leach-uuids-guids-01.txt

   Note: the IETF draft was allowed to expire because given by the group
   considered value of the OSF work
         experimental use (Exp) field in label stack entries. The Exp
         field has a referenceable standard and did not chose length of 3 bits.  These are mapped to
   duplicate it.

4.19 ipdr:dateTimeUsec

   The dateTimeUsec type is defined in the IPDR namespace. It represents
   a specific instant three
         least valued bits of time. It is further restricted from the basic
   XML dateTime type to having a precision classOfService octet.  All other bits
         of microseconds and
   normalized the octet are set to zero.

      *  For VLAN the GMT timezone.

4.20 ipfix:dateTimeNsec

   The dateTimeNsec type class of service is defined in given by the IPFIX namespace, it allows
   for preservation value of the granularity type
         of time down to the nano-second
   (10**-9). Time models based on NTP (RFC1305) style encoding can
   identify time down to a granularity of 232 picoseconds (.232
   nanoseconds).

4.21 Integral Type Semantics

   The integral types, 1,2,4 and 8 bytes long, signed or unsigned, may
   be qualified by additional semantic details.

   Specifically integral values may be called out user_priority field as having the
   semanctic types:  quantity, counter, defined in IEEE802.1q[802.1q] and
         IEEE 802.1p[802.1p].

      EDITORS' NOTE: THIS NEEDS FURTHER WORK

   Abstract Data Type: octet

   Data Type Semantics: identifier or flags.

4.21.1 Quantity

   A quantity value represents a discrete measured value pertaining to

   Field Id: 5

   Reference:

      See RFC 791 for the record.  This is distinguished from counters which represent an
   ongoing measured value whose "odometer" reading is captured as part definition of a given record.  If no semantic qualifier is given, the integer
   should behave as a quantity.

4.21.2 Counter

   A measurement which is ongoing from IPv4 TOS field. See RFC 2460
      for the perspective definition of the exporter. IPv6 traffic class field. See RFC 3032
      for the definition of the Exp field in label stack entries. See



Calato, et al.          Expires May 21, August 16, 2004                [Page 11] 10]

Internet-Draft          IPFIX Information Model            November 2003


   Basically the same semantics as counters in SNMP.  Counters are
   unsigned            February 2004


      IEEE802.1q and wrap back to zero after reaching IEEE 802.1p for the limit definition of the type.
   E.g. VLAN
      user_priority field.


4.6 tcpControlBits

   Description:

      The TCP control bits seen for this flow.  Note that a long with counter semantics will continue to increment until
   reaching the 0 value of 2**64 - 1.  At this point for
      each bit only indicates that the next increment
   will wrap its value flag was not detected (i.e. it
      may have occurred but was not detected by the reporting CCE).
      EDITORS' NOTE: THIS NEEDS FURTHER WORK. The bit mapping needs to zero.

   To reduce incidence of wrapping, counters should
      be either specified.

   Abstract Data Type: octet

   Data Type Semantics: flags

   Field Id: 6

   Reference: See RFC 793 for a definiton of type
   unsignedInt or unsignedLong.

4.21.3 Identifier

   An integral value which serves as an identifier.  Specifically
   mathematical operations on two identifiers (aside from the equality
   operation) are meaningless.  E.g. Autonomous System Id 1 * Autonomous
   System Id 2 is meaningless.

4.21.4 Flags

   An integral value which actually represents a set TCP control bits in the
      TCP header.


4.7 sourcePort

   Description: A source port number in the UDP or TCP header,
      respectively.

   Abstract Data Type: unsigned16

   Data Type Semantics: identifier

   Field Id: 7

   Reference:

      See RFC 768 for the definiton of bit fields.
   Logical operations are appropriate the UDP source port field. See
      RFC 793 for the definiton of the TCP source port field. Additional
      information on such values, but not other
   mathematical operations.  Flags should always defined UDP and TCP port numbers can be of an unsigned type. found at
      http://www.iana.org/assignments/port-numbers.


4.8 sourceAddressV4

   Description: The IPv4 source address in the IPv4 packet header.

   Abstract Data Type: ipv4Address



Calato, et al.          Expires May 21, August 16, 2004                [Page 12] 11]

Internet-Draft          IPFIX Information Model            November 2003


5. Extending the Information Model

   A key requirement for IPFIX is to allow            February 2004


   Field Id: 8

   Reference: See RFC 791 for extending the set definition of
   information items which are reported for flows. This section defines the mechanism for extending this set. IPv4 source address
      field.


4.9 sourceMask

   Description: 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 number of contiguous bits that are relevant in the information items
   and their order.
      source address field of the IP packet header (i.e. the subnet mask
      in slash notation).

   Abstract Data Type: octet

   Field Id: 9

   Units: bits

4.10 ingressInterface

   Description: The means index of identification the IP interface (ifIndex) where packets of information items in
   a template is via
      a field ID. Field Id's flow are unique identifiers
   administered by IANA (ed. ? true for vendor specific fields?).

   Extension is done by defining new Information elements, including being received.

   Abstract Data Type: unsigned32

   Data Type Semantics: identifier

   Field Id: 10

   Reference: See RFC 2863 for the
   set definition of necessary information and possibly additional optional
   information the ifIndex object.


4.11 destinationPort

   Description: A destination port number in the UDP or TCP header,
      respectively.

   Abstract Data Type: unsigned16

   Data Type Semantics: identifier

   Field Id: 11

   Reference:

      See RFC 768 for each element. Each new information item MUST be
   assigned a unique fieldId as part the definiton of its definition. These unique
   field ids are the connection between UDP destination port field.
      See RFC 793 for the record structure
   communicated by definiton of the protocol using templates TCP destination port field.
      Additional information on defined UDP and a consuming
   application. TCP port numbers can be



Calato, et al.          Expires May 21, August 16, 2004                [Page 13] 12]

Internet-Draft          IPFIX Information Model            November 2003


6. Flow Attributes

6.1 sourceAddress            February 2004


      found at http://www.iana.org/assignments/port-numbers.


4.12 destinationAddressV4

   Description: The IPv4 source destination address taken from in the IPv4 packet header.

   Abstract Data Type:  ipdr:ipV4Addr. ipv4Address

   Field Id:  8

6.2 sourceAddressV6

   Description:

   IPv6 source address taken from 12

   Reference: See RFC 791 for the definition of the packet header.

   Type:  ipdr:ipV6Addr.

   Field Id:  27

6.3 destinationAddress

   Description: IPv4 destination
      address taken from field.


4.13 destinationMask

   Description:

      The number of contiguous bits that are relevant in the destination
      address field of the IP packet header. header (i.e. the subnet mask in
      slash notation).

   Abstract Data Type:  ipdr:ipV4Addr. octet

   Field Id:  12

6.4 destinationAddressV6 13

   Units: bits

4.14 egressInterface

   Description:

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

   Abstract Data Type:  ipdr:ipV6Addr. unsigned32

   Data Type Semantics: identifier

   Field Id:  28

6.5 protocolIdentifier 14

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


4.15 ipNextHopAddressV4

   Description:

   Protocol number identified in The IPv4 address of the next IP packet. hop to which packets are
      forwarded.




Calato, et al.          Expires May 21, August 16, 2004                [Page 14] 13]

Internet-Draft          IPFIX Information Model            November 2003


   In the Internet Protocol version 4 (IPv4) [RFC791] there is a field,
   called "Protocol", to identify the next level protocol.  This is an 8
   bit field.  In Internet Protocol version 6 (IPv6) [RFC1883] this
   field is called the "Next Header" field.

   These numbers are administered by IANA.            February 2004


   Abstract Data Type:  unsignedByte.

   Semantics:  identifier.

   Reference:  Additional information on this element can be found at
   http://www.iana.org/assignments/protocol-numbers. ipv4Address

   Field Id:  4

6.6 sourcePort 15

4.16 sourceAsNumber

   Description:

   This information element is used to report  UDP source port [see RFC
   768] or TCP The autonomous system (AS) number of the source port [see RFC 793] as taken from address
      in the IP packet header.

   Abstract Data Type:  unsignedShort. unsigned16

   Data Type Semantics:  identifier. identifier

   Field Id:  7

6.7 destinationPort

   Description:

   This information element is used to report  UDP destination port [see 16

   Reference: See RFC 768] or TCP destination port [see 1771 for a description of BGB-4 and see RFC 793] as taken from 1930 a
      definition of the AS number.


4.17 destinationAsNumber

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

   Abstract Data Type:  unsignedShort. unsigned16

   Data Type Semantics:  identifier. identifier

   Field Id:  11

6.8 ingressPort 17

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


4.18 bgpNextHopAddressV4

   Description: The ifIndex where IPv4 address of the next BGP hop to which packets
      are forwarded.

   Abstract Data Type: ipv4Address

   Data Type Semantics: identifier

   Field Id: 18

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




Calato, et al.          Expires May 21, August 16, 2004                [Page 15] 14]

Internet-Draft          IPFIX Information Model            November 2003


   ifIndex is defined by RFC 2863.

   Type:  unsignedInt.

   Semantics:  identifier.

   Field Id:  10

6.9 egressPort            February 2004


4.19 mcPacketsSent

   Description: The ifIndex where the packets for the flow are exiting. ifIndex is
   defined by RFC 2863. number of sent multicast packets.

   Abstract Data Type:  unsignedInt.

   Semantics:  identifier. unsigned64

   Field Id:  14

6.10 packetCount 19

   Units: packets

4.20 mcOctetsSent

   Description:

   Contains the The number of packets in the flow, in the "downstream"
   (source-to-destination) direction. sent multicast octets.

   Abstract Data Type:  unsignedLong.

   Units:  The unit of measure is  packets. unsigned64

   Field Id:  2

6.11 byteCount 20

   Units: octets

4.21 flowEndTime

   Description:

   Contains the number The timestamp of bytes in the flow, in the "downstream"
   (source-to-destination) direction. last packet of a flow.

   Abstract Data Type:  unsignedLong.

   Units: dateTimeSeconds

   Field Id: 21

4.22 flowCreationTime

   Description: The unit timestamp of measure is  bytes. the first packet of a flow.

   Abstract Data Type: dateTimeSeconds

   Field Id:  1 22

4.23 sourceAddressV6

   Description: IPv6 source address taken from the packet header.

   Abstract Data Type: ipv6Address

   Field Id: 27

4.24 destinationAddressV6






Calato, et al.          Expires May 21, August 16, 2004                [Page 16] 15]

Internet-Draft          IPFIX Information Model            November 2003


6.12 classOfService            February 2004


   Description: IPv6 destination address taken from the packet header.

   Abstract Data Type: ipv6Address

   Field Id: 28

4.25 anotherSourceMask

   Description:

      The class of service associated with a flow.

   Class of Service Received

   Class number of Service Transmitted

   1. IPv4, CoS value is defined by ToS contiguous bits that are relevant in RFC 791 2. IPv6, CoS value is
   defined by Traffic Class the source
      address field of the IP packet header (i.e. the subnet mask in RFC 2460 3. MPLS, CoS value is defined by
   Exp
      slash notation).  This redundant field has the same semantics as
      field 9.

   Abstract Data Type: octet

   Field Id: 29

   Units: bits

4.26 destinationMask

   Description:

      The number of contiguous bits that are relevant in RFC 3032 4. VLAN, CoS value is defined by user_priority the destination
      address field of the IP packet header (i.e. the subnet mask in
   IEEE802.1q[802.1q] and IEEE 802.1p[802.1p]
      slash notation).  This redundant field has the same semantics as
      field 13.

   Abstract Data Type:  unsignedByte. octet

   Field Id:  5

6.13 30

   Units: bits

4.27 flowLabel

   Description: The Flow Label information element contains the IPV6 Flow Label
   information as defined by RFC 2460.  Note that a flow label only
   occupies 20 bits in of the IPv6 packet header.

   Abstract Data Type:  unsignedInt. unsigned32

   Field Id: 31

   Range:  The valid range is 0..1048575.

6.14 flowCreationTime

   Description:

   The timestamp of the first packet of the flow.  (Ed. note:  current
   NFv9 protocol uses sysuptime vs. direct time.  Not interesting from
   an info model perspective, an artifact (and an annoying one from

   Reference: See RFC 2460 for a
   consumer perspective) definition of the protocol implementation details. How to
   address?)

   Type:  dateTime.

   Field Id:  22 flow label field in
      the IPv6 packet header.





Calato, et al.          Expires May 21, August 16, 2004                [Page 17] 16]

Internet-Draft          IPFIX Information Model            November 2003


6.15 flowEndTime            February 2004


4.28 icmpTypeCode

   Description:

   The timestamp Type and Code of the last packet of the flow.  (Ed. note:  current
   NFv9 protocol uses sysuptime vs. direct time.  Not interesting from
   an info model perspective, an artifact (and an annoying one from a
   consumer perspective) of the protocol implementation details. How to
   address?) ICMP message.

   Abstract Data Type:  dateTime. unsigned16

   Field Id:  21

6.16 sourceAS

   Description:

   The Autonomous System (AS) numbers 32

   Reference: See RFC 792 for the source address associated
   with a flow. Autonomous System (AS) number is defined by RFC 1930 definition of the ICMP type and
   RFC 1771 (BGP-4): code
      fields.


4.29 igmpType

   Description: The type field of the IGMP message.

   Abstract Data Type:  unsignedInt.

   Semantics:  identifier. octet

   Field Id:  16

6.17 destinationAS

   Description:

   The Autonomous System (AS) numbers 33

   Reference: See RFC 2236 for a definition of the destination address
   associated wit IGMP type field.


4.30 samplingInterval

   Description:

      Number of packets received as a flow. Autonomous System (AS) ratio of number is defined of packets
      sampled. For example a value of 100 would mean that one packet in
      100 was sampled.  EDITORS' NOTE: This will be replaced by
   RFC 1930 and RFC 1771 (BGP-4). the
      PSAMP INFO MODEL

   Abstract Data Type:  unsignedInt.

   Semantics:  identifier. unsigned32

   Field Id:  17

6.18 nextHopAS 34

   Units: packets

4.31 samplingAlgorithm

   Description:

      The Autonomous System (AS) numbers for the next hop IP. Autonomous
   System (AS) number is defined by RFC 1930 and RFC 1771 (BGP-4). following sampling algorithms are defined:

      *  1 Deterministic sampling

      *  2 Random Sampling




Calato, et al.          Expires May 21, August 16, 2004                [Page 18] 17]

Internet-Draft          IPFIX Information Model            November 2003            February 2004


      *  3 Time-based sampling

      EDITORS' NOTE: This will be replaced by the PSAMP INFO MODEL

   Abstract Data Type:  unsignedInt. octet

   Data Type Semantics:  identifier. identifier

   Field Id:  -1

6.19 tcpControlBits 35

4.32 flowReportingInterval

   Description:

   The TCP control bits seen Interval between reports for this an active flow. Note a 0 value for each bit
   only indicates that the flag was not detected (i.e. it may have
   occurred but was

   Abstract Data Type: unsigned16

   Field Id: 36

   Units: seconds

4.33 flowIdleTimeout

   Description:

      A flow is considered to be timed out if not detected by packet belonging to
      the reporting CCE). TCP Control Bits
   are defined flow has been observed for the number of seconds specified by RFC 793.
      this field.

   Abstract Data Type:  unsignedByte.

   Semantics:  flags. unsigned16

   Field Id:  6

6.20 ipV4SourceExporterAddress 37

   Units: seconds

4.34 exportedOctetCount

   Description: The IPV4 address number of the Exporter reporting the flow. This information
   is used octets reported by applications to later correlate the ingress/egress port
   with a specific Exporter. It is also used to maintain the source
   Exporter information when there is an intermediate proxy. For
   example, given the picture below:



                  SW1 --------    P1 ------ Collector
                                  ^
                                  |
                  SW2----------   |

   Flows coming from SW1 and SW2 through proxy P1 would look to the
   Collector like the same Exporter connection. With the Source Exporter
   in the message the original Exporter  address is maintained. exporting process.

   Abstract Data Type:  ipdr:ipV4Addr. unsigned64

   Field Id:  -1

6.21 ipV6SourceExporterAddress 40

   Units: octets

4.35 exportedPacketCount






Calato, et al.          Expires May 21, August 16, 2004                [Page 19] 18]

Internet-Draft          IPFIX Information Model            November 2003            February 2004


   Description: The IPv4 address number of the Exporter reporting  the flow. This
   information is used packets reported by applications to later correlate the ingress/
   egress port with a specific Exporter. It is also used to maintain the
   source Exporter information when there is an intermediate proxy. For
   example, given the picture below:



                  SW1 --------    P1 ------ Collector
                                  ^
                                  |
                  SW2----------   |

   Flows coming from SW1 and SW2 through proxy P1 would look to the
   Collector like the same Exporter connection. With the Source Exporter
   in the message the original Exporter  address is maintained. exporting process.

   Abstract Data Type:  ipdr:ipV6Addr. unsigned64

   Field Id:  -1

6.22 droppedPacketCount 41

   Units: packets

4.36 exportedFlowCount

   Description:

   Contains the count The number of packets dropped at the observation point
   associated with the identified flow since flows reported by the last report for this
   flow. exporting process.

   Abstract Data Type:  unsignedLong. unsigned64

   Field Id: 42

   Units: flows

4.37 ipVersion

   Description: The unit of measure is  packets. IP version field given in the IP header.

   Abstract Data Type: octet

   Field Id:  -1

6.23 samplingInterval

   Description:

   When using Sampling, 60

   Units: flows

   Reference:

      See RFC 791 for a definition of the rate at which packets is sampled. For
   example, version field in the IPv6
      packet header. See RFC 2460 for a value definition of 100 indicates that one 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.38 ipNextHopAddressV6

   Description: The IPv6 address of every hundred the next IP hop to which packets
   is sampled. are
      forwarded.

   Abstract Data Type:  unsignedInt. ipv6Address

   Field Id:  34 62






Calato, et al.          Expires May 21, August 16, 2004                [Page 20] 19]

Internet-Draft          IPFIX Information Model            November 2003


6.24 samplingAlgorithm            February 2004


4.39 bgpNextHopAddressV6

   Description: The type IPv6 address of algorithm used for sampling data. Currently, the only
   sampling algorithm defined  is: 0x02 packet-sampling next BGP hop to which packets
      are forwarded.

   Abstract Data Type:  unsignedShort. ipv6Address

   Data Type Semantics: identifier

   Field Id:  35

6.25 flowEndState

   Description:

   The reason the flow has ended. 1. Inactivity timeout 2. End 63

   Reference: See RFC 1771 for a description of flow
   detected (e.g. TCP FIN) 3. Forced end ???? 4. Cache full
   [enumerations in IPDR service def schemas are recommended to be BGB-4 and see RFC 1930 a
      definition of
   form string, w/ integer values (for Compact format) defined via
   annotation] the AS number.


4.40 bgpNextHopAsNumber

   Description: The autonomous system (AS) number of the next BGP hop
      the packets are sent to.

   Abstract Data Type:  unsignedByte. unsigned16

   Data Type Semantics: identifier

   Field Id:  -1

6.26 droppedByteCount

   Description:

   Contains the count 80

   Reference: See RFC 1771 for a description of BGB-4 and see RFC 1930 a
      definition of octets dropped at the observation point
   associated with AS number.


4.41 ipNextHopAsNumber

   Description: The autonomous system (AS) number of the identified flow since next IP hop the last report for this
   flow.
      packets are sent to.

   Abstract Data Type:  unsignedLong.

   Units:  The unit of measure is  bytes. unsigned16

   Data Type Semantics: identifier

   Field Id:  -1 81

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


4.42 exporterAddressV4





Calato, et al.          Expires May 21, August 16, 2004                [Page 21] 20]

Internet-Draft          IPFIX Information Model            November 2003


7.            February 2004


   Description:

      The Benefits IPv4 address of a Formal Machine Readable Information Model

   Appendix A. expresses the IPFIX Information model as an XML-Schema.
   Using a formal and machine readable syntax for flow exporter. This is used by the Information model
   enables
      collecter to identify the creation exporter in cases where the identity of IPFIX aware tools which can automatically
   adapt to extensions to
      the information model, exporter may have been obscured by simply reading
   updated information model specifications.

   The the use of XML-Schema as a proxy.

   Abstract Data Type: ipv4Address

   Field Id: 82

4.43 exporterAddressV6

   Description:

      The IPv6 address of the formal specification language flow exporter. This is modeled
   after used by the
      collecter to identify the exporter in cases where the identity of
      the techniques employed exporter may have been obscured by the IPDR NDM-U specification.

   The wide availability use 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 initially 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 proxy.

   Abstract Data Type: ipv4Address

   Field Id: 83

4.44 droppedOctetCount

   Description: The number of their operation.  It is expected that IPFIX collectors MAY take
   advantage octets dropped.

   Abstract Data Type: unsigned64

   Field Id: 84

   Units: octets

4.45 droppedPacketCount

   Description: The number of the machine readability packets dropped.

   Abstract Data Type: unsigned64

   Field Id: 84

   Units: packets

4.46 flowEndReason

   Description: The number of the Information Model vs.
   hardcoding their behavior or inventing proprietary means for
   accomodating extensions. packets dropped.

      *  idle timeout




Calato, et al.          Expires May 21, August 16, 2004                [Page 22] 21]

Internet-Draft          IPFIX Information Model            November 2003


8. Security Considerations

   The IPFIX information model itself does not directly introduce
   security issues. Rather it defines a set            February 2004


      *  end 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 flow detected (e.g. TCP FIN)

      *  forced end

      *  cache full

      EDITORS' NOTE: This needs to guarantee the
   integrity and confidentiality of the exported information.  Such
   protocols are be defined in separate documents. Specifically the IPFIX
   Protocol document. as an enumerated range.

   Abstract Data Type: octet

   Field Id: 84








































Calato, et al.          Expires May 21, August 16, 2004                [Page 23] 22]

Internet-Draft          IPFIX Information Model            November 2003


References

   [1]   Quittek, J., "Requirements for IP Flow            February 2004


5. Extending the Information Export",
         IETF draft work in progress, August 2003, <http://www.ietf.org/
         internet-drafts/draft-ietf-ipfix-reqs-10.txt>.

   [2]   Sadasivan, G. and N. Brownlee, "Architecture Model

   A key requirement for IP Flow
         Information Export", IETF draft work in progress, June 2003,
         <http://www.ietf.org/internet-drafts/
         draft-ietf-ipfix-arch-01.txt>.

   [3]   Zseby, T., Penno, R., Claise, B. 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 N. Brownlee, "IPFIX
         Applicability", IETF draft work a collector. A given template identifies the information items
   and their order. The means of identification of information items in progress, June 2003, <http:/
         /www.ietf.org/internet-drafts/draft-ietf-ipfix-as-00.txt>.

   [4]   Claise, B., Fullmer, M., Calato, P.
   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 R. Penno, "IPFIX
         Protocol Specification", 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
   enterprise ID assignments, without registering specific field ID's
   with IANA.  In these cases the field definiton 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 draft work and IANA
   mechanisms for extendind the information model is recommended.






















Calato, et al.          Expires August 16, 2004                [Page 23]

Internet-Draft          IPFIX Information Model            February 2004


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










































Calato, et al.          Expires August 16, 2004                [Page 24]

Internet-Draft          IPFIX Information Model            February 2004


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








































Calato, et al.          Expires August 16, 2004                [Page 25]

Internet-Draft          IPFIX Information Model            February 2004


8. Acknowledgements

   The editors thank Stewart Bryant 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.













































Calato, et al.          Expires August 16, 2004                [Page 26]

Internet-Draft          IPFIX Information Model            February 2004


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













































Calato, et al.          Expires August 16, 2004                [Page 27]

Internet-Draft          IPFIX Information Model            February 2004


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

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

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

   [5]   Claise, B., "Cisco Systems NetFlow Services Export Version 9",
         IETF draft work in progress, June 2003, <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>.

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

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

   [9]   Internet Protocol Detail Record Organization, "Network Data
         Management - Usage (NDM-U) For IP-Based Services Version
         3.1.1", October 2002, <http://www.ipdr.org/documents/
         NDM-U_3.1.1.pdf>.

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

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

   [12]  Hollenbeck, S., Rose, M. 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>.



Calato, et al.          Expires August 16, 2004                [Page 28]

Internet-Draft          IPFIX Information Model            February 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

   Paul Calato
   Riverstone Networks Inc
   5200 Great America Parkway
   Santa Clara, CA  95054
   US

   Phone: +1 603 557-6913
   EMail: calato@riverstonenet.com
   URI:   http://www.riverstonenet.com


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

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


   Juergen Quittek
   NEC Europe Ltd.
   Kurfuersten-Anlage 36
   Heidelberg  69115
   Germany

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










Calato, et al.          Expires August 16, 2004                [Page 29]

Internet-Draft          IPFIX Information Model            February 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="octetCount" dataType="unsigned64"
            fieldType="1" applicability="data" status="current">
       <description>
         The number of observed octets.
       </description>
       <units>octets</units>
     </field>

     <field name="packetCount" dataType="unsigned64"
            fieldType="2" applicability="data" status="current">
       <description>
         The number of observed packets.
       </description>
       <units>packets</units>
     </field>

     <field name="flowCount" dataType="unsigned64"



Calato, et al.          Expires August 16, 2004                [Page 30]

Internet-Draft          IPFIX Information Model            February 2004


            fieldType="3" applicability="data" status="current">
       <description>
         The number of (aggregated) flows.
       </description>
       <units>flows</units>
     </field>

     <field name="protocolIdentifier" dataType="octet"
            dataTypeSemantics="identifier"
            fieldType="4" applicability="all" status="current">
       <description>
         <paragraph>
         The protocol number that identifies the IP packet payload.
         Protocol numbers are defined in the IANA Protocol Numbers
         registry.</paragraph>

         <paragraph>
         In Internet Protocol version 4 (IPv4) this is carried
         in the "Protocol" field. In Internet Protocol version 6
         (IPv6) this is carried in the "Next Header" field.</paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 791 for the specification of the IPv4 protocol field.
         See RFC 1883 for the specification of the IPv6 protocol field.
         See list of protocol numbers assigned by IANA at
         http://www.iana.org/assignments/protocol-numbers.
         </paragraph>
       </reference>
     </field>

     <field name="classOfService" dataType="octet"
            dataTypeSemantics="identifier"
            fieldType="5" applicability="all" status="current">
       <description>
         <paragraph>
         The class of service.
         </paragraph>

         <paragraph>
         The definition of classOfService is dependent on the protocol
         being observed. Those considered here are:
         </paragraph>
         <list>
         <item>For IPv4 packets the class of service is given by the
               value of the type of service field in the IPv4 packet
               header.</item>
         <item>For IPv6 packets the class of service is given by the



Calato, et al.          Expires August 16, 2004                [Page 31]

Internet-Draft          IPFIX Information Model            February 2004


               value of the traffic class field in the IPv6 packet
               header.</item>
         <item>For MPLS the class of service is given by the value of
               the experimental use (Exp) field in label stack entries.
               The Exp field has a length of 3 bits.  These are mapped
               to the three least valued bits of the classOfService
               octet.  All other bits of the octet are set to
               zero.</item>
         <item>For VLAN the class of service is given by the value
               of the type of the user_priority field as defined
               in IEEE802.1q[802.1q] and IEEE 802.1p[802.1p].</item>
         </list>

         EDITORS' NOTE: THIS NEEDS FURTHER WORK
       </description>
       <reference>
         <paragraph>
         See RFC 791 for the definition of the IPv4 TOS field.
         See RFC 2460 for the definition of the IPv6 traffic class
         field.
         See RFC 3032 for the definition of the Exp field in label stack
         entries.
         See IEEE802.1q and IEEE 802.1p for the definition of the VLAN
         user_priority field.
         </paragraph>
       </reference>
     </field>

     <field name="tcpControlBits" dataType="octet"
            dataTypeSemantics="flags"
            fieldType="6" applicability="all" status="current">
       <description>
         <paragraph>
         The TCP control bits seen for this flow.  Note that a 0 value
         for each bit only indicates that the flag was not detected
         (i.e. it may have occurred but was not detected by the
         reporting CCE).
         </paragraph>

         EDITORS' NOTE: THIS NEEDS FURTHER WORK.
         The bit mapping needs to be specified.
       </description>
       <reference>See RFC 793 for a definiton of the TCP control bits
       in the TCP header.</reference>
     </field>

     <field name="sourcePort" dataType="unsigned16"
            dataTypeSemantics="identifier"



Calato, et al.          Expires August 16, 2004                [Page 32]

Internet-Draft          IPFIX Information Model            February 2004


            fieldType="7" applicability="all" status="current">
       <description>
         A source port number in the UDP or TCP header, respectively.
       </description>
       <reference>
         <paragraph>
         See RFC 768 for the definiton of the UDP source port field.
         See RFC 793 for the definiton of the TCP source port field.
         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="sourceAddressV4" dataType="ipv4Address"
            fieldType="8" applicability="all" status="current">
       <description>
         The IPv4 source address in progress, June
         2003, <http://www.ietf.org/internet-drafts/
         draft-ietf-ipfix-protocol-00.txt>.

   [5]   Claise, B., "Cisco Systems NetFlow Services Export Version 9",
         IETF draft work the IPv4 packet header.
       </description>
       <reference>
         See RFC 791 for the definition of the IPv4 source address
         field.
       </reference>
     </field>

     <field name="sourceMask" dataType="octet"
            fieldType="9" applicability="option" status="current">
       <description>
         The number of contiguous bits that are relevant in progress, June 2003, <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, the source
         address field of the IP packet header
         (i.e. the subnet mask in slash notation).
       </description>
       <units>bits</units>
     </field>

     <field name="ingressInterface" dataType="unsigned32"
            dataTypeSemantics="identifier"
            fieldType="10" applicability="all" status="current">
       <description>
         The index of the IP interface (ifIndex) where packets of a flow
         are being received.
       </description>
       <reference>
         See RFC 2863 for the definition of the ifIndex object.
       </reference>
     </field>

     <field name="destinationPort" dataType="unsigned16"



Calato, et al.          Expires August 16, 2004                [Page 33]

Internet-Draft          IPFIX Information Model            February 1998, <http://www.w3.org/TR/1998/
         REC-xml-19980210>.

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

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

   [9]   Internet Protocol Detail Record Organization, "Network Data
         Management - Usage (NDM-U) For IP-Based Services Version
         3.1.1", October 2002, <http://www.ipdr.org/documents/
         NDM-U_3.1.1.pdf>.

   [10]  Brownlee, N. and A. Blount, "Accounting Attributes and Record
         Formats", 2004


            dataTypeSemantics="identifier"
            fieldType="11" applicability="all" status="current">
       <description>
         A destination port number in the UDP or TCP header,
         respectively.
       </description>
       <reference>
         <paragraph>
         See RFC 2924, Sept. 2000, <http://www.ietf.org/rfc/
         rfc2924.txt>.

   [11]  Rose, M., "Writing I-Ds 768 for the definiton of the UDP destination port
         field.
         See RFC 793 for the definiton of the TCP destination port
         field.
         Additional information on defined UDP and RFCs using XML", TCP port numbers
         can be found at http://www.iana.org/assignments/port-numbers.
         </paragraph>
       </reference>
     </field>

     <field name="destinationAddressV4" dataType="ipv4Address"
            fieldType="12" applicability="all" status="current">
       <description>
         The IPv4 destination address in the IPv4 packet header.
       </description>
       <reference>
         See RFC 2629, June
         1999, <http://xml.resource.org/public/rfc/html/rfc2629.html>. 791 for the definition of the IPv4 destination address
         field.
       </reference>
     </field>

     <field name="destinationMask" dataType="octet"
            fieldType="13" applicability="option" status="current">
       <description>
         <paragraph>
         The number of contiguous bits that are relevant in the
         destination address field of the IP packet header
         (i.e. the subnet mask in slash notation).
         </paragraph>
       </description>
       <units>bits</units>
     </field>

     <field name="egressInterface" dataType="unsigned32"
            dataTypeSemantics="identifier"
            fieldType="14" applicability="all" status="current">
       <description>
         The index of the IP interface (ifIndex) where packets of a flow
         are being sent.
       </description>



Calato, et al.          Expires May 21, August 16, 2004                [Page 24] 34]

Internet-Draft          IPFIX Information Model            November 2003


   [12]  Hollenbeck, S., Rose, M. and L. Masinter, "Guidelines            February 2004


       <reference>
         See RFC 2863 for the
         Use definition of Extensible Markup Language (XML) within IETF Protocols", the ifIndex object.
       </reference>
     </field>

     <field name="ipNextHopAddressV4" dataType="ipv4Address"
            fieldType="15" applicability="data" status="current">
       <description>
         The IPv4 address of the next IP hop to which packets are
         forwarded.
       </description>
     </field>

     <field name="sourceAsNumber" dataType="unsigned16"
            dataTypeSemantics="identifier"
            fieldType="16" applicability="all" status="current">
       <description>
         The autonomous system (AS) number of the source address in
         the IP packet header.
       </description>
       <reference>
         See RFC 3470, January 2003, <http://www.ietf.org/rfc/rfc3470.txt>.

   [13]  Pras, A. 1771 for a description of BGB-4 and J. Schoenwaelder, "On
         see RFC 1930 a definition of the Difference between
         Information Models AS number.
       </reference>
     </field>

     <field name="destinationAsNumber" dataType="unsigned16"
            dataTypeSemantics="identifier"
            fieldType="17" applicability="all" status="current">
       <description>
         The autonomous system (AS) number of the destination address
         in the IP packet header.
       </description>
       <reference>
         See RFC 1771 for a description of BGB-4 and Data Models",
         see RFC 3444, January 2003,
         <http://www.ietf.org/rfc/rfc3444.txt>.


Authors' Addresses

   Paul Calato
   Riverstone Networks Inc
   5200 Great America Parkway
   Santa Clara, CA  95054
   US

   Phone: +1 603 557-6913
   EMail: calato@riverstonenet.com
   URI:   http://www.riverstonenet.com


   Jeff Meyer
   Hewlett-Packard
   19420 Homestead Rd.
   Cupertino, CA  95014
   US

   Phone: +1 408 447-3477
   EMail: jeff.meyer2@hp.com
   URI:   http://www.hp.com


   Juergen Quittek
   NEC Europe Ltd.
   Adenauerplatz 6
   Heidelberg  69115
   Germany

   Phone: +49 6221 90511-15
   EMail: quittek@ccrle.nec.de
   URI:   http://www.neceurope.com/ 1930 a definition of the AS number.
       </reference>
     </field>

     <field name="bgpNextHopAddressV4" dataType="ipv4Address"
            dataTypeSemantics="identifier"
            fieldType="18" applicability="all" status="current">
       <description>
         The IPv4 address of the next BGP hop to which packets are
         forwarded.
       </description>
       <reference>
         See RFC 1771 for a description of BGB-4 and



Calato, et al.          Expires August 16, 2004                [Page 35]

Internet-Draft          IPFIX Information Model            February 2004


         see RFC 1930 a definition of the AS number.
       </reference>
     </field>

     <field name="mcPacketsSent" dataType="unsigned64"
            fieldType="19" applicability="data" status="current">
       <description>
         The number of sent multicast packets.
       </description>
       <units>packets</units>
     </field>

     <field name="mcOctetsSent" dataType="unsigned64"
            fieldType="20" applicability="data" status="current">
       <description>
         The number of sent multicast octets.
       </description>
       <units>octets</units>
     </field>

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

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

     <field name="sourceAddressV6" dataType="ipv6Address"
            fieldType="27" applicability="all" status="current">
       <description>
         IPv6 source address taken from the packet header.
       </description>
     </field>

     <field name="destinationAddressV6" dataType="ipv6Address"
            fieldType="28" applicability="all" status="current">
       <description>
         IPv6 destination address taken from the packet header.
       </description>
     </field>




Calato, et al.          Expires May 21, August 16, 2004                [Page 25] 36]

Internet-Draft          IPFIX Information Model            November 2003


Appendix A. IPFIX IPDR Service Definition

   This proposal does not currently address possible IANA implications
   associated with XML Namespace URIs.            February 2004


     <field name="anotherSourceMask" dataType="octet"
            fieldType="29" applicability="option" status="current">
       <description>
         <paragraph>
         The use number of Namespaces as an
   extension mechanism implies that an IANA registered Namespace URI
   should be available and contiguous bits that directory names below this base URI be
   assigned for are relevant IETF specifications. The author is not aware in the source
         address field of
   this mechanism today. Alternatively IPDR.org could fulfill this role.
   The sample uses the IPDR.org namespace. IP packet header (i.e. the subnet mask
         in slash notation).  This redundant field has the same
         semantics as field 9.
         </paragraph>
       </description>
       <units>bits</units>
     </field>

     <field name="destinationMask" dataType="octet"
            fieldType="30" applicability="option" status="current">
       <description>
         <paragraph>
         The normative status number of this appendix versus contiguous bits that are relevant in the section "Flow
   Attributes" is a point
         destination address field of discussion.  The "Flow Attributes" section
   is simply machine generated from the formal XML document below.  As
   such using IP packet header (i.e. the formal XML document would seem preferable.  However
   historical conventions and IETF's overall level
         subnet mask in slash notation).  This redundant field has
         the same semantics as field 13.
         </paragraph>
       </description>
       <units>bits</units>
     </field>

     <field name="flowLabel" dataType="unsigned32"
            fieldType="31" applicability="all" status="current">
       <description>
         The Flow Label of XML adoption may
   lead to selection the IPv6 packet header.
       </description>
       <reference>
         See RFC 2460 for a definition of the human readable text flow label field in the "Flow Attributes"
   section as being preferable as normative.



   <schema xmlns:ipdr="http://www.ipdr.org/namespaces/ipdr"
           xmlns:ipfix="http://www.iana.org/namespaces/ipfix">

   <annotation>
     <documentation>
     <t>
     This document defines
         IPv6 packet header.
       </reference>
     </field>

     <field name="icmpTypeCode" dataType="unsigned16"
            fieldType="32" applicability="all" status="current">
       <description>
         Type and Code of the ICMP message.
       </description>
       <reference>
         See RFC 792 for a subset definition of the identified IPFIX data
     model as XML Schema elements ICMP type and complexTypes.  This schema code fields.
       </reference>
     </field>

     <field name="igmpType" dataType="octet"



Calato, et al.          Expires August 16, 2004                [Page 37]

Internet-Draft          IPFIX Information Model            February 2004


            fieldType="33" applicability="all" status="current">
       <description>
         The type field of the IGMP message.
       </description>
       <reference>
         See RFC 2236 for a definition is compatable with of the IPDR Service Definition
     format, enabling flow information to be represented IGMP type field.
       </reference>
     </field>

     <field name="samplingInterval" dataType="unsigned32"
            fieldType="34" applicability="all" status="current">
       <description>
         <paragraph>
         Number of packets received as XML
     or binary documents.  And defines the format used when streaming
     flow information to a recording system.
     </t>
     </documentation>
   </annotation>


   <element name="sourceAddress" type="ipdr:ipV4Addr">
   <annotation>
     <documentation>
     <t>
      IPv4 source address taken from ratio of number of packets
         sampled. For example a value of 100 would mean that one packet
         in 100 was sampled.
         </paragraph>

         EDITORS' NOTE: This will be replaced by the packet header.
     </t>
     </documentation>
     <appinfo>
       <ipfix:fieldId>8</ipfix:fieldId>
     </appinfo>
   </annotation> PSAMP INFO MODEL
       </description>
       <units>packets</units>
     </field>

     <field name="samplingAlgorithm" dataType="octet"
            dataTypeSemantics="identifier"
            fieldType="35" applicability="all" status="current">
       <description>
         <paragraph>
         The following sampling algorithms are defined:
         </paragraph>

         <list>
           <item>1 Deterministic sampling</item>
           <item>2 Random Sampling</item>
           <item>3 Time-based sampling</item>
         </list>

         EDITORS' NOTE: This will be replaced by the PSAMP INFO MODEL
       </description>
     </field>

     <field name="flowReportingInterval" dataType="unsigned16"
            fieldType="36" applicability="all" status="current">
       <description>
         Interval between reports for an active flow.
       </description>
       <units>seconds</units>
     </field>



Calato, et al.          Expires May 21, August 16, 2004                [Page 26] 38]

Internet-Draft          IPFIX Information Model            November 2003


   </element>


   <element name="sourceAddressV6" type="ipdr:ipV6Addr">
   <annotation>
     <documentation>
     <t>
      IPv6 source address taken from the            February 2004


     <field name="flowIdleTimeout" dataType="unsigned16"
            fieldType="37" applicability="all" status="current">
       <description>
          <paragraph>
          A flow is considered to be timed out if not packet
          belonging to the flow has been observed for the number
          of seconds specified by this field.
          </paragraph>
       </description>
       <units>seconds</units>
     </field>

     <field name="exportedOctetCount" dataType="unsigned64"
            fieldType="40" applicability="data" status="current">
       <description>
         The number of octets reported by the exporting process.
       </description>
       <units>octets</units>
     </field>

     <field name="exportedPacketCount" dataType="unsigned64"
            fieldType="41" applicability="data" status="current">
       <description>
         The number of packets reported by the exporting process.
       </description>
       <units>packets</units>
     </field>

     <field name="exportedFlowCount" dataType="unsigned64"
            fieldType="42" applicability="data" status="current">
       <description>
         The number of flows reported by the exporting process.
       </description>
       <units>flows</units>
     </field>

     <field name="ipVersion" dataType="octet"
            fieldType="60" applicability="all" status="current">
       <description>
         The IP version field given in the IP header.
     </t>
     </documentation>
     <appinfo>
       <ipfix:fieldId>27</ipfix:fieldId>
     </appinfo>
   </annotation>
   </element>


   <element name="destinationAddress" type="ipdr:ipV4Addr">
   <annotation>
     <documentation>
     <t>
      IPv4 destination address taken from
       </description>
       <units>flows</units>
       <reference>
         <paragraph>
         See RFC 791 for a definition of the version field in the
         IPv6 packet header.
     </t>
     </documentation>
     <appinfo>
       <ipfix:fieldId>12</ipfix:fieldId>
     </appinfo>
   </annotation>
   </element>


   <element name="destinationAddressV6" type="ipdr:ipV6Addr">
   <annotation>
     <documentation>
     <t>
      IPv6 destination address taken from
         See RFC 2460 for a definition of the version field in the
         IPv6 packet header.
     </t>
     </documentation>
     <appinfo>
       <ipfix:fieldId>28</ipfix:fieldId>
     </appinfo>
   </annotation>
   </element>


   <element name="protocolIdentifier" type="unsignedByte">
   <annotation>
     <documentation>



Calato, et al.          Expires May 21, August 16, 2004                [Page 27] 39]

Internet-Draft          IPFIX Information Model            November 2003


      <t>
      Protocol number identified in the IP packet.
      </t><t>
      In the Internet Protocol version 4 (IPv4) [RFC791] there is a field,
      called "Protocol", to identify the next level protocol.  This is an 8
      bit field.  In Internet Protocol            February 2004


         Additional information on defined version 6 (IPv6) [RFC1883] this field
      is called the "Next Header" field.
      </t><t>
      These numbers are administered by IANA.
      </t>
     </documentation>
     <appinfo>
       <ipfix:semantics>identifier</ipfix:semantics>
     </appinfo>
     <appinfo>
       <ipdr:reference>http://www.iana.org/assignments/protocol-numbers</ipdr:reference>
     </appinfo>
     <appinfo>
       <ipfix:fieldId>4</ipfix:fieldId>
     </appinfo>
   </annotation>
   </element>

   <element name="sourcePort" type="unsignedShort">
   <annotation>
     <documentation>
     <t>
      This information element is used to report  UDP source port [see
      RFC 768] or TCP source port [see RFC 793] as taken from
         can be found at
         http://www.iana.org/assignments/version-numbers.
         </paragraph>
       </reference>
     </field>

     <field name="ipNextHopAddressV6" dataType="ipv6Address"
            fieldType="62" applicability="data" status="current">
       <description>
         The IPv6 address of the next IP
      header.
     </t>
     </documentation>
     <appinfo>
       <ipfix:semantics>identifier</ipfix:semantics>
     </appinfo>
     <appinfo>
       <ipfix:fieldId>7</ipfix:fieldId>
     </appinfo>
   </annotation>
   </element>

   <element name="destinationPort" type="unsignedShort">
   <annotation>
     <documentation>
     <t>
      This information element is used hop to which packets are
         forwarded.
       </description>
     </field>

     <field name="bgpNextHopAddressV6" dataType="ipv6Address"
            dataTypeSemantics="identifier"
            fieldType="63" applicability="all" status="current">
       <description>
         The IPv6 address of the next BGP hop to report  UDP destination port
      [see which packets are
         forwarded.
       </description>
       <reference>
         See RFC 768] or TCP destination port [see 1771 for a description of BGB-4 and
         see RFC 793] as taken from 1930 a definition of the AS number.
       </reference>
     </field>

     <field name="bgpNextHopAsNumber" dataType="unsigned16"
            dataTypeSemantics="identifier"
            fieldType="80" applicability="all" status="current">
       <description>
         The autonomous system (AS) number of the next BGP hop the
         packets are sent to.
       </description>
       <reference>
         See RFC 1771 for a description of BGB-4 and
         see RFC 1930 a definition of the AS number.
       </reference>
     </field>

     <field name="ipNextHopAsNumber" dataType="unsigned16"
            dataTypeSemantics="identifier"
            fieldType="81" applicability="all" status="current">
       <description>
         The autonomous system (AS) number of the next IP header. hop the
         packets are sent to.
       </description>



Calato, et al.          Expires May 21, August 16, 2004                [Page 28] 40]

Internet-Draft          IPFIX Information Model            November 2003


     </t>
     </documentation>
     <appinfo>
       <ipfix:semantics>identifier</ipfix:semantics>
     </appinfo>
     <appinfo>
       <ipfix:fieldId>11</ipfix:fieldId>
     </appinfo>
   </annotation>
   </element>

   <element name="ingressPort" type="unsignedInt">
   <annotation>
     <documentation>
     <t>
      The ifIndex where the packets            February 2004


       <reference>
         See RFC 1771 for a description of BGB-4 and
         see RFC 1930 a definition of the AS number.
       </reference>
     </field>

     <field name="exporterAddressV4" dataType="ipv4Address"
            fieldType="82" applicability="all" status="current">
       <description>
         <paragraph>
         The IPv4 address of the flow are being received.
      ifIndex exporter. This is defined used by RFC 2863.
     </t>
     </documentation>
     <appinfo>
       <ipfix:semantics>identifier</ipfix:semantics>
     </appinfo>
     <appinfo>
       <ipfix:fieldId>10</ipfix:fieldId>
     </appinfo></annotation>
   </element>

   <element name="egressPort" type="unsignedInt">
   <annotation>
     <documentation>
     <t>
      The ifIndex the
         collecter to identify the exporter in cases where the packets for identity
         of the exporter may have been obscured by the use of a proxy.
         </paragraph>
       </description>
     </field>

     <field name="exporterAddressV6" dataType="ipv4Address"
            fieldType="83" applicability="all" status="current">
       <description>
         <paragraph>
         The IPv6 address of the flow are exiting. ifIndex exporter. This is
      defined used by RFC 2863.
     </t>
     </documentation>
     <appinfo>
       <ipfix:semantics>identifier</ipfix:semantics>
     </appinfo>
     <appinfo>
       <ipfix:fieldId>14</ipfix:fieldId>
     </appinfo></annotation>
   </element>

   <element name="packetCount" type="unsignedLong">
   <annotation>
     <documentation>
     <t>
       Contains the number of packets in
         collecter to identify the flow, exporter in cases where the identity
         of the "downstream" exporter may have been obscured by the use of a proxy.
         </paragraph>
       </description>
     </field>

     <field name="droppedOctetCount" dataType="unsigned64"
            fieldType="84" applicability="data" status="current">
       <description>
         The number of octets dropped.
       </description>
       <units>octets</units>
     </field>

     <field name="droppedPacketCount" dataType="unsigned64"
            fieldType="84" applicability="data" status="current">
       <description>
         The number of packets dropped.
       </description>
       <units>packets</units>
     </field>

     <field name="flowEndReason" dataType="octet"
            fieldType="84" applicability="data" status="current">
       <description>
         The number of packets dropped.



Calato, et al.          Expires May 21, August 16, 2004                [Page 29] 41]

Internet-Draft          IPFIX Information Model            November 2003


       (source-to-destination) direction.
     </t>
     </documentation>
     <appinfo>
       <ipdr:units>packets</ipdr:units>
     </appinfo>
     <appinfo>
       <ipfix:fieldId>2</ipfix:fieldId>
     </appinfo></annotation>
   </element>

   <element name="byteCount" type="unsignedLong">
   <annotation>
     <documentation>
      <t>
       Contains the number of bytes in the flow, in the "downstream"
       (source-to-destination) direction.
      </t>
     </documentation>
     <appinfo>
       <ipdr:units>bytes</ipdr:units>
     </appinfo>
     <appinfo>
       <ipfix:fieldId>1</ipfix:fieldId>
     </appinfo></annotation>
   </element>

   <element name="classOfService" type="unsignedByte">
   <annotation>
     <documentation>
      <t>
      The class of service associated with a flow.
      </t><t>
      Class            February 2004


         <list>
           <item>idle timeout</item>
           <item>end of Service Received
      </t><t>
      Class of Service Transmitted
      </t><t>
         1. IPv4, CoS value is defined by ToS in RFC 791
         2. IPv6, CoS value is defined by Traffic Class in RFC 2460
         3. MPLS, CoS value is defined by Exp in RFC 3032
         4. VLAN, CoS value is defined by user_priority in
            IEEE802.1q[802.1q] and IEEE 802.1p[802.1p]
      </t>
     </documentation>
     <appinfo>
       <ipfix:fieldId>5</ipfix:fieldId>
     </appinfo></annotation>
   </element> 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.
       </description>
     </field>

   </fieldDefinitions>







































Calato, et al.          Expires May 21, August 16, 2004                [Page 30] 42]

Internet-Draft          IPFIX Information Model            November 2003


   <element name="flowLabel" type="unsignedInt">
   <annotation>
     <documentation>
      <t>
      The Flow Label information element contains the IPV6 Flow Label
      information as defined by RFC 2460.  Note that            February 2004


Appendix B. Formal Specification of Abstract Data Types

   This appendix containfs a flow label only
      occupies 20 bits in formal description of the IPv6 header.
      </t>
     </documentation>
     <appinfo>
       <ipfix:fieldId>31</ipfix:fieldId>
     </appinfo>
     <appinfo>
       <ipfix:range>0..1048575</ipfix:range>
     </appinfo></annotation>
   </element>

   <element name="flowCreationTime" type="dateTime">
   <annotation>
     <documentation>
     <t>
      The timestamp abstract data
   types to be used for IPFIX fields and a formal description of the first packet
   template used for defining IPFIX fields.  Note that this appendix is
   of informational nature, while the flow.  (Ed. note:  current NFv9
      protocol uses sysuptime vs. direct time.  Not interesting from an info
      model perspective, an artifact (and an annoying one 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" represents a consumer
      perspective) of
               non-negative integer value in the protocol implementation details. How range of 0 to address?)
     </t> 255.
             </documentation>
     <appinfo>
       <ipfix:fieldId>22</ipfix:fieldId>
     </appinfo></annotation>
   </element>


   <element name="flowEndTime" type="dateTime">
           </annotation>
         </enumeration>

         <enumeration value="unsigned16">
           <annotation>
     <documentation>
     <t>
      The timestamp of
             <documentation>The type "unsigned16" represents a
               non-negative integer value in the last packet range of the flow.  (Ed. note:  current NFv9
      protocol uses sysuptime vs. direct time.  Not interesting from an info
      model perspective, an artifact (and an annoying one from 0 to 65535.
             </documentation>
           </annotation>
         </enumeration>

         <enumeration value="unsigned32">
           <annotation>
             <documentation>The type "unsigned32" represents a consumer
      perspective)
                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 protocol implementation details. How range of 0 to address?)
     </t>
               18446744073709551615.
             </documentation>
     <appinfo>
       <ipfix:fieldId>21</ipfix:fieldId>
     </appinfo></annotation>
   </element>
           </annotation>



Calato, et al.          Expires May 21, August 16, 2004                [Page 31] 43]

Internet-Draft          IPFIX Information Model            November 2003


   <element name="sourceAS" type="unsignedInt">            February 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>
     <t>
               The Autonomous System (AS) numbers for the source address
      associated with type "string" represents a flow. Autonomous System (AS) number is defined
      by RFC 1930 finite length string
               of valid characters from the Unicode character
               encoding set.  Unicode allows for ASCII and RFC 1771 (BGP-4):
      </t> 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>
     <appinfo>
       <ipfix:semantics>identifier</ipfix:semantics>
     </appinfo>
     <appinfo>
       <ipfix:fieldId>16</ipfix:fieldId>
     </appinfo></annotation>
   </element>

   <element name="destinationAS" type="unsignedInt">
           </annotation>
         </enumeration>

         <enumeration value="dateTimeSeconds">
           <annotation>
             <documentation>
     <t>
               The Autonomous System (AS) numbers for the destination address
      associated wit type "dateTimeSeconds" represents a flow. Autonomous System (AS) number is defined by
      RFC 1930 time value
               having a precision of seconds and RFC 1771 (BGP-4).
     </t>
     </documentation>
     <appinfo>
       <ipfix:semantics>identifier</ipfix:semantics>
     </appinfo>
     <appinfo>
       <ipfix:fieldId>17</ipfix:fieldId>
     </appinfo></annotation>
   </element>

   <element name="nextHopAS" type="unsignedInt">
   <annotation>
     <documentation>
     <t>
      The Autonomous System (AS) numbers for normalized to the next hop IP. Autonomous
      System (AS) number is defined by RFC 1930
               GMT timezone.  Such types are in common use on many
               operating systems and RFC 1771 (BGP-4).
     </t>
     </documentation>
     <appinfo>
       <ipfix:semantics>identifier</ipfix:semantics>
     </appinfo>
     <appinfo>
       <ipfix:fieldId>-1</ipfix:fieldId>
     </appinfo> have the advantage that they



Calato, et al.          Expires May 21, August 16, 2004                [Page 32] 44]

Internet-Draft          IPFIX Information Model            November 2003            February 2004


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

   <element name="tcpControlBits" type="unsignedByte">
         </enumeration>

         <enumeration value="dataTimeMicroSeconds">
           <annotation>
     <documentation>
     <t>
      The TCP control bits seen for this flow. Note
             <documentation>The type "dateTimeSeconds" represents a 0
               time value for each
      bit only indicates that the flag was not detected (i.e. it may
      have occurred but was not detected by having a precision of microseconds and
               normalized to the reporting CCE). TCP
      Control Bits GMT timezone.
             </documentation>
           </annotation>
         </enumeration>

         <enumeration value="ipv4Address">
           <annotation>
             <documentation>The type "ipv4Addr" represents a value of
               an IPv4 address. These addresses are defined by RFC 793.
      </t> typically stored
               as 32-bit integers.
             </documentation>
     <appinfo>
       <ipfix:semantics>flags</ipfix:semantics>
     </appinfo>
     <appinfo>
       <ipfix:fieldId>6</ipfix:fieldId>
     </appinfo>
           </annotation>
   </element>

   <element name="ipV4SourceExporterAddress" type="ipdr:ipV4Addr">
         </enumeration>

         <enumeration value="ipv6Address">
           <annotation>
     <documentation>
     <t>
      The IPV4 address
             <documentation>The type "ipv6Addr" represents a value
               of the Exporter reporting the flow. This
      information is used by applications to later correlate the
      ingress/egress port with an IPv6 address.
             </documentation>
           </annotation>
         </enumeration>
       </restriction>
     </simpleType>

     <simpleType name="dataTypeSemantics">
       <restriction base="string">
         <enumeration value="quantity">
           <annotation>
             <documentation>
               A quantity value represents a specific Exporter. It is also used discrete
               measured value pertaining to
      maintain the source Exporter information when there record. This is
               distinguished from counters which represent an
      intermediate proxy. For example, ongoing
               measured value whose "odometer" reading is captured as
               part of a given the picture below:
     </t><t><figure><artwork xml:space="preserve">

                  SW1 --------    P1 ------ Collector
                                  ^
                                  |
                  SW2----------   |
      </artwork></figure></t><t>
      Flows coming from SW1 and SW2 through proxy P1 would look to the
      Collector like the same Exporter
      connection. With the Source Exporter in the message the original
      Exporter  address record. If no semantic qualifier is maintained.
      </t>
               given, the integral fields should behave as a quantity.
             </documentation>
     <appinfo>
       <ipfix:fieldId>-1</ipfix:fieldId>
     </appinfo>
           </annotation>
         </enumeration>




Calato, et al.          Expires May 21, August 16, 2004                [Page 33] 45]

Internet-Draft          IPFIX Information Model            November 2003


   </element>

   <element name="ipV6SourceExporterAddress" type="ipdr:ipV6Addr">            February 2004


         <enumeration value="counter">
           <annotation>
             <documentation>
     <t>
      The IPv4 address of the Exporter reporting  the flow. This
      information
               A measurement which is used by applications to later correlate ongoing from the
      ingress/egress port with a specific Exporter. It is also used to
      maintain perspective
               of the source Exporter information when there is an
      intermediate proxy. For example, given exporter.  Basically the picture below:
     </t><t><figure><artwork xml:space="preserve">

                  SW1 --------    P1 ------ Collector
                                  ^
                                  |
                  SW2----------   |
      </artwork></figure></t><t>
      Flows coming from SW1 same semantics as
               counters in SNMP.  Counters are unsigned and SW2 through proxy P1 would look wrap back
               to zero after reaching the
      Collector like limit of the same Exporter
      connection. With type. E.g. an
               unsigned64 with counter semantics will continue to
               increment until reaching the Source Exporter in value of 2**64 - 1.
               At this point the message next increment will wrap its value
               to zero and continue counting from zero.
             </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 original
      Exporter  address equality operation) are
               meaningless. E.g. Autonomous System Id 1 * Autonomous
               System Id 2 is maintained.
      </t> meaningless.
             </documentation>
     <appinfo>
       <ipfix:fieldId>-1</ipfix:fieldId>
     </appinfo>
           </annotation>
   </element>

   <element name="droppedPacketCount" type="unsignedLong">
         </enumeration>

         <enumeration value="flags">
           <annotation>
             <documentation>
     <t>
      Contains the count
               An integral value which actually represents a set of packets dropped at the observation point
      associated with the identified flow since the last report for this flow.
     </t>
               bit fields.  Logical operations are appropriate on
               such values, but not other mathematical operations.
               Flags should always be of an unsigned type.
             </documentation>
     <appinfo>
       <ipdr:units>packets</ipdr:units>
     </appinfo>
     <appinfo>
       <ipfix:fieldId>-1</ipfix:fieldId>
     </appinfo>
           </annotation>
   </element>

   <element name="samplingInterval" type="unsignedInt">
         </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>



Calato, et al.          Expires May 21, August 16, 2004                [Page 34] 46]

Internet-Draft          IPFIX Information Model            November 2003            February 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>
     <t>
      When using Sampling, the rate at which packets is sampled. For
      example, a value of 100 indicates
               Used for fields that one of every hundred
      packets is sampled.
      </t> are applicable to flow records
               as well as to option records.
             </documentation>
     <appinfo>
       <ipfix:fieldId>34</ipfix:fieldId>
     </appinfo>
           </annotation>
   </element>

   <element name="samplingAlgorithm" type="unsignedShort">
         </enumeration>
       </restriction>
     </simpleType>

     <simpleType name="status">
       <restriction base="string">
         <enumeration value="current">
           <annotation>
             <documentation>
     <t>
      The type of algorithm used for sampling data. Currently,
               Indicates that the only
      sampling algorithm defined  is:
      0x02 packet-sampling
     </t> field definition is that the
               definition is current and valid.
             </documentation>
     <appinfo>
       <ipfix:fieldId>35</ipfix:fieldId>
     </appinfo>
           </annotation>
   </element>

   <element name="flowEndState" type="unsignedByte">
         </enumeration>

         <enumeration value="deprecated">
           <annotation>
             <documentation>
     <t>
      The reason
               Indicates that the flow has ended.
           1. Inactivity timeout
           2. End of flow detected (e.g. TCP FIN)
           3. Forced end ????
           4. Cache full

      [enumerations field definition is obsolete, but
               it permits new/continued implementation in IPDR service def schemas are recommended order to be
       of form string, w/ integer values (for Compact format)
       defined via annotation]
      </t>
               foster interoperability with older/existing
               implementations.
             </documentation>
     <appinfo>
       <ipfix:fieldId>-1</ipfix:fieldId>
     </appinfo>
           </annotation>
         </enumeration>

         <enumeration value="obsolete">
           <annotation>
             <documentation>



Calato, et al.          Expires May 21, August 16, 2004                [Page 35] 47]

Internet-Draft          IPFIX Information Model            November 2003            February 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">
       <sequence>
         <element name="droppedByteCount" type="unsignedLong"> maxOccurs="unbounded" minOccurs="0"
                  name="paragraph" type="string">
           <annotation>
     <documentation>
      <t>
      Contains the count of octets dropped at the observation point
      associated with the identified flow since the last report for this flow.
      </t>
     </documentation>
     <appinfo>
       <ipdr:units>bytes</ipdr:units>
     </appinfo>
     <appinfo>
       <ipfix:fieldId>-1</ipfix:fieldId>
     </appinfo>
             <documentation>to be done ...</documentation>
           </annotation>
         </element>

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



Calato, et al.          Expires May 21, August 16, 2004                [Page 36] 48]

Internet-Draft          IPFIX Information Model            November 2003


Appendix B. Change History

   This document was originally based on a submission of the IETF draft
   document "IPFIX Data Model, Data Model for IP Flow Information
   Export",  draft-ietf-ipfix-data-00.txt. Written by Paul Calato and
   K.C. Norseth.  That document expired in August 2002. There was
   significant restructuring            February 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 the document to create teh first
   draft-ietf-ipfix-info-00.txt and a switch to using a more formal
   information model.

B.1 Changes Since -01 Revision

   Issue:  INFO-17  Variant Field Types

   Description:

   - allow in encoding, make explicit in this information model. Motivation element.
                       Describes how this field is if known integer quantities for a given exporter are in a smaller
   range, fewer bytes can be used to send across derived from the wire.

   A consumer should be made aware of
                       flow or other information available to the largest size any compliant
   should export - (information model)

   http://ipfix.doit.wisc.edu/archive/1935.html

   Issue:  INFO-18  Field semantics (counters vs. quantities)

   Description: Counters vs. Identifiers (OVMS) vs. Discrete Quantities
   (Gauge?)

   - explicitly distinguish between
                       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 two.  However, when it comes to
   storing results, e.g. to do reporting, a counter field is pretty much
   useless (i.e. a collector will likely turn a counter into an
   integer).

   - Counters measure of some kind, the
                       units identify what the measure is.
                     </documentation>
                   </annotation>
                 </element>

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

                 <element maxOccurs="1" minOccurs="0"
                          name="enumeratedRange" type="ipfix:enumRange">
                   <annotation>
                     <documentation>
                       Some items may NOT have a variable length, as this makes wrap
   calculation problematic.

   http://ipfix.doit.wisc.edu/archive/1981.html

   Issue:  INFO-19  Timestamps

   Description: http://ipfix.doit.wisc.edu/archive/2056.html

   - various resolutions and encoding formats can be specified:

   o seconds      - 32 bit since EPOCH specific set of numeric



Calato, et al.          Expires May 21, August 16, 2004                [Page 37] 49]

Internet-Draft          IPFIX Information Model            November 2003


   o milliseconds - 64 bit since EPOCH  (no rollover)

   o microseconds - ?

   o nanoseconds  - ? ** Use for NTP **

   o NTP format  - 232 picosecond resolution (1/2**32)

   Encoding options include:

   - simple 32-bit time (sec)

   - simple 64-bit time (msec)

   - high res 32-bit time (m or usec) relative to header time

   - very high res 2*32-bit time in NTP format sec.fraction

   Issue:  INFO-24  Use of signed versus unsigned

   Description: Many            February 2004


                       identifiers associated with a set of the items in the information model specify
   signed quantities, when these discrete
                       values will never go below zero.  Call
   them out as unsigned:

   - Sign bit on AS numbers x

   - Sign this element may take. The meaning of
                       each discrete value and direction 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 counters x

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

               <attribute name="dataType" type="ipfix:dataType"
                          use="required">
                 <annotation>
                   <documentation>
                     One of the types listed in the "Type Space"
                     section.  The type space for attributes is
                     constrained to facilitate implementation.
                     The existing type unsignedByte x

   - ClassOfService should be unsigned byte v. byte x

   - TcpControlBits should be an unsigned byte x

   - SamplingInterval should be unsignedInt x

   - SamplingAlgorithm space does however encompass
                     most basic types used in modern programming
                     languages, as unsignedShort x

   - FlowEndState well as unsigned (int or short) x

   - IfIndex (egress some derived types
                     (such as IPAddress) which are common to this
                     domain and ingress) can be 2**32 x

   Issue: INFO-21 FlowCreationTime/EndTime ids should be swithced 22,21

   Description: transcription error from NFv9. http://
   ipfix.doit.wisc.edu/archive/1919.html

   Issue: INFO-22 Flow Label is 3 bytes long? x - address through doc... useful to distinguish.
                   </documentation>
                 </annotation>
               </attribute>



Calato, et al.          Expires May 21, August 16, 2004                [Page 38] 50]

Internet-Draft          IPFIX Information Model            November 2003


   Description:            February 2004


               <attribute name="dataTypeSemantics"
                          type="ipfix:dataTypeSemantics" use="optional">
                 <annotation>
                   <documentation>
                     The integral types may be qualified by additional
                     semantic details. Qualifying the flow label field only has 20 bytes allocated to it.
   Hence it doesn't need a full int.  Is this an issue, fields as
                     'quantity', 'counter', 'identifier' or simply
   indicate this fact in info model. http://ipfix.doit.wisc.edu/archive/
   1919.html


B.2 Changes Since -00 Revision

   Issue:  INFO-1 reference section updates

   Issue:  INFO-2 change the XSL style sheet to reduce verbosity when
   creating human friendly information element section.

   Issue:  INFO-3 add discussion around use of the "ipdr:" namespace
   qualifier in some of the type fields.

   Issue: INFO-4 change reference from "flow id" to "field id"

   Issue: INFO-5 qualify the sourceExporterAddress with ipV4 and ipV6
   variants (still need field ID assignment)

   Issue: INFO-6 correct the fieldId value 'flags'.
                   </documentation>
                 </annotation>
               </attribute>

               <attribute name="fieldType" type="nonNegativeInteger"
                          use="required">
                 <annotation>
                   <documentation>
                     A numeric identifier administered by IANA.
                     This is used for packetCount to 2

   Issue: INFO-7 remove excessive whitespace in between words "IP flows"

   Issue: INFO-8 rewording in introduction section around

   Issue: INFO-9 remove "Definition of a Flow" section and merge wording
   with "Scope" section

   Issue: INFO-10 modifications to section "Properties compact identification of an IPFIX Flow
   Attribute"

   Issue: INFO-11 modify wording and capitalization
                     information item when encoding templates in "Type Space"
   introduction

   Issue: INFO-12 change wording of IPv6 type descriptrion

   Issue: INFO-13 change section title to be "Flow Attributes" from
   "Information Elements"

   Issue: INFO-14 move and combine the sections on "Use of XML-Schema"
   and "Benefits
                     protocol.
                   </documentation>
                 </annotation>
               </attribute>

               <attribute name="vendorId" type="nonNegativeInteger"
                          use="optional">
                 <annotation>
                   <documentation>
                     When extension is done outside of a Formal Information Model" to the back.  Leaving
   the readability scope of
                     the major front matter fairly "XML free".

   Issue: INFO-15 add "Security Considerations" section which IANA IPFIX fieldId range, a vendorId MUST
                     be provided.  This identifier is
   mandatory. based on IANA
                     assigned enterprise identifiers.
                   </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>



Calato, et al.          Expires May 21, August 16, 2004                [Page 39] 51]

Internet-Draft          IPFIX Information Model            November 2003


   Issue: INFO-16 modify abstract following additional comments from
   Juergen.            February 2004


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

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

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







































Calato, et al.          Expires May 21, August 16, 2004                [Page 40] 52]

Internet-Draft          IPFIX Information Model            November 2003            February 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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 does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication 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 or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.


Full Copyright Statement

   Copyright (C) The Internet Society (2003). (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 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.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION



Calato, et al.          Expires May 21, August 16, 2004                [Page 41] 53]

Internet-Draft          IPFIX Information Model            November 2003            February 2004


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgement


Acknowledgment

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











































Calato, et al.          Expires May 21, August 16, 2004                [Page 42] 54]
----