view Side-By-Side changes

Network Working Group                                          P. Calato
Internet-Draft                                   Riverstone Networks Inc
Expires: August 16, 2004                                           J. Meyer
Internet-Draft                                                    PayPal
Expires: January 17, 2005                                     J. Quittek
                                                                     NEC Europe Ltd.
                                                       February 16,
                                                               S. Bryant
                                                       Cisco Systems Ltd
                                                           July 19, 2004


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

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 August 16, 2004. January 17, 2005.

Copyright Notice

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

Abstract

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





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


Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   4   5
   2.   Properties of IPFIX Protocol Fields  . . . . . . . . . . . .   5   6
   3.   Type Space . . . . . . . . . . . . . . . . . . . . . . . . .   7   8
   3.1  octet  . . . . . . . . . . . . . . . . . . . . . . . . . . .   7   8
   3.2  unsigned16 . . . . . . . . . . . . . . . . . . . . . . . . .   7   8
   3.3  unsigned32 . . . . . . . . . . . . . . . . . . . . . . . . .   7   8
   3.4  unsigned64 . . . . . . . . . . . . . . . . . . . . . . . . .   7   8
   3.5  float32  . . . . . . . . . . . . . . . . . . . . . . . . . .   7   8
   3.6  boolean  . . . . . . . . . . . . . . . . . . . . . . . . . .   7   8
   3.7  octetArray . . . . . . . . . . . . . . . . . . . . . . . . .   7   8
   3.8  string . . . . . . . . . . . . . . . . . . . . . . . . . . .   7   8
   3.9  dateTimeSeconds  . . . . . . . . . . . . . . . . . . . . . .   8   9
   3.10 dataTimeMicroSeconds . . . . . . . . . . . . . . . . . . . .   8   9
   3.11 ipv4Address  . . . . . . . . . . . . . . . . . . . . . . . .   8   9
   3.12 ipv6Address  . . . . . . . . . . . . . . . . . . . . . . . .   8   9
   4.   Flow Attributes  . . . . . . . . . . . . . . . . . . . . . .   9  10
   4.1  octetCount  deltaOctetCount  . . . . . . . . . . . . . . . . . . . . . . . . .   9  10
   4.2  packetCount  .  deltaPacketCount . . . . . . . . . . . . . . . . . . . . . . .   9  10
   4.3  flowCount  .  totalFlowCount . . . . . . . . . . . . . . . . . . . . . . . .   9  10
   4.4  protocolIdentifier . . . . . . . . . . . . . . . . . . . . .   9  11
   4.5  classOfService .  classOfServiceV4 . . . . . . . . . . . . . . . . . . . . . .  10  11
   4.6  tcpControlBits . . . . . . . . . . . . . . . . . . . . . . .  11
   4.7  sourcePort . .  transportSourcePort  . . . . . . . . . . . . . . . . . . . . . . .  11  12
   4.8  sourceAddressV4  . . . . . . . . . . . . . . . . . . . . . .  11  13
   4.9  sourceMask .  sourceMaskV4 . . . . . . . . . . . . . . . . . . . . . . . .  12  13
   4.10 ingressInterface . . . . . . . . . . . . . . . . . . . . . .  12  13
   4.11 destinationPort transportDestinationPort . . . . . . . . . . . . . . . . . . . . . .  12  14
   4.12 destinationAddressV4 . . . . . . . . . . . . . . . . . . . .  13  14
   4.13 destinationMask destinationMaskV4  . . . . . . . . . . . . . . . . . . . . . .  13  15
   4.14 egressInterface  . . . . . . . . . . . . . . . . . . . . . .  13  15
   4.15 ipNextHopAddressV4 . . . . . . . . . . . . . . . . . . . . .  13  15
   4.16 sourceAsNumber . . . . . . . . . . . . . . . . . . . . . . .  14  15
   4.17 destinationAsNumber  . . . . . . . . . . . . . . . . . . . .  14  16
   4.18 bgpNextHopAddressV4  . . . . . . . . . . . . . . . . . . . .  14  16
   4.19 mcPacketsSent  . . . OutMulticastPacketCount  . . . . . . . . . . . . . . . . . . . .  15  16
   4.20 mcOctetsSent . . . . OutMulticastOctetCount . . . . . . . . . . . . . . . . . . . .  15  17
   4.21 flowEndTime  . . . . . . . . . . . . . . . . . . . . . . . .  15  17
   4.22 flowCreationTime . . . . . . . . . . . . . . . . . . . . . .  15  17
   4.23 sourceAddressV6 deltaOutOctetCount . . . . . . . . . . . . . . . . . . . . . .  15  17
   4.24 destinationAddressV6 deltaOutPacketCount  . . . . . . . . . . . . . . . . . . . .  15  18
   4.25 anotherSourceMask minPacketLength  . . . . . . . . . . . . . . . . . . . . .  16 .  18
   4.26 destinationMask maxPacketLength  . . . . . . . . . . . . . . . . . . . . . .  16  18
   4.27 flowLabel  . . . sourceAddressV6  . . . . . . . . . . . . . . . . . . . . . .  16  18
   4.28 icmpTypeCode . . . . destinationAddressV6 . . . . . . . . . . . . . . . . . . . .  17  19
   4.29 igmpType . . sourceMaskV6 . . . . . . . . . . . . . . . . . . . . . . . .  17  19
   4.30 samplingInterval destinationMaskV6  . . . . . . . . . . . . . . . . . . . . . .  17



Calato,  19



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


   4.31 samplingAlgorithm flowLabelV6  . . . . . . . . . . . . . . . . . . . . .  17 . . .  19
   4.32 flowReportingInterval icmpTypeCode . . . . . . . . . . . . . . . . . . .  18 . . . . .  20
   4.33 flowIdleTimeout igmpType . . . . . . . . . . . . . . . . . . . . . .  18 . . . .  20
   4.34 exportedOctetCount flowActiveTimeOut  . . . . . . . . . . . . . . . . . . . . .  18  20
   4.35 exportedPacketCount flowInactiveTimeout  . . . . . . . . . . . . . . . . . . . .  18  21
   4.36 exportedFlowCount exportedOctetCount . . . . . . . . . . . . . . . . . . . . .  19  21
   4.37 ipVersion  . . exportedPacketCount  . . . . . . . . . . . . . . . . . . . .  21
   4.38 exportedFlowCount  . . .  19
   4.38 ipNextHopAddressV6 . . . . . . . . . . . . . . . . . .  21
   4.39 sourcePrefixV4 . . .  19
   4.39 bgpNextHopAddressV6 . . . . . . . . . . . . . . . . . . . .  20  22
   4.40 bgpNextHopAsNumber . destinationPrefixV4  . . . . . . . . . . . . . . . . . . . .  20  22
   4.41 ipNextHopAsNumber mplsTopLabelType . . . . . . . . . . . . . . . . . . . . .  20 .  22
   4.42 exporterAddressV4 mplsTopLabelIPAddressV4  . . . . . . . . . . . . . . . . . .  23
   4.43 minimumTTL . . .  20
   4.43 exporterAddressV6 . . . . . . . . . . . . . . . . . . . . .  21 .  23
   4.44 droppedOctetCount maximumTTL . . . . . . . . . . . . . . . . . . . . .  21 . . . .  23
   4.45 droppedPacketCount identificationV4 . . . . . . . . . . . . . . . . . . . . .  21 .  23
   4.46 flowEndReason sourceMacAddress . . . . . . . . . . . . . . . . . . . . . .  24
   4.47 ipVersion  .  21
   5.   Extending the Information Model . . . . . . . . . . . . . .  23
   6.   IANA Considerations . . . . . . . . . .  24
   4.48 ipNextHopAddressV6 . . . . . . . . . .  24
   7.   Security Considerations . . . . . . . . . . .  24
   4.49 bgpNextHopAddressV6  . . . . . . .  25
   8.   Acknowledgements . . . . . . . . . . . . .  25
   4.50 ipv6OptionHeaders  . . . . . . . . .  26
        Normative Reference . . . . . . . . . . . .  25
   4.51 partialMPLSLabelStackEntry1  . . . . . . . . . . . . . . . .  26
   4.52 partialMPLSLabelStackEntry2  . . . . . . . . . . . . . . . .  26
   4.53 partialMPLSLabelStackEntry3  . . . . . . . . . . . . . . . .  27
        Informative Reference
   4.54 partialMPLSLabelStackEntry4  . . . . . . . . . . . . . . . .  27
   4.55 partialMPLSLabelStackEntry5  . . . . . . . . . . . . . . . .  27
   4.56 partialMPLSLabelStackEntry6  . . . . . . . . . . . . . . . .  28
        Authors' Addresses
   4.57 partialMPLSLabelStackEntry7  . . . . . . . . . . . . . . . .  28
   4.58 partialMPLSLabelStackEntry8  . . . . . . . . . . . . . . . .  28
   4.59 partialMPLSLabelStackEntry9  . . . . . . . . . . . . . . . .  29
   A.   Formal Specification of IPFIX Fields
   4.60 partialMPLSLabelStackEntry10 . . . . . . . . . . . . . . . .  29
   4.61 runningOctetCounter  . . . . . . . . . . . . . . . . . . . .  29
   4.62 runningPacketCounter . . . . . . . . . . . . . . . . . . . .  30
   B.   Formal Specification of Abstract Data Types
   4.63 bgpNextHopAsNumber . . . . . . . .  43
        Intellectual Property and Copyright Statements . . . . . . .  53

























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


