Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5102

Information Model for IP Flow Information Export

Pages: 171
Obsoleted by:  7012
Updated by:  6313
Part 7 of 7 – Pages 143 to 171
First   Prev   None

ToP   noToC   RFC5102 - Page 143   prevText
     <field name="tcpOptions" dataType="unsigned64"
            dataTypeSemantics="flags"
            group="minMax"
            elementId="209" applicability="all" status="current">
       <description>
         <paragraph>
        TCP options in packets of this Flow.
        The information is encoded in a set of bit fields.  For
        each TCP option, there is a bit in this set.
        The bit is set to 1 if any observed packet of this Flow
        contains the corresponding TCP option.
        Otherwise, if no observed packet of this Flow contained
        the respective TCP option, the value of the
        corresponding bit is 0.
         </paragraph>
         <paragraph>
         Options are mapped to bits according to their option
         numbers.  Option number X is mapped to bit X.
         TCP option numbers are maintained by IANA.
         </paragraph>
         <artwork>
              0     1     2     3     4     5     6     7
          +-----+-----+-----+-----+-----+-----+-----+-----+
          |   0 |   1 |   2 |   3 |   4 |   5 |   6 |   7 |  ...
          +-----+-----+-----+-----+-----+-----+-----+-----+

              8     9    10    11    12    13    14    15
          +-----+-----+-----+-----+-----+-----+-----+-----+
      ... |   8 |   9 |  10 |  11 |  12 |  13 |  14 |  15 |...
          +-----+-----+-----+-----+-----+-----+-----+-----+

             16    17    18    19    20    21    22    23
          +-----+-----+-----+-----+-----+-----+-----+-----+
      ... |  16 |  17 |  18 |  19 |  20 |  21 |  22 |  23 |...
          +-----+-----+-----+-----+-----+-----+-----+-----+

                                . . .

             56    57    58    59    60    61    62    63
          +-----+-----+-----+-----+-----+-----+-----+-----+
      ... |  56 |  57 |  58 |  59 |  60 |  61 |  62 |  63 |
          +-----+-----+-----+-----+-----+-----+-----+-----+
         </artwork>
       </description>
       <reference>
         <paragraph>
         See RFC 793 for the definition of TCP options.
         See the list of TCP option numbers assigned by IANA
ToP   noToC   RFC5102 - Page 144
         at http://www.iana.org/assignments/tcp-parameters.
         </paragraph>
       </reference>
     </field>

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

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

     <field name="flowStartMilliseconds" dataType="dateTimeMilliseconds"
            group="timestamp"
            elementId="152" applicability="data" status="current">
       <description>
         <paragraph>
         The absolute timestamp of the first packet of this Flow.
         </paragraph>
       </description>
       <units>milliseconds</units>
     </field>

     <field name="flowEndMilliseconds" dataType="dateTimeMilliseconds"
            group="timestamp"
            elementId="153" applicability="data" status="current">
       <description>
         <paragraph>
         The absolute timestamp of the last packet of this Flow.
         </paragraph>
       </description>
       <units>milliseconds</units>
     </field>
ToP   noToC   RFC5102 - Page 145
     <field name="flowStartMicroseconds" dataType="dateTimeMicroseconds"
            group="timestamp"
            elementId="154" applicability="data" status="current">
       <description>
         <paragraph>
         The absolute timestamp of the first packet of this Flow.
         </paragraph>
       </description>
       <units>microseconds</units>
     </field>

     <field name="flowEndMicroseconds" dataType="dateTimeMicroseconds"
            group="timestamp"
            elementId="155" applicability="data" status="current">
       <description>
         <paragraph>
         The absolute timestamp of the last packet of this Flow.
         </paragraph>
       </description>
       <units>microseconds</units>
     </field>

     <field name="flowStartNanoseconds" dataType="dateTimeNanoseconds"
            group="timestamp"
            elementId="156" applicability="data" status="current">
       <description>
         <paragraph>
         The absolute timestamp of the first packet of this Flow.
         </paragraph>
       </description>
       <units>nanoseconds</units>
     </field>

     <field name="flowEndNanoseconds" dataType="dateTimeNanoseconds"
            group="timestamp"
            elementId="157" applicability="data" status="current">
       <description>
         <paragraph>
         The absolute timestamp of the last packet of this Flow.
         </paragraph>
       </description>
       <units>nanoseconds</units>
     </field>

     <field name="flowStartDeltaMicroseconds" dataType="unsigned32"
            group="timestamp"
            elementId="158" applicability="data" status="current">
       <description>
