Information Model for IP Flow Information Export
RFC 5102
| Document | Type |
RFC
- Proposed Standard
(January 2008)
Errata
Obsoleted by RFC 7012
Updated by RFC 6313
|
|
|---|---|---|---|
| Authors | Benoît Claise , Juergen Quittek , Jeff Meyer , Stewart Bryant , Paul Aitken | ||
| Last updated | 2020-01-21 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| IESG | Responsible AD | Dan Romascanu | |
| Send notices to | (None) |
RFC 5102
>
<description>
Quittek, et al. Standards Track [Page 138]
RFC 5102 IPFIX Information Model January 2008
<paragraph>
IPv4 options in packets of this Flow.
The information is encoded in a set of bit fields. For
each valid IPv4 option type, there is a bit in this set.
The bit is set to 1 if any observed packet of this Flow
contains the corresponding IPv4 option type. Otherwise,
if no observed packet of this Flow contained the
respective IPv4 option type, the value of the
corresponding bit is 0.
</paragraph>
<paragraph>
The list of valid IPv4 options is maintained by IANA.
Note that for identifying an option not just the 5-bit
Option Number, but all 8 bits of the Option Type need to
match one of the IPv4 options specified at
http://www.iana.org/assignments/ip-parameters.
</paragraph>
<paragraph>
Options are mapped to bits according to their option numbers.
Option number X is mapped to bit X.
The mapping is illustrated by the figure below.
</paragraph>
<artwork>
0 1 2 3 4 5 6 7
+------+------+------+------+------+------+------+------+
| EOOL | NOP | SEC | LSR | TS |E-SEC |CIPSO | RR | ...
+------+------+------+------+------+------+------+------+
8 9 10 11 12 13 14 15
+------+------+------+------+------+------+------+------+
... | SID | SSR | ZSU | MTUP | MTUR | FINN | VISA |ENCODE| ...
+------+------+------+------+------+------+------+------+
16 17 18 19 20 21 22 23
+------+------+------+------+------+------+------+------+
... |IMITD | EIP | TR |ADDEXT|RTRALT| SDB |NSAPA | DPS | ...
+------+------+------+------+------+------+------+------+
24 25 26 27 28 29 30 31
+------+------+------+------+------+------+------+------+
... | UMP | QS | to be assigned by IANA | EXP | |
+------+------+------+------+------+------+------+------+
Type Option
Bit Value Name Reference
---+-----+-------+------------------------------------
0 0 EOOL End of Options List, RFC 791
1 1 NOP No Operation, RFC 791
Quittek, et al. Standards Track [Page 139]
RFC 5102 IPFIX Information Model January 2008
2 130 SEC Security, RFC 1108
3 131 LSR Loose Source Route, RFC 791
4 68 TS Time Stamp, RFC 791
5 133 E-SEC Extended Security, RFC 1108
6 134 CIPSO Commercial Security
7 7 RR Record Route, RFC 791
8 136 SID Stream ID, RFC 791
9 137 SSR Strict Source Route, RFC 791
10 10 ZSU Experimental Measurement
11 11 MTUP (obsoleted) MTU Probe, RFC 1191
12 12 MTUR (obsoleted) MTU Reply, RFC 1191
13 205 FINN Experimental Flow Control
14 142 VISA Experimental Access Control
15 15 ENCODE
16 144 IMITD IMI Traffic Descriptor
17 145 EIP Extended Internet Protocol, RFC 1385
18 82 TR Traceroute, RFC 3193
19 147 ADDEXT Address Extension
20 148 RTRALT Router Alert, RFC 2113
21 149 SDB Selective Directed Broadcast
22 150 NSAPA NSAP Address
23 151 DPS Dynamic Packet State
24 152 UMP Upstream Multicast Pkt.
25 25 QS Quick-Start
30 30 EXP RFC3692-style Experiment
30 94 EXP RFC3692-style Experiment
30 158 EXP RFC3692-style Experiment
30 222 EXP RFC3692-style Experiment
... ... ... Further options numbers
may be assigned by IANA
</artwork>
</description>
<reference>
<paragraph>
See RFC 791 for the definition of IPv4 options.
See the list of IPv4 option numbers assigned by IANA
at http://www.iana.org/assignments/ip-parameters.
</paragraph>
</reference>
</field>
<field name="ipv6ExtensionHeaders" dataType="unsigned32"
dataTypeSemantics="flags"
group="minMax"
elementId="64" applicability="all" status="current">
<description>
<paragraph>
Quittek, et al. Standards Track [Page 140]
RFC 5102 IPFIX Information Model January 2008
IPv6 extension headers observed in packets of this Flow.
The information is encoded in a set of bit fields. For
each IPv6 option header, there is a bit in this set.
The bit is set to 1 if any observed packet of this Flow
contains the corresponding IPv6 extension header.
Otherwise, if no observed packet of this Flow contained
the respective IPv6 extension header, the value of the
corresponding bit is 0.
</paragraph>
<artwork>
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| Res | FRA1| RH | FRA0| UNK | Res | HOP | DST | ...
+-----+-----+-----+-----+-----+-----+-----+-----+
8 9 10 11 12 13 14 15
+-----+-----+-----+-----+-----+-----+-----+-----+
... | PAY | AH | ESP | Reserved | ...
+-----+-----+-----+-----+-----+-----+-----+-----+
16 17 18 19 20 21 22 23
+-----+-----+-----+-----+-----+-----+-----+-----+
... | Reserved | ...
+-----+-----+-----+-----+-----+-----+-----+-----+
24 25 26 27 28 29 30 31
+-----+-----+-----+-----+-----+-----+-----+-----+
... | Reserved |
+-----+-----+-----+-----+-----+-----+-----+-----+
Bit IPv6 Option Description
0, Res Reserved
1, FRA1 44 Fragmentation header - not first fragment
2, RH 43 Routing header
3, FRA0 44 Fragment header - first fragment
4, UNK Unknown Layer 4 header
(compressed, encrypted, not supported)
5, Res Reserved
6, HOP 0 Hop-by-hop option header
7, DST 60 Destination option header
8, PAY 108 Payload compression header
9, AH 51 Authentication Header
10, ESP 50 Encrypted security payload
11 to 31 Reserved
</artwork>
</description>
<reference>
<paragraph>
See RFC 2460 for the general definition of
Quittek, et al. Standards Track [Page 141]
RFC 5102 IPFIX Information Model January 2008
IPv6 extension headers and for the specification of
the hop-by-hop options header, the routing header,
the fragment header, and the destination options header.
See RFC 4302 for the specification of the
authentication header.
See RFC 4303 for the specification of the
encapsulating security payload.
</paragraph>
</reference>
</field>
<field name="tcpControlBits" dataType="unsigned8"
dataTypeSemantics="flags"
group="minMax"
elementId="6" applicability="all" status="current">
<description>
<paragraph>
TCP control bits observed for packets of this Flow.
The information is encoded in a set of bit fields.
For each TCP control bit, there is a bit in this
set. A bit is set to 1 if any observed packet of this
Flow has the corresponding TCP control bit set to 1.
A value of 0 for a bit indicates that the corresponding
bit was not set in any of the observed packets
of this Flow.
</paragraph>
<artwork>
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| Reserved | URG | ACK | PSH | RST | SYN | FIN |
+-----+-----+-----+-----+-----+-----+-----+-----+
Reserved: Reserved for future use by TCP. Must be zero.
URG: Urgent Pointer field significant
ACK: Acknowledgment field significant
PSH: Push Function
RST: Reset the connection
SYN: Synchronize sequence numbers
FIN: No more data from sender
</artwork>
</description>
<reference>
<paragraph>
See RFC 793 for the definition of
the TCP control bits in the TCP header.
</paragraph>
</reference>
</field>
Quittek, et al. Standards Track [Page 142]
RFC 5102 IPFIX Information Model January 2008
<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
Quittek, et al. Standards Track [Page 143]
RFC 5102 IPFIX Information Model January 2008
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>
Quittek, et al. Standards Track [Page 144]
RFC 5102 IPFIX Information Model January 2008
<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>
Quittek, et al. Standards Track [Page 145]
RFC 5102 IPFIX Information Model January 2008
<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>
Quittek, et al. Standards Track [Page 146]
RFC 5102 IPFIX Information Model January 2008
<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
Quittek, et al. Standards Track [Page 147]
RFC 5102 IPFIX Information Model January 2008
'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>
Quittek, et al. Standards Track [Page 148]
RFC 5102 IPFIX Information Model January 2008
</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>
Quittek, et al. Standards Track [Page 149]
RFC 5102 IPFIX Information Model January 2008
<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">
Quittek, et al. Standards Track [Page 150]
RFC 5102 IPFIX Information Model January 2008
<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
Quittek, et al. Standards Track [Page 151]
RFC 5102 IPFIX Information Model January 2008
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
Quittek, et al. Standards Track [Page 152]
RFC 5102 IPFIX Information Model January 2008
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"
Quittek, et al. Standards Track [Page 153]
RFC 5102 IPFIX Information Model January 2008
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>
Quittek, et al. Standards Track [Page 154]
RFC 5102 IPFIX Information Model January 2008
</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"
Quittek, et al. Standards Track [Page 155]
RFC 5102 IPFIX Information Model January 2008
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>
Quittek, et al. Standards Track [Page 156]
RFC 5102 IPFIX Information Model January 2008
<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
Quittek, et al. Standards Track [Page 157]
RFC 5102 IPFIX Information Model January 2008
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>
Quittek, et al. Standards Track [Page 158]
RFC 5102 IPFIX Information Model January 2008
<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].
Quittek, et al. Standards Track [Page 159]
RFC 5102 IPFIX Information Model January 2008
</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
Quittek, et al. Standards Track [Page 160]
RFC 5102 IPFIX Information Model January 2008
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
Quittek, et al. Standards Track [Page 161]
RFC 5102 IPFIX Information Model January 2008
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
Quittek, et al. Standards Track [Page 162]
RFC 5102 IPFIX Information Model January 2008
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>
Quittek, et al. Standards Track [Page 163]
RFC 5102 IPFIX Information Model January 2008
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.
Quittek, et al. Standards Track [Page 164]
RFC 5102 IPFIX Information Model January 2008
</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>
Quittek, et al. Standards Track [Page 165]
RFC 5102 IPFIX Information Model January 2008
<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
Quittek, et al. Standards Track [Page 166]
RFC 5102 IPFIX Information Model January 2008
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"
Quittek, et al. Standards Track [Page 167]
RFC 5102 IPFIX Information Model January 2008
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.
Quittek, et al. Standards Track [Page 168]
RFC 5102 IPFIX Information Model January 2008
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>
Quittek, et al. Standards Track [Page 169]
RFC 5102 IPFIX Information Model January 2008
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
Quittek, et al. Standards Track [Page 170]
RFC 5102 IPFIX Information Model January 2008
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.
Quittek, et al. Standards Track [Page 171]