1. Introduction

   The IP Flow Information eXport (IPFIX) protocol serves for
   transmitting information related to measured IP traffic over the
   Internet.  The protocol specification in [IPFIX-PROTO] defines how
   information elements are transmitted.  For information elements, it
   specifies the encoding of a set of basic data types.  However, the
   list of fields that can be transmitted by the protocol, such as flow
   attributes (source IP address, number of . . . . . .  30
   4.64 ipNextHopAsNumber  . . . . . . . . . . . . . . . . . . . . .  30
   4.65 exporterAddressV4  . . . . . . . . . . . . . . . . . . . . .  31
   4.66 exporterAddressV6  . . . . . . . . . . . . . . . . . . . . .  31
   4.67 droppedOctetDeltaCount . . . . . . . . . . . . . . . . . . .  31
   4.68 droppedPacketDeltaCount  . . . . . . . . . . . . . . . . . .  32
   4.69 droppedOctetTotalCount . . . . . . . . . . . . . . . . . . .  32
   4.70 droppedPacketTotalCount  . . . . . . . . . . . . . . . . . .  32
   4.71 flowEndReason  . . . . . . . . . . . . . . . . . . . . . . .  32
   4.72 classOfServiceV6 . . . . . . . . . . . . . . . . . . . . . .  33
   5.   Extending the Information Model  . . . . . . . . . . . . . .  34
   6.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .  35
   7.   Security Considerations  . . . . . . . . . . . . . . . . . .  36
   8.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  37
        Normative Reference  . . . . . . . . . . . . . . . . . . . .  38
        Informative Reference  . . . . . . . . . . . . . . . . . . .  39



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


        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  40
   A.   Formal Specification of IPFIX Fields . . . . . . . . . . . .  41
   B.   Formal Specification of Abstract Data Types  . . . . . . . .  63
        Intellectual Property and Copyright Statements . . . . . . .  73















































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


1. Introduction

   The IP Flow Information eXport (IPFIX) protocol serves for
   transmitting information related to measured IP traffic over the
   Internet.  The protocol specification in [IPFIX-PROTO] defines how
   information elements are transmitted.  For information elements, it
   specifies the encoding of a set of basic data types.  However, the
   list of fields that can be transmitted by the protocol, such as flow
   attributes (source IP address, number of packets, etc.) and
   information about
   information about the metering and exporting process (packet
   observation point, smapling rate, flow timeout interval, etc.), is
   not specified in [IPFIX-PROTO].

   This document complements the IPFIX protocol specification by
   providing the IPFIX information model.  The main part of this
   document is Section 5 defines the (extensible) list of fields to be
   transmitted by the IPFIX protcol.  Section 2 defines a template for
   specifying IPFIX fields that is used in Section 4.  Section 3 defines
   the set of abstract data types that are available for IPFIX fields.
   Section 5 discusses extensibility of the IPFIX information model.

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

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

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













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


2. Properties of IPFIX Protocol Fields

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

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

   name - 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").

   fieldType - A numeric identifier administered by IANA. This is used
      for compact identification of an information item when encoding
      templates in the protocol.

   description - The semantics of this information element. Describes
      how this field is derived from the flow or other information
      available to the observer.

   dataType - One of the types listed in the "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.

   dataTypeSemantics - The integral types may be qualified by additional
      semantic details. Qualifying the fields as 'quantity', 'counter',
      'identifier' or 'flags'.

   applicability - to be done ...

   status - to be done ...

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

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

   usage - to be done ...





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


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

   enumeratedRange - Some items may have a specific set of numeric
      identifiers associated with a set of discrete values this element
      may take. The meaning of each discrete value and a human readable
      name should be assigned.

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

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




































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


3. Type Space

   The following subsections describe the abstract data types that can
   be used for the specification of IPFIX fields in Section 4.

3.1 octet

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

3.2 unsigned16

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

3.3 unsigned32

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

3.4 unsigned64

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

3.5 float32

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

3.6 boolean

   The type "boolean" represents a binary value.

3.7 octetArray

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

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.





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


3.9 dateTimeSeconds

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

3.10 dataTimeMicroSeconds

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

3.11 ipv4Address

   The type "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 value of an IPv6 address.































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


4. Flow Attributes

4.1 deltaOctetCount

   Description:

      The number of octets in (incoming) packets observed for this flow
      at the observation point since the previous report (if any). The
      number of octets include IP header(s) and IP payload.

   Abstract Data Type: unsigned64

   Data Type Semantics: deltaCounter

   Field Id: 1

   Units: octets

4.2 deltaPacketCount

   Description:

      The number of (incoming) packets observed for this flow at the
      observation point since the previous report (if any).

   Abstract Data Type: unsigned64

   Data Type Semantics: deltaCounter

   Field Id: 2

   Units: packets

4.3 totalFlowCount

   Description:

      The number of flows observed so far in the observation domain.

   Abstract Data Type: unsigned64

   Data Type Semantics: runningCounter

   Field Id: 3

   Units: flows





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


4.4 protocolIdentifier

   Description:

      The protocol number observed for packets of this flow. The
      protocol number identifies the IP packet payload. Protocol numbers
      are defined in the IANA Protocol Numbers registry.

      In Internet Protocol version 4 (IPv4) this is carried in the
      "Protocol" field. In Internet Protocol version 6 (IPv6) this is
      carried in the "Next Header" field in the last extension header of
      the packet.

   Abstract Data Type: octet

   Data Type Semantics: identifier

   Field Id: 4

   Reference:

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


4.5 classOfServiceV4

   Description:

      The value of the IPv4 TOS field observed for packets of this flow.

   Abstract Data Type: octet

   Data Type Semantics: identifier

   Field Id: 5

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


4.6 tcpControlBits

   Description:






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


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

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

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

   Abstract Data Type: octet

   Data Type Semantics: flags

   Field Id: 6

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


4.7 transportSourcePort

   Description:

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

   Abstract Data Type: unsigned16

   Data Type Semantics: identifier

   Field Id: 7





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


   Reference:

      See RFC 768 for the metering definition of the UDP source port field. See
      RFC 793 for the definition of the TCP source port field. See RFC
      2960 for the definition of SCTP.

      Additional information on defined UDP and exporting process (packet
   observation point, smapling rate, flow timeout interval, etc.), is
   not specified TCP port numbers can be
      found at http://www.iana.org/assignments/port-numbers.


4.8 sourceAddressV4

   Description:

      IPv4 source address taken from the IP packet header of a packet of
      this flow.

   Abstract Data Type: ipv4Address

   Field Id: 8

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


4.9 sourceMaskV4

   Description:

      The number of contiguous bits that are relevant in [IPFIX-PROTO].

   This document complements the IPFIX protocol specification by
   providing
      sourceAddressV4 field.

   Abstract Data Type: octet

   Field Id: 9

   Units: bits

4.10 ingressInterface

   Description:

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

   Abstract Data Type: unsigned32

   Data Type Semantics: identifier



Meyer, et al.           Expires January 17, 2005               [Page 13]

Internet-Draft          IPFIX information model.  The main part Information Model                July 2004


   Field Id: 10

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


4.11 transportDestinationPort

   Description:

      A destination port identifier in the transport header. For
      transport protocols UDP, TCP and SCTP this
   document is Section 5 defines the (extensible) list destination port
      number given in the respective header. This field MAY also be used
      for future transport protocols that have 16 bit destination port
      identifiers.

   Abstract Data Type: unsigned16

   Data Type Semantics: identifier

   Field Id: 11

   Reference:

      See RFC 768 for the definition of fields to be
   transmitted by the IPFIX protcol.  Section 2 defines a template UDP source port field. See
      RFC 793 for
   specifying IPFIX fields that is used in Section 4.  Section 3 defines the set definition of abstract data types that are available the TCP source port field. See RFC
      2960 for IPFIX fields.
   Section 5 discusses extensibility of the IPFIX information model.

   The main bodies of Sections 2, 3 and 4 were generated from XML
   documents.  The XML-based specification definition of template, abstract data
   types SCTP.

      Additional information on defined UDP and IPFIX fields TCP port numbers can be used for automatically checking
   syntactical correctness of
      found at http://www.iana.org/assignments/port-numbers.


4.12 destinationAddressV4

   Description:

      IPv4 destination address taken from the specification IP packet header of IPFIX fields.
   Further it can be used for generating IPFIX protocol implementation
   code that deals with processing IPFIX fields.  Also code a
      packet of this flow.

   Abstract Data Type: ipv4Address

   Field Id: 12

   Reference: See RFC 791 for
   applications that further process traffic information transmitted via
   the IPFIX protocol can be generated with the XML specification definition of the IPv4 destination
      address field.







Meyer, et al.           Expires January 17, 2005               [Page 14]

Internet-Draft          IPFIX fields.

   For Information Model                July 2004


4.13 destinationMaskV4

   Description:

      The number of contiguous bits that reason, are relevant in the XML document that served as source for Section 4
   and
      destinationAddressV4 field.

   Abstract Data Type: octet

   Field Id: 13

   Units: bits

4.14 egressInterface

   Description:

      The index of the XML schema that served as source IP interface (ifIndex) where packets of this flow
      are being sent.

   Abstract Data Type: unsigned32

   Data Type Semantics: identifier

   Field Id: 14

   Reference: See RFC 2863 for Sections 2 and 3 are
   attached the definition of the ifIndex object.


4.15 ipNextHopAddressV4

   Description:

      The IPv4 address of the next IP hop to which packets of this document in Appendices A and B.

   Note that although partially generated from flow
      are forwarded.

   Abstract Data Type: ipv4Address

   Field Id: 15

4.16 sourceAsNumber

   Description:

      The autonomous system (AS) number of the attached XML
   documents, source address in the main body IP
      packet header in a packet of this document is normative while the
   appendices are informational.













Calato, flow.

   Abstract Data Type: unsigned16



Meyer, et al.           Expires August 16, 2004 January 17, 2005               [Page 4] 15]

Internet-Draft          IPFIX Information Model            February                July 2004


2. Properties


   Data Type Semantics: identifier

   Field Id: 16

   Reference: See RFC 1771 for a description of IPFIX Protocol Fields

   Fields BGB-4 and see RFC 1930 a
      definition of the IPFIX protocol carrying information about traffic
   measurement are modeled as elements AS number.


4.17 destinationAsNumber

   Description:

      The autonomous system (AS) number of the IPFIX information model
   and specified destination address in Section 4.  For defining the fields, a template is
   used that is specified below.

   All fields specified for
      the IPFIX protocol either IP packet header in a packet of this document
   or by an extension MUST have the following properties defined:

   name - 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").

   fieldType - A numeric flow.

   Abstract Data Type: unsigned16

   Data Type Semantics: identifier administered by IANA. This is used

   Field Id: 17

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


4.18 bgpNextHopAddressV4

   Description:

      The IPv4 address of an information item when encoding
      templates in the protocol. next BGP hop to which packets of this flow
      are forwarded.

   Abstract Data Type: ipv4Address

   Field Id: 18

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


4.19 OutMulticastPacketCount

   Description:

      The semantics number of outgoing multicast packets created for packets of
      this information element. Describes
      how this field is derived from the flow or other information
      available to the observer.

   dataType - One by an adjacent multicast daemon. Note that typically not
      all of the types listed in created packets can be observed at the "Type Space" section. The
      type space for attributes is constrained to facilitate
      implementation. observation
      point of this flow.



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


   Abstract Data Type: unsigned64

   Field Id: 19

   Units: packets

4.20 OutMulticastOctetCount

   Description:

      The existing type space does however encompass
      most basic types used number of octets in modern programming languages, as well as
      some derived types (such as IPAddress) which are common to outgoing multicast packets created for
      packets of this
      domain and useful to distinguish.

   dataTypeSemantics - The integral types may be qualified flow by additional
      semantic details. Qualifying an adjacent multicast daemon. Note that
      typically not all of the fields as 'quantity', 'counter',
      'identifier' or 'flags'.

   applicability - to be done ...

   status - to created packets can be done ...

   All fields specified for observed at the
      observation point of this flow.

   Abstract Data Type: unsigned64

   Field Id: 20

   Units: octets

4.21 flowEndTime

   Description: The timestamp of the last packet of this flow.

   Abstract Data Type: dateTimeSeconds

   Field Id: 21

4.22 flowCreationTime

   Description: The timestamp of the IPFIX protocol either first packet of this flow.

   Abstract Data Type: dateTimeSeconds

   Field Id: 22

4.23 deltaOutOctetCount

   Description:

      The number of octets in outgoing packets observed for this document
   or by an extension MAY have flow at
      the following properties defined:

   vendorId - When extension is done outside of observation point since the scope previous report (if any). The
      number of the IANA
      IPFIX fieldId range, a vendorId MUST be provided. This identifier
      is based on IANA assigned enterprise identifiers.

   usage - to be done ...