ToP   noToC   RFC5102 - Page 146
         <paragraph>
         This is a relative timestamp only valid within the scope
         of a single IPFIX Message.  It contains the negative time
         offset of the first observed packet of this Flow relative
         to the export time specified in the IPFIX Message Header.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See the IPFIX protocol specification [RFC5101] for the
         definition of the IPFIX Message Header.
         </paragraph>
       </reference>
       <units>microseconds</units>
     </field>

     <field name="flowEndDeltaMicroseconds" dataType="unsigned32"
            group="timestamp"
            elementId="159" applicability="data" status="current">
       <description>
         <paragraph>
         This is a relative timestamp only valid within the scope
         of a single IPFIX Message.  It contains the negative time
         offset of the last observed packet of this Flow relative
         to the export time specified in the IPFIX Message Header.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See the IPFIX protocol specification [RFC5101] for the
         definition of the IPFIX Message Header.
         </paragraph>
       </reference>
       <units>microseconds</units>
     </field>

     <field name="systemInitTimeMilliseconds"
            dataType="dateTimeMilliseconds"
            group="timestamp"
            elementId="160" applicability="data" status="current">
       <description>
         <paragraph>
         The absolute timestamp of the last (re-)initialization of the
         IPFIX Device.
         </paragraph>
       </description>
       <units>milliseconds</units>
     </field>
ToP   noToC   RFC5102 - Page 147
     <field name="flowStartSysUpTime" dataType="unsigned32"
            group="timestamp"
            elementId="22" applicability="data" status="current">
       <description>
         <paragraph>
         The relative timestamp of the first packet of this Flow.
         It indicates the number of milliseconds since the
         last (re-)initialization of the IPFIX Device (sysUpTime).
         </paragraph>
       </description>
       <units>milliseconds</units>
     </field>

     <field name="flowEndSysUpTime" dataType="unsigned32"
            group="timestamp"
            elementId="21" applicability="data" status="current">
       <description>
         <paragraph>
         The relative timestamp of the last packet of this Flow.
         It indicates the number of milliseconds since the
         last (re-)initialization of the IPFIX Device (sysUpTime).
         </paragraph>
       </description>
       <units>milliseconds</units>
     </field>

     <field name="octetDeltaCount" dataType="unsigned64"
            dataTypeSemantics="deltaCounter"
            group="flowCounter"
            elementId="1" applicability="data" status="current">
       <description>
         <paragraph>
         The number of octets since the previous report (if any)
         in incoming packets for this Flow at the Observation Point.
         The number of octets includes IP header(s) and IP payload.
         </paragraph>
       </description>
       <units>octets</units>
     </field>

     <field name="postOctetDeltaCount" dataType="unsigned64"
            dataTypeSemantics="deltaCounter"
            group="flowCounter"
            elementId="23" applicability="data" status="current">
       <description>
         <paragraph>
         The definition of this Information Element is identical
         to the definition of Information Element
ToP   noToC   RFC5102 - Page 148
         'octetDeltaCount', except that it reports a
         potentially modified value caused by a middlebox
         function after the packet passed the Observation Point.
         </paragraph>
       </description>
       <units>octets</units>
     </field>

     <field name="octetDeltaSumOfSquares" dataType="unsigned64"
            group="flowCounter"
            elementId="198" applicability="data" status="current">
       <description>
         <paragraph>
         The sum of the squared numbers of octets per incoming
         packet since the previous report (if any) for this
         Flow at the Observation Point.
         The number of octets includes IP header(s) and IP payload.
         </paragraph>
       </description>
     </field>

     <field name="octetTotalCount" dataType="unsigned64"
            dataTypeSemantics="totalCounter"
            group="flowCounter"
            elementId="85" applicability="all" status="current">
       <description>
         <paragraph>
         The total number of octets in incoming packets
         for this Flow at the Observation Point since the Metering
         Process (re-)initialization for this Observation Point.  The
         number of octets includes IP header(s) and IP payload.
         </paragraph>
       </description>
       <units>octets</units>
     </field>

     <field name="postOctetTotalCount" dataType="unsigned64"
            dataTypeSemantics="totalCounter"
            group="flowCounter"
            elementId="171" applicability="all" status="current">
       <description>
         <paragraph>
         The definition of this Information Element is identical
         to the definition of Information Element
         'octetTotalCount', except that it reports a
         potentially modified value caused by a middlebox
         function after the packet passed the Observation Point.
         </paragraph>
