One document matched: draft-ietf-ipfix-info-06.txt
Differences from draft-ietf-ipfix-info-05.txt
Network Working Group J. Quittek
Internet-Draft NEC
Expires: August 21, 2005 S. Bryant
Cisco Systems Ltd
J. Meyer
PayPal
February 20, 2005
Information Model for IP Flow Information Export
draft-ietf-ipfix-info-06
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 21, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This memo defines and information model for the IP Flow Information
eXport (IPFIX) protocol. It is used by the IPFIX protocol for
encoding measured traffic information and information related to the
traffic Observation Point, the traffic Metering Process and the
Quittek, et al. Expires August 21, 2005 [Page 1]
Internet-Draft IPFIX Information Model February 2005
Exporting Process. Although developed for the IPFIX protocol, the
model is defined in an open way that easily allows using it in other
protocols, interfaces, and applications.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Properties of IPFIX Protocol Information Elements . . . . . 6
3. Type Space . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1 Data Types . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.1 octet . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.2 unsigned16 . . . . . . . . . . . . . . . . . . . . . . 8
3.1.3 unsigned32 . . . . . . . . . . . . . . . . . . . . . . 8
3.1.4 unsigned64 . . . . . . . . . . . . . . . . . . . . . . 8
3.1.5 float32 . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.6 boolean . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.7 octetArray . . . . . . . . . . . . . . . . . . . . . . 8
3.1.8 string . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.9 dateTimeSeconds . . . . . . . . . . . . . . . . . . . 9
3.1.10 dateTimeMicroSeconds . . . . . . . . . . . . . . . . 9
3.1.11 ipv4Address . . . . . . . . . . . . . . . . . . . . 9
3.1.12 ipv6Address . . . . . . . . . . . . . . . . . . . . 9
3.2 Data Type Semantics . . . . . . . . . . . . . . . . . . . 9
3.2.1 quantity . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.2 totalCounter . . . . . . . . . . . . . . . . . . . . . 9
3.2.3 deltaCounter . . . . . . . . . . . . . . . . . . . . . 10
3.2.4 identifier . . . . . . . . . . . . . . . . . . . . . . 10
3.2.5 flags . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Information Element Identifiers . . . . . . . . . . . . . . 11
5. Information Elements . . . . . . . . . . . . . . . . . . . . 13
5.1 IP Header Fields . . . . . . . . . . . . . . . . . . . . . 13
5.1.1 ipVersion . . . . . . . . . . . . . . . . . . . . . . 13
5.1.2 sourceIPv4Address . . . . . . . . . . . . . . . . . . 14
5.1.3 sourceIPv6Address . . . . . . . . . . . . . . . . . . 14
5.1.4 sourceIPv4Mask . . . . . . . . . . . . . . . . . . . . 15
5.1.5 sourceIPv6Mask . . . . . . . . . . . . . . . . . . . . 15
5.1.6 sourceIPv4Prefix . . . . . . . . . . . . . . . . . . . 15
5.1.7 destinationIPv4Address . . . . . . . . . . . . . . . . 16
5.1.8 destinationIPv6Address . . . . . . . . . . . . . . . . 16
5.1.9 destinationIPv4Mask . . . . . . . . . . . . . . . . . 16
5.1.10 destinationIPv6Mask . . . . . . . . . . . . . . . . 16
5.1.11 destinationIPv4Prefix . . . . . . . . . . . . . . . 17
5.1.12 classOfServiceIPv4 . . . . . . . . . . . . . . . . . 17
5.1.13 classOfServiceV6 . . . . . . . . . . . . . . . . . . 18
5.1.14 flowLabelV6 . . . . . . . . . . . . . . . . . . . . 18
5.1.15 identificationV4 . . . . . . . . . . . . . . . . . . 18
5.1.16 protocolIdentifier . . . . . . . . . . . . . . . . . 19
5.2 Trandport Header Fields . . . . . . . . . . . . . . . . . 19
Quittek, et al. Expires August 21, 2005 [Page 2]
Internet-Draft IPFIX Information Model February 2005
5.2.1 sourceTransportPort . . . . . . . . . . . . . . . . . 19
5.2.2 destinationtransportPort . . . . . . . . . . . . . . . 20
5.2.3 icmpTypeCode . . . . . . . . . . . . . . . . . . . . . 20
5.2.4 igmpType . . . . . . . . . . . . . . . . . . . . . . . 21
5.3 Sub-IP Header Fields . . . . . . . . . . . . . . . . . . . 21
5.3.1 sourceMacAddress . . . . . . . . . . . . . . . . . . . 21
5.3.2 mplsLabelStackEntry1 . . . . . . . . . . . . . . . . . 22
5.3.3 mplsLabelStackEntry2 . . . . . . . . . . . . . . . . . 22
5.3.4 mplsLabelStackEntry3 . . . . . . . . . . . . . . . . . 22
5.3.5 mplsLabelStackEntry4 . . . . . . . . . . . . . . . . . 23
5.3.6 mplsLabelStackEntry5 . . . . . . . . . . . . . . . . . 23
5.3.7 mplsLabelStackEntry6 . . . . . . . . . . . . . . . . . 23
5.3.8 mplsLabelStackEntry7 . . . . . . . . . . . . . . . . . 24
5.3.9 mplsLabelStackEntry8 . . . . . . . . . . . . . . . . . 24
5.3.10 mplsLabelStackEntry9 . . . . . . . . . . . . . . . . 24
5.3.11 mplsLabelStackEntry10 . . . . . . . . . . . . . . . 25
5.4 Derived Packet Properties . . . . . . . . . . . . . . . . 25
5.4.1 ipNextHopIPv4Address . . . . . . . . . . . . . . . . . 25
5.4.2 ipNextHopIPv6Address . . . . . . . . . . . . . . . . . 26
5.4.3 ingressInterface . . . . . . . . . . . . . . . . . . . 26
5.4.4 egressInterface . . . . . . . . . . . . . . . . . . . 26
5.4.5 ipNextHopAsNumber . . . . . . . . . . . . . . . . . . 27
5.4.6 bgpSourceAsNumber . . . . . . . . . . . . . . . . . . 27
5.4.7 bgpDestinationAsNumber . . . . . . . . . . . . . . . . 27
5.4.8 bgpNextHopAsNumber . . . . . . . . . . . . . . . . . . 28
5.4.9 bgpNextHopIPv4Address . . . . . . . . . . . . . . . . 28
5.4.10 bgpNextHopIPv6Address . . . . . . . . . . . . . . . 28
5.4.11 mplsTopLabelType . . . . . . . . . . . . . . . . . . 29
5.4.12 mplsTopLabelIPv4Address . . . . . . . . . . . . . . 29
5.4.13 mplsTopLabelIPv6Address . . . . . . . . . . . . . . 29
5.5 Properties of Metering/Exporting Process . . . . . . . . . 30
5.5.1 exporterIPv4Address . . . . . . . . . . . . . . . . . 30
5.5.2 exporterIPv6Address . . . . . . . . . . . . . . . . . 30
5.6 Min/Max Flow Properties . . . . . . . . . . . . . . . . . 30
5.6.1 minimumPacketLength . . . . . . . . . . . . . . . . . 31
5.6.2 maximumPacketLength . . . . . . . . . . . . . . . . . 31
5.6.3 minimumTTL . . . . . . . . . . . . . . . . . . . . . . 32
5.6.4 maximumTTL . . . . . . . . . . . . . . . . . . . . . . 32
5.6.5 ipv6OptionHeaders . . . . . . . . . . . . . . . . . . 32
5.6.6 tcpControlBits . . . . . . . . . . . . . . . . . . . . 33
5.6.7 flowCreationTime . . . . . . . . . . . . . . . . . . . 33
5.6.8 flowEndTime . . . . . . . . . . . . . . . . . . . . . 34
5.6.9 flowActiveTimeOut . . . . . . . . . . . . . . . . . . 34
5.6.10 flowInactiveTimeout . . . . . . . . . . . . . . . . 34
5.6.11 flowEndReason . . . . . . . . . . . . . . . . . . . 34
5.7 Per-Flow Counters . . . . . . . . . . . . . . . . . . . . 35
5.7.1 inOctetDeltaCount . . . . . . . . . . . . . . . . . . 36
5.7.2 outOctetDeltaCount . . . . . . . . . . . . . . . . . . 36
Quittek, et al. Expires August 21, 2005 [Page 3]
Internet-Draft IPFIX Information Model February 2005
5.7.3 octetDeltaCount . . . . . . . . . . . . . . . . . . . 36
5.7.4 inOctetTotalCount . . . . . . . . . . . . . . . . . . 37
5.7.5 inPacketDeltaCount . . . . . . . . . . . . . . . . . . 37
5.7.6 outPacketDeltaCount . . . . . . . . . . . . . . . . . 37
5.7.7 packetDeltaCount . . . . . . . . . . . . . . . . . . . 38
5.7.8 inPacketTotalCount . . . . . . . . . . . . . . . . . . 38
5.7.9 droppedOctetDeltaCount . . . . . . . . . . . . . . . . 38
5.7.10 droppedOctetTotalCount . . . . . . . . . . . . . . . 39
5.7.11 droppedPacketDeltaCount . . . . . . . . . . . . . . 39
5.7.12 droppedPacketTotalCount . . . . . . . . . . . . . . 40
5.7.13 outMulticastPacketCount . . . . . . . . . . . . . . 40
5.7.14 outMulticastOctetCount . . . . . . . . . . . . . . . 40
5.8 Process Counters . . . . . . . . . . . . . . . . . . . . . 41
5.8.1 observedFlowTotalCount . . . . . . . . . . . . . . . . 41
5.8.2 exportedOctetTotalCount . . . . . . . . . . . . . . . 41
5.8.3 exportedPacketTotalCount . . . . . . . . . . . . . . . 42
5.8.4 exportedFlowTotalCount . . . . . . . . . . . . . . . . 42
6. Extending the Information Model . . . . . . . . . . . . . . 43
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 44
8. Security Considerations . . . . . . . . . . . . . . . . . . 45
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 46
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 47
10.1 Normative Reference . . . . . . . . . . . . . . . . . . . 47
10.2 Informative Reference . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 48
A. Formal Specification of IPFIX Fields . . . . . . . . . . . . 50
B. Formal Specification of Abstract Data Types . . . . . . . . 74
Intellectual Property and Copyright Statements . . . . . . . 85
Quittek, et al. Expires August 21, 2005 [Page 4]
Internet-Draft IPFIX Information Model February 2005
1. Introduction
The IP Flow Information eXport (IPFIX) protocol serves for
transmitting information related to measured IP traffic over the
Internet. The protocol specification in [IPFIX-PROTO] defines how
information elements are transmitted. For information elements, it
specifies the encoding of a set of basic data types. However, the
list of fields that can be transmitted by the protocol, such as flow
attributes (source IP address, number of packets, etc.) and
information about the Metering and Exporting Process (packet
Observation Point, smapling rate, flow timeout interval, etc.), is
not specified in [IPFIX-PROTO].
This document complements the IPFIX protocol specification by
providing the IPFIX information model. IPFIX-specific terminology
used in this document including terms such as 'IP Traffic Flow',
'Observation Point', 'Metering Process', 'Exporting Process', and
'Collecting Process' is defined in [IPFIX-PROTO].
The main part of this document is Section 5 defining the (extensible)
list of fields to be transmitted by the IPFIX protcol. Section 2
defines a template for specifying IPFIX fields that is used in
Section 4. Section 3 defines the set of abstract data types that are
available for IPFIX fields. Section 5 discusses extensibility of the
IPFIX information model.
The main bodies of Sections 2, 3 and 4 were generated from XML
documents. The XML-based specification of template, abstract data
types and IPFIX fields can be used for automatically checking
syntactical correctness of the specification of IPFIX fields. It can
further be used for generating IPFIX protocol implementation code
that deals with processing IPFIX fields. Also code for applications
that further process traffic information transmitted via the IPFIX
protocol can be generated with the XML specification of IPFIX fields.
For that reason, the XML document that served as source for Section 4
and the XML schema that served as source for Sections 2 and 3 are
attached to this document in Appendices A and B.
Note that although partially generated from the attached XML
documents, the main body of this document is normative while the
appendices are informational.
Quittek, et al. Expires August 21, 2005 [Page 5]
Internet-Draft IPFIX Information Model February 2005
2. Properties of IPFIX Protocol Information Elements
Fields in messages of the IPFIX protocol carrying information about
traffic measurement are modeled as elements of the IPFIX information
model and specified in Section 4. For defining these information
elements, a template is used that is specified below.
All information elements specified for the IPFIX protocol either in
this document or by any future extension MUST have the following
properties defined:
name - A unique and meaningful name for the information element. The
preferred spelling for the name is to use mixed case if the name
is compound, with an initial lower case letter, e.g.,
"sourceIpAddress".
fieldId - A numeric identifier administered by IANA. This is used
for compact identification of an information item when encoding
templates in the protocol.
description - The semantics of this information element. Describes
how this field is derived from the flow or other information
available to the observer.
dataType - One of the types listed in section 3.1 of this document or
in an extension of the information model. The type space for
attributes is constrained to facilitate implementation. The
existing type space does however encompass most basic types used
in modern programming languages, as well as some derived types
(such as IPAddress) which are common to this domain and useful to
distinguish.
applicability - This propoerty of an information element indicates in
which kind of records the element can be used. Allowed values for
this property are 'data', 'option', and 'all'.
status - The status of the specification of this information element.
Allowed values are 'current', 'deprecated', and 'obsolete'.
All information elements specified for the IPFIX protocol either in
this document or by any future extension MAY have the following
properties defined:
enterpriseId - When extension is done outside of the scope of the
IANA IPFIX fieldId range, a enterpriseId MUST be provided. Valid
values for the enterpriseId are defined by IANA as SMI network
management private enterprise code. They are defined at
http://www.iana.org/assignments/enterprise-numbers.
dataTypeSemantics - 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 an extension of
the information model.
Quittek, et al. Expires August 21, 2005 [Page 6]
Internet-Draft IPFIX Information Model February 2005
units - If the field is a measure of some kind, the units identify
what the measure is.
enumeratedRange - Some items may have a specific set of numeric
identifiers associated with a set of discrete values this element
may take. The meaning of each discrete value and a human readable
name should be assigned.
range - Some elements may only be able to take on a restricted set of
values which can be expressed as a range (e.g. 0 through 511
inclusive). If this is the case, the valid inclusive range should
be specified.
reference - Identifies additional specifications which more precisely
define this item or provide additional context for its use.
Quittek, et al. Expires August 21, 2005 [Page 7]
Internet-Draft IPFIX Information Model February 2005
3. Type Space
This section describes the abstract data types that can be used for
the specification of IPFIX fields in Section 4. Section 3.1
describes the set of data types. For the integral data types octet,
unsigned16, unsigned32, and unsigned64 also data type semantics can
be specified, such as, for example, 'counter', 'identifier' or
'flags'. Data type semantics are specified in section 3.2.
3.1 Data Types
This section describes the set of valid data types of the IPFIX
information model. Note that further data types may be specified by
protocol extensions.
3.1.1 octet
The type "octet" represents a non-negative integer value in the range
of 0 to 255.
3.1.2 unsigned16
The type "unsigned16" represents a non-negative integer value in the
range of 0 to 65535.
3.1.3 unsigned32
The type "unsigned32" represents a non-negative integer value in the
range of 0 to 4294967295.
3.1.4 unsigned64
The type "unsigned64" represents a non-negative integer value in the
range of 0 to 18446744073709551615.
3.1.5 float32
The type "float32" corresponds to an IEEE single-precision 32-bit
floating point type.
3.1.6 boolean
The type "boolean" represents a binary value.
3.1.7 octetArray
The type "octetArray" represents a finite length string of octets.
Quittek, et al. Expires August 21, 2005 [Page 8]
Internet-Draft IPFIX Information Model February 2005
3.1.8 string
The type "string" represents a finite length string of valid
characters from the Unicode character encoding set. Unicode allows
for ASCII and many other international character sets to be used. It
is expected that strings will be encoded in UTF-8 format, which is
identical in encoding for USASCII characters, but also accomodates
other Unicode multibyte characters.
3.1.9 dateTimeSeconds
The type "dateTimeSeconds" represents a time value having a precision
of seconds and normalized to the GMT timezone. Such types are in
common use on many operating systems and have the advantage that they
can be stored in 32-bit integers.
3.1.10 dateTimeMicroSeconds
The type "dateTimeSeconds" represents a time value having a precision
of microseconds and normalized to the GMT timezone.
3.1.11 ipv4Address
The type "ipv4Addr" represents a value of an IPv4 address. These
addresses are typically stored as 32-bit integers.
3.1.12 ipv6Address
The type "ipv6Addr" represents a value of an IPv6 address.
3.2 Data Type Semantics
This section describes the set of valid data type semantics of the
IPFIX information model. Note that further data type semantics may
be specified by protocol extensions.
3.2.1 quantity
A quantity value represents a discrete measured value pertaining to
the record. This is distinguished from counters which represent an
ongoing measured value whose "odometer" reading is captured as part
of a given record. If no semantic qualifier is given, the integral
fields should behave as a quantity.
3.2.2 totalCounter
A measurement which is ongoing from the perspective of the Exporter.
Quittek, et al. Expires August 21, 2005 [Page 9]
Internet-Draft IPFIX Information Model February 2005
Basically the same semantics as counters in SNMP. Counters are
unsigned and wrap back to zero after reaching the limit of the type.
For example, an unsigned64 with counter semantics will continue to
increment until reaching the value of 2**64 - 1. At this point the
next increment will wrap its value to zero and continue counting from
zero. A running counter counts independent of the export of its
value.
3.2.3 deltaCounter
A measurement which is ongoing from the perspective of the Exporter.
Basically the same semantics as counters in SNMP. Counters are
unsigned and wrap back to zero after reaching the limit of the type.
For example, an unsigned64 with counter semantics will continue to
increment until reaching the value of 2**64 - 1. At this point the
next increment will wrap its value to zero and continue counting from
zero. A delta counter is reset to zero each time its value is
exported.
3.2.4 identifier
An integral value which serves as an identifier. Specifically
mathematical operations on two identifiers (aside from the equality
operation) are meaningless. For example, Autonomous System Id 1 *
Autonomous System Id 2 is meaningless.
3.2.5 flags
An integral value which actually represents a set of bit fields.
Logical operations are appropriate on such values, but not other
mathematical operations. Flags should always be of an unsigned type.
Quittek, et al. Expires August 21, 2005 [Page 10]
Internet-Draft IPFIX Information Model February 2005
4. Information Element Identifiers
The elements of this information model are identified by the
combination of a field identifier and an optional enterprise
identifier.
Standardized information elements defined in section 5 of this
document or in extensions of the IPFIX information model have their
values assigned by IANA. These values are in the range of 1 - 32767.
In this range, the value of the most significant bit in a
16-bit-representation always equals 0.
Enterprise-specific field IDs are in the range of 32768 - 65535. In
this range, the value of the most significant bit in a
16-bit-representation always equals 1. This choice of ranges allows
a Collecting Process to clearly and easily distinguished standardized
fields from enterprise-specific fields by just checking a single bit.
+---------------------------------+---------------------------------+
| Field ID Range | Description |
+---------------------------------+---------------------------------+
| 0 | reserved |
| | |
| 1 - 127 | standardized field IDs |
| | compatible to NetFlow version 9 |
| | |
| 128 - 32767 | standardized field IDs assigned |
| | by IANA |
| | |
| 32768 - 65535 | enterprise-defined field IDs |
+---------------------------------+---------------------------------+
Enterprise-specific IDs can be chosen by an enterprise arbitrarily
within the given range. The same ID may be assigned by different
enterprises for different purposes. In order to ensure that
Collecting Processes can always identify information elements
uniquely, enterprise-specific information elements are identified by
the combination of a field ID and an enterprise ID. Valid valuse for
enterprise IDs are also assigned by IANA. The IPFIX information
model uses the SMI network management private enterprise code defined
at http://www.iana.org/assignments/enterprise-numbers as the set of
valid numbers for enterprise IDs. Enterprise IDs used for
identifying IPFIX information elements MUST be registered as SMI
network management private enterprise code numbers at IANA.
The following list gives an overview of field IDs used as identifiers
of the information elements specified in section 5.
Quittek, et al. Expires August 21, 2005 [Page 11]
Internet-Draft IPFIX Information Model February 2005
+-------+-------------------------+-------+-------------------------+
| ID | Field Name | ID | Field Name |
+-------+-------------------------+-------+-------------------------+
| 1 | inOctetDeltaCount | 44 | sourceIPv4Prefix |
| 2 | inPacketDeltaCount | 45 | destinationIPv4Prefix |
| 3 | totalFlowCount | 46 | mplsTopLabelType |
| 4 | protocolIdentifier | 47 | mplsTopLabelIPv4Address |
| 5 | classOfServiceIPv4 | 48-51 | RESERVED |
| 6 | tcpControlBits | 52 | minimumTTL |
| 7 | sourceTransportPort | 53 | maximumTTL |
| 8 | sourceIPv4Address | 54 | identificationIPv4 |
| 9 | sourceIPv4Mask | 55 | RESERVED |
| 10 | ingressInterface | 56 | sourceMacAddress |
| 11 | destinationTransportPort| 57-59 | RESERVED |
| 12 | destinationIPv4Address | 60 | ipVersion |
| 13 | destinationIPv4Mask | 61 | RESERVED |
| 14 | egressInterface | 62 | ipNextHopIPv6Address |
| 15 | ipNextHopIPv4Address | 63 | bgpNextHopIPv6Address |
| 16 | bgpSourceAsNumber | 64 | ipv6OptionHeaders |
| 17 | bgpDestinationAsNumber | 65-69 | RESERVED |
| 18 | bgpNextHopIPv4Address | 70 | mplsLabelStackEntry1 |
| 19 | OutMulticastPacketCount | 71 | mplsLabelStackEntry2 |
| 20 | OutMulticastOctetCount | 72 | mplsLabelStackEntry3 |
| 21 | flowEndTime | 73 | mplsLabelStackEntry4 |
| 22 | flowCreationTime | 74 | mplsLabelStackEntry5 |
| 23 | outOctetDeltaCount | 75 | mplsLabelStackEntry6 |
| 24 | outPacketDeltaCount | 76 | mplsLabelStackEntry7 |
| 25 | minimumPacketLength | 77 | mplsLabelStackEntry8 |
| 26 | maximumPacketLength | 78 | mplsLabelStackEntry9 |
| 27 | sourceIPv6Address | 79 | mplsLabelStackEntry10 |
| 28 | destinationIPv6Address | 80-84 | RESERVED |
| 29 | sourceIPv6Mask | 85 | inOctetTotalCount |
| 30 | destinationIPv6Mask | 86 | inPacketTotalCount |
| 31 | flowLabelIPv6 |87-127 | RESERVED |
| 32 | icmpTypeCode | 128 | bgpNextHopAsNumber |
| 33 | igmpType | 129 | ipNextHopAsNumber |
| 34-35 | RESERVED | 130 | exporterIPv4Address |
| 36 | flowActiveTimeOut | 131 | exporterIPv6Address |
| 37 | flowInactiveTimeout | 132 | droppedOctetDeltaCount |
| 38-39 | RESERVED | 133 | droppedPacketDeltaCount |
| 40 | exportedOctetCount | 134 | droppedOctetTotalCount |
| 41 | exportedPacketCount | 135 | droppedPacketTotalCount |
| 42 | exportedFlowCount | 136 | flowEndReason |
| 43 | RESERVED | 137 | classOfServiceIPv6 |
| | | 138 | octetDeltaCount |
| | | 139 | packetDeltaCount |
| | | 140 | mplsTopLabelIPv6Address |
+-------+-------------------------+-------+-------------------------+
Quittek, et al. Expires August 21, 2005 [Page 12]
Internet-Draft IPFIX Information Model February 2005
5. Information Elements
This section describes the flow attributes of the IPFIX information
model. The elements are grouped into 8 groups according to their
semantics and their applicability.
5.1 IP Header Fields
Information elements in this section indicate values of header fields
or are derived from IP header field values in combination with
further information. These information elements can serve as part of
a flow key used for mapping packets to flows. But also they may
contain values related to header fields that are not constant for a
single flow. For example a flow using a certain source IPv4 address
as flow key has sourceAddressV4 as constant property but may have
destinationAddressV4 as a property that changes from packet to
packet.
For information elements that are not constant for a flow, the value
MUST be the value of the first packet observed for this flow. This
simple rule allows writing all information elements related to header
fields once when the first packet of the flow is observed. For
further observed packets of the same flow, only the counters need to
be increased.
The set of information elements related to IP header fields includes
the information elements listed in the table below.
+-------+-------------------------+-------+-------------------------+
| ID | Field Name | ID | Field Name |
+-------+-------------------------+-------+-------------------------+
| 60 | ipVersion | 5 | classOfServiceIPv4 |
| 8 | sourceIPv4Address | 137 | classOfServiceIPv6 |
| 27 | sourceIPv6Address | 31 | flowLabelIPv6 |
| 9 | sourceIPv4Mask | 54 | identificationIPv4 |
| 29 | sourceIPv6Mask | 4 | protocolIdentifier |
| 44 | sourceIPv4Prefix | | |
| 12 | destinationIPv4Address | | |
| 28 | destinationIPv6Address | | |
| 13 | destinationIPv4Mask | | |
| 30 | destinationIPv6Mask | | |
| 45 | destinationIPv4Prefix | | |
+-------+-------------------------+-------+-------------------------+
5.1.1 ipVersion
Quittek, et al. Expires August 21, 2005 [Page 13]
Internet-Draft IPFIX Information Model February 2005
Description: The IP version field given in the IP header.
Abstract Data Type: octet
FieldId: 60
Applicability: all
Status: current
Units: flows
Reference:
See RFC 791 for a definition of the version field in the IPv6
packet header. See RFC 2460 for a definition of the version field
in the IPv6 packet header. Additional information on defined
version numbers can be found at
http://www.iana.org/assignments/version-numbers.
5.1.2 sourceIPv4Address
Description:
IPv4 source address taken from the IP packet header of a packet of
this flow.
Abstract Data Type: ipv4Address
FieldId: 8
Applicability: all
Status: current
Reference: See RFC 791 for the definition of the IPv4 source address
field.
5.1.3 sourceIPv6Address
Description:
IPv6 source address taken from the IP packet header of a packet of
this flow.
Abstract Data Type: ipv6Address
FieldId: 27
Applicability: all
Status: current
Quittek, et al. Expires August 21, 2005 [Page 14]
Internet-Draft IPFIX Information Model February 2005
5.1.4 sourceIPv4Mask
Description:
The number of contiguous bits that are relevant in the
sourceAddressV4 field.
Abstract Data Type: octet
FieldId: 9
Applicability: option
Status: current
Units: bits
Range: The valid range is 0-32.
5.1.5 sourceIPv6Mask
Description:
The number of contiguous bits that are relevant in the
sourceAddressV6 field.
Abstract Data Type: octet
FieldId: 29
Applicability: option
Status: current
Units: bits
Range: The valid range is 0-128.
5.1.6 sourceIPv4Prefix
Description:
IPv4 source address prefix.
EDITOR'S NOTE: to be discussed on ipfix mailing list
Abstract Data Type: ipV4Address
FieldId: 44
Applicability: data
Status: current
Units: flows
Quittek, et al. Expires August 21, 2005 [Page 15]
Internet-Draft IPFIX Information Model February 2005
5.1.7 destinationIPv4Address
Description:
IPv4 destination address taken from the IP packet header of a
packet of this flow.
Abstract Data Type: ipv4Address
FieldId: 12
Applicability: all
Status: current
Reference: See RFC 791 for the definition of the IPv4 destination
address field.
5.1.8 destinationIPv6Address
Description:
IPv6 destination address taken from the IP packet header of a
packet of this flow.
Abstract Data Type: ipv6Address
FieldId: 28
Applicability: all
Status: current
5.1.9 destinationIPv4Mask
Description:
The number of contiguous bits that are relevant in the
destinationAddressV4 field.
Abstract Data Type: octet
FieldId: 13
Applicability: option
Status: current
Units: bits
Range: The valid range is 0-32.
5.1.10 destinationIPv6Mask
Quittek, et al. Expires August 21, 2005 [Page 16]
Internet-Draft IPFIX Information Model February 2005
Description:
The number of contiguous bits that are relevant in the
destinationAddressV6 field.
Abstract Data Type: octet
FieldId: 30
Applicability: option
Status: current
Units: bits
Range: The valid range is 0-128.
5.1.11 destinationIPv4Prefix
Description:
IPv4 destination address prefix.
EDITOR'S NOTE: to be discussed on ipfix mailing list
Abstract Data Type: ipV4Address
FieldId: 45
Applicability: data
Status: current
Units: flows
5.1.12 classOfServiceIPv4
Description:
The value of the IPv4 TOS field observed for packets of this flow.
Abstract Data Type: octet
Data Type Semantics: identifier
FieldId: 5
Applicability: all
Status: current
Reference: See RFC 791 for the definition of the IPv4 TOS field.
Quittek, et al. Expires August 21, 2005 [Page 17]
Internet-Draft IPFIX Information Model February 2005
5.1.13 classOfServiceV6
Description:
The value of the IPv6 traffic class field observed for packets of
this flow.
Abstract Data Type: octet
FieldId: 137
Applicability: data
Status: current
Reference: See RFC 2460 for the definition of the IPv6 traffic class
field.
5.1.14 flowLabelV6
Description:
The Flow Label of the IPv6 packet header observed in the first
packet of this flow.
Abstract Data Type: unsigned32
FieldId: 31
Applicability: all
Status: current
Reference: See RFC 2460 for a definition of the flow label field in
the IPv6 packet header.
5.1.15 identificationV4
Description:
The IPv4 packet identification field from the first packet of this
flow.
Abstract Data Type: unsigned16
Data Type Semantics: identifier
FieldId: 54
Applicability: data
Status: current
Reference: See RFC 791 for the definition of the IPv4 identification
field.
Quittek, et al. Expires August 21, 2005 [Page 18]
Internet-Draft IPFIX Information Model February 2005
5.1.16 protocolIdentifier
Description:
The protocol number observed for packets of this flow. The
protocol number identifies the IP packet payload. Protocol
numbers are defined in the IANA Protocol Numbers registry.
In Internet Protocol version 4 (IPv4) this is carried in the
"Protocol" field. In Internet Protocol version 6 (IPv6) this is
carried in the "Next Header" field in the last extension header of
the packet.
Abstract Data Type: octet
Data Type Semantics: identifier
FieldId: 4
Applicability: all
Status: current
Reference:
See RFC 791 for the specification of the IPv4 protocol field. See
RFC 2460 for the specification of the IPv6 protocol field. See
list of protocol numbers assigned by IANA at
http://www.iana.org/assignments/protocol-numbers.
5.2 Trandport Header Fields
The set of information elements related to transport header fields
includes the information elements listed in the table below.
+-------+-------------------------+-------+-------------------------+
| ID | Field Name | ID | Field Name |
+-------+-------------------------+-------+-------------------------+
| 7 | sourceTransportPort | 32 | icmpTypeCode |
| 11 | destinationTransportPort| 33 | igmpType |
+-------+-------------------------+-------+-------------------------+
5.2.1 sourceTransportPort
Description:
A source port identifier in the transport header. For transport
protocols UDP, TCP and SCTP this is the source port number given
in the respective header. This field MAY also be used for future
transport protocols that have 16 bit source port identifiers.
Abstract Data Type: unsigned16
Data Type Semantics: identifier
Quittek, et al. Expires August 21, 2005 [Page 19]
Internet-Draft IPFIX Information Model February 2005
FieldId: 7
Applicability: all
Status: current
Reference:
See RFC 768 for the definition of the UDP source port field. See
RFC 793 for the definition of the TCP source port field. See RFC
2960 for the definition of SCTP.
Additional information on defined UDP and TCP port numbers can be
found at http://www.iana.org/assignments/port-numbers.
5.2.2 destinationtransportPort
Description:
A destination port identifier in the transport header. For
transport protocols UDP, TCP and SCTP this is the destination port
number given in the respective header. This field MAY also be
used for future transport protocols that have 16 bit destination
port identifiers.
Abstract Data Type: unsigned16
Data Type Semantics: identifier
FieldId: 11
Applicability: all
Status: current
Reference:
See RFC 768 for the definition of the UDP source port field. See
RFC 793 for the definition of the TCP source port field. See RFC
2960 for the definition of SCTP.
Additional information on defined UDP and TCP port numbers can be
found at http://www.iana.org/assignments/port-numbers.
5.2.3 icmpTypeCode
Description:
Type and Code of the ICMP message. The combination of both values
is reported as (ICMP type * 256) + ICMP code.
Abstract Data Type: unsigned16
FieldId: 32
Applicability: all
Status: current
Quittek, et al. Expires August 21, 2005 [Page 20]
Internet-Draft IPFIX Information Model February 2005
Reference: See RFC 792 for a definition of the ICMP type and code
fields.
5.2.4 igmpType
Description: The type field of the IGMP message.
Abstract Data Type: octet
FieldId: 33
Applicability: all
Status: current
Reference: See RFC 2236 for a definition of the IGMP type field.
5.3 Sub-IP Header Fields
The set of information elements related to Sub-IP header fields
includes the information elements listed in the table below.
+-------+-------------------------+-------+-------------------------+
| ID | Field Name | ID | Field Name |
+-------+-------------------------+-------+-------------------------+
| 56 | sourceMacAddress | 75 | mplsLabelStackEntry6 |
| 70 | mplsLabelStackEntry1 | 76 | mplsLabelStackEntry7 |
| 71 | mplsLabelStackEntry2 | 77 | mplsLabelStackEntry8 |
| 72 | mplsLabelStackEntry3 | 78 | mplsLabelStackEntry9 |
| 73 | mplsLabelStackEntry4 | 79 | mplsLabelStackEntry10 |
| 74 | mplsLabelStackEntry5 | | |
+-------+-------------------------+-------+-------------------------+
5.3.1 sourceMacAddress
Description:
Packet identification field from the first IP packet of this flow.
Abstract Data Type: octetArray
FieldId: 56
Applicability: data
Status: current
Reference: See RFC 791 for the definition of the IPv4 identification
field.
Quittek, et al. Expires August 21, 2005 [Page 21]
Internet-Draft IPFIX Information Model February 2005
5.3.2 mplsLabelStackEntry1
Description:
The label, exp and s fields from the outermost MPLS label stack
entry e.g. the last label that was pushed last.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | Exp |S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label: Label Value, 20 bits
Exp: Experimental Use, 3 bits
S: Bottom of Stack, 1 bit
Abstract Data Type: unsigned32
FieldId: 70
Applicability: all
Status: current
Reference: See RFC 3032.
5.3.3 mplsLabelStackEntry2
Description:
The label, exp and s fields from the LSE that was pushed
immediately before the LSE that would be reported by
mplsLabelStackEntry1. See the definition of mplsLabelStackEntry1
for further details.
Abstract Data Type: unsigned32
FieldId: 71
Applicability: all
Status: current
Reference: See RFC 3032.
5.3.4 mplsLabelStackEntry3
Description:
The label, exp and s fields from the LSE that was pushed
immediately before the LSE that would be reported by
mplsLabelStackEntry2. See the definition of mplsLabelStackEntry1
for further details.
Abstract Data Type: unsigned32
Quittek, et al. Expires August 21, 2005 [Page 22]
Internet-Draft IPFIX Information Model February 2005
FieldId: 72
Applicability: all
Status: current
Reference: See RFC 3032.
5.3.5 mplsLabelStackEntry4
Description:
The label, exp and s fields from the LSE that was pushed
immediately before the LSE that would be reported by
mplsLabelStackEntry3. See the definition of mplsLabelStackEntry1
for further details.
Abstract Data Type: unsigned32
FieldId: 73
Applicability: all
Status: current
Reference: See RFC 3032.
5.3.6 mplsLabelStackEntry5
Description:
The label, exp and s fields from the LSE that was pushed
immediately before the LSE that would be reported by
mplsLabelStackEntry4. See the definition of mplsLabelStackEntry1
for further details.
Abstract Data Type: unsigned32
FieldId: 74
Applicability: all
Status: current
Reference: See RFC 3032.
5.3.7 mplsLabelStackEntry6
Description:
The label, exp and s fields from the LSE that was pushed
immediately before the LSE that would be reported by
mplsLabelStackEntry5. See the definition of mplsLabelStackEntry1
for further details.
Abstract Data Type: unsigned32
Quittek, et al. Expires August 21, 2005 [Page 23]
Internet-Draft IPFIX Information Model February 2005
FieldId: 75
Applicability: all
Status: current
Reference: See RFC 3032.
5.3.8 mplsLabelStackEntry7
Description:
The label, exp and s fields from the LSE that was pushed
immediately before the LSE that would be reported by
mplsLabelStackEntry6. See the definition of mplsLabelStackEntry1
for further details.
Abstract Data Type: unsigned32
FieldId: 76
Applicability: all
Status: current
Reference: See RFC 3032.
5.3.9 mplsLabelStackEntry8
Description:
The label, exp and s fields from the LSE that was pushed
immediately before the LSE that would be reported by
mplsLabelStackEntry7. See the definition of mplsLabelStackEntry1
for further details.
Abstract Data Type: unsigned32
FieldId: 77
Applicability: all
Status: current
Reference: See RFC 3032.
5.3.10 mplsLabelStackEntry9
Description:
The label, exp and s fields from the LSE that was pushed
immediately before the LSE that would be reported by
mplsLabelStackEntry8. See the definition of mplsLabelStackEntry1
for further details.
Abstract Data Type: unsigned32
Quittek, et al. Expires August 21, 2005 [Page 24]
Internet-Draft IPFIX Information Model February 2005
FieldId: 78
Applicability: all
Status: current
Reference: See RFC 3032.
5.3.11 mplsLabelStackEntry10
Description:
The label, exp and s fields from the LSE that was pushed
immediately before the LSE that would be reported by
mplsLabelStackEntry9. See the definition of mplsLabelStackEntry1
for further details.
Abstract Data Type: unsigned32
FieldId: 79
Applicability: all
Status: current
Reference: See RFC 3032.
5.4 Derived Packet Properties
The set of information elements derived from values of header fields
and further information includes the information elements listed in
the table below.
+-------+-------------------------+-------+-------------------------+
| ID | Field Name | ID | Field Name |
+-------+-------------------------+-------+-------------------------+
| 15 | ipNextHopIPv4Address | 128 | bgpNextHopAsNumber |
| 62 | ipNextHopIPv6Address | 18 | bgpNextHopIPv4Address |
| 10 | ingressInterface | 63 | bgpNextHopIPv6Address |
| 14 | egressInterface | 46 | mplsTopLabelType |
| 129 | ipNextHopAsNumber | 47 | mplsTopLabelIPv4Address |
| 16 | bgpSourceAsNumber | 140 | mplsTopLabelIPv6Address |
| 17 | bgpDestinationAsNumber | | |
+-------+-------------------------+-------+-------------------------+
5.4.1 ipNextHopIPv4Address
Description:
The IPv4 address of the next IP hop to which packets of this flow
are forwarded.
Abstract Data Type: ipv4Address
Quittek, et al. Expires August 21, 2005 [Page 25]
Internet-Draft IPFIX Information Model February 2005
FieldId: 15
Applicability: data
Status: current
5.4.2 ipNextHopIPv6Address
Description:
The IPv6 address of the next BGP hop to which packets of this flow
are forwarded.
Abstract Data Type: ipv6Address
FieldId: 62
Applicability: data
Status: current
5.4.3 ingressInterface
Description:
The index of the IP interface (ifIndex) where packets of this flow
are being received.
Abstract Data Type: unsigned32
Data Type Semantics: identifier
FieldId: 10
Applicability: all
Status: current
Reference: See RFC 2863 for the definition of the ifIndex object.
5.4.4 egressInterface
Description:
The index of the IP interface (ifIndex) where packets of this flow
are being sent.
Abstract Data Type: unsigned32
Data Type Semantics: identifier
FieldId: 14
Applicability: all
Quittek, et al. Expires August 21, 2005 [Page 26]
Internet-Draft IPFIX Information Model February 2005
Status: current
Reference: See RFC 2863 for the definition of the ifIndex object.
5.4.5 ipNextHopAsNumber
Description:
The autonomous system (AS) number of the next IP hop to which
packets of this flow are forwarded.
Abstract Data Type: unsigned16
Data Type Semantics: identifier
FieldId: 129
Applicability: all
Status: current
Reference: See RFC 1771 for a description of BGB-4 and see RFC 1930 a
definition of the AS number.
5.4.6 bgpSourceAsNumber
Description:
The autonomous system (AS) number of the source address in the IP
packet header in a packet of this flow.
Abstract Data Type: unsigned16
Data Type Semantics: identifier
FieldId: 16
Applicability: all
Status: current
Reference: See RFC 1771 for a description of BGB-4 and see RFC 1930 a
definition of the AS number.
5.4.7 bgpDestinationAsNumber
Description:
The autonomous system (AS) number of the destination address in
the IP packet header in a packet of this flow.
Abstract Data Type: unsigned16
Data Type Semantics: identifier
FieldId: 17
Quittek, et al. Expires August 21, 2005 [Page 27]
Internet-Draft IPFIX Information Model February 2005
Applicability: all
Status: current
Reference: See RFC 1771 for a description of BGB-4 and see RFC 1930 a
definition of the AS number.
5.4.8 bgpNextHopAsNumber
Description:
The autonomous system (AS) number of the next BGP hop to which
packets of this flow are forwarded.
Abstract Data Type: unsigned16
Data Type Semantics: identifier
FieldId: 128
Applicability: all
Status: current
Reference: See RFC 1771 for a description of BGB-4 and see RFC 1930 a
definition of the AS number.
5.4.9 bgpNextHopIPv4Address
Description:
The IPv4 address of the next BGP hop to which packets of this flow
are forwarded.
Abstract Data Type: ipv4Address
FieldId: 18
Applicability: all
Status: current
Reference: See RFC 1771 for a description of BGB-4 and see RFC 1930 a
definition of the AS number.
5.4.10 bgpNextHopIPv6Address
Description:
The IPv6 address of the next BGP hop to which packets of this flow
are forwarded.
Abstract Data Type: ipv6Address
Data Type Semantics: identifier
FieldId: 63
Quittek, et al. Expires August 21, 2005 [Page 28]
Internet-Draft IPFIX Information Model February 2005
Applicability: all
Status: current
Reference: See RFC 1771 for a description of BGB-4. See RFC 1930 a
definition of the AS number.
5.4.11 mplsTopLabelType
Description:
MPLS top label type:
This field identifies the control protocol that allocated the top
of stack label.
Abstract Data Type: octet
Data Type Semantics: identifier
FieldId: 46
Applicability: data
Status: current
5.4.12 mplsTopLabelIPv4Address
Description:
The IPv4 address of the system that the MPLS top label will cause
this packet to be forwarded to.
Abstract Data Type: ipV4Address
FieldId: 47
Applicability: data
Status: current
5.4.13 mplsTopLabelIPv6Address
Description:
The IPv4 address of the system that the MPLS top label will cause
this packet to be forwarded to.
Abstract Data Type: ipV6Address
FieldId: 140
Applicability: data
Status: current
Quittek, et al. Expires August 21, 2005 [Page 29]
Internet-Draft IPFIX Information Model February 2005
5.5 Properties of Metering/Exporting Process
Information elements in this section describe static properties of
the Metering Process and/or the Exporting Process. The set of these
information elements is listed in the table below
+-------+-------------------------+-------+-------------------------+
| ID | Field Name | ID | Field Name |
+-------+-------------------------+-------+-------------------------+
| 130 | exporterIPv4Address | 131 | exporterIPv6Address |
+-------+-------------------------+-------+-------------------------+
5.5.1 exporterIPv4Address
Description:
The IPv4 address used by the Exporting Process. This is used by
the Collector to identify the Exporter in cases where the identity
of the Exporter may have been obscured by the use of a proxy.
Abstract Data Type: ipv4Address
Data Type Semantics: identifier
FieldId: 130
Applicability: all
Status: current
5.5.2 exporterIPv6Address
Description:
The IPv6 address used by the Exporting Process. This is used by
the Collector to identify the Exporter in cases where the identity
of the Exporter may have been obscured by the use of a proxy.
Abstract Data Type: ipv6Address
Data Type Semantics: identifier
FieldId: 131
Applicability: all
Status: current
5.6 Min/Max Flow Properties
Information elements in this section are results of minimum or
Quittek, et al. Expires August 21, 2005 [Page 30]
Internet-Draft IPFIX Information Model February 2005
maximum operations over multiple or all packets of a flow. They
cannot serve as flow keys, but their value can be used as trigger for
selecting and/or exporting flows.
The set of information elements resulting from minimum or maximum
operations over all packets of a flow includes the information
elements listed in the table below.
+-------+-------------------------+-------+-------------------------+
| ID | Field Name | ID | Field Name |
+-------+-------------------------+-------+-------------------------+
| 25 | minimumPacketLength | 22 | flowCreationTime |
| 26 | maximumPacketLength | 21 | flowEndTime |
| 52 | minimumTTL | 36 | flowActiveTimeOut |
| 53 | maximumTTL | 37 | flowInactiveTimeOut |
| 64 | ipv6OptionHeaders | 136 | flowEndReason |
| 6 | tcpControlBits | | |
+-------+-------------------------+-------+-------------------------+
5.6.1 minimumPacketLength
Description:
Length of the smallest packet observed for this flow.
Abstract Data Type: unsigned16
FieldId: 25
Applicability: all
Status: current
Units: octets
5.6.2 maximumPacketLength
Description:
Length of the largest packet observed for this flow.
Abstract Data Type: unsigned16
FieldId: 26
Applicability: all
Status: current
Units: octets
Quittek, et al. Expires August 21, 2005 [Page 31]
Internet-Draft IPFIX Information Model February 2005
5.6.3 minimumTTL
Description:
Minimum TTL value observed for any packet in this flow.
Abstract Data Type: octet
FieldId: 52
Applicability: data
Status: current
5.6.4 maximumTTL
Description:
Maximum TTL value observed for any packet in this flow.
Abstract Data Type: octet
FieldId: 53
Applicability: data
Status: current
5.6.5 ipv6OptionHeaders
Description:
IPv6 options in the IP packet headers of this flow. This is
encoded as a bit field.
bit IPv6 Option Definition
0 Reserved
1 44 Fragmentation header - not first fragment
2 43 Routing header
3 44 Fragmentation header - first fragment
4 Unknown Layer 4 header (compressed,
encrypted, not supported)
5 Reserved
6 0 Hop-by-hop option header
7 60 Destination option header
8 108 Payload compression header
9 51 Authentication Header
10 50 Encrypted security payload
11 to 31 Reserved
Abstract Data Type: unsigned32
Data Type Semantics: flags
Quittek, et al. Expires August 21, 2005 [Page 32]
Internet-Draft IPFIX Information Model February 2005
FieldId: 64
Applicability: all
Status: current
Reference: To be done.
5.6.6 tcpControlBits
Description:
TCP control bits observed for packets of this flow. The value of
this field is the result of a logical OR operation over the flags
observed in all packets of the flow. This implies that a 0 value
for a bit indicates that the respective bit was not set in any of
the observed packets of this flow.
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| Reserved | URG | ACK | PSH | RST | SYN | FIN |
+-----+-----+-----+-----+-----+-----+-----+-----+
Reserved: Reserved for future use by TCP. Must be zero.
URG: Urgent Pointer field significant
ACK: Acknowledgment field significant
PSH: Push Function
RST: Reset the connection
SYN: Synchronize sequence numbers
FIN: No more data from sender
Abstract Data Type: octet
Data Type Semantics: flags
FieldId: 6
Applicability: all
Status: current
Reference: See RFC 793 for a definition of the TCP control bits in
the TCP header.
5.6.7 flowCreationTime
Description: The timestamp of the first packet of this flow.
Abstract Data Type: dateTimeSeconds
FieldId: 22
Applicability: data
Quittek, et al. Expires August 21, 2005 [Page 33]
Internet-Draft IPFIX Information Model February 2005
Status: current
5.6.8 flowEndTime
Description: The timestamp of the last packet of this flow.
Abstract Data Type: dateTimeSeconds
FieldId: 21
Applicability: data
Status: current
5.6.9 flowActiveTimeOut
Description:
The number of seconds after which an active flow is timed out
anyway, even if there is still a continuous flow of packets.
Abstract Data Type: unsigned16
FieldId: 36
Applicability: all
Status: current
Units: seconds
5.6.10 flowInactiveTimeout
Description:
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.
Abstract Data Type: unsigned16
FieldId: 37
Applicability: all
Status: current
Units: seconds
5.6.11 flowEndReason
Quittek, et al. Expires August 21, 2005 [Page 34]
Internet-Draft IPFIX Information Model February 2005
Description:
The reason for flow termination.
EDITORS' NOTE: This needs to be defined as an enumerated range.
Abstract Data Type: octet
FieldId: 136
Applicability: data
Status: current
5.7 Per-Flow Counters
Information elements in this section are counters all having integral
values. Their values may change for every report they are used in.
They cannot serve as part of a flow key used for mapping packets to
flows. However, potentially they can be used for selecting exported
flow, for example by only exporting flows with more than a thresholh
number of observed octets.
There are running counters and delta counters. Delta counters are
reset to zero for each time their values are exported. Running
counters continue counting independent of the Exporting Process.
There are per-flow counters and counters related to the Metering
Process and/or the Exporting Process. Per-flow counters are flow
properites that potentially change each time a packets belonging to
the flow is observed. Per-flow counters are flow properites that
potentially change each time a packet belonging to the flow is
observed. The set of per-flow counters includes the information
elements listed in the table below.
+-------+-------------------------+-------+-------------------------+
| ID | Field Name | ID | Field Name |
+-------+-------------------------+-------+-------------------------+
| 1 | inOctetDeltaCount | 132 | droppedOctetDeltaCount |
| 23 | outOctetDeltaCount | 133 | droppedOctetTotalCount |
| 138 | octetDeltaCount | 134 | droppedPacketDeltaCount |
| 85 | inOctetTotalCount | 135 | droppedPacketTotalCount |
| 2 | inPacketDeltaCount | 19 | outMulticastPacketCount |
| 24 | outPacketDeltaCount | 20 | outMulticastOctetCount |
| 139 | packetDeltaCount | | |
| 86 | inPacketTotalCount | | |
+-------+-------------------------+-------+-------------------------+
Quittek, et al. Expires August 21, 2005 [Page 35]
Internet-Draft IPFIX Information Model February 2005
5.7.1 inOctetDeltaCount
Description:
The number of octets in incoming packets observed for this flow at
the Observation Point since the previous report (if any). The
number of octets include IP header(s) and IP payload.
Abstract Data Type: unsigned64
Data Type Semantics: deltaCounter
FieldId: 1
Applicability: data
Status: current
Units: octets
5.7.2 outOctetDeltaCount
Description:
The number of octets in outgoing packets observed for this flow at
the Observation Point since the previous report (if any). The
number of octets include IP header(s) and IP payload.
Abstract Data Type: unsigned64
Data Type Semantics: deltaCounter
FieldId: 23
Applicability: data
Status: current
Units: octets
5.7.3 octetDeltaCount
Description:
The number of octets in all packets observed for this flow at the
Observation Point since the previous report (if any). The number
of octets include IP header(s) and IP payload.
Abstract Data Type: unsigned64
Data Type Semantics: deltaCounter
FieldId: 138
Quittek, et al. Expires August 21, 2005 [Page 36]
Internet-Draft IPFIX Information Model February 2005
Applicability: data
Status: current
Units: octets
5.7.4 inOctetTotalCount
Description:
The running counter for the number of octets in incoming packets
observed for this flow at the Observation Point since the Metering
Process initialization for this Observation Point. The number of
octets include IP header(s) and IP payload.
Abstract Data Type: unsigned64
Data Type Semantics: totalCounter
FieldId: 85
Applicability: all
Status: current
Units: octets
5.7.5 inPacketDeltaCount
Description:
The number of incoming packets observed for this flow at the
Observation Point since the previous report (if any).
Abstract Data Type: unsigned64
Data Type Semantics: deltaCounter
FieldId: 2
Applicability: data
Status: current
Units: packets
5.7.6 outPacketDeltaCount
Description:
The number of outgoing packets observed for this flow at the
Observation Point since the previous report (if any).
Abstract Data Type: unsigned64
Quittek, et al. Expires August 21, 2005 [Page 37]
Internet-Draft IPFIX Information Model February 2005
Data Type Semantics: deltaCounter
FieldId: 24
Applicability: data
Status: current
Units: packets
5.7.7 packetDeltaCount
Description:
The number of all packets observed for this flow at the
Observation Point since the previous report (if any).
Abstract Data Type: unsigned64
Data Type Semantics: deltaCounter
FieldId: 139
Applicability: data
Status: current
Units: packets
5.7.8 inPacketTotalCount
Description:
The running counter for the number of incoming packets observed
for this flow at the Observation Point since the Metering Process
initialization for this Observation Point.
Abstract Data Type: unsigned64
Data Type Semantics: totalCounter
FieldId: 86
Applicability: all
Status: current
Units: packets
5.7.9 droppedOctetDeltaCount
Quittek, et al. Expires August 21, 2005 [Page 38]
Internet-Draft IPFIX Information Model February 2005
Description:
The number of octets in packets of this flow dropped by packet
treatment.
Abstract Data Type: unsigned64
Data Type Semantics: deltaCounter
FieldId: 132
Applicability: data
Status: current
Units: octets
5.7.10 droppedOctetTotalCount
Description:
The number of octets in packets of this flow dropped by packet
treatment.
Abstract Data Type: unsigned64
Data Type Semantics: totalCounter
FieldId: 133
Applicability: data
Status: current
Units: octets
5.7.11 droppedPacketDeltaCount
Description:
The number of packets of this flow dropped by packet treatment.
Abstract Data Type: unsigned64
Data Type Semantics: deltaCounter
FieldId: 134
Applicability: data
Status: current
Units: packets
Quittek, et al. Expires August 21, 2005 [Page 39]
Internet-Draft IPFIX Information Model February 2005
5.7.12 droppedPacketTotalCount
Description:
The number of packets of this flow dropped by packet treatment.
Abstract Data Type: unsigned64
Data Type Semantics: totalCounter
FieldId: 135
Applicability: data
Status: current
Units: packets
5.7.13 outMulticastPacketCount
Description:
The number of outgoing multicast packets created for packets of
this flow by an adjacent multicast daemon. Note that typically
not all of the created packets can be observed at the Observation
Point of this flow.
Abstract Data Type: unsigned64
FieldId: 19
Applicability: data
Status: current
Units: packets
5.7.14 outMulticastOctetCount
Description:
The number of octets in outgoing multicast packets created for
packets of this flow by an adjacent multicast daemon. Note that
typically not all of the created packets can be observed at the
Observation Point of this flow.
Abstract Data Type: unsigned64
FieldId: 20
Applicability: data
Status: current
Quittek, et al. Expires August 21, 2005 [Page 40]
Internet-Draft IPFIX Information Model February 2005
Units: octets
5.8 Process Counters
The set of counters related to the Metering Process and/or the
Exporting Process exported includes the information elements listed
in the table below.
+-------+-------------------------+-------+-------------------------+
| ID | Field Name | ID | Field Name |
+-------+-------------------------+-------+-------------------------+
| 3 | observedFlowTotalCount | 41 | exportedPacketTotalCount|
| 40 | exportedOctetToalCount | 42 | exportedFlowTotalCount |
+-------+-------------------------+-------+-------------------------+
5.8.1 observedFlowTotalCount
Description:
The number of flows observed so far in the Observation Domain.
Abstract Data Type: unsigned64
Data Type Semantics: totalCounter
FieldId: 3
Applicability: data
Status: current
Units: flows
5.8.2 exportedOctetTotalCount
Description:
The number of all octets reported by the Exporting Process to this
Collecting Process.
Abstract Data Type: unsigned64
Data Type Semantics: totalCounter
FieldId: 40
Applicability: data
Status: current
Units: octets
Quittek, et al. Expires August 21, 2005 [Page 41]
Internet-Draft IPFIX Information Model February 2005
5.8.3 exportedPacketTotalCount
Description:
The number of all packets reported by the Exporting Process to
this Collecting Process.
Abstract Data Type: unsigned64
Data Type Semantics: totalCounter
FieldId: 41
Applicability: data
Status: current
Units: packets
5.8.4 exportedFlowTotalCount
Description:
The number of all flows records reported by the Exporting Process
to this Collecting Process.
Abstract Data Type: unsigned64
FieldId: 42
Applicability: data
Status: current
Units: flows
Quittek, et al. Expires August 21, 2005 [Page 42]
Internet-Draft IPFIX Information Model February 2005
6. Extending the Information Model
A key requirement for IPFIX is to allow for extending the set of
information items which are reported for flows. This section defines
the mechanism for extending this set.
The IPFIX protocol carries flow records defined by a template.
Multiple templates may be defined for a dialog between an Exporter
and a Collector. A given template identifies the information items
and their order. The means of identification of information items in
a template is via a field ID. Field Id's are unique identifiers
administered by IANA.
Extension is done by defining new Information elements, including the
set of necessary information and possibly additional optional
information for each element. Each new information item MUST be
assigned a unique fieldId as part of its definition. These unique
field ids are the connection between the record structure
communicated by the protocol using templates and a consuming
application.
Enterprise-specific extensions may be made by enterprises with an SMI
network management private enterprise code defined by IANA at
http://www.iana.org/assignments/enterprise-numbers.
Enterprise-specific field IDs do not need to be registered by IANA.
The definition of a enterprise-specific information element MUST
specify the enterprise ID as well as the enterprise-specified field
ID and other mandatory field properties. Before creating
enterprise-specific fields, the general applicability of such
information elements should be considered. For generally applicable
fields using IETF and IANA mechanisms for extending the information
model is recommended.
Quittek, et al. Expires August 21, 2005 [Page 43]
Internet-Draft IPFIX Information Model February 2005
7. IANA Considerations
IANA has to create a new registry for IPFIX field ID's.
Appendix B defines an XML schema which may be used to create
consistent machine readable extensions to the IPFIX information
model. This schema introduces a new namespace, which will be
assigned by IANA according to RFC 3688. Currently the name space for
this schema is identified as http://www.ietf.org/ipfix.
Quittek, et al. Expires August 21, 2005 [Page 44]
Internet-Draft IPFIX Information Model February 2005
8. Security Considerations
The IPFIX information model itself does not directly introduce
security issues. Rather it defines a set of attributes which may for
privacy or business issues be considered sensitive information.
The underlying protocol used to exchange the information described
here must therefore apply appropriate procedures to guarantee the
integrity and confidentiality of the exported information. Such
protocols are defined in separate documents, specifically the IPFIX
Protocol document [IPFIX-PROTO].
Quittek, et al. Expires August 21, 2005 [Page 45]
Internet-Draft IPFIX Information Model February 2005
9. Acknowledgements
The editors thank Benoit Claise for a lot of useful input on the
field definitions. Also many thanks to Thomas Dietz for developing
the XSLT scripts that generate large portions of the text part of
this document from the XML appendices.
Quittek, et al. Expires August 21, 2005 [Page 46]
Internet-Draft IPFIX Information Model February 2005
10. References
10.1 Normative Reference
[1] Claise, B., Fullmer, M., Calato, P. and R. Penno, "IPFIX
Protocol Specification", IETF draft work in progress, January
2004,
<http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-0
2.txt>.
10.2 Informative Reference
[2] Quittek, J., Zseby, T., Claise, B. and S. Zander, "Requirements
for IP Flow Information Export", IETF draft work in progress,
January 2004,
<http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reqs-15.t
xt>.
[3] Sadasivan, G. and N. Brownlee, "Architecture Model for IP Flow
Information Export", IETF draft work in progress, October 2003,
<http://www.ietf.org/internet-drafts/draft-ietf-ipfix-arch-02.t
xt>.
[4] Zseby, T., Penno, R., Claise, B. and N. Brownlee, "IPFIX
Applicability", IETF draft work in progress, October 2003,
<http://www.ietf.org/internet-drafts/draft-ietf-ipfix-as-01.txt
>.
[5] Claise, B., "Cisco Systems NetFlow Services Export Version 9",
RFC 3954, October 2004, <http://www.ietf.org/rfc/rfc3954.txt>.
[6] World Wide Web Consortium, "Extensible Markup Language (XML)
1.0", W3C XML, February 1998,
<http://www.w3.org/TR/1998/REC-xml-19980210>.
[7] World Wide Web Consortium, "XML Schema Part 1: Structures", W3C
XML, May 2001,
<http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/>.
[8] World Wide Web Consortium, "XML Schema Part 2: Datatypes", W3C
XML, May 2001,
<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes.h
tml>.
[9] Internet Protocol Detail Record Organization, "Network Data
Management - Usage (NDM-U) For IP-Based Services Version
3.1.1", October 2002,
<http://www.ipdr.org/documents/NDM-U_3.1.1.pdf>.
Quittek, et al. Expires August 21, 2005 [Page 47]
Internet-Draft IPFIX Information Model February 2005
[10] Brownlee, N. and A. Blount, "Accounting Attributes and Record
Formats", RFC 2924, Sept. 2000,
<http://www.ietf.org/rfc/rfc2924.txt>.
[11] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June
1999, <http://xml.resource.org/public/rfc/html/rfc2629.html>.
[12] Hollenbeck, S., Rose, M. and L. Masinter, "Guidelines for the
Use of Extensible Markup Language (XML) within IETF Protocols",
RFC 3470, January 2003, <http://www.ietf.org/rfc/rfc3470.txt>.
[13] Pras, A. and J. Schoenwaelder, "On the Difference between
Information Models and Data Models", RFC 3444, January 2003,
<http://www.ietf.org/rfc/rfc3444.txt>.
[14] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004,
<http://www.ietf.org/rfc/rfc3688.txt>.
Authors' Addresses
Juergen Quittek
NEC
Kurfuersten-Anlage 36
Heidelberg 69115
Germany
Phone: +49 6221 90511-15
EMail: quittek@netlab.nec.de
URI: http://www.netlab.nec.de/
Stewart Bryant
Cisco Systems Ltd
250, Longwater, Green Park
Reading RG2 6GB
United Kingdom
EMail: stbryant@cisco.com
Quittek, et al. Expires August 21, 2005 [Page 48]
Internet-Draft IPFIX Information Model February 2005
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. Expires August 21, 2005 [Page 49]
Internet-Draft IPFIX Information Model February 2005
Appendix A. Formal Specification of IPFIX Fields
This appendix contains a formal description of the IPFIX information
model XML document. Note that this appendix is of informational
nature, while the text in section 4 generated from this appendix is
normative.
Using a formal and machine readable syntax for the Information model
enables the creation of IPFIX aware tools which can automatically
adapt to extensions to the information model, by simply reading
updated information model specifications.
The wide availability of XML aware tools and libraries for client
devices is a primary consideration for this choice. In particular
libraries for parsing XML documents are readily available. Also
mechanisms such as the Extensible Stylesheet Language (XSL) allow for
transforming a source XML document into other documents. This draft
was authored in XML and transformed according to RFC2629.
It should be noted that the use of XML in Exporters, Collectors or
other tools is not mandatory for the deployment of IPFIX. In
particular Exporting Processes do not produce or consume XML as part
of their operation. It is expected that IPFIX Collectors MAY take
advantage of the machine readability of the Information Model vs.
hardcoding their behavior or inventing proprietary means for
accomodating extensions.
<?xml version="1.0" encoding="UTF-8"?>
<fieldDefinitions>
<field name="ipVersion" dataType="octet"
group="IpHeader"
fieldId="60" applicability="all" status="current">
<description>
The IP version field given in the IP header.
</description>
<units>flows</units>
<reference>
<paragraph>
See RFC 791 for a definition of the version field in the
IPv6 packet header.
See RFC 2460 for a definition of the version field in the
IPv6 packet header.
Additional information on defined version numbers
can be found at
http://www.iana.org/assignments/version-numbers.
</paragraph>
Quittek, et al. Expires August 21, 2005 [Page 50]
Internet-Draft IPFIX Information Model February 2005
</reference>
</field>
<field name="sourceIPv4Address" dataType="ipv4Address"
group="IpHeader"
fieldId="8" applicability="all" status="current">
<description>
<paragraph>
IPv4 source address taken from the IP packet header of a
packet of this flow.
</paragraph>
</description>
<reference>
See RFC 791 for the definition of the IPv4 source address
field.
</reference>
</field>
<field name="sourceIPv6Address" dataType="ipv6Address"
group="IpHeader"
fieldId="27" applicability="all" status="current">
<description>
<paragraph>
IPv6 source address taken from the IP packet header of a
packet of this flow.
</paragraph>
</description>
</field>
<field name="sourceIPv4Mask" dataType="octet"
group="IpHeader"
fieldId="9" applicability="option" status="current">
<description>
<paragraph>
The number of contiguous bits that are relevant in the
sourceAddressV4 field.
</paragraph>
</description>
<units>bits</units>
<range>0-32</range>
</field>
<field name="sourceIPv6Mask" dataType="octet"
group="IpHeader"
fieldId="29" applicability="option" status="current">
<description>
<paragraph>
The number of contiguous bits that are relevant in the
Quittek, et al. Expires August 21, 2005 [Page 51]
Internet-Draft IPFIX Information Model February 2005
sourceAddressV6 field.
</paragraph>
</description>
<units>bits</units>
<range>0-128</range>
</field>
<field name="sourceIPv4Prefix" dataType="ipV4Address"
group="IpHeader"
fieldId="44" applicability="data" status="current">
<description>
<paragraph> IPv4 source address prefix. </paragraph>
<paragraph>
EDITOR'S NOTE: to be discussed on ipfix mailing list
</paragraph>
</description>
<units>flows</units>
</field>
<field name="destinationIPv4Address" dataType="ipv4Address"
group="IpHeader"
fieldId="12" applicability="all" status="current">
<description>
<paragraph>
IPv4 destination address taken from the IP packet header of a
packet of this flow.
</paragraph>
</description>
<reference>
See RFC 791 for the definition of the IPv4 destination address
field.
</reference>
</field>
<field name="destinationIPv6Address" dataType="ipv6Address"
group="IpHeader"
fieldId="28" applicability="all" status="current">
<description>
<paragraph>
IPv6 destination address taken from the IP packet header of a
packet of this flow.
</paragraph>
</description>
</field>
<field name="destinationIPv4Mask" dataType="octet"
group="IpHeader"
fieldId="13" applicability="option" status="current">
Quittek, et al. Expires August 21, 2005 [Page 52]
Internet-Draft IPFIX Information Model February 2005
<description>
<paragraph>
The number of contiguous bits that are relevant in the
destinationAddressV4 field.
</paragraph>
</description>
<units>bits</units>
<range>0-32</range>
</field>
<field name="destinationIPv6Mask" dataType="octet"
group="IpHeader"
fieldId="30" applicability="option" status="current">
<description>
<paragraph>
The number of contiguous bits that are relevant in the
destinationAddressV6 field.
</paragraph>
</description>
<units>bits</units>
<range>0-128</range>
</field>
<field name="destinationIPv4Prefix" dataType="ipV4Address"
group="IpHeader"
fieldId="45" applicability="data" status="current">
<description>
<paragraph> IPv4 destination address prefix. </paragraph>
<paragraph>
EDITOR'S NOTE: to be discussed on ipfix mailing list
</paragraph>
</description>
<units>flows</units>
</field>
<field name="classOfServiceIPv4" dataType="octet"
group="IpHeader"
dataTypeSemantics="identifier"
fieldId="5" applicability="all" status="current">
<description>
<paragraph>
The value of the IPv4 TOS field observed for packets of this flow.
</paragraph>
</description>
<reference>
See RFC 791 for the definition of the IPv4 TOS field.
</reference>
</field>
Quittek, et al. Expires August 21, 2005 [Page 53]
Internet-Draft IPFIX Information Model February 2005
<field name="classOfServiceV6" dataType="octet"
group="IpHeader"
fieldId="137" applicability="data" status="current">
<description>
<paragraph>
The value of the IPv6 traffic class field observed
for packets of this flow.
</paragraph>
</description>
<reference>
See RFC 2460 for the definition of the IPv6 traffic class field.
</reference>
</field>
<field name="flowLabelV6" dataType="unsigned32"
group="IpHeader"
fieldId="31" applicability="all" status="current">
<description>
<paragraph>
The Flow Label of the IPv6 packet header observed in the first packet
of this flow.
</paragraph>
</description>
<reference>
See RFC 2460 for a definition of the flow label field in the
IPv6 packet header.
</reference>
</field>
<field name="identificationV4" dataType="unsigned16"
group="IpHeader"
dataTypeSemantics="identifier"
fieldId="54" applicability="data" status="current">
<description>
<paragraph>
The IPv4 packet identification field from the first
packet of this flow.
</paragraph>
</description>
<reference>
See RFC 791 for the definition of the IPv4 identification field.
</reference>
</field>
<field name="protocolIdentifier" dataType="octet"
group="IpHeader"
dataTypeSemantics="identifier"
fieldId="4" applicability="all" status="current">
Quittek, et al. Expires August 21, 2005 [Page 54]
Internet-Draft IPFIX Information Model February 2005
<description>
<paragraph>
The protocol number observed for packets of this flow.
The protocol number identifies the IP packet payload.
Protocol numbers are defined in the IANA Protocol Numbers
registry.</paragraph>
<paragraph>
In Internet Protocol version 4 (IPv4) this is carried in
the "Protocol" field. In Internet Protocol version 6 (IPv6)
this is carried in the "Next Header" field in the last
extension header of the packet.</paragraph>
</description>
<reference>
<paragraph>
See RFC 791 for the specification of the IPv4 protocol field.
See RFC 2460 for the specification of the IPv6 protocol field.
See list of protocol numbers assigned by IANA at
http://www.iana.org/assignments/protocol-numbers.
</paragraph>
</reference>
</field>
<field name="sourceTransportPort" dataType="unsigned16"
group="transportHeader"
dataTypeSemantics="identifier"
fieldId="7" applicability="all" status="current">
<description>
<paragraph>
A source port identifier in the transport header. For transport
protocols UDP, TCP and SCTP this is the source port number
given in the respective header. This field MAY also be used
for future transport protocols that have 16 bit source port
identifiers.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 768 for the definition of the UDP source port field.
See RFC 793 for the definition of the TCP source port field.
See RFC 2960 for the definition of SCTP.</paragraph>
<paragraph>
Additional information on defined UDP and TCP port numbers
can be found at http://www.iana.org/assignments/port-numbers.
</paragraph>
</reference>
</field>
Quittek, et al. Expires August 21, 2005 [Page 55]
Internet-Draft IPFIX Information Model February 2005
<field name="destinationtransportPort" dataType="unsigned16"
group="transportHeader"
dataTypeSemantics="identifier"
fieldId="11" applicability="all" status="current">
<description>
<paragraph>
A destination port identifier in the transport header.
For transport protocols UDP, TCP and SCTP this is the
destination port number given in the respective header.
This field MAY also be used for future transport protocols
that have 16 bit destination port identifiers.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 768 for the definition of the UDP source port field.
See RFC 793 for the definition of the TCP source port field.
See RFC 2960 for the definition of SCTP. </paragraph>
<paragraph>
Additional information on defined UDP and TCP port numbers can
be found at http://www.iana.org/assignments/port-numbers.
</paragraph>
</reference>
</field>
<field name="icmpTypeCode" dataType="unsigned16"
group="transportHeader"
fieldId="32" applicability="all" status="current">
<description>
<paragraph>
Type and Code of the ICMP message. The combination of both values
is reported as (ICMP type * 256) + ICMP code.
</paragraph>
</description>
<reference>
See RFC 792 for a definition of the ICMP type and code fields.
</reference>
</field>
<field name="igmpType" dataType="octet"
group="transportHeader"
fieldId="33" applicability="all" status="current">
<description>
The type field of the IGMP message.
</description>
<reference>
See RFC 2236 for a definition of the IGMP type field.
Quittek, et al. Expires August 21, 2005 [Page 56]
Internet-Draft IPFIX Information Model February 2005
</reference>
</field>
<field name="sourceMacAddress" dataType="octetArray"
group="subIpHeader"
fieldId="56" applicability="data" status="current">
<description>
<paragraph>
Packet identification field from the first IP packet of this flow.
</paragraph>
</description>
<reference>
See RFC 791 for the definition of the IPv4 identification field.
</reference>
</field>
<field name="mplsLabelStackEntry1" dataType="unsigned32"
group="subIpHeader"
fieldId="70" applicability="all" status="current">
<description>
<paragraph>
The label, exp and s fields from the outermost MPLS label
stack entry e.g. the last label that was pushed last.
</paragraph>
<artwork>
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | Exp |S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label: Label Value, 20 bits
Exp: Experimental Use, 3 bits
S: Bottom of Stack, 1 bit
</artwork>
</description>
<reference>
See RFC 3032.
</reference>
</field>
<field name="mplsLabelStackEntry2" dataType="unsigned32"
group="subIpHeader"
fieldId="71" applicability="all" status="current">
<description>
<paragraph>
The label, exp and s fields from the LSE that was pushed
immediately before the LSE that would be reported by
Quittek, et al. Expires August 21, 2005 [Page 57]
Internet-Draft IPFIX Information Model February 2005
mplsLabelStackEntry1. See the definition of mplsLabelStackEntry1 for
further details.
</paragraph>
</description>
<reference>
See RFC 3032.
</reference>
</field>
<field name="mplsLabelStackEntry3" dataType="unsigned32"
group="subIpHeader"
fieldId="72" applicability="all" status="current">
<description>
<paragraph>
The label, exp and s fields from the LSE that was pushed
immediately before the LSE that would be reported by
mplsLabelStackEntry2. See the definition of mplsLabelStackEntry1 for
further details.
</paragraph>
</description>
<reference>
See RFC 3032.
</reference>
</field>
<field name="mplsLabelStackEntry4" dataType="unsigned32"
group="subIpHeader"
fieldId="73" applicability="all" status="current">
<description>
<paragraph>
The label, exp and s fields from the LSE that was pushed
immediately before the LSE that would be reported by
mplsLabelStackEntry3. See the definition of mplsLabelStackEntry1 for
further details.
</paragraph>
</description>
<reference>
See RFC 3032.
</reference>
</field>
<field name="mplsLabelStackEntry5" dataType="unsigned32"
group="subIpHeader"
fieldId="74" applicability="all" status="current">
<description>
<paragraph>
The label, exp and s fields from the LSE that was pushed
immediately before the LSE that would be reported by
Quittek, et al. Expires August 21, 2005 [Page 58]
Internet-Draft IPFIX Information Model February 2005
mplsLabelStackEntry4. See the definition of mplsLabelStackEntry1 for
further details.
</paragraph>
</description>
<reference>
See RFC 3032.
</reference>
</field>
<field name="mplsLabelStackEntry6" dataType="unsigned32"
group="subIpHeader"
fieldId="75" applicability="all" status="current">
<description>
<paragraph>
The label, exp and s fields from the LSE that was pushed
immediately before the LSE that would be reported by
mplsLabelStackEntry5. See the definition of mplsLabelStackEntry1 for
further details.
</paragraph>
</description>
<reference>
See RFC 3032.
</reference>
</field>
<field name="mplsLabelStackEntry7" dataType="unsigned32"
group="subIpHeader"
fieldId="76" applicability="all" status="current">
<description>
<paragraph>
The label, exp and s fields from the LSE that was pushed
immediately before the LSE that would be reported by
mplsLabelStackEntry6. See the definition of mplsLabelStackEntry1 for
further details.
</paragraph>
</description>
<reference>
See RFC 3032.
</reference>
</field>
<field name="mplsLabelStackEntry8" dataType="unsigned32"
group="subIpHeader"
fieldId="77" applicability="all" status="current">
<description>
<paragraph>
The label, exp and s fields from the LSE that was pushed
immediately before the LSE that would be reported by
Quittek, et al. Expires August 21, 2005 [Page 59]
Internet-Draft IPFIX Information Model February 2005
mplsLabelStackEntry7. See the definition of mplsLabelStackEntry1 for
further details.
</paragraph>
</description>
<reference>
See RFC 3032.
</reference>
</field>
<field name="mplsLabelStackEntry9" dataType="unsigned32"
group="subIpHeader"
fieldId="78" applicability="all" status="current">
<description>
<paragraph>
The label, exp and s fields from the LSE that was pushed
immediately before the LSE that would be reported by
mplsLabelStackEntry8. See the definition of mplsLabelStackEntry1 for
further details.
</paragraph>
</description>
<reference>
See RFC 3032.
</reference>
</field>
<field name="mplsLabelStackEntry10" dataType="unsigned32"
group="subIpHeader"
fieldId="79" applicability="all" status="current">
<description>
<paragraph>
The label, exp and s fields from the LSE that was pushed
immediately before the LSE that would be reported by
mplsLabelStackEntry9. See the definition of mplsLabelStackEntry1 for
further details.
</paragraph>
</description>
<reference>
See RFC 3032.
</reference>
</field>
<field name="ipNextHopIPv4Address" dataType="ipv4Address"
group="derived"
fieldId="15" applicability="data" status="current">
<description>
<paragraph>
The IPv4 address of the next IP hop to which packets of
this flow are forwarded.
Quittek, et al. Expires August 21, 2005 [Page 60]
Internet-Draft IPFIX Information Model February 2005
</paragraph>
</description>
</field>
<field name="ipNextHopIPv6Address" dataType="ipv6Address"
group="derived"
fieldId="62" applicability="data" status="current">
<description>
<paragraph>
The IPv6 address of the next BGP hop to which packets of
this flow are forwarded.
</paragraph>
</description>
</field>
<field name="ingressInterface" dataType="unsigned32"
group="derived"
dataTypeSemantics="identifier"
fieldId="10" applicability="all" status="current">
<description>
<paragraph>
The index of the IP interface (ifIndex) where packets of
this flow are being received.
</paragraph>
</description>
<reference>
See RFC 2863 for the definition of the ifIndex object.
</reference>
</field>
<field name="egressInterface" dataType="unsigned32"
group="derived"
dataTypeSemantics="identifier"
fieldId="14" applicability="all" status="current">
<description>
<paragraph>
The index of the IP interface (ifIndex) where packets of this
flow are being sent.
</paragraph>
</description>
<reference>
See RFC 2863 for the definition of the ifIndex object.
</reference>
</field>
<field name="ipNextHopAsNumber" dataType="unsigned16"
group="derived"
dataTypeSemantics="identifier"
Quittek, et al. Expires August 21, 2005 [Page 61]
Internet-Draft IPFIX Information Model February 2005
fieldId="129" applicability="all" status="current">
<description>
<paragraph>
The autonomous system (AS) number of the next IP hop to
which packets of this flow are forwarded.
</paragraph>
</description>
<reference>
See RFC 1771 for a description of BGB-4 and
see RFC 1930 a definition of the AS number.
</reference>
</field>
<field name="bgpSourceAsNumber" dataType="unsigned16"
group="derived"
dataTypeSemantics="identifier"
fieldId="16" applicability="all" status="current">
<description>
<paragraph>
The autonomous system (AS) number of the source address in
the IP packet header in a packet of this flow.
</paragraph>
</description>
<reference>
See RFC 1771 for a description of BGB-4 and
see RFC 1930 a definition of the AS number.
</reference>
</field>
<field name="bgpDestinationAsNumber" dataType="unsigned16"
group="derived"
dataTypeSemantics="identifier"
fieldId="17" applicability="all" status="current">
<description>
<paragraph>
The autonomous system (AS) number of the destination address
in the IP packet header in a packet of this flow.
</paragraph>
</description>
<reference>
See RFC 1771 for a description of BGB-4 and
see RFC 1930 a definition of the AS number.
</reference>
</field>
<field name="bgpNextHopAsNumber" dataType="unsigned16"
group="derived"
dataTypeSemantics="identifier"
Quittek, et al. Expires August 21, 2005 [Page 62]
Internet-Draft IPFIX Information Model February 2005
fieldId="128" applicability="all" status="current">
<description>
<paragraph>
The autonomous system (AS) number of the next BGP hop to
which packets of this flow are forwarded.
</paragraph>
</description>
<reference>
See RFC 1771 for a description of BGB-4 and
see RFC 1930 a definition of the AS number.
</reference>
</field>
<field name="bgpNextHopIPv4Address" dataType="ipv4Address"
group="derived"
fieldId="18" applicability="all" status="current">
<description>
<paragraph>
The IPv4 address of the next BGP hop to which packets of
this flow are forwarded.
</paragraph>
</description>
<reference>
See RFC 1771 for a description of BGB-4 and
see RFC 1930 a definition of the AS number.
</reference>
</field>
<field name="bgpNextHopIPv6Address" dataType="ipv6Address"
group="derived"
dataTypeSemantics="identifier"
fieldId="63" applicability="all" status="current">
<description>
<paragraph>
The IPv6 address of the next BGP hop to which packets of
this flow are forwarded.
</paragraph>
</description>
<reference>
See RFC 1771 for a description of BGB-4.
See RFC 1930 a definition of the AS number.
</reference>
</field>
<field name="mplsTopLabelType" dataType="octet"
group="derived"
dataTypeSemantics="identifier"
fieldId="46" applicability="data" status="current">
Quittek, et al. Expires August 21, 2005 [Page 63]
Internet-Draft IPFIX Information Model February 2005
<description>
<paragraph>
MPLS top label type:
<list>
<item> 0x01 TE-MIDPT: Any TE tunnel mid-point or tail label</item>
<item> 0x02 Pseudowire: Any PWE3 or Cisco AToM based label</item>
<item> 0x03 VPN: Any label associated with VPN</item>
<item> 0x04 BGP: Any label associated with BGP or BGP routing</item>
<item> 0x05 LDP: Any label associated with dynamically assigned
labels using LDP</item>
</list>
This field identifies the control protocol that allocated the
top of stack label.
</paragraph>
</description>
</field>
<field name="mplsTopLabelIPv4Address" dataType="ipV4Address"
group="derived"
fieldId="47" applicability="data" status="current">
<description>
<paragraph>
The IPv4 address of the system that the MPLS top label will
cause this packet to be forwarded to.
</paragraph>
</description>
</field>
<field name="mplsTopLabelIPv6Address" dataType="ipV6Address"
group="derived"
fieldId="140" applicability="data" status="current">
<description>
<paragraph>
The IPv4 address of the system that the MPLS top label will
cause this packet to be forwarded to.
</paragraph>
</description>
</field>
<field name="exporterIPv4Address" dataType="ipv4Address"
dataTypeSemantics="identifier"
group="config"
fieldId="130" applicability="all" status="current">
<description>
<paragraph>
The IPv4 address used by the Exporting Process.
This is used by the Collector to identify the Exporter
in cases where the identity of the Exporter may have been
Quittek, et al. Expires August 21, 2005 [Page 64]
Internet-Draft IPFIX Information Model February 2005
obscured by the use of a proxy.
</paragraph>
</description>
</field>
<field name="exporterIPv6Address" dataType="ipv6Address"
dataTypeSemantics="identifier"
group="config"
fieldId="131" applicability="all" status="current">
<description>
<paragraph>
The IPv6 address used by the Exporting Process.
This is used by the Collector to identify the Exporter
in cases where the identity of the Exporter may have been
obscured by the use of a proxy.
</paragraph>
</description>
</field>
<field name="minimumPacketLength" dataType="unsigned16"
group="minMax"
fieldId="25" applicability="all" status="current">
<description>
<paragraph>
Length of the smallest packet observed for this flow.
</paragraph>
</description>
<units>octets</units>
</field>
<field name="maximumPacketLength" dataType="unsigned16"
group="minMax"
fieldId="26" applicability="all" status="current">
<description>
<paragraph>
Length of the largest packet observed for this flow.
</paragraph>
</description>
<units>octets</units>
</field>
<field name="minimumTTL" dataType="octet"
group="minMax"
fieldId="52" applicability="data" status="current">
<description>
<paragraph>
Minimum TTL value observed for any packet in this flow.
</paragraph>
Quittek, et al. Expires August 21, 2005 [Page 65]
Internet-Draft IPFIX Information Model February 2005
</description>
</field>
<field name="maximumTTL" dataType="octet"
group="minMax"
fieldId="53" applicability="data" status="current">
<description>
<paragraph>
Maximum TTL value observed for any packet in this flow.
</paragraph>
</description>
</field>
<field name="ipv6OptionHeaders" dataType="unsigned32"
dataTypeSemantics="flags"
group="minMax"
fieldId="64" applicability="all" status="current">
<description>
<paragraph>
IPv6 options in the IP packet headers of this flow.
This is encoded as a bit field.
</paragraph>
<artwork>
bit IPv6 Option Definition
0 Reserved
1 44 Fragmentation header - not first fragment
2 43 Routing header
3 44 Fragmentation header - first fragment
4 Unknown Layer 4 header (compressed,
encrypted, not supported)
5 Reserved
6 0 Hop-by-hop option header
7 60 Destination option header
8 108 Payload compression header
9 51 Authentication Header
10 50 Encrypted security payload
11 to 31 Reserved
</artwork>
</description>
<reference>
To be done.
</reference>
</field>
<field name="tcpControlBits" dataType="octet"
dataTypeSemantics="flags"
group="minMax"
Quittek, et al. Expires August 21, 2005 [Page 66]
Internet-Draft IPFIX Information Model February 2005
fieldId="6" applicability="all" status="current">
<description>
<paragraph>
TCP control bits observed for packets of this flow.
The value of this field is the result of a logical OR operation
over the flags observed in all packets of the flow.
This implies that a 0 value for a bit indicates that the
respective 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>See RFC 793 for a definition of the TCP control bits
in the TCP header.</reference>
</field>
<field name="flowCreationTime" dataType="dateTimeSeconds"
group="minMax"
fieldId="22" applicability="data" status="current">
<description>
The timestamp of the first packet of this flow.
</description>
</field>
<field name="flowEndTime" dataType="dateTimeSeconds"
group="minMax"
fieldId="21" applicability="data" status="current">
<description>
The timestamp of the last packet of this flow.
</description>
</field>
<field name="flowActiveTimeOut" dataType="unsigned16"
group="minMax"
fieldId="36" applicability="all" status="current">
Quittek, et al. Expires August 21, 2005 [Page 67]
Internet-Draft IPFIX Information Model February 2005
<description>
<paragraph>
The number of seconds after which an active flow is timed out
anyway, even if there is still a continuous flow of packets.
</paragraph>
</description>
<units>seconds</units>
</field>
<field name="flowInactiveTimeout" dataType="unsigned16"
group="minMax"
fieldId="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="octet"
group="minMax"
fieldId="136" applicability="data" status="current">
<description>
<paragraph>
The reason for flow termination.
<list>
<item>idle timeout</item>
<item>end of flow detected (e.g. TCP FIN)</item>
<item>forced end</item>
<item>cache full</item>
</list>
EDITORS' NOTE: This needs to be defined as an
enumerated range.
</paragraph>
</description>
</field>
<field name="inOctetDeltaCount" dataType="unsigned64"
dataTypeSemantics="deltaCounter"
group="flowCounter"
fieldId="1" applicability="data" status="current">
<description>
<paragraph>
The number of octets in incoming packets observed for this
flow at the Observation Point since the previous report (if any).
Quittek, et al. Expires August 21, 2005 [Page 68]
Internet-Draft IPFIX Information Model February 2005
The number of octets include IP header(s) and IP payload.
</paragraph>
</description>
<units>octets</units>
</field>
<field name="outOctetDeltaCount" dataType="unsigned64"
dataTypeSemantics="deltaCounter"
group="flowCounter"
fieldId="23" applicability="data" status="current">
<description>
<paragraph>
The number of octets in outgoing packets observed for this
flow at the Observation Point since the previous report (if any).
The number of octets include IP header(s) and IP payload.
</paragraph>
</description>
<units>octets</units>
</field>
<field name="octetDeltaCount" dataType="unsigned64"
dataTypeSemantics="deltaCounter"
group="flowCounter"
fieldId="138" applicability="data" status="current">
<description>
<paragraph>
The number of octets in all packets observed for this
flow at the Observation Point since the previous report (if any).
The number of octets include IP header(s) and IP payload.
</paragraph>
</description>
<units>octets</units>
</field>
<field name="inOctetTotalCount" dataType="unsigned64"
dataTypeSemantics="totalCounter"
group="flowCounter"
fieldId="85" applicability="all" status="current">
<description>
<paragraph>
The running counter for the number of octets in incoming packets
observed for this flow at the Observation Point since the Metering
Process initialization for this Observation Point. The
number of octets include IP header(s) and IP payload.
</paragraph>
</description>
<units>octets</units>
</field>
Quittek, et al. Expires August 21, 2005 [Page 69]
Internet-Draft IPFIX Information Model February 2005
<field name="inPacketDeltaCount" dataType="unsigned64"
dataTypeSemantics="deltaCounter"
group="flowCounter"
fieldId="2" applicability="data" status="current">
<description>
<paragraph>
The number of incoming packets observed for this flow at
the Observation Point since the previous report (if any).
</paragraph>
</description>
<units>packets</units>
</field>
<field name="outPacketDeltaCount" dataType="unsigned64"
dataTypeSemantics="deltaCounter"
group="flowCounter"
fieldId="24" applicability="data" status="current">
<description>
<paragraph>
The number of outgoing packets observed for this flow at
the Observation Point since the previous report (if any).
</paragraph>
</description>
<units>packets</units>
</field>
<field name="packetDeltaCount" dataType="unsigned64"
dataTypeSemantics="deltaCounter"
group="flowCounter"
fieldId="139" applicability="data" status="current">
<description>
<paragraph>
The number of all packets observed for this flow at
the Observation Point since the previous report (if any).
</paragraph>
</description>
<units>packets</units>
</field>
<field name="inPacketTotalCount" dataType="unsigned64"
dataTypeSemantics="totalCounter"
group="flowCounter"
fieldId="86" applicability="all" status="current">
<description>
<paragraph>
The running counter for the number of incoming packets observed for
this flow at the Observation Point since the Metering Process
initialization for this Observation Point.
Quittek, et al. Expires August 21, 2005 [Page 70]
Internet-Draft IPFIX Information Model February 2005
</paragraph>
</description>
<units>packets</units>
</field>
<field name="droppedOctetDeltaCount" dataType="unsigned64"
dataTypeSemantics="deltaCounter"
group="flowCounter"
fieldId="132" applicability="data" status="current">
<description>
<paragraph>
The number of octets in packets of this flow dropped by packet treatment.
</paragraph>
</description>
<units>octets</units>
</field>
<field name="droppedOctetTotalCount" dataType="unsigned64"
dataTypeSemantics="totalCounter"
group="flowCounter"
fieldId="133" applicability="data" status="current">
<description>
<paragraph>
The number of octets in packets of this flow dropped by packet treatment.
</paragraph>
</description>
<units>octets</units>
</field>
<field name="droppedPacketDeltaCount" dataType="unsigned64"
dataTypeSemantics="deltaCounter"
group="flowCounter"
fieldId="134" applicability="data" status="current">
<description>
<paragraph>
The number of packets of this flow dropped by packet treatment.
</paragraph>
</description>
<units>packets</units>
</field>
<field name="droppedPacketTotalCount" dataType="unsigned64"
dataTypeSemantics="totalCounter"
group="flowCounter"
fieldId="135" applicability="data" status="current">
<description>
<paragraph>
The number of packets of this flow dropped by packet treatment.
Quittek, et al. Expires August 21, 2005 [Page 71]
Internet-Draft IPFIX Information Model February 2005
</paragraph>
</description>
<units>packets</units>
</field>
<field name="outMulticastPacketCount" dataType="unsigned64"
group="flowCounter"
fieldId="19" applicability="data" status="current">
<description>
<paragraph>
The number of outgoing multicast packets created for packets
of this flow by an adjacent multicast daemon.
Note that typically not all of the created packets can be
observed at the Observation Point of this flow.
</paragraph>
</description>
<units>packets</units>
</field>
<field name="outMulticastOctetCount" dataType="unsigned64"
group="flowCounter"
fieldId="20" applicability="data" status="current">
<description>
<paragraph>
The number of octets in outgoing multicast packets created
for packets of this flow by an adjacent multicast daemon.
Note that typically not all of the created packets can be
observed at the Observation Point of this flow.
</paragraph>
</description>
<units>octets</units>
</field>
<field name="observedFlowTotalCount" dataType="unsigned64"
dataTypeSemantics="totalCounter"
group="processCounter"
fieldId="3" applicability="data" status="current">
<description>
<paragraph>
The number of flows observed so far in the Observation Domain.
</paragraph>
</description>
<units>flows</units>
</field>
<field name="exportedOctetTotalCount" dataType="unsigned64"
dataTypeSemantics="totalCounter"
group="processCounter"
Quittek, et al. Expires August 21, 2005 [Page 72]
Internet-Draft IPFIX Information Model February 2005
fieldId="40" applicability="data" status="current">
<description>
<paragraph>
The number of all octets reported by the Exporting Process
to this Collecting Process.
</paragraph>
</description>
<units>octets</units>
</field>
<field name="exportedPacketTotalCount" dataType="unsigned64"
dataTypeSemantics="totalCounter"
group="processCounter"
fieldId="41" applicability="data" status="current">
<description>
<paragraph>
The number of all packets reported by the Exporting Process
to this Collecting Process.
</paragraph>
</description>
<units>packets</units>
</field>
<field name="exportedFlowTotalCount" dataType="unsigned64"
group="processCounter"
fieldId="42" applicability="data" status="current">
<description>
<paragraph>
The number of all flows records reported by the Exporting
Process to this Collecting Process.
</paragraph>
</description>
<units>flows</units>
</field>
</fieldDefinitions>
Quittek, et al. Expires August 21, 2005 [Page 73]
Internet-Draft IPFIX Information Model February 2005
Appendix B. Formal Specification of Abstract Data Types
This appendix containfs a formal description of the abstract data
types to be used for IPFIX fields and a formal description of the
template used for defining IPFIX fields. Note that this appendix is
of informational nature, while the text in sections 2 and 3 generated
from this appendix is normative.
<?xml version="1.0" encoding="UTF-8"?>
<schema>
<!-- <schema elementFormDefault="qualified"
targetNamespace="http://www.ietf.org/ipfix"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:ipfix="http://www.ietf.org/ipfix"> -->
<simpleType name="dataType">
<restriction base="string">
<enumeration value="octet">
<annotation>
<documentation>The type "octet" represents a
non-negative integer value in the range of 0 to 255.
</documentation>
</annotation>
</enumeration>
<enumeration value="unsigned16">
<annotation>
<documentation>The type "unsigned16" represents a
non-negative integer value in the range of 0 to 65535.
</documentation>
</annotation>
</enumeration>
<enumeration value="unsigned32">
<annotation>
<documentation>The type "unsigned32" represents a
non-negative integer value in the range of 0 to
4294967295.
</documentation>
</annotation>
</enumeration>
<enumeration value="unsigned64">
<annotation>
<documentation>The type "unsigned64" represents a
non-negative integer value in the range of 0 to
18446744073709551615.
Quittek, et al. Expires August 21, 2005 [Page 74]
Internet-Draft IPFIX Information Model February 2005
</documentation>
</annotation>
</enumeration>
<enumeration value="float32">
<annotation>
<documentation>The type "float32" corresponds to an IEEE
single-precision 32-bit floating point type.
</documentation>
</annotation>
</enumeration>
<enumeration value="boolean">
<annotation>
<documentation>The type "boolean" represents a binary
value.
</documentation>
</annotation>
</enumeration>
<enumeration value="octetArray">
<annotation>
<documentation>The type "octetArray" represents a finite
length string of octets.
</documentation>
</annotation>
</enumeration>
<enumeration value="string">
<annotation>
<documentation>
The type "string" represents a finite length string
of valid characters from the Unicode character
encoding set. Unicode allows for ASCII and many
other international character sets to be used.
It is expected that strings will be encoded in UTF-8
format, which is identical in encoding for USASCII
characters, but also accomodates other Unicode
multibyte characters.
</documentation>
</annotation>
</enumeration>
<enumeration value="dateTimeSeconds">
<annotation>
<documentation>
The type "dateTimeSeconds" represents a time value
having a precision of seconds and normalized to the
Quittek, et al. Expires August 21, 2005 [Page 75]
Internet-Draft IPFIX Information Model February 2005
GMT timezone. Such types are in common use on many
operating systems and have the advantage that they
can be stored in 32-bit integers.
</documentation>
</annotation>
</enumeration>
<enumeration value="dateTimeMicroSeconds">
<annotation>
<documentation>The type "dateTimeSeconds" represents a
time value having a precision of microseconds and
normalized to the GMT timezone.
</documentation>
</annotation>
</enumeration>
<enumeration value="ipv4Address">
<annotation>
<documentation>The type "ipv4Addr" represents a value of
an IPv4 address. These addresses are typically stored
as 32-bit integers.
</documentation>
</annotation>
</enumeration>
<enumeration value="ipv6Address">
<annotation>
<documentation>The type "ipv6Addr" represents a value
of an IPv6 address.
</documentation>
</annotation>
</enumeration>
</restriction>
</simpleType>
<simpleType name="dataTypeSemantics">
<restriction base="string">
<enumeration value="quantity">
<annotation>
<documentation>
A quantity value represents a discrete
measured value pertaining to the record. This is
distinguished from counters which represent an ongoing
measured value whose "odometer" reading is captured as
part of a given record. If no semantic qualifier is
given, the integral fields should behave as a quantity.
</documentation>
</annotation>
Quittek, et al. Expires August 21, 2005 [Page 76]
Internet-Draft IPFIX Information Model February 2005
</enumeration>
<enumeration value="totalCounter">
<annotation>
<documentation>
A measurement which is ongoing from the perspective
of the Exporter. Basically the same semantics as
counters in SNMP. Counters are unsigned and wrap back
to zero after reaching the limit of the type. For example, an
unsigned64 with counter semantics will continue to
increment until reaching the value of 2**64 - 1.
At this point the next increment will wrap its value
to zero and continue counting from zero.
A running counter counts independent of the export
of its value.
</documentation>
</annotation>
</enumeration>
<enumeration value="deltaCounter">
<annotation>
<documentation>
A measurement which is ongoing from the perspective
of the Exporter. Basically the same semantics as
counters in SNMP. Counters are unsigned and wrap back
to zero after reaching the limit of the type. For example, an
unsigned64 with counter semantics will continue to
increment until reaching the value of 2**64 - 1.
At this point the next increment will wrap its value
to zero and continue counting from zero.
A delta counter is reset to zero each time its
value is exported.
</documentation>
</annotation>
</enumeration>
<enumeration value="identifier">
<annotation>
<documentation>
An integral value which serves as an identifier.
Specifically mathematical operations on two
identifiers (aside from the equality operation) are
meaningless. For example, Autonomous System Id 1 * Autonomous
System Id 2 is meaningless.
</documentation>
</annotation>
</enumeration>
Quittek, et al. Expires August 21, 2005 [Page 77]
Internet-Draft IPFIX Information Model February 2005
<enumeration value="flags">
<annotation>
<documentation>
An integral value which actually represents a set of
bit fields. Logical operations are appropriate on
such values, but not other mathematical operations.
Flags should always be of an unsigned type.
</documentation>
</annotation>
</enumeration>
</restriction>
</simpleType>
<simpleType name="applicability">
<restriction base="string">
<enumeration value="data">
<annotation>
<documentation>
Used for fields that are applicable to flow records
only.
</documentation>
</annotation>
</enumeration>
<enumeration value="option">
<annotation>
<documentation>
Used for fields that are applicable to option records
only.
</documentation>
</annotation>
</enumeration>
<enumeration value="all">
<annotation>
<documentation>
Used for fields that are applicable to flow records
as well as to option records.
</documentation>
</annotation>
</enumeration>
</restriction>
</simpleType>
<simpleType name="status">
<restriction base="string">
<enumeration value="current">
<annotation>
Quittek, et al. Expires August 21, 2005 [Page 78]
Internet-Draft IPFIX Information Model February 2005
<documentation>
Indicates that the field definition is that the
definition is current and valid.
</documentation>
</annotation>
</enumeration>
<enumeration value="deprecated">
<annotation>
<documentation>
Indicates that the field definition is obsolete, but
it permits new/continued implementation in order to
foster interoperability with older/existing
implementations.
</documentation>
</annotation>
</enumeration>
<enumeration value="obsolete">
<annotation>
<documentation>
Indicates that the field definition is obsolete and
should not be implemented and/or can be removed if
previously implemented.
</documentation>
</annotation>
</enumeration>
</restriction>
</simpleType>
<simpleType name="enumRange">
<restriction base="string"/>
</simpleType>
<simpleType name="range">
<restriction base="string"/>
</simpleType>
<complexType name="descriptionList">
<sequence>
<element maxOccurs="unbounded" minOccurs="1"
name="item" type="string">
<annotation>
<documentation>to be done ...</documentation>
</annotation>
</element>
</sequence>
</complexType>
Quittek, et al. Expires August 21, 2005 [Page 79]
Internet-Draft IPFIX Information Model February 2005
<complexType name="text" mixed="true">
<sequence>
<element maxOccurs="unbounded" minOccurs="0"
name="paragraph" type="string">
<annotation>
<documentation>to be done ...</documentation>
</annotation>
</element>
<element maxOccurs="unbounded" minOccurs="0"
name="list" type="ipfix:descriptionList">
<annotation>
<documentation>to be done ...</documentation>
</annotation>
</element>
</sequence>
</complexType>
<element name="fieldDefinitions">
<complexType>
<sequence>
<element maxOccurs="unbounded" minOccurs="1" name="field">
<complexType>
<sequence>
<element maxOccurs="1" minOccurs="1" name="description"
type="ipfix:text">
<annotation>
<documentation>
The semantics of this information element.
Describes how this field is derived from the
flow or other information available to the
observer.
</documentation>
</annotation>
</element>
<!--
<element maxOccurs="1" minOccurs="0" name="usage"
type="ipfix:text">
<annotation>
<documentation>to be done ...</documentation>
</annotation>
</element>
-->
<element maxOccurs="1" minOccurs="0" name="units"
type="string">
<annotation>
<documentation>
If the field is a measure of some kind, the
units identify what the measure is.
Quittek, et al. Expires August 21, 2005 [Page 80]
Internet-Draft IPFIX Information Model February 2005
</documentation>
</annotation>
</element>
<element maxOccurs="1" minOccurs="0" name="reference"
type="ipfix:text">
<annotation>
<documentation>
Identifies additional specifications which more
precisely define this item or provide additional
context for its use.
</documentation>
</annotation>
</element>
<element maxOccurs="1" minOccurs="0"
name="enumeratedRange" type="ipfix:enumRange">
<annotation>
<documentation>
Some items may have a specific set of numeric
identifiers associated with a set of discrete
values this element may take. The meaning of
each discrete value and a human readable name
should be assigned.
</documentation>
</annotation>
</element>
<element maxOccurs="1" minOccurs="0" name="range"
type="ipfix:range">
<annotation>
<documentation>
Some elements may only be able to take on a
restricted set of values which can be
expressed as a range (e.g. 0 through 511
inclusive). If this is the case, the valid
inclusive range should be specified.
</documentation>
</annotation>
</element>
</sequence>
<attribute name="name" type="string" use="required">
<annotation>
<documentation>
A unique and meaningful name for the information element.
The preferred spelling for the name is to use mixed
case if the name is compound, with an initial
Quittek, et al. Expires August 21, 2005 [Page 81]
Internet-Draft IPFIX Information Model February 2005
lower case letter, e.g., "sourceIpAddress".
</documentation>
</annotation>
</attribute>
<attribute name="dataType" type="ipfix:dataType"
use="required">
<annotation>
<documentation>
One of the types listed in section 3.1 of this document
or in an 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
IPAddress) which 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 an extension of the information model.
</documentation>
</annotation>
</attribute>
<attribute name="fieldId" type="nonNegativeInteger"
use="required">
<annotation>
<documentation>
A numeric identifier administered by IANA.
This is used for compact identification of an
information item when encoding templates in the
protocol.
</documentation>
</annotation>
</attribute>
<attribute name="enterpriseId" type="nonNegativeInteger"
use="optional">
<annotation>
Quittek, et al. Expires August 21, 2005 [Page 82]
Internet-Draft IPFIX Information Model February 2005
<documentation>
When extension is done outside of the scope of
the IANA IPFIX fieldId range, a enterpriseId MUST
be provided. Valid values for the enterpriseId are
defined by IANA as SMI network management private
enterprise code. They are defined at
http://www.iana.org/assignments/enterprise-numbers.
</documentation>
</annotation>
</attribute>
<attribute name="applicability"
type="ipfix:applicability" use="required">
<annotation>
<documentation>This propoerty of an information element
indicates in which kind of records the element can be used.
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="fieldIdUnique">
<selector xpath="field"/>
<field xpath="fieldId"/>
</unique>
Quittek, et al. Expires August 21, 2005 [Page 83]
Internet-Draft IPFIX Information Model February 2005
</element>
</schema>
Quittek, et al. Expires August 21, 2005 [Page 84]
Internet-Draft IPFIX Information Model February 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Quittek, et al. Expires August 21, 2005 [Page 85]
| PAFTECH AB 2003-2026 | 2026-04-23 03:58:15 |