Calato, octets include IP header(s) and IP payload.

   Abstract Data Type: unsigned64

   Data Type Semantics: deltaCounter



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


   units - If the field is a measure


   Field Id: 23

   Units: octets

4.24 deltaOutPacketCount

   Description:

      The number of some kind, outgoing packets observed for this flow at the units identify
      what
      observation point since the measure is.

   enumeratedRange - Some items may have a specific set of numeric
      identifiers associated with a set previous report (if any).

   Abstract Data Type: unsigned64

   Data Type Semantics: deltaCounter

   Field Id: 24

   Units: packets

4.25 minPacketLength

   Description:

      Length of discrete values the smallest packet observed for this element
      may take. The meaning of each discrete value and a human readable
      name should be assigned.

   range - Some elements may only be able to take on a restricted set flow.

   Abstract Data Type: unsigned16

   Field Id: 25

   Units: octets

4.26 maxPacketLength

   Description:

      Length 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, largest packet observed for this flow.

   Abstract Data Type: unsigned16

   Field Id: 26

   Units: octets

4.27 sourceAddressV6

   Description:





Meyer, et al.           Expires August 16, 2004 January 17, 2005               [Page 6] 18]

Internet-Draft          IPFIX Information Model            February                July 2004


3. Type Space

   The following subsections describe the abstract data types that can
   be used for the specification of IPFIX fields in Section 4.

3.1 octet

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

3.2 unsigned16

   The type "unsigned16" represents a non-negative integer value in


      IPv6 source address taken from the
   range IP packet header of 0 to 65535.

3.3 unsigned32

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

3.4 unsigned64

   The type "unsigned64" represents a non-negative integer value in
      this flow.

   Abstract Data Type: ipv6Address

   Field Id: 27

4.28 destinationAddressV6

   Description:

      IPv6 destination address taken from the
   range IP packet header of 0 to 18446744073709551615.

3.5 float32

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

3.6 boolean

   The type "boolean" represents a binary value.

3.7 octetArray

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

3.8 string this flow.

   Abstract Data Type: ipv6Address

   Field Id: 28

4.29 sourceMaskV6

   Description:

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





Calato, the
      sourceAddressV6 field.

   Abstract Data Type: octet

   Field Id: 29

   Units: bits

4.30 destinationMaskV6

   Description:

      The number of contiguous bits that are relevant in the
      destinationAddressV6 field.

   Abstract Data Type: octet

   Field Id: 30

   Units: bits

4.31 flowLabelV6






Meyer, et al.           Expires August 16, 2004 January 17, 2005               [Page 7] 19]

Internet-Draft          IPFIX Information Model            February                July 2004


3.9 dateTimeSeconds


   Description:

      The type "dateTimeSeconds" represents Flow Label of the IPv6 packet header observed in a time value having packet of
      this flow.

   Abstract Data Type: unsigned32

   Field Id: 31

   Reference: See RFC 2460 for a precision definition of seconds and normalized to the GMT timezone. Such types are flow label field in
   common use on many operating systems
      the IPv6 packet header.


4.32 icmpTypeCode

   Description:

      Type and have Code of the advantage that they
   can be stored in 32-bit integers.

3.10 dataTimeMicroSeconds ICMP message. The combination of both values
      is reported as (ICMP type "dateTimeSeconds" represents a time value having * 256) + ICMP code.

   Abstract Data Type: unsigned16

   Field Id: 32

   Reference: See RFC 792 for a precision definition of microseconds and normalized to the GMT timezone.

3.11 ipv4Address ICMP type and code
      fields.


4.33 igmpType

   Description: The type "ipv4Addr" represents field of the IGMP message.

   Abstract Data Type: octet

   Field Id: 33

   Reference: See RFC 2236 for a value definition of the IGMP type field.


4.34 flowActiveTimeOut

   Description:

      The number of seconds after which an IPv4 address. These
   addresses are typically stored as 32-bit integers.

3.12 ipv6Address active flow is timed out
      anyway, even if there is still a continuous flow of packets.

   Abstract Data Type: unsigned16




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


   Field Id: 36

   Units: seconds

4.35 flowInactiveTimeout

   Description:

      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.

   Abstract Data Type: unsigned16

   Field Id: 37

   Units: seconds

4.36 exportedOctetCount

   Description:

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































Calato, all octets reported by the exporting process to this
      collecting process.

   Abstract Data Type: unsigned64

   Field Id: 40

   Units: octets

4.37 exportedPacketCount

   Description:

      The number of all packets reported by the exporting process to
      this collecting process.

   Abstract Data Type: unsigned64

   Field Id: 41

   Units: packets

4.38 exportedFlowCount






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


4. Flow Attributes

4.1 octetCount


   Description:

      The number of observed octets. all flows records reported by the exporting process
      to this collecting process.

   Abstract Data Type: unsigned64

   Field Id: 1 42

   Units: octets

4.2 packetCount flows

4.39 sourcePrefixV4

   Description: The number of observed packets.

      IPv4 source address prefix.

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

   Abstract Data Type: unsigned64 ipV4Address

   Field Id: 2 44

   Units: packets

4.3 flowCount flows

4.40 destinationPrefixV4

   Description: The number of (aggregated) flows.

      IPv4 destination address prefix.

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

   Abstract Data Type: unsigned64 ipV4Address

   Field Id: 3 45

   Units: flows

4.4 protocolIdentifier

4.41 mplsTopLabelType

   Description:

      The

      MPLS top label type:

      This field identifies the control protocol number that identifies allocated the IP packet payload.
      Protocol numbers are defined in top
      of stack label.




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


   Abstract Data Type: octet

   Data Type Semantics: identifier

   Field Id: 46

4.42 mplsTopLabelIPAddressV4

   Description:

      The IPv4 address of the IANA Protocol Numbers
      registry.

      In Internet Protocol version 4 (IPv4) system that the MPLS top label will cause
      this is carried packet to be forwarded to.

   Abstract Data Type: ipV4Address

   Field Id: 47

4.43 minimumTTL

   Description:

      Minimum TTL value observed for any packet in the
      "Protocol" field. In Internet Protocol version 6 (IPv6) this is
      carried flow.

   Abstract Data Type: octet

   Field Id: 52

4.44 maximumTTL

   Description:

      Maximum TTL value observed for any packet in this flow.

   Abstract Data Type: octet

   Field Id: 53

4.45 identificationV4

   Description:

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

   Abstract Data Type: octet

   Data Type Semantics: identifier




Calato,

   Field Id: 54



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


   Field Id: 4


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


4.46 sourceMacAddress

   Description:

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

   Abstract Data Type: octet

   Field Id: 56

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


4.5 classOfService


4.47 ipVersion

   Description: The class of service.

      The definition of classOfService is dependent on the protocol
      being observed. Those considered here are:

      *  For IPv4 packets the class of service is IP version field given by in the value IP header.

   Abstract Data Type: octet

   Field Id: 60

   Units: flows

   Reference:

      See RFC 791 for a definition of the type of service version field in the IPv4 IPv6
      packet header.

      *  For IPv6 packets the class of service is given by the value See RFC 2460 for a definition of the traffic class version field
      in the IPv6 packet header.

      *  For MPLS the class of service is given by the value of the
         experimental use (Exp) field in label stack entries. Additional information on defined
      version numbers can be found at http://www.iana.org/assignments/
      version-numbers.


4.48 ipNextHopAddressV6

   Description:

      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 IPv6 address of the octet are set next BGP hop to zero.

      *  For VLAN the class which packets of service is given by the value this flow
      are forwarded.

   Abstract Data Type: ipv6Address

   Field Id: 62




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


4.49 bgpNextHopAddressV6

   Description:

      The IPv6 address of the type next BGP hop to which packets of the user_priority field as defined in IEEE802.1q[802.1q] and
         IEEE 802.1p[802.1p].

      EDITORS' NOTE: THIS NEEDS FURTHER WORK this flow
      are forwarded.

   Abstract Data Type: octet ipv6Address

   Data Type Semantics: identifier

   Field Id: 5 63

   Reference: See RFC 791 for the definition of the IPv4 TOS field. See RFC 2460 1771 for the definition a description of the IPv6 traffic class field. BGB-4. See RFC 3032
      for the 1930 a
      definition of the Exp field AS number.


4.50 ipv6OptionHeaders

   Description:

      IPv6 options in label stack entries. See



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


      IEEE802.1q and IEEE 802.1p for the definition IP packet headers of the VLAN
      user_priority field.


4.6 tcpControlBits

   Description:

      The TCP control bits seen for this flow.  Note that This is
      encoded as a 0 value for
      each bit only indicates that the flag was field.

      bit      IPv6 Option    Definition

       0                       Reserved
       1        44             Fragmentation header -
                               not detected (i.e. it
      may have occurred but was first fragment
       2        43             Routing header
       3        44             Fragmentation header -
                               first fragment
       4                       Unknown Layer 4 header
                               (compressed, encrypted,
                               not detected by the reporting CCE).
      EDITORS' NOTE: THIS NEEDS FURTHER WORK. The bit mapping needs supported)
       5                       Reserved
       6         0             Hop-by-hop option header
       7        60             Destination option
                               header
       8       108             Payload compression
                               header
       9        51             Authentication Header
      10        50             Encrypted security
                               payload
      11 to
      be specified. 31                 Reserved

   Abstract Data Type: octet unsigned32




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


   Data Type Semantics: flags

   Field Id: 6 64

   Reference: See RFC 793 for a definiton of the TCP control bits in the
      TCP header.


4.7 sourcePort To be done.


4.51 partialMPLSLabelStackEntry1

   Description: A source port number in

      The label, exp and s fields from the UDP or TCP header,
      respectively. outermost MPLS label stack
      entry e.g. the last label that was pushed last.

       0                   1                   2                   
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Label                  | Exp |S|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      
      Label:  Label Value, 20 bits
      Exp:    Experimental Use, 3 bits
      S:      Bottom of Stack, 1 bit

   Abstract Data Type: unsigned16

   Data Type Semantics: identifier unsigned32

   Field Id: 7 70

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


4.8 sourceAddressV4 3032.


4.52 partialMPLSLabelStackEntry2

   Description:

      The IPv4 source address in label, exp and s fields from the IPv4 packet header. LSE that was pushed
      immediately before the LSE that would be reported by
      partialMplsLse1. See the definition of partialMplsLse1 for further
      details.

   Abstract Data Type: ipv4Address



Calato, unsigned32

   Field Id: 71

   Reference: See RFC 3032.






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


4.53 partialMPLSLabelStackEntry3

   Description:

      The label, exp and s fields from the LSE that was pushed
      immediately before the LSE that would be reported by
      partialMplsLse2. See the definition of partialMplsLse1 for further
      details.

   Abstract Data Type: unsigned32

   Field Id: 8 72

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


4.9 sourceMask 3032.


4.54 partialMPLSLabelStackEntry4

   Description:

      The number of contiguous bits that are relevant in label, exp and s fields from the
      source address field of LSE that was pushed
      immediately before the IP packet header (i.e. LSE that would be reported by
      partialMplsLse3. See the subnet mask
      in slash notation). definition of partialMplsLse1 for further
      details.

   Abstract Data Type: octet unsigned32

   Field Id: 9

   Units: bits

4.10 ingressInterface 73

   Reference: See RFC 3032.


4.55 partialMPLSLabelStackEntry5

   Description:

      The index of label, exp and s fields from the IP interface (ifIndex) where packets LSE that was pushed
      immediately before the LSE that would be reported by
      partialMplsLse4. See the definition of
      a flow are being received. partialMplsLse1 for further
      details.

   Abstract Data Type: unsigned32

   Data Type Semantics: identifier

   Field Id: 10 74

   Reference: See RFC 2863 for 3032.





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


4.56 partialMPLSLabelStackEntry6

   Description:

      The label, exp and s fields from the definition of LSE that was pushed
      immediately before the ifIndex object.


4.11 destinationPort

   Description: A destination port number in LSE that would be reported by
      partialMplsLse5. See the UDP or TCP header,
      respectively. definition of partialMplsLse1 for further
      details.

   Abstract Data Type: unsigned16

   Data Type Semantics: identifier unsigned32

   Field Id: 11 75

   Reference: See RFC 768 for 3032.


4.57 partialMPLSLabelStackEntry7

   Description:

      The label, exp and s fields from the definiton of LSE that was pushed
      immediately before the UDP destination port field. LSE that would be reported by
      partialMplsLse6. See RFC 793 for the definiton definition of the TCP destination port field.
      Additional information on defined UDP partialMplsLse1 for further
      details.

   Abstract Data Type: unsigned32

   Field Id: 76

   Reference: See RFC 3032.


4.58 partialMPLSLabelStackEntry8

   Description:

      The label, exp and TCP port numbers can s fields from the LSE that was pushed
      immediately before the LSE that would be



Calato, reported by
      partialMplsLse7. See the definition of partialMplsLse1 for further
      details.

   Abstract Data Type: unsigned32

   Field Id: 77

   Reference: See RFC 3032.





Meyer, et al.           Expires August 16, 2004 January 17, 2005               [Page 12] 28]