ToP   noToC   RFC5102 - Page 149
       </description>
       <units>octets</units>
     </field>

     <field name="octetTotalSumOfSquares" dataType="unsigned64"
            group="flowCounter"
            elementId="199" applicability="all" status="current">
       <description>
         <paragraph>
         The total sum of the squared numbers of octets in incoming
         packets for this Flow at the Observation Point since the
         Metering Process (re-)initialization for this Observation
         Point.  The number of octets includes IP header(s) and IP
         payload.
         </paragraph>
       </description>
       <units>octets</units>
     </field>

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

     <field name="postPacketDeltaCount" dataType="unsigned64"
            dataTypeSemantics="deltaCounter"
            group="flowCounter"
            elementId="24" applicability="data" status="current">
       <description>
         <paragraph>
         The definition of this Information Element is identical
         to the definition of Information Element
         'packetDeltaCount', except that it reports a
         potentially modified value caused by a middlebox
         function after the packet passed the Observation Point.
         </paragraph>
       </description>
       <units>packets</units>
     </field>
ToP   noToC   RFC5102 - Page 150
     <field name="packetTotalCount" dataType="unsigned64"
            dataTypeSemantics="totalCounter"
            group="flowCounter"
            elementId="86" applicability="all" status="current">
       <description>
         <paragraph>
         The total number of incoming packets for this Flow
         at the Observation Point since the Metering Process
         (re-)initialization for this Observation Point.
         </paragraph>
       </description>
       <units>packets</units>
     </field>

     <field name="postPacketTotalCount" dataType="unsigned64"
            dataTypeSemantics="totalCounter"
            group="flowCounter"
            elementId="172" applicability="all" status="current">
       <description>
         <paragraph>
         The definition of this Information Element is identical
         to the definition of Information Element
         'packetTotalCount', except that it reports a
         potentially modified value caused by a middlebox
         function after the packet passed the Observation Point.
         </paragraph>
       </description>
       <units>packets</units>
     </field>

     <field name="droppedOctetDeltaCount" dataType="unsigned64"
            dataTypeSemantics="deltaCounter"
            group="flowCounter"
            elementId="132" applicability="data" status="current">
       <description>
         <paragraph>
         The number of octets since the previous report (if any)
         in packets of this Flow dropped by packet treatment.
         The number of octets includes IP header(s) and IP payload.
         </paragraph>
       </description>
       <units>octets</units>
     </field>

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

     <field name="droppedOctetTotalCount" dataType="unsigned64"
            dataTypeSemantics="totalCounter"
            group="flowCounter"
            elementId="134" applicability="data" status="current">
       <description>
         <paragraph>
         The total number of octets in packets of this Flow dropped
         by packet treatment since the Metering Process
         (re-)initialization for this Observation Point.
         The number of octets includes IP header(s) and IP payload.
         </paragraph>
       </description>
       <units>octets</units>
     </field>

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

     <field name="postMCastPacketDeltaCount" dataType="unsigned64"
            dataTypeSemantics="deltaCounter"
            group="flowCounter"
            elementId="19" applicability="data" status="current">
       <description>
         <paragraph>
         The number of outgoing multicast packets since the
         previous report (if any) sent for packets of this Flow
         by a multicast daemon within the Observation Domain.
         This property cannot necessarily be observed at the