Internet-Draft          IPFIX Information Model            February                July 2004


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


4.12 destinationAddressV4


4.59 partialMPLSLabelStackEntry9

   Description:

      The IPv4 destination address in label, exp and s fields from the IPv4 packet header. LSE that was pushed
      immediately before the LSE that would be reported by
      partialMplsLse8. See the definition of partialMplsLse1 for further
      details.

   Abstract Data Type: ipv4Address unsigned32

   Field Id: 12 78

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


4.13 destinationMask 3032.


4.60 partialMPLSLabelStackEntry10

   Description:

      The number of contiguous bits that are relevant in label, exp and s fields from the destination
      address field of LSE that was pushed
      immediately before the IP packet header (i.e. LSE that would be reported by
      partialMplsLse9. See the subnet mask in
      slash notation). definition of partialMplsLse1 for further
      details.

   Abstract Data Type: octet unsigned32

   Field Id: 13

   Units: bits

4.14 egressInterface 79

   Reference: See RFC 3032.


4.61 runningOctetCounter

   Description: The index of the IP interface (ifIndex) where packets

      Number of observed octets for a flow are being sent. pre-defined permanent flow.

      EDITOR'S NOTE: clarification required.

   Abstract Data Type: unsigned32 unsigned64

   Data Type Semantics: identifier runningCounter

   Field Id: 14

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


4.15 ipNextHopAddressV4

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




Calato, 85

   Units: octets




Meyer, et al.           Expires August 16, 2004 January 17, 2005               [Page 13] 29]

Internet-Draft          IPFIX Information Model            February                July 2004


   Abstract Data Type: ipv4Address

   Field Id: 15

4.16 sourceAsNumber


4.62 runningPacketCounter

   Description: The autonomous system (AS) number

      Number of the source address
      in the IP packet header. observed packets for a pre-defined permanent flow.

      EDITOR'S NOTE: clarification required.

   Abstract Data Type: unsigned16 unsigned64

   Data Type Semantics: identifier runningCounter

   Field Id: 16

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


4.17 destinationAsNumber 86

   Units: packets

4.63 bgpNextHopAsNumber

   Description:

      The autonomous system (AS) number of the destination
      address in the IP packet header. next BGP hop to which
      packets of this flow are forwarded.

   Abstract Data Type: unsigned16

   Data Type Semantics: identifier

   Field Id: 17 128

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


4.18 bgpNextHopAddressV4


4.64 ipNextHopAsNumber

   Description:

      The IPv4 address autonomous system (AS) number of the next BGP IP hop to which
      packets of this flow are forwarded.

   Abstract Data Type: ipv4Address unsigned16

   Data Type Semantics: identifier

   Field Id: 18 129






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


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




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


4.19 mcPacketsSent

   Description: The number of sent multicast packets.

   Abstract Data Type: unsigned64

   Field Id: 19

   Units: packets

4.20 mcOctetsSent

   Description: The number of sent multicast octets.

   Abstract Data Type: unsigned64

   Field Id: 20

   Units: octets

4.21 flowEndTime


4.65 exporterAddressV4

   Description:

      The timestamp IPv4 address of the last packet of a flow.

   Abstract Data Type: dateTimeSeconds

   Field Id: 21

4.22 flowCreationTime

   Description: The timestamp used by the exporting process. This is
      used by the collector to identify the exporter in cases where the
      identity of the first packet exporter may have been obscured by the use of a flow.

   Abstract Data Type: dateTimeSeconds

   Field Id: 22

4.23 sourceAddressV6

   Description: IPv6 source address taken from the packet header.
      proxy.

   Abstract Data Type: ipv6Address

   Field Id: 27

4.24 destinationAddressV6






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


   Description: IPv6 destination address taken from the packet header.

   Abstract ipv4Address

   Data Type: ipv6Address Type Semantics: identifier

   Field Id: 28

4.25 anotherSourceMask 130

4.66 exporterAddressV6

   Description:

      The number of contiguous bits that are relevant in the source IPv6 address field of the IP packet header (i.e. used by the subnet mask in
      slash notation). exporting process. This redundant field has is
      used by 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 collector to identify the exporter in cases where the destination
      address field
      identity of the IP packet header (i.e. the subnet mask in
      slash notation).  This redundant field has exporter may have been obscured by the same semantics as
      field 13. use of a
      proxy.

   Abstract Data Type: octet ipv6Address

   Data Type Semantics: identifier

   Field Id: 30

   Units: bits

4.27 flowLabel 131

4.67 droppedOctetDeltaCount

   Description:

      The Flow Label number of the IPv6 octets in packets of this flow dropped by packet header.
      treatment.

   Abstract Data Type: unsigned32 unsigned64

   Data Type Semantics: deltaCounter

   Field Id: 31

   Reference: See RFC 2460 for a definition of the flow label field in
      the IPv6 packet header.





Calato, 132

   Units: octets



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


4.28 icmpTypeCode


4.68 droppedPacketDeltaCount

   Description: Type and Code

      The number of the ICMP message. packets of this flow dropped by packet treatment.

   Abstract Data Type: unsigned16 unsigned64

   Data Type Semantics: deltaCounter

   Field Id: 32

   Reference: See RFC 792 for a definition of the ICMP type and code
      fields.


4.29 igmpType 133

   Units: packets

4.69 droppedOctetTotalCount

   Description:

      The type field number of the IGMP message. octets in packets of this flow dropped by packet
      treatment.

   Abstract Data Type: octet unsigned64

   Data Type Semantics: runningCounter

   Field Id: 33

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


4.30 samplingInterval 134

   Units: octets

4.70 droppedPacketTotalCount

   Description:

      Number of packets received as a ratio of

      The number of packets
      sampled. For example a value of 100 would mean that one packet in
      100 was sampled.  EDITORS' NOTE: This will be replaced this flow dropped by the
      PSAMP INFO MODEL packet treatment.

   Abstract Data Type: unsigned32 unsigned64

   Data Type Semantics: runningCounter

   Field Id: 34 135

   Units: packets

4.31 samplingAlgorithm

4.71 flowEndReason

   Description:

      The following sampling algorithms are defined:

      *  1 Deterministic sampling

      *  2 Random Sampling




Calato,





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


      *  3 Time-based sampling


      The reason for flow termination.

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

   Abstract Data Type: octet

   Data Type Semantics: identifier

   Field Id: 35

4.32 flowReportingInterval

   Description: Interval between reports for defined as an active flow. enumerated range.

   Abstract Data Type: unsigned16 octet

   Field Id: 36

   Units: seconds

4.33 flowIdleTimeout 136

4.72 classOfServiceV6

   Description:

      A flow is considered to be timed out if not packet belonging to

      The value of the flow has been IPv6 traffic class field observed for the number of seconds specified by
      this field.

   Abstract Data Type: unsigned16

   Field Id: 37

   Units: seconds

4.34 exportedOctetCount

   Description: The number packets of octets reported by the exporting process.
      this flow.

   Abstract Data Type: unsigned64 octet

   Field Id: 40

   Units: octets

4.35 exportedPacketCount






Calato, 135

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






























Meyer, et al.           Expires August 16, 2004 January 17, 2005               [Page 18] 33]

Internet-Draft          IPFIX Information Model            February                July 2004


   Description: The number


5. Extending the Information Model

   A key requirement for IPFIX is to allow for extending the set of packets
   information items which are reported by for flows. This section defines
   the exporting process.

   Abstract Data Type: unsigned64

   Field Id: 41

   Units: packets

4.36 exportedFlowCount

   Description: mechanism for extending this set.

   The number of flows reported IPFIX protocol carries flow records defined by a template.
   Multiple templates may be defined for a dialog between an exporter
   and a collector. A given template identifies the exporting process.

   Abstract Data Type: unsigned64

   Field Id: 42

   Units: flows

4.37 ipVersion

   Description: information items
   and their order. The IP version field given means of identification of information items in the IP header.

   Abstract Data Type: octet
   a template is via a field ID. Field Id: 60

   Units: flows

   Reference:

      See RFC 791 Id's are unique identifiers
   administered by IANA.

   Extension is done by defining new Information elements, including the
   set of necessary information and possibly additional optional
   information for each element. Each new information item MUST be
   assigned a definition unique fieldId as part of its definition. These unique
   field ids are the version 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 in ID's
   with IANA.  In these cases the field definiton must specify the IPv6
      packet header. See RFC 2460 for a definition of
   vendor ID as well as the version vendor-specified field
      in ID and other
   mandatory field properties.  Before creating vendor-specific fields,
   the IPv6 packet header. Additional general applicability of such information on defined
      version numbers can elements should be found at http://www.iana.org/assignments/
      version-numbers.


4.38 ipNextHopAddressV6

   Description: The IPv6 address of
   considered. For generally applicable fields using IETF and IANA
   mechanisms for extendind the next IP hop to which packets are
      forwarded.

   Abstract Data Type: ipv6Address

   Field Id: 62






Calato, information model is recommended.






















Meyer, et al.           Expires August 16, 2004 January 17, 2005               [Page 19] 34]

Internet-Draft          IPFIX Information Model            February                July 2004


4.39 bgpNextHopAddressV6

   Description: The IPv6 address of the next BGP hop


6. IANA Considerations

   IANA has to which packets
      are forwarded.

   Abstract Data Type: ipv6Address

   Data Type Semantics: identifier

   Field Id: 63

   Reference: See RFC 1771 for a description of BGB-4 and see RFC 1930 create a
      definition of 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: unsigned16

   Data Type Semantics: identifier

   Field Id: 80

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


4.41 ipNextHopAsNumber

   Description: The autonomous system (AS) number of the next IP hop IPFIX fields ID's.

   Appendix B defines an XML schema which may be used to create
   consistent machine readable extensions to the
      packets are sent to.

   Abstract Data Type: unsigned16

   Data Type Semantics: identifier

   Field Id: 81

   Reference: See RFC 1771 for IPFIX information
   model. This schema introduces a description of BGB-4 and see new namaspace, which will be assigned
   by IANA according to RFC 1930 a
      definition of 3688.  Currently the AS number.


4.42 exporterAddressV4





Calato, name space for this
   schema is identified as http://www.ietf.org/ipfix.










































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


   Description:


7. Security Considerations

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

   The underlying protocol used by the
      collecter to identify exchange the exporter in cases where information described
   here must therefor apply appropriate procedures to guarantee the identity
   integrity and confidentiality of the exporter may have been obscured by exported information.  Such
   protocols are defined in separate documents. Specifically the use of a proxy.

   Abstract Data Type: ipv4Address

   Field Id: 82

4.43 exporterAddressV6

   Description: IPFIX
   Protocol document.








































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


8. Acknowledgements

   The IPv6 address editors thank Stewart Bryant for a lot of useful input on the flow exporter. This is used by the
      collecter
   field definitions.  Also many thanks to identify the exporter in cases where Thomas Dietz for developing
   the identity XSLT scripts that generate large portions of the exporter may have been obscured by the use of a proxy.

   Abstract Data Type: ipv4Address

   Field Id: 83

4.44 droppedOctetCount

   Description: The number of octets dropped.

   Abstract Data Type: unsigned64

   Field Id: 84

   Units: octets

4.45 droppedPacketCount

   Description: The number of packets dropped.

   Abstract Data Type: unsigned64

   Field Id: 84

   Units: packets

4.46 flowEndReason

   Description: The number text part of packets dropped.

      *  idle timeout
   this document from the XML appendices.













































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













































Meyer, et al.           Expires August 16, 2004 January 17, 2005               [Page 21] 38]

Internet-Draft          IPFIX Information Model            February                July 2004


      *  end of flow detected (e.g. TCP FIN)

      *  forced end

      *  cache full

      EDITORS' NOTE: This needs to be defined as an enumerated range.

   Abstract


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 Type: octet

   Field Id: 84








































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



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


5. Extending the Information Model

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

   The IPFIX protocol carries flow records defined by a template.
   Multiple templates may be defined for a dialog between an exporter
   and a collector. A given template identifies the information items
   and their order. The means of identification of information items in
   a template is via a field ID. Field Id's are unique identifiers
   administered by IANA.

   Extension is done by defining new Information elements, including the
   set of necessary information


   [13]  Pras, A. and possibly additional optional
   information for each element. Each new information item MUST be
   assigned a unique fieldId as part of its definition. These unique
   field ids are J. Schoenwaelder, "On the connection Difference 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
         Information Models 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 Data Models", RFC 3444, January 2003,
         <http://www.ietf.org/rfc/rfc3444.txt>.

   [14]  Mealling, M., "The IETF and IANA
   mechanisms for extendind the information model is recommended.






















Calato, XML Registry", RFC 3688, January 2004,
         <http://www.ietf.org/rfc/rfc3688.txt>.


Authors' Addresses

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

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


   Juergen Quittek
   NEC
   Kurfuersten-Anlage 36
   Heidelberg  69115
   Germany

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


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

   EMail: stbryant@cisco.com












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


6. IANA Considerations

   IANA has to create


Appendix A. Formal Specification of IPFIX Fields

   This appendix contains a new registry for formal description of the IPFIX fields ID's.

   Appendix B defines an information
   model XML schema which may be used to create
   consistent 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 IPFIX information
   model. This schema introduces a new namaspace, which will be assigned model, by IANA 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 RFC 3688.  Currently 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 name space machine readability of the Information Model vs.
   hardcoding their behavior or inventing proprietary means for
   accomodating extensions.


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

     <field name="deltaOctetCount" dataType="unsigned64"
            dataTypeSemantics="deltaCounter"
            fieldType="1" applicability="data" status="current">
       <description>
         <paragraph>
         The number of octets in (incoming) packets observed for this
   schema is identified as http://www.ietf.org/ipfix.










































Calato,
         flow at the observation point since the previous report (if any).
         The number of octets include IP header(s) and IP payload.
         </paragraph>
       </description>
       <units>octets</units>
     </field>

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



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


7. Security Considerations


         <paragraph>
         The IPFIX information model itself does not directly introduce
   security issues. Rather it defines a set number of attributes which may (incoming) packets observed for
   privacy or business issues be considered sensitive information.

   The underlying protocol used to exchange this flow at
         the information described
   here must therefor apply appropriate procedures to guarantee observation point since the
   integrity and confidentiality previous report (if any).
         </paragraph>
       </description>
       <units>packets</units>
     </field>

     <field name="totalFlowCount" dataType="unsigned64"
            dataTypeSemantics="runningCounter"
            fieldType="3" applicability="data" status="current">
       <description>
         <paragraph>
         The number of flows observed so far in the exported information.  Such
   protocols observation domain.
         </paragraph>
       </description>
       <units>flows</units>
     </field>

     <field name="protocolIdentifier" dataType="octet"
            dataTypeSemantics="identifier"
            fieldType="4" applicability="all" status="current">
       <description>
         <paragraph>
         The protocol number observed for packets of this flow.
         The protocol number identifies the IP packet payload.
         Protocol numbers are defined in separate documents. Specifically the IPFIX IANA Protocol document.








































Calato, Numbers
         registry.</paragraph>

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

     <field name="classOfServiceV4" dataType="octet"
            dataTypeSemantics="identifier"
            fieldType="5" applicability="all" status="current">



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


8. Acknowledgements


       <description>
         <paragraph>
         The editors thank Stewart Bryant for a lot value of useful input on the IPv4 TOS field definitions.  Also many thanks to Thomas Dietz observed for packets of this flow.
         </paragraph>
       </description>
       <reference>
         See RFC 791 for developing the XSLT scripts definition of the IPv4 TOS field.
       </reference>
     </field>

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

         <paragraph>to be replaced by ASCII drawing</paragraph>
         <paragraph>to be replaced by ASCII drawing</paragraph>
         <paragraph>to be replaced by ASCII drawing</paragraph>
         <paragraph>to be replaced by ASCII drawing</paragraph>
         <paragraph>to be replaced by ASCII drawing</paragraph>
         <paragraph>to be replaced by ASCII drawing</paragraph>
         <paragraph>to be replaced by ASCII drawing</paragraph>
         <paragraph>to be replaced by ASCII drawing</paragraph>
       </description>
       <reference>See RFC 793 for a definition of 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. TCP control bits
       in the TCP header.</reference>
     </field>

     <field name="transportSourcePort" dataType="unsigned16"
            dataTypeSemantics="identifier"
            fieldType="7" applicability="all" status="current">
       <description>
         <paragraph>
         A source port identifier in the transport header. For transport
         protocols UDP, TCP and R. Penno, "IPFIX
        Protocol Specification", IETF draft work SCTP this is the source port number
         given in progress, January
        2004, <http://www.ietf.org/internet-drafts/
        draft-ietf-ipfix-protocol-02.txt>.













































Calato, the respective header. This field MAY also be used
         for future transport protocols that have 16 bit source port
         identifiers.
         </paragraph>
       </description>
       <reference>



Meyer, et al.           Expires August 16, 2004 January 17, 2005               [Page 27] 43]

Internet-Draft          IPFIX Information Model            February                July 2004


Informative Reference

   [2]   Quittek, J., Zseby, T., Claise, B. and S. Zander, "Requirements


         <paragraph>
         See RFC 768 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 the definition of the UDP source port field.
         See RFC 793 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", the definition of the TCP source port field.
         See RFC 2924, Sept. 2000, <http://www.ietf.org/rfc/
         rfc2924.txt>.

   [11]  Rose, M., "Writing I-Ds 2960 for the definition of SCTP.</paragraph>
         <paragraph>
         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="sourceAddressV4" dataType="ipv4Address"
            fieldType="8" applicability="all" status="current">
       <description>
         <paragraph>
         IPv4 source address taken from the IP packet header of a
         packet of this flow.
         </paragraph>
       </description>
       <reference>
         See RFC 2629, June
         1999, <http://xml.resource.org/public/rfc/html/rfc2629.html>.

   [12]  Hollenbeck, S., Rose, M. and L. Masinter, "Guidelines 791 for the
         Use definition of Extensible Markup Language (XML) within IETF Protocols", the IPv4 source address
         field.
       </reference>
     </field>

     <field name="sourceMaskV4" dataType="octet"
            fieldType="9" applicability="option" status="current">
       <description>
         <paragraph>
         The number of contiguous bits that are relevant in the
         sourceAddressV4 field.
         </paragraph>
       </description>
       <units>bits</units>
       <range>0-32</range>
     </field>

     <field name="ingressInterface" dataType="unsigned32"
            dataTypeSemantics="identifier"
            fieldType="10" applicability="all" status="current">
       <description>
         <paragraph>
         The index of the IP interface (ifIndex) where packets of
         this flow are being received.
         </paragraph>
       </description>
       <reference>
         See RFC 3470, January 2003, <http://www.ietf.org/rfc/rfc3470.txt>.



Calato, 2863 for the definition of the ifIndex object.



Meyer, et al.           Expires August 16, 2004 January 17, 2005               [Page 28] 44]

Internet-Draft          IPFIX Information Model            February                July 2004


   [13]  Pras, A. and J. Schoenwaelder, "On


       </reference>
     </field>

     <field name="transportDestinationPort" dataType="unsigned16"
            dataTypeSemantics="identifier"
            fieldType="11" applicability="all" status="current">
       <description>
         <paragraph>
         A destination port identifier in the Difference between
         Information Models transport header.
         For transport protocols UDP, TCP 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 SCTP this is the
         destination port number given in the respective header.
         This appendix contains a formal description of field MAY also be used for future transport protocols
         that have 16 bit destination port identifiers.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 768 for the IPFIX information
   model XML document.  Note that this appendix is definition of informational
   nature, while the text in section 4 generated from this appendix is
   normative.

   Using a formal and machine readable syntax UDP source port field.
         See RFC 793 for the Information model
   enables the creation definition 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 TCP source port field.
         See RFC 2960 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 definition of SCTP.  </paragraph>

         <paragraph>
         Additional information on defined UDP and transformed according to RFC2629.

   It should TCP port numbers can
         be noted that found at http://www.iana.org/assignments/port-numbers.
         </paragraph>
       </reference>
     </field>

     <field name="destinationAddressV4" dataType="ipv4Address"
            fieldType="12" applicability="all" status="current">
       <description>
         <paragraph>
         IPv4 destination address taken from the use IP packet header of XML in exporters, collectors or
   other tools is not mandatory a
         packet of this flow.
         </paragraph>
       </description>
       <reference>
         See RFC 791 for the deployment definition of IPFIX.  In
   particular exporting processes do not produce or consume XML as part the IPv4 destination address
         field.
       </reference>
     </field>

     <field name="destinationMaskV4" dataType="octet"
            fieldType="13" applicability="option" status="current">
       <description>
         <paragraph>
         The number of their operation.  It is expected contiguous bits that are relevant in the
         destinationAddressV4 field.