ToP   noToC   RFC5102 - Page 152
         Observation Point, but may be retrieved by other means.
         </paragraph>
       </description>
       <units>packets</units>
     </field>

     <field name="postMCastOctetDeltaCount" dataType="unsigned64"
            dataTypeSemantics="deltaCounter"
            group="flowCounter"
            elementId="20" applicability="data" status="current">
       <description>
         <paragraph>
         The number of octets since the previous report (if any)
         in outgoing multicast packets sent for packets of this
         Flow by a multicast daemon within the Observation Domain.
         This property cannot necessarily be observed at the
         Observation Point, but may be retrieved by other means.
         The number of octets includes IP header(s) and IP payload.
         </paragraph>
       </description>
       <units>octets</units>
     </field>

     <field name="postMCastPacketTotalCount" dataType="unsigned64"
            dataTypeSemantics="totalCounter"
            group="flowCounter"
            elementId="174" applicability="data" status="current">
       <description>
         <paragraph>
         The total number of outgoing multicast packets sent for
         packets of this Flow by a multicast daemon within the
         Observation Domain since the Metering Process
         (re-)initialization.  This property cannot necessarily
         be observed at the Observation Point, but may be retrieved
         by other means.
         </paragraph>
       </description>
       <units>packets</units>
     </field>

     <field name="postMCastOctetTotalCount" dataType="unsigned64"
            dataTypeSemantics="totalCounter"
            group="flowCounter"
            elementId="175" applicability="data" status="current">
       <description>
         <paragraph>
         The total number of octets in outgoing multicast packets
         sent for packets of this Flow by a multicast daemon in the
ToP   noToC   RFC5102 - Page 153
         Observation Domain since the Metering Process
         (re-)initialization.  This property cannot necessarily be
         observed at the Observation Point, but may be retrieved by
         other means.
         The number of octets includes IP header(s) and IP payload.
         </paragraph>
       </description>
       <units>octets</units>
     </field>

     <field name="tcpSynTotalCount" dataType="unsigned64"
            dataTypeSemantics="totalCounter"
            group="flowCounter"
            elementId="218" applicability="data" status="current">
       <description>
         <paragraph>
          The total number of packets of this Flow with
          TCP "Synchronize sequence numbers" (SYN) flag set.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 793 for the definition of the TCP SYN flag.
         </paragraph>
       </reference>
       <units>packets</units>
     </field>

     <field name="tcpFinTotalCount" dataType="unsigned64"
            dataTypeSemantics="totalCounter"
            group="flowCounter"
            elementId="219" applicability="data" status="current">
       <description>
         <paragraph>
          The total number of packets of this Flow with
          TCP "No more data from sender" (FIN) flag set.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 793 for the definition of the TCP FIN flag.
         </paragraph>
       </reference>
       <units>packets</units>
     </field>

     <field name="tcpRstTotalCount" dataType="unsigned64"
            dataTypeSemantics="totalCounter"
ToP   noToC   RFC5102 - Page 154
            group="flowCounter"
            elementId="220" applicability="data" status="current">
       <description>
         <paragraph>
          The total number of packets of this Flow with
          TCP "Reset the connection" (RST) flag set.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 793 for the definition of the TCP RST flag.
         </paragraph>
       </reference>
       <units>packets</units>
     </field>

     <field name="tcpPshTotalCount" dataType="unsigned64"
            dataTypeSemantics="totalCounter"
            group="flowCounter"
            elementId="221" applicability="data" status="current">
       <description>
         <paragraph>
          The total number of packets of this Flow with
          TCP "Push Function" (PSH) flag set.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 793 for the definition of the TCP PSH flag.
         </paragraph>
       </reference>
       <units>packets</units>
     </field>

     <field name="tcpAckTotalCount" dataType="unsigned64"
            dataTypeSemantics="totalCounter"
            group="flowCounter"
            elementId="222" applicability="data" status="current">
       <description>
         <paragraph>
          The total number of packets of this Flow with
          TCP "Acknowledgment field significant" (ACK) flag set.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 793 for the definition of the TCP ACK flag.
         </paragraph>
ToP   noToC   RFC5102 - Page 155
       </reference>
       <units>packets</units>
     </field>

     <field name="tcpUrgTotalCount" dataType="unsigned64"
            dataTypeSemantics="totalCounter"
            group="flowCounter"
            elementId="223" applicability="data" status="current">
       <description>
         <paragraph>
          The total number of packets of this Flow with
          TCP "Urgent Pointer field significant" (URG) flag set.
         </paragraph>
       </description>
       <reference>
         <paragraph>
         See RFC 793 for the definition of the TCP URG flag.
         </paragraph>
       </reference>
       <units>packets</units>
     </field>

     <field name="flowActiveTimeout" dataType="unsigned16"
            group="misc"
            elementId="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="flowIdleTimeout" dataType="unsigned16"
            group="misc"
            elementId="37" applicability="all" status="current">
       <description>
         <paragraph>
          A Flow is considered to be timed out if no packets belonging
          to the Flow have been observed for the number of seconds
          specified by this field.
         </paragraph>
       </description>
       <units>seconds</units>
     </field>

     <field name="flowEndReason" dataType="unsigned8"
ToP   noToC   RFC5102 - Page 156
            group="misc"
            dataTypeSemantics="identifier"
            elementId="136" applicability="data" status="current">
       <description>
         <paragraph>
         The reason for Flow termination.  The range of values includes
         the following:
         </paragraph>
         <artwork>
      0x01: idle timeout
            The Flow was terminated because it was considered to be
            idle.
      0x02: active timeout
            The Flow was terminated for reporting purposes while it was
            still active, for example, after the maximum lifetime of
            unreported Flows was reached.
      0x03: end of Flow detected
            The Flow was terminated because the Metering Process
            detected signals indicating the end of the Flow,
            for example, the TCP FIN flag.
      0x04: forced end
            The Flow was terminated because of some external event,
            for example, a shutdown of the Metering Process initiated
            by a network management application.
      0x05: lack of resources
            The Flow was terminated because of lack of resources
            available to the Metering Process and/or the Exporting
            Process.
         </artwork>
       </description>
     </field>

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

     <field name="flowDurationMicroseconds" dataType="unsigned32"
            group="misc"
            elementId="162" applicability="data" status="current">
       <description>
ToP   noToC   RFC5102 - Page 157
         <paragraph>
         The difference in time between the first observed packet
         of this Flow and the last observed packet of this Flow.
         </paragraph>
       </description>
       <units>microseconds</units>
     </field>

     <field name="flowDirection" dataType="unsigned8"
            dataTypeSemantics="identifier"
            group="misc"
            elementId="61" applicability="data" status="current">
       <description>
         <paragraph>
         The direction of the Flow observed at the Observation
         Point.  There are only two values defined.
         </paragraph>
         <artwork>
         0x00: ingress flow
         0x01: egress flow
         </artwork>
       </description>
     </field>

     <field name="paddingOctets" dataType="octetArray"
            group="padding"
            elementId="210" applicability="option" status="current">
       <description>
         <paragraph>
           The value of this Information Element is always a sequence of
           0x00 values.
         </paragraph>
       </description>
     </field>

   </fieldDefinitions>

Appendix B. XML Specification of Abstract Data Types

This appendix contains a machine-readable description of the abstract data types to be used for IPFIX Information Elements and a machine- readable description of the template used for defining IPFIX Information Elements. Note that this appendix is of informational nature, while the text in Sections 2 and 3 (generated from this appendix) is normative. At the same time, this appendix is also an XML schema that was used for creating the XML specification of Information Elements in
ToP   noToC   RFC5102 - Page 158
   Appendix A.  It may also be used for specifying further Information
   Elements in extensions of the IPFIX information model.  This schema
   and its namespace are registered by IANA at
   http://www.iana.org/assignments/xml-registry/schema/ipfix.xsd.

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

   <schema targetNamespace="urn:ietf:params:xml:ns:ipfix-info"
           xmlns:ipfix="urn:ietf:params:xml:ns:ipfix-info"
           xmlns="http://www.w3.org/2001/XMLSchema"
           elementFormDefault="qualified">

     <simpleType name="dataType">
       <restriction base="string">
         <enumeration value="unsigned8">
           <annotation>
             <documentation>The type "unsigned8" 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>
         </enumeration>
ToP   noToC   RFC5102 - Page 159
         <enumeration value="signed8">
           <annotation>
             <documentation>The type "signed8" represents
               an integer value in the range of -128 to 127.
             </documentation>
           </annotation>
         </enumeration>

         <enumeration value="signed16">
           <annotation>
             <documentation>The type "signed16" represents an
               integer value in the range of -32768 to 32767.
             </documentation>
           </annotation>
         </enumeration>

         <enumeration value="signed32">
           <annotation>
             <documentation>The type "signed32" represents an
                integer value in the range of -2147483648 to
                2147483647.
             </documentation>
           </annotation>
         </enumeration>

         <enumeration value="signed64">
           <annotation>
             <documentation>The type "signed64" represents an
                integer value in the range of -9223372036854775808
                to 9223372036854775807.
             </documentation>
           </annotation>
         </enumeration>

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

         <enumeration value="float64">
           <annotation>
             <documentation>The type "float64" corresponds to an IEEE
               double-precision 64-bit floating point type as defined
               in [IEEE.754.1985].