Meyer, et al.           Expires January 17, 2005               [Page 45]

Internet-Draft          IPFIX collectors MAY take
   advantage Information Model                July 2004


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

     <field name="egressInterface" dataType="unsigned32"
            dataTypeSemantics="identifier"
            fieldType="14" applicability="all" status="current">
       <description>
         <paragraph>
         The index of the machine readability IP interface (ifIndex) where packets of the Information Model vs.
   hardcoding their behavior or inventing proprietary means this
         flow are being sent.
         </paragraph>
       </description>
       <reference>
         See RFC 2863 for
   accomodating extensions.


   <?xml version="1.0" encoding="UTF-8"?>
   <fieldDefinitions> the definition of the ifIndex object.
       </reference>
     </field>

     <field name="octetCount" dataType="unsigned64"
            fieldType="1" name="ipNextHopAddressV4" dataType="ipv4Address"
            fieldType="15" applicability="data" status="current">
       <description>
         <paragraph>
         The number IPv4 address of observed octets. the next IP hop to which packets of
         this flow are forwarded.
         </paragraph>
       </description>
       <units>octets</units>
     </field>

     <field name="packetCount" dataType="unsigned64"
            fieldType="2" applicability="data" name="sourceAsNumber" dataType="unsigned16"
            dataTypeSemantics="identifier"
            fieldType="16" applicability="all" status="current">
       <description>
         <paragraph>
         The autonomous system (AS) number of observed packets. the source address in
         the IP packet header in a packet of this flow.
         </paragraph>
       </description>
       <units>packets</units>
       <reference>
         See RFC 1771 for a description of BGB-4 and
         see RFC 1930 a definition of the AS number.
       </reference>
     </field>

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



Calato, name="destinationAsNumber" dataType="unsigned16"
            dataTypeSemantics="identifier"
            fieldType="17" applicability="all" status="current">



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


            fieldType="3" applicability="data" status="current">


       <description>
         <paragraph>
         The autonomous system (AS) number of (aggregated) flows. the destination address
         in the IP packet header in a packet of this flow.
         </paragraph>
       </description>
       <units>flows</units>
       <reference>
         See RFC 1771 for a description of BGB-4 and
         see RFC 1930 a definition of the AS number.
       </reference>
     </field>

     <field name="protocolIdentifier" dataType="octet"
            dataTypeSemantics="identifier"
            fieldType="4" name="bgpNextHopAddressV4" dataType="ipv4Address"
            fieldType="18" 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 IPv4 address of the "Protocol" field. In Internet Protocol version 6
         (IPv6) next BGP hop to which packets of
         this is carried in the "Next Header" field.</paragraph> flow are forwarded.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 791 1771 for the specification a description of the IPv4 protocol field.
         See BGB-4 and
         see RFC 1883 for the specification 1930 a definition of the IPv6 protocol field.
         See list of protocol numbers assigned by IANA at
         http://www.iana.org/assignments/protocol-numbers.
         </paragraph> AS number.
       </reference>
     </field>

     <field name="classOfService" dataType="octet"
            dataTypeSemantics="identifier"
            fieldType="5" applicability="all" name="OutMulticastPacketCount" dataType="unsigned64"
            fieldType="19" applicability="data" status="current">
       <description>
         <paragraph>
         The class number of outgoing multicast packets created for packets
         of this flow by an adjacent multicast daemon.
         Note that typically not all of the created packets can be
         observed at the observation point of service. this flow.
         </paragraph>
       </description>
       <units>packets</units>
     </field>

     <field name="OutMulticastOctetCount" dataType="unsigned64"
            fieldType="20" applicability="data" status="current">
       <description>
         <paragraph>
         The definition number of classOfService is dependent on the protocol
         being observed. Those considered here are:
         </paragraph>
         <list>
         <item>For IPv4 octets in outgoing multicast packets created
         for packets the class of service is given this flow by the
               value of the type an adjacent multicast daemon.
         Note that typically not all of service field in the IPv4 packet
               header.</item>
         <item>For IPv6 created packets can be
         observed at the class observation point of service is given by the



Calato, this flow.
         </paragraph>



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


               value


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

     <field name="flowEndTime" dataType="dateTimeSeconds"
            fieldType="21" applicability="data" status="current">
       <description>
         The timestamp of the traffic class field in the IPv6 last 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. this flow.
       </description>
     </field>

     <field name="flowCreationTime" dataType="dateTimeSeconds"
            fieldType="22" applicability="data" status="current">
       <description>
         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 timestamp of the type first packet 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 this flow.
       </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
     </field>

     <field name="deltaOutOctetCount" dataType="unsigned64"
            dataTypeSemantics="deltaCounter"
            fieldType="23" applicability="data" status="current">
       <description>
         <paragraph>
         The number of the Exp field octets in label stack
         entries.
         See IEEE802.1q and IEEE 802.1p outgoing packets observed for this
         flow at the definition of observation point since the VLAN
         user_priority field. previous report (if any).
         The number of octets include IP header(s) and IP payload.
         </paragraph>
       </reference>
       </description>
       <units>octets</units>
     </field>

     <field name="tcpControlBits" dataType="octet"
            dataTypeSemantics="flags"
            fieldType="6" applicability="all" name="deltaOutPacketCount" dataType="unsigned64"
            dataTypeSemantics="deltaCounter"
            fieldType="24" applicability="data" status="current">
       <description>
         <paragraph>
         The TCP control bits seen number of outgoing packets observed for this flow.  Note that a 0 value
         for each bit only indicates that flow at
         the flag was not detected
         (i.e. it may have occurred but was not detected by observation point since the
         reporting CCE). previous report (if any).
         </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>
       <units>packets</units>
     </field>

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



Calato,
            fieldType="25" applicability="all" status="current">
       <description>
         <paragraph>
         Length of the smallest packet observed for this flow.



Meyer, et al.           Expires August 16, 2004 January 17, 2005               [Page 32] 48]

Internet-Draft          IPFIX Information Model            February                July 2004


            fieldType="7"


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

     <field name="maxPacketLength" dataType="unsigned16"
            fieldType="26" 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
         Length of the UDP source port field.
         See RFC 793 largest packet observed 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. this flow.
         </paragraph>
       </reference>
       </description>
       <units>octets</units>
     </field>

     <field name="sourceAddressV4" dataType="ipv4Address"
            fieldType="8" name="sourceAddressV6" dataType="ipv6Address"
            fieldType="27" applicability="all" status="current">
       <description>
         The IPv4
         <paragraph>
         IPv6 source address in taken from the IPv4 IP packet header. header of a
         packet of this flow.
         </paragraph>
       </description>
       <reference>
         See RFC 791 for
     </field>

     <field name="destinationAddressV6" dataType="ipv6Address"
            fieldType="28" applicability="all" status="current">
       <description>
         <paragraph>
         IPv6 destination address taken from the definition IP packet header of a
         packet of this flow.
         </paragraph>
       </description>
     </field>

     <field name="sourceMaskV6" dataType="octet"
            fieldType="29" applicability="option" status="current">
       <description>
         <paragraph>
         The number of contiguous bits that are relevant in the IPv4 source address
         sourceAddressV6 field.
       </reference>
         </paragraph>
       </description>
       <units>bits</units>
       <range>0-128</range>
     </field>

     <field name="sourceMask" name="destinationMaskV6" dataType="octet"
            fieldType="9"



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


            fieldType="30" applicability="option" status="current">
       <description>
         <paragraph>
         The number of contiguous bits that are relevant in the source
         address field of the IP packet header
         (i.e. the subnet mask in slash notation).
         destinationAddressV6 field.
         </paragraph>
       </description>
       <units>bits</units>
       <range>0-128</range>
     </field>

     <field name="ingressInterface" name="flowLabelV6" dataType="unsigned32"
            dataTypeSemantics="identifier"
            fieldType="10"
            fieldType="31" applicability="all" status="current">
       <description>
         <paragraph>
         The index Flow Label of the IP interface (ifIndex) where packets of IPv6 packet header observed in a flow
         are being received. packet
         of this flow.
         </paragraph>
       </description>
       <reference>
         See RFC 2863 2460 for the a definition of the ifIndex object. flow label field in the
         IPv6 packet header.
       </reference>
     </field>

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



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


            dataTypeSemantics="identifier"
            fieldType="11"
            fieldType="32" applicability="all" status="current">
       <description>
         A destination port number in the UDP or TCP header,
         respectively.
       </description>
       <reference>
         <paragraph>
         See RFC 768 for the definiton
         Type and Code of the UDP destination port
         field. ICMP message. The combination of both values
         is reported as (ICMP type * 256) + ICMP code.
         </paragraph>
       </description>
       <reference>
         See RFC 793 792 for the definiton a definition of the TCP destination port
         field.
         Additional information on defined UDP ICMP type and TCP port numbers
         can be found at http://www.iana.org/assignments/port-numbers.
         </paragraph> code fields.
       </reference>
     </field>

     <field name="destinationAddressV4" dataType="ipv4Address"
            fieldType="12" name="igmpType" dataType="octet"
            fieldType="33" applicability="all" status="current">
       <description>
         The IPv4 destination address in type field of the IPv4 packet header. IGMP message.
       </description>
       <reference>
         See RFC 791 2236 for the a definition of the IPv4 destination address IGMP type field.
       </reference>
     </field>




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


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

     <field name="flowInactiveTimeout" dataType="unsigned16"
            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="destinationMask" dataType="octet"
            fieldType="13" applicability="option" name="exportedOctetCount" dataType="unsigned64"
            fieldType="40" applicability="data" status="current">
       <description>
         <paragraph>
         The number of contiguous bits that are relevant in the
         destination address field of the IP packet header
         (i.e. all octets reported by the subnet mask in slash notation). exporting process
         to this collecting process.
         </paragraph>
       </description>
       <units>bits</units>
       <units>octets</units>
     </field>

     <field name="egressInterface" dataType="unsigned32"
            dataTypeSemantics="identifier"
            fieldType="14" applicability="all" name="exportedPacketCount" dataType="unsigned64"
            fieldType="41" applicability="data" status="current">
       <description>
         <paragraph>
         The index number of the IP interface (ifIndex) where all packets of a flow
         are being sent. reported by the exporting process
         to this collecting process.
         </paragraph>
       </description>



Calato,
       <units>packets</units>
     </field>

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



Meyer, et al.           Expires August 16, 2004 January 17, 2005               [Page 34] 51]