ToP   noToC   RFC5102 - Page 160
             </documentation>
           </annotation>
         </enumeration>

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

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

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

         <enumeration value="string">
           <annotation>
             <documentation>
               The type "string" represents a finite-length string
               of valid characters from the Unicode character encoding
               set [ISO.10646-1.1993].  Unicode allows for ASCII
               [ISO.646.1991] and many other international character
               sets to be used.
             </documentation>
           </annotation>
         </enumeration>

         <enumeration value="dateTimeSeconds">
           <annotation>
             <documentation>
               The type "dateTimeSeconds" represents a time value
               in units of seconds based on coordinated universal time
               (UTC).  The choice of an epoch, for example, 00:00 UTC,
               January 1, 1970, is left to corresponding encoding
               specifications for this type, for example, the IPFIX
ToP   noToC   RFC5102 - Page 161
               protocol specification.  Leap seconds are excluded.
               Note that transformation of values might be required
               between different encodings if different epoch values
               are used.
             </documentation>
           </annotation>
         </enumeration>

         <enumeration value="dateTimeMilliseconds">
           <annotation>
             <documentation>The type "dateTimeMilliseconds" represents
               a time value in units of milliseconds
               based on coordinated universal time (UTC).
               The choice of an epoch, for example,  00:00 UTC,
               January 1, 1970, is left to corresponding encoding
               specifications for this type, for example, the IPFIX
               protocol specification.  Leap seconds are excluded.
               Note that transformation of values might be required
               between different encodings if different epoch values
               are used.
             </documentation>
           </annotation>
         </enumeration>

         <enumeration value="dateTimeMicroseconds">
           <annotation>
             <documentation>The type "dateTimeMicroseconds" represents
               a time value in units of microseconds
               based on coordinated universal time (UTC).
               The choice of an epoch, for example,  00:00 UTC,
               January 1, 1970, is left to corresponding encoding
               specifications for this type, for example, the IPFIX
               protocol specification.  Leap seconds are excluded.
               Note that transformation of values might be required
               between different encodings if different epoch values
               are used.
             </documentation>
           </annotation>
         </enumeration>

         <enumeration value="dateTimeNanoseconds">
           <annotation>
             <documentation>The type "dateTimeNanoseconds" represents
               a time value in units of nanoseconds
               based on coordinated universal time (UTC).
               The choice of an epoch, for example,  00:00 UTC,
               January 1, 1970, is left to corresponding encoding
               specifications for this type, for example, the IPFIX
ToP   noToC   RFC5102 - Page 162
               protocol specification.  Leap seconds are excluded.
               Note that transformation of values might be required
               between different encodings if different epoch values
               are used.
             </documentation>
           </annotation>
         </enumeration>

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

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

         <enumeration value="totalCounter">
           <annotation>
             <documentation>
               An integral value reporting the value of a counter.
               Counters are unsigned and wrap back to zero after
               reaching the limit of the type.  For example, an
               unsigned64 with counter semantics will continue to
ToP   noToC   RFC5102 - Page 163
               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.  The semantics
               of a total counter is similar to the semantics of
               counters used in SNMP, such as Counter32 defined in
               RFC 2578 [RFC2578].  The only difference between total
               counters and counters used in SNMP is that the total
               counters have an initial value of 0.  A total counter
               counts independently of the export of its value.
             </documentation>
           </annotation>
         </enumeration>

         <enumeration value="deltaCounter">
           <annotation>
             <documentation>
               An integral value reporting the value of a counter.
               Counters are unsigned and wrap back to zero after
               reaching the limit of the type.  For example, an
               unsigned64 with counter semantics will continue to
               increment until reaching the value of 2**64 - 1.  At
               this point, the next increment will wrap its value to
               zero and continue counting from zero.  The semantics
               of a delta counter is similar to the semantics of
               counters used in SNMP, such as Counter32 defined in
               RFC 2578 [RFC2578].  The only difference between delta
               counters and counters used in SNMP is that the delta
               counters have an initial value of 0.  A delta counter
               is reset to 0 each time its value is exported.
             </documentation>
           </annotation>
         </enumeration>

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

         <enumeration value="flags">
           <annotation>
             <documentation>
ToP   noToC   RFC5102 - Page 164
               An integral value that 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 Information Elements that are applicable to
               Flow Records only.
             </documentation>
           </annotation>
         </enumeration>

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

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

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

         <enumeration value="deprecated">
           <annotation>
             <documentation>
               Indicates that the Information Element definition is
               obsolete, but it permits new/continued implementation
               in order to foster interoperability with older/existing
               implementations.
             </documentation>
           </annotation>
         </enumeration>
         <enumeration value="obsolete">
           <annotation>
             <documentation>
               Indicates that the Information Element definition is
               obsolete and should not be implemented and/or can be
               removed if previously implemented.
             </documentation>
           </annotation>
         </enumeration>
       </restriction>
     </simpleType>

     <complexType name="text">
       <choice maxOccurs="unbounded" minOccurs="0">
         <element name="paragraph">
           <complexType mixed="true">
             <sequence>
                <element maxOccurs="unbounded" minOccurs="0"
                  name="xref">
                  <complexType>
                    <attribute name="target" type="string"
                      use="required"/>
                  </complexType>
                </element>
             </sequence>
           </complexType>
         </element>
         <element name="artwork">
           <simpleType>
             <restriction base="string"/>
           </simpleType>
         </element>
       </choice>
     </complexType>
ToP   noToC   RFC5102 - Page 166
     <simpleType name="range">
       <restriction base="string"/>
     </simpleType>
     <element name="fieldDefinitions">
       <complexType>
         <sequence>
           <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 Information Element is
                       derived from the Flow or other information
                       available to the observer.
                     </documentation>
                   </annotation>
                 </element>

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

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

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

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

               <attribute name="dataType" type="ipfix:dataType"
                          use="required">
                 <annotation>
                   <documentation>
                     One of the types listed in Section 3.1 of this
                     document or in a future extension of the
                     information model.  The type space for attributes
                     is constrained to facilitate implementation.  The
                     existing type space does however encompass most
                     basic types used in modern programming languages,
                     as well as some derived types (such as ipv4Address)
                     that are common to this domain and useful
                     to distinguish.
                   </documentation>
                 </annotation>
               </attribute>

               <attribute name="dataTypeSemantics"
                          type="ipfix:dataTypeSemantics" use="optional">
                 <annotation>
                   <documentation>
                     The integral types may be qualified by additional
                     semantic details.  Valid values for the data type
                     semantics are specified in Section 3.2 of this
                     document or in a future extension of the
                     information model.
                   </documentation>
                 </annotation>
               </attribute>

               <attribute name="elementId" type="nonNegativeInteger"
ToP   noToC   RFC5102 - Page 168
                          use="required">
                 <annotation>
                   <documentation>
                     A numeric identifier of the Information Element.
                     If this identifier is used without an enterprise
                     identifier (see [RFC5101] and
                     enterpriseId below), then it is globally unique
                     and the list of allowed values is administered by
                     IANA.  It is used for compact identification of an
                     Information Element when encoding Templates in the
                     protocol.
                   </documentation>
                 </annotation>
               </attribute>

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

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

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

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

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

         <field xpath="elementId"/>
       </unique>
     </element>
   </schema>
ToP   noToC   RFC5102 - Page 170

Authors' Addresses

Juergen Quittek NEC Kurfuersten-Anlage 36 Heidelberg 69115 Germany Phone: +49 6221 90511-15 EMail: quittek@nw.neclab.eu URI: http://www.neclab.eu/ Stewart Bryant Cisco Systems, Inc. 250, Longwater Ave., Green Park Reading RG2 6GB United Kingdom EMail: stbryant@cisco.com Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 Diegem 1831 Belgium Phone: +32 2 704 5622 EMail: bclaise@cisco.com Paul Aitken Cisco Systems, Inc. 96 Commercial Quay Edinburgh EH6 6LX Scotland Phone: +44 131 561 3616 EMail: paitken@cisco.com Jeff Meyer PayPal 2211 N. First St. San Jose, CA 95131-2021 US Phone: +1 408 976-9149 EMail: jemeyer@paypal.com URI: http://www.paypal.com
ToP   noToC   RFC5102 - Page 171
Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

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

Intellectual Property

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

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

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