Internet-Draft          IPFIX Information Model            February                July 2004


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

     <field name="ipNextHopAddressV4" dataType="ipv4Address"
            fieldType="15" applicability="data" status="current">
       <description>


         <paragraph>
         The IPv4 address number of all flows records reported by the next IP hop exporting
         process to which packets are
         forwarded. this collecting process.
         </paragraph>
       </description>
       <units>flows</units>
     </field>

     <field name="sourceAsNumber" dataType="unsigned16"
            dataTypeSemantics="identifier"
            fieldType="16" applicability="all" name="sourcePrefixV4" dataType="ipV4Address"
            fieldType="44" applicability="data" status="current">
       <description>
         The autonomous system (AS) number of the
         <paragraph> IPv4 source address in
         the IP packet header. prefix. </paragraph>
         <paragraph>
         EDITOR'S NOTE: to be discussed on ipfix mailing list
         </paragraph>
       </description>
       <reference>
         See RFC 1771 for a description of BGB-4 and
         see RFC 1930 a definition of the AS number.
       </reference>
       <units>flows</units>
     </field>

     <field name="destinationAsNumber" dataType="unsigned16"
            dataTypeSemantics="identifier"
            fieldType="17" applicability="all" name="destinationPrefixV4" dataType="ipV4Address"
            fieldType="45" applicability="data" status="current">
       <description>
         The autonomous system (AS) number of the
         <paragraph> IPv4 destination address
         in the IP packet header. prefix. </paragraph>
         <paragraph>
         EDITOR'S NOTE: to be discussed on ipfix mailing list
         </paragraph>
       </description>
       <reference>
         See RFC 1771 for a description of BGB-4 and
         see RFC 1930 a definition of the AS number.
       </reference>
       <units>flows</units>
     </field>

     <field name="bgpNextHopAddressV4" dataType="ipv4Address" name="mplsTopLabelType" dataType="octet"
            dataTypeSemantics="identifier"
            fieldType="18" applicability="all"
            fieldType="46" applicability="data" status="current">
       <description>
         The IPv4 address of
         <paragraph>
         MPLS top label type:
         <list>
         <item> 0x01 TE-MIDPT: Any TE tunnel mid-point or tail label</item>
         <item> 0x02 Pseudowire: Any PWE3 or Cisco AToM based label</item>
         <item> 0x03 VPN: Any label associated with VPN</item>
         <item> 0x04 BGP: Any label associated with BGP or BGP routing</item>
         <item> 0x05 LDP: Any label associated with dynamically assigned
                labels using LDP</item>
         </list>
         This field identifies the next BGP hop to which packets are
         forwarded.
       </description>
       <reference>
         See RFC 1771 for a description control protocol that allocated the
         top of BGB-4 and



Calato, stack label.
         </paragraph>
       </description>



Meyer, et al.           Expires August 16, 2004 January 17, 2005               [Page 35] 52]

Internet-Draft          IPFIX Information Model            February                July 2004


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


     </field>

     <field name="mcPacketsSent" dataType="unsigned64"
            fieldType="19" name="mplsTopLabelIPAddressV4" dataType="ipV4Address"
            fieldType="47" applicability="data" status="current">
       <description>
         <paragraph>
           The number IPv4 address of sent multicast packets. the system that the MPLS top label will
           cause this packet to be forwarded to.
         </paragraph>
       </description>
       <units>packets</units>
     </field>

     <field name="mcOctetsSent" dataType="unsigned64"
            fieldType="20" name="minimumTTL" dataType="octet"
            fieldType="52" applicability="data" status="current">
       <description>
         The number of sent multicast octets.
         <paragraph>
           Minimum TTL value observed for any packet in this flow.
         </paragraph>
       </description>
       <units>octets</units>
     </field>

     <field name="flowEndTime" dataType="dateTimeSeconds"
            fieldType="21" name="maximumTTL" dataType="octet"
            fieldType="53" applicability="data" status="current">
       <description>
         The timestamp of the last
         <paragraph>
           Maximum TTL value observed for any packet of a in this flow.
         </paragraph>
       </description>
     </field>

     <field name="flowCreationTime" dataType="dateTimeSeconds"
            fieldType="22" name="identificationV4" dataType="octet"
            dataTypeSemantics="identifier"
            fieldType="54" applicability="data" status="current">
       <description>
         The timestamp of
         <paragraph>
           Packet identification field from the first IP packet of a this flow.
         </paragraph>
       </description>
     </field>

     <field name="sourceAddressV6" dataType="ipv6Address"
            fieldType="27" applicability="all" status="current">
       <description>
         IPv6 source address taken from
       <reference>
         See RFC 791 for the packet header.
       </description> definition of the IPv4 identification field.
       </reference>
     </field>

     <field name="destinationAddressV6" dataType="ipv6Address"
            fieldType="28" applicability="all" name="sourceMacAddress" dataType="octet"
            fieldType="56" applicability="data" status="current">
       <description>
         IPv6 destination address taken
         <paragraph>
           Packet identification field from the first IP packet header.
       </description>
     </field>




Calato, of this flow.



Meyer, et al.           Expires August 16, 2004 January 17, 2005               [Page 36] 53]

Internet-Draft          IPFIX Information Model            February                July 2004


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

     <field name="anotherSourceMask" name="ipVersion" dataType="octet"
            fieldType="29" applicability="option"
            fieldType="60" applicability="all" status="current">
       <description>
         <paragraph>
         The number of contiguous bits that are relevant IP version field given in the source
         address field IP header.
       </description>
       <units>flows</units>
       <reference>
         <paragraph>
         See RFC 791 for a definition of the IP version field in the
         IPv6 packet header (i.e. header.
         See RFC 2460 for a definition of the subnet mask
         in slash notation).  This redundant version field has in the same
         semantics as field 9.
         IPv6 packet header.
         Additional information on defined version numbers
         can be found at
         http://www.iana.org/assignments/version-numbers.
         </paragraph>
       </description>
       <units>bits</units>
       </reference>
     </field>

     <field name="destinationMask" dataType="octet"
            fieldType="30" applicability="option" name="ipNextHopAddressV6" dataType="ipv6Address"
            fieldType="62" applicability="data" status="current">
       <description>
         <paragraph>
         The number of contiguous bits that are relevant in the
         destination IPv6 address field of the IP packet header (i.e. the
         subnet mask in slash notation).  This redundant field has
         the same semantics as field 13. next BGP hop to which packets of
         this flow are forwarded.
         </paragraph>
       </description>
       <units>bits</units>
     </field>

     <field name="flowLabel" dataType="unsigned32"
            fieldType="31" name="bgpNextHopAddressV6" dataType="ipv6Address"
            dataTypeSemantics="identifier"
            fieldType="63" applicability="all" status="current">
       <description>
         <paragraph>
         The Flow Label IPv6 address of the IPv6 packet header. next BGP hop to which packets of
         this flow are forwarded.
         </paragraph>
       </description>
       <reference>
         See RFC 2460 1771 for a description of BGB-4.
         See RFC 1930 a definition of the flow label field AS number.



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


       </reference>
     </field>

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

     <field name="icmpTypeCode" dataType="unsigned16"
            fieldType="32" name="partialMPLSLabelStackEntry1" dataType="unsigned32"
            fieldType="70" applicability="all" status="current">
       <description>
         Type
         <paragraph>
         The label, exp and Code of s fields from the ICMP message. outermost MPLS label
         stack entry e.g. the last label that was pushed last.
         </paragraph>
         <paragraph> to be replaced by ASCII drawing </paragraph>
         <paragraph> to be replaced by ASCII drawing </paragraph>
         <paragraph> to be replaced by ASCII drawing </paragraph>
         <paragraph> to be replaced by ASCII drawing </paragraph>
         <paragraph> to be replaced by ASCII drawing </paragraph>
       </description>
       <reference>
         See RFC 792 for a definition of the ICMP type and code fields. 3032.
       </reference>
     </field>

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



Calato, name="partialMPLSLabelStackEntry2" dataType="unsigned32"
            fieldType="71" applicability="all" status="current">



Meyer, et al.           Expires August 16, 2004 January 17, 2005               [Page 37] 55]

Internet-Draft          IPFIX Information Model            February                July 2004


            fieldType="33" applicability="all" status="current">


       <description>
         <paragraph>
         The type field of label, exp and s fields from the IGMP message. LSE that was pushed
         immediately before the LSE that would be reported by
         partialMplsLse1. See the definition of partialMplsLse1 for
         further details.
         </paragraph>
       </description>
       <reference>
         See RFC 2236 for a definition of the IGMP type field. 3032.
       </reference>
     </field>

     <field name="samplingInterval" name="partialMPLSLabelStackEntry3" dataType="unsigned32"
            fieldType="34"
            fieldType="72" applicability="all" status="current">
       <description>
         <paragraph>
         Number of packets received as a ratio of number of packets
         sampled. For example a value of 100 would mean
         The label, exp and s fields from the LSE that one packet
         in 100 was sampled.
         </paragraph>

         EDITORS' NOTE: This will pushed
         immediately before the LSE that would be replaced reported by
         partialMplsLse2. See the PSAMP INFO MODEL definition of partialMplsLse1 for
         further details.
         </paragraph>
       </description>
       <units>packets</units>
       <reference>
         See RFC 3032.
       </reference>
     </field>

     <field name="samplingAlgorithm" dataType="octet"
            dataTypeSemantics="identifier"
            fieldType="35" name="partialMPLSLabelStackEntry4" dataType="unsigned32"
            fieldType="73" 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 label, exp and s fields from the LSE that was pushed
         immediately before the LSE that would be replaced reported by
         partialMplsLse3. See the PSAMP INFO MODEL definition of partialMplsLse1 for
         further details.
         </paragraph>
       </description>
       <reference>
         See RFC 3032.
       </reference>
     </field>

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



Calato,
         <paragraph>
         The label, exp and s fields from the LSE that was pushed



Meyer, et al.           Expires August 16, 2004 January 17, 2005               [Page 38] 56]

Internet-Draft          IPFIX Information Model            February                July 2004


         immediately before the LSE that would be reported by
         partialMplsLse4. See the definition of partialMplsLse1 for
         further details.
         </paragraph>
       </description>
       <reference>
         See RFC 3032.
       </reference>
     </field>

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

     <field name="partialMPLSLabelStackEntry7" dataType="unsigned32"
            fieldType="76" applicability="all" status="current">
       <description>
         <paragraph>
         The label, exp and s fields from the number
          of seconds specified LSE that was pushed
         immediately before the LSE that would be reported by this field.
         partialMplsLse6. See the definition of partialMplsLse1 for
         further details.
         </paragraph>
       </description>
       <units>seconds</units>
       <reference>
         See RFC 3032.
       </reference>
     </field>

     <field name="exportedOctetCount" dataType="unsigned64"
            fieldType="40" applicability="data" name="partialMPLSLabelStackEntry8" dataType="unsigned32"
            fieldType="77" applicability="all" status="current">
       <description>
         <paragraph>
         The number of octets label, exp and s fields from the LSE that was pushed
         immediately before the LSE that would be reported by
         partialMplsLse7. See the exporting process. definition of partialMplsLse1 for
         further details.



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


         </paragraph>
       </description>
       <units>octets</units>
       <reference>
         See RFC 3032.
       </reference>
     </field>

     <field name="exportedPacketCount" dataType="unsigned64"
            fieldType="41" applicability="data" name="partialMPLSLabelStackEntry9" dataType="unsigned32"
            fieldType="78" applicability="all" status="current">
       <description>
         <paragraph>
         The number of packets label, exp and s fields from the LSE that was pushed
         immediately before the LSE that would be reported by
         partialMplsLse8. See the exporting process. definition of partialMplsLse1 for
         further details.
         </paragraph>
       </description>
       <units>packets</units>
       <reference>
         See RFC 3032.
       </reference>
     </field>

     <field name="exportedFlowCount" dataType="unsigned64"
            fieldType="42" applicability="data" name="partialMPLSLabelStackEntry10" dataType="unsigned32"
            fieldType="79" applicability="all" status="current">
       <description>
         <paragraph>
         The number of flows label, exp and s fields from the LSE that was pushed
         immediately before the LSE that would be reported by
         partialMplsLse9. See the exporting process. definition of partialMplsLse1 for
         further details.
         </paragraph>
       </description>
       <units>flows</units>
       <reference>
         See RFC 3032.
       </reference>
     </field>

     <field name="ipVersion" dataType="octet"
            fieldType="60" name="runningOctetCounter" dataType="unsigned64"
            dataTypeSemantics="runningCounter"
            fieldType="85" applicability="all" status="current">
       <description>
         The IP version field given in the IP header.
       </description>
       <units>flows</units>
       <reference>
         <paragraph>
         See RFC 791 for a definition
         Number of the version field in the
         IPv6 packet header.
         See RFC 2460 observed octets for a definition of the version field in the
         IPv6 packet header.



Calato, pre-defined permanent flow.
         </paragraph>
         <paragraph>
         EDITOR'S NOTE: clarification required.
         </paragraph>
       </description>



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


         Additional information on defined version numbers
         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 hop to which packets are
         forwarded.
       </description>


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

     <field name="bgpNextHopAddressV6" dataType="ipv6Address"
            dataTypeSemantics="identifier"
            fieldType="63" name="runningPacketCounter" dataType="unsigned64"
            dataTypeSemantics="runningCounter"
            fieldType="86" applicability="all" status="current">
       <description>
         The IPv6 address
         <paragraph>
         Number of the next BGP hop to which observed packets are
         forwarded.
       </description>
       <reference>
         See RFC 1771 for a description of BGB-4 and
         see RFC 1930 a definition of the AS number.
       </reference> pre-defined permanent flow.
         </paragraph>
         <paragraph>
         EDITOR'S NOTE: clarification required.
         </paragraph>
       </description>
       <units>packets</units>
     </field>

     <field name="bgpNextHopAsNumber" dataType="unsigned16"
            dataTypeSemantics="identifier"
            fieldType="80"
            fieldType="128" applicability="all" status="current">
       <description>
         <paragraph>
         The autonomous system (AS) number of the next BGP hop the to
         which packets of this flow are sent to. forwarded.
         </paragraph>
       </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"
            fieldType="129" applicability="all" status="current">
       <description>
         <paragraph>
         The autonomous system (AS) number of the next IP hop the to
         which packets of this flow are sent to. forwarded.
         </paragraph>
       </description>



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



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


            dataTypeSemantics="identifier"
            fieldType="130" applicability="all" status="current">
       <description>
         <paragraph>
         The IPv4 address of the flow exporter. used by the exporting process.
         This is used by the
         collecter collector to identify the exporter
         in cases where the identity of the exporter may have been
         obscured by the use of a proxy.
         </paragraph>
       </description>
     </field>

     <field name="exporterAddressV6" dataType="ipv4Address"
            fieldType="83" dataType="ipv6Address"
            dataTypeSemantics="identifier"
            fieldType="131" applicability="all" status="current">
       <description>
         <paragraph>
         The IPv6 address of the flow exporter. used by the exporting process.
         This is used by the
         collecter collector to identify the exporter
         in cases where the identity of the exporter may have been
         obscured by the use of a proxy.
         </paragraph>
       </description>
     </field>

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

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

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



Calato, name="droppedOctetTotalCount" dataType="unsigned64"



Meyer, et al.           Expires August 16, 2004 January 17, 2005               [Page 41] 60]

Internet-Draft          IPFIX Information Model            February                July 2004


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

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

     <field name="flowEndReason" dataType="octet"
            fieldType="136" applicability="data" status="current">
       <description>
         <paragraph>
         The reason for flow termination.
         <list>
           <item>idle timeout</item>
           <item>end of flow detected (e.g. TCP FIN)</item>
           <item>forced end</item>
           <item>cache full</item>
         </list>
         EDITORS' NOTE: This needs to be defined as an
         enumerated range.
         </paragraph>
       </description>
     </field>

   </fieldDefinitions>







































Calato,

     <field name="classOfServiceV6" dataType="octet"
            fieldType="135" applicability="data" status="current">
       <description>
         <paragraph>
         The value of the IPv6 traffic class field observed
         for packets of this flow.
         </paragraph>
       </description>
       <reference>
         See RFC 2460 for the definition of the IPv6 traffic class field.



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


       </reference>
     </field>

   </fieldDefinitions>















































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


Appendix B. Formal Specification of Abstract Data Types

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


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

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

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

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

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



Calato,



Meyer, et al.           Expires August 16, 2004 January 17, 2005               [Page 43] 63]

Internet-Draft          IPFIX Information Model            February                July 2004


         </enumeration>

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

         <enumeration value="boolean">
           <annotation>
             <documentation>The type "boolean" represents a binary
               value.
             </documentation>
           </annotation>
         </enumeration>

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

         <enumeration value="string">
           <annotation>
             <documentation>
               The type "string" represents a finite length string
               of valid characters from the Unicode character
               encoding set.  Unicode allows for ASCII and many
               other international character sets to be used.
               It is expected that strings will be encoded in UTF-8
               format, which is identical in encoding for USASCII
               characters, but also accomodates other Unicode
               multibyte characters.
             </documentation>
           </annotation>
         </enumeration>

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



Calato,



Meyer, et al.           Expires August 16, 2004 January 17, 2005               [Page 44] 64]

Internet-Draft          IPFIX Information Model            February                July 2004


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

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

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

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

     <simpleType name="dataTypeSemantics">
       <restriction base="string">
         <enumeration value="quantity">
           <annotation>
             <documentation>
               A quantity value represents a discrete
               measured value pertaining to the record. This is
               distinguished from counters which represent an ongoing
               measured value whose "odometer" reading is captured as
               part of a given record. If no semantic qualifier is
               given, the integral fields should behave as a quantity.
             </documentation>
           </annotation>
         </enumeration>




Calato,




Meyer, et al.           Expires August 16, 2004 January 17, 2005               [Page 45] 65]

Internet-Draft          IPFIX Information Model            February                July 2004


         <enumeration value="counter">
           <annotation>
             <documentation>
               A measurement which is ongoing from the perspective
               of the exporter.  Basically the same semantics as
               counters in SNMP.  Counters are unsigned and wrap back
               to zero after reaching the limit of the type. E.g. an
               unsigned64 with counter semantics will continue to
               increment until reaching the value of 2**64 - 1.
               At this point the next increment will wrap its value
               to zero and continue counting from zero.
             </documentation>
           </annotation>
         </enumeration>

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

         <enumeration value="flags">
           <annotation>
             <documentation>
               An integral value which actually represents a set of
               bit fields.  Logical operations are appropriate on
               such values, but not other mathematical operations.
               Flags should always be of an unsigned type.
             </documentation>
           </annotation>
         </enumeration>
       </restriction>
     </simpleType>

     <simpleType name="applicability">
       <restriction base="string">
         <enumeration value="data">
           <annotation>
             <documentation>
               Used for fields that are applicable to flow records
               only.
             </documentation>



Calato,



Meyer, et al.           Expires August 16, 2004 January 17, 2005               [Page 46] 66]

Internet-Draft          IPFIX Information Model            February                July 2004


           </annotation>
         </enumeration>

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

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

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

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

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



Calato,



Meyer, et al.           Expires August 16, 2004 January 17, 2005               [Page 47] 67]

Internet-Draft          IPFIX Information Model            February                July 2004


               Indicates that the field definition is obsolete and
               should not be implemented and/or can be removed if
               previously implemented.
             </documentation>
           </annotation>
         </enumeration>
       </restriction>
     </simpleType>

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

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

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

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

     <element name="fieldDefinitions">
       <complexType>
         <sequence>



Calato,



Meyer, et al.           Expires August 16, 2004 January 17, 2005               [Page 48] 68]

Internet-Draft          IPFIX Information Model            February                July 2004


           <element maxOccurs="unbounded" minOccurs="1" name="field">
             <complexType>
               <sequence>
                 <element maxOccurs="1" minOccurs="1" name="description"
                          type="ipfix:text">
                   <annotation>
                     <documentation>
                       The semantics of this information element.
                       Describes how this field is derived from the
                       flow or other information available to the
                       observer.
                     </documentation>
                   </annotation>
                 </element>

                 <element maxOccurs="1" minOccurs="0" name="usage"
                          type="ipfix:text">
                   <annotation>
                     <documentation>to be done ...</documentation>
                   </annotation>
                 </element>

                 <element maxOccurs="1" minOccurs="0" name="units"
                          type="string">
                   <annotation>
                     <documentation>
                       If the field is a measure of some kind, the
                       units identify what the measure is.
                     </documentation>
                   </annotation>
                 </element>

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

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



Calato,



Meyer, et al.           Expires August 16, 2004 January 17, 2005               [Page 49] 69]

Internet-Draft          IPFIX Information Model            February                July 2004


                       identifiers associated with a set of discrete
                       values this element may take. The meaning of
                       each discrete value and a human readable name
                       should be assigned.
                     </documentation>
                   </annotation>
                 </element>

                 <element maxOccurs="1" minOccurs="0" name="range"
                          type="ipfix:range">
                   <annotation>
                     <documentation>
                       Some elements may only be able to take on a
                       restricted set of values which can be
                       expressed as a range (e.g. 0 through 511
                       inclusive). If this is the case, the valid
                       inclusive range should be specified.
                     </documentation>
                   </annotation>
                 </element>
               </sequence>

               <attribute name="name" type="string" use="required">
                 <annotation>
                   <documentation>
                     A unique and meaningful name for the field. 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 space does however encompass
                     most basic types used in modern programming
                     languages, as well as some derived types
                     (such as IPAddress) which are common to this
                     domain and useful to distinguish.
                   </documentation>
                 </annotation>
               </attribute>



Calato,



Meyer, et al.           Expires August 16, 2004 January 17, 2005               [Page 50] 70]

Internet-Draft          IPFIX Information Model            February                July 2004


               <attribute name="dataTypeSemantics"
                          type="ipfix:dataTypeSemantics" use="optional">
                 <annotation>
                   <documentation>
                     The integral types may be qualified by additional
                     semantic details. Qualifying the fields as
                     'quantity', 'counter', 'identifier' or 'flags'.
                   </documentation>
                 </annotation>
               </attribute>

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

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



Meyer, et al.           Expires August 16, 2004 January 17, 2005               [Page 51] 71]

Internet-Draft          IPFIX Information Model            February                July 2004


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

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

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







































Calato,







































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



Meyer, et al.           Expires August 16, 2004 January 17, 2005               [Page 53] 73]

Internet-Draft          IPFIX Information Model            February                July 2004


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


Acknowledgment

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











































Calato,











































Meyer, et al.           Expires August 16, 2004 January 17, 2005               [Page 54] 74]
----