One document matched: draft-ietf-ipfix-info-05.txt
Differences from draft-ietf-ipfix-info-04.txt
Network Working Group J. Meyer
Internet-Draft PayPal
Expires: April 25, 2005 J. Quittek
NEC
S. Bryant
Cisco Systems Ltd
October 25, 2004
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 April 25, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
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
Meyer, et al. Expires April 25, 2005 [Page 1]
Internet-Draft IPFIX Information Model October 2004
exporting process. Although developed for the IPFIX protcol, the
model is defined in an open way that easily allows using it in other
protocols, interfaces, and applications.
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 runningCounter . . . . . . . . . . . . . . . . . . . . 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 Header Fields . . . . . . . . . . . . . . . . . . . . . . 13
5.1.1 ipVersion . . . . . . . . . . . . . . . . . . . . . . 14
5.1.2 sourceIPv4Address . . . . . . . . . . . . . . . . . . 15
5.1.3 sourceIPv6Address . . . . . . . . . . . . . . . . . . 15
5.1.4 sourceIPv4Mask . . . . . . . . . . . . . . . . . . . . 15
5.1.5 sourceIPv6Mask . . . . . . . . . . . . . . . . . . . . 15
5.1.6 sourceIPv4Prefix . . . . . . . . . . . . . . . . . . . 16
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 . . . . . . . . . . . . . . . . . . 17
5.1.14 flowLabelV6 . . . . . . . . . . . . . . . . . . . . 17
5.1.15 identificationV4 . . . . . . . . . . . . . . . . . . 18
5.1.16 protocolIdentifier . . . . . . . . . . . . . . . . . 18
5.1.17 sourceTransportPort . . . . . . . . . . . . . . . . 18
Meyer, et al. Expires April 25, 2005 [Page 2]
Internet-Draft IPFIX Information Model October 2004
5.1.18 destinationtransportPort . . . . . . . . . . . . . . 19
5.1.19 icmpTypeCode . . . . . . . . . . . . . . . . . . . . 19
5.1.20 igmpType . . . . . . . . . . . . . . . . . . . . . . 19
5.1.21 sourceMacAddress . . . . . . . . . . . . . . . . . . 20
5.1.22 mplsLabelStackEntry1 . . . . . . . . . . . . . . . . 20
5.1.23 mplsLabelStackEntry2 . . . . . . . . . . . . . . . . 20
5.1.24 mplsLabelStackEntry3 . . . . . . . . . . . . . . . . 20
5.1.25 mplsLabelStackEntry4 . . . . . . . . . . . . . . . . 21
5.1.26 mplsLabelStackEntry5 . . . . . . . . . . . . . . . . 21
5.1.27 mplsLabelStackEntry6 . . . . . . . . . . . . . . . . 21
5.1.28 mplsLabelStackEntry7 . . . . . . . . . . . . . . . . 21
5.1.29 mplsLabelStackEntry8 . . . . . . . . . . . . . . . . 22
5.1.30 mplsLabelStackEntry9 . . . . . . . . . . . . . . . . 22
5.1.31 mplsLabelStackEntry10 . . . . . . . . . . . . . . . 22
5.1.32 ipNextHopIPv4Address . . . . . . . . . . . . . . . . 22
5.1.33 ipNextHopIPv6Address . . . . . . . . . . . . . . . . 23
5.1.34 ingressInterface . . . . . . . . . . . . . . . . . . 23
5.1.35 egressInterface . . . . . . . . . . . . . . . . . . 23
5.1.36 ipNextHopAsNumber . . . . . . . . . . . . . . . . . 23
5.1.37 bgpSourceAsNumber . . . . . . . . . . . . . . . . . 24
5.1.38 bgpDestinationAsNumber . . . . . . . . . . . . . . . 24
5.1.39 bgpNextHopAsNumber . . . . . . . . . . . . . . . . . 24
5.1.40 bgpNextHopIPv4Address . . . . . . . . . . . . . . . 24
5.1.41 bgpNextHopIPv6Address . . . . . . . . . . . . . . . 25
5.1.42 mplsTopLabelType . . . . . . . . . . . . . . . . . . 25
5.1.43 mplsTopLabelIPv4Address . . . . . . . . . . . . . . 25
5.1.44 mplsTopLabelIPv6Address . . . . . . . . . . . . . . 25
5.2 Properties of Metering/Exporting Process . . . . . . . . . 26
5.2.1 exporterIPv4Address . . . . . . . . . . . . . . . . . 26
5.2.2 exporterIPv4Address . . . . . . . . . . . . . . . . . 26
5.3 Min/Max Flow Properties . . . . . . . . . . . . . . . . . 26
5.3.1 minPacketLength . . . . . . . . . . . . . . . . . . . 27
5.3.2 maxPacketLength . . . . . . . . . . . . . . . . . . . 27
5.3.3 minimumTTL . . . . . . . . . . . . . . . . . . . . . . 27
5.3.4 maximumTTL . . . . . . . . . . . . . . . . . . . . . . 27
5.3.5 ipv6OptionHeaders . . . . . . . . . . . . . . . . . . 28
5.3.6 tcpControlBits . . . . . . . . . . . . . . . . . . . . 28
5.3.7 flowCreationTime . . . . . . . . . . . . . . . . . . . 29
5.3.8 flowEndTime . . . . . . . . . . . . . . . . . . . . . 29
5.3.9 flowActiveTimeOut . . . . . . . . . . . . . . . . . . 29
5.3.10 flowInactiveTimeout . . . . . . . . . . . . . . . . 29
5.3.11 flowEndReason . . . . . . . . . . . . . . . . . . . 29
5.4 Counters . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.4.1 inOctetDeltaCount . . . . . . . . . . . . . . . . . . 31
5.4.2 outOctetDeltaCount . . . . . . . . . . . . . . . . . . 31
5.4.3 octetDeltaCount . . . . . . . . . . . . . . . . . . . 31
5.4.4 octetTotalCount . . . . . . . . . . . . . . . . . . . 31
5.4.5 inPacketDeltaCount . . . . . . . . . . . . . . . . . . 32
Meyer, et al. Expires April 25, 2005 [Page 3]
Internet-Draft IPFIX Information Model October 2004
5.4.6 outPacketDeltaCount . . . . . . . . . . . . . . . . . 32
5.4.7 packetDeltaCount . . . . . . . . . . . . . . . . . . . 32
5.4.8 packetTotalCount . . . . . . . . . . . . . . . . . . . 33
5.4.9 droppedOctetDeltaCount . . . . . . . . . . . . . . . . 33
5.4.10 droppedOctetTotalCount . . . . . . . . . . . . . . . 33
5.4.11 droppedPacketDeltaCount . . . . . . . . . . . . . . 33
5.4.12 droppedPacketTotalCount . . . . . . . . . . . . . . 34
5.4.13 outMulticastPacketCount . . . . . . . . . . . . . . 34
5.4.14 outMulticastOctetCount . . . . . . . . . . . . . . . 34
5.4.15 observedFlowTotalCount . . . . . . . . . . . . . . . 34
5.4.16 exportedOctetTotalCount . . . . . . . . . . . . . . 35
5.4.17 exportedPacketTotalCount . . . . . . . . . . . . . . 35
5.4.18 exportedFlowTotalCount . . . . . . . . . . . . . . . 35
6. Extending the Information Model . . . . . . . . . . . . . . 36
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 37
8. Security Considerations . . . . . . . . . . . . . . . . . . 38
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 40
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
11.1 Normative Reference . . . . . . . . . . . . . . . . . . . 41
11.2 Informative Reference . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 42
A. Formal Specification of IPFIX Fields . . . . . . . . . . . . 44
B. Formal Specification of Abstract Data Types . . . . . . . . 66
Intellectual Property and Copyright Statements . . . . . . . 76
Meyer, et al. Expires April 25, 2005 [Page 4]
Internet-Draft IPFIX Information Model October 2004
1. Introduction
The IP Flow Information eXport (IPFIX) protocol serves for
transmitting information related to measured IP traffic over the
Internet. The protocol specification in [IPFIX-PROTO] defines how
information elements are transmitted. For information elements, it
specifies the encoding of a set of basic data types. However, the
list of fields that can be transmitted by the protocol, such as flow
attributes (source IP address, number of packets, etc.) and
information about the metering and exporting process (packet
observation point, smapling rate, flow timeout interval, etc.), is
not specified in [IPFIX-PROTO].
This document complements the IPFIX protocol specification by
providing the IPFIX information model. The main part of this
document is Section 5 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.
Meyer, et al. Expires April 25, 2005 [Page 5]
Internet-Draft IPFIX Information Model October 2004
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.
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.
applicability - to be done ...
status - to be done ...
All information elements specified for the IPFIX protocol either in
this document or by any future extension MAY have the following
properties defined:
vendorId - When extension is done outside of the scope of the IANA
IPFIX fieldId range, a vendorId MUST be provided. Valid values
for the vendorID are defined by IANA as SMI network management
private enterprise code. They are defined at
http://www.iana.org/assignments/enterprise-numbers.
usage - to be done ...
units - If the field is a measure of some kind, the units identify
what the measure is.
Meyer, et al. Expires April 25, 2005 [Page 6]
Internet-Draft IPFIX Information Model October 2004
enumeratedRange - Some items may have a specific set of numeric
identifiers associated with a set of discrete values this element
may take. The meaning of each discrete value and a human readable
name should be assigned.
range - Some elements may only be able to take on a restricted set of
values which can be expressed as a range (e.g. 0 through 511
inclusive). If this is the case, the valid inclusive range should
be specified.
reference - Identifies additional specifications which more precisely
define this item or provide additional context for its use.
Meyer, et al. Expires April 25, 2005 [Page 7]
Internet-Draft IPFIX Information Model October 2004
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.
Meyer, et al. Expires April 25, 2005 [Page 8]
Internet-Draft IPFIX Information Model October 2004
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 types 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 runningCounter
A measurement which is ongoing from the perspective of the exporter.
Meyer, et al. Expires April 25, 2005 [Page 9]
Internet-Draft IPFIX Information Model October 2004
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.
Meyer, et al. Expires April 25, 2005 [Page 10]
Internet-Draft IPFIX Information Model October 2004
4. Information Element Identifiers
The elements of this information model are identified by the
combination of a field identifier and an optional vendor 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.
Vendor-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 vendor-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 | vendor-defined field IDs |
+---------------------------------+---------------------------------+
Vendor-specific IDs can be chosen by a vendor arbitrarily within the
given range. The same ID may be assigned by different vendors for
different purposes. In order to ensure that collecting processes can
always identify information elements uniquely, vendor-specific
information elements are identified by the combination of a field ID
and a vendor ID. Valid valuse for vendor 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 vendor IDs. Vendor 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.
+-------+-------------------------+-------+-------------------------+
Meyer, et al. Expires April 25, 2005 [Page 11]
Internet-Draft IPFIX Information Model October 2004
| 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 | octetTotalCount |
| 30 | destinationIPv6Mask | 86 | packetTotalCount |
| 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 |
+-------+-------------------------+-------+-------------------------+
Meyer, et al. Expires April 25, 2005 [Page 12]
Internet-Draft IPFIX Information Model October 2004
5. Information Elements
This section describes the flow attributes of the IPFIX information
model. The elements are grouped into X groups according to their
semantics and their applicability.
5.1 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, just 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 | | |
+-------+-------------------------+-------+-------------------------+
The set of information elements related to transport header fields
includes the information elements listed in the table below.
Meyer, et al. Expires April 25, 2005 [Page 13]
Internet-Draft IPFIX Information Model October 2004
+-------+-------------------------+-------+-------------------------+
| ID | Field Name | ID | Field Name |
+-------+-------------------------+-------+-------------------------+
| 7 | sourceTransportPort | 32 | icmpTypeCode |
| 11 | destinationTransportPort| 33 | igmpType |
+-------+-------------------------+-------+-------------------------+
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 | | |
+-------+-------------------------+-------+-------------------------+
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 |
| 14 | egressInterface | 63 | bgpNextHopIPv6Address |
| 129 | ipNextHopAsNumber | 46 | mplsTopLabelType |
| 16 | bgpSourceAsNumber | 47 | mplsTopLabelIPv4Address |
| 17 | bgpDestinationAsNumber | 140 | mplsTopLabelIPv6Address |
+-------+-------------------------+-------+-------------------------+
5.1.1 ipVersion
Description: The IP version field given in the IP header.
Abstract Data Type: octet
FieldId: 60
Units: flows
Meyer, et al. Expires April 25, 2005 [Page 14]
Internet-Draft IPFIX Information Model October 2004
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
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
5.1.4 sourceIPv4Mask
Description:
The number of contiguous bits that are relevant in the
sourceAddressV4 field.
Abstract Data Type: octet
FieldId: 9
Units: bits
5.1.5 sourceIPv6Mask
Description:
The number of contiguous bits that are relevant in the
sourceAddressV6 field.
Abstract Data Type: octet
FieldId: 29
Units: bits
Meyer, et al. Expires April 25, 2005 [Page 15]
Internet-Draft IPFIX Information Model October 2004
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
Units: flows
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
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
5.1.9 destinationIPv4Mask
Description:
The number of contiguous bits that are relevant in the
destinationAddressV4 field.
Abstract Data Type: octet
FieldId: 13
Units: bits
5.1.10 destinationIPv6Mask
Description:
The number of contiguous bits that are relevant in the
destinationAddressV6 field.
Abstract Data Type: octet
Meyer, et al. Expires April 25, 2005 [Page 16]
Internet-Draft IPFIX Information Model October 2004
FieldId: 30
Units: bits
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
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
Reference: See RFC 791 for the definition of the IPv4 TOS field.
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
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 a packet of
this flow.
Abstract Data Type: unsigned32
FieldId: 31
Meyer, et al. Expires April 25, 2005 [Page 17]
Internet-Draft IPFIX Information Model October 2004
Reference: See RFC 2460 for a definition of the flow label field in
the IPv6 packet header.
5.1.15 identificationV4
Description:
Packet identification field from the first IP packet of this flow.
Abstract Data Type: octet
Data Type Semantics: identifier
FieldId: 54
Reference: See RFC 791 for the definition of the IPv4 identification
field.
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
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.1.17 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
FieldId: 7
Meyer, et al. Expires April 25, 2005 [Page 18]
Internet-Draft IPFIX Information Model October 2004
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.1.18 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
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.1.19 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
Reference: See RFC 792 for a definition of the ICMP type and code
fields.
5.1.20 igmpType
Description: The type field of the IGMP message.
Abstract Data Type: octet
FieldId: 33
Reference: See RFC 2236 for a definition of the IGMP type field.
Meyer, et al. Expires April 25, 2005 [Page 19]
Internet-Draft IPFIX Information Model October 2004
5.1.21 sourceMacAddress
Description:
Packet identification field from the first IP packet of this flow.
Abstract Data Type: octet
FieldId: 56
Reference: See RFC 791 for the definition of the IPv4 identification
field.
5.1.22 mplsLabelStackEntry1
Description:
The label, exp and s fields from the outermost MPLS label stack
entry e.g. the last label that was pushed last.
to be replaced by ASCII drawing
to be replaced by ASCII drawing
to be replaced by ASCII drawing
to be replaced by ASCII drawing
to be replaced by ASCII drawing
Abstract Data Type: unsigned32
FieldId: 70
Reference: See RFC 3032.
5.1.23 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
Reference: See RFC 3032.
5.1.24 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
FieldId: 72
Meyer, et al. Expires April 25, 2005 [Page 20]
Internet-Draft IPFIX Information Model October 2004
Reference: See RFC 3032.
5.1.25 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
Reference: See RFC 3032.
5.1.26 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
Reference: See RFC 3032.
5.1.27 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
FieldId: 75
Reference: See RFC 3032.
5.1.28 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
Meyer, et al. Expires April 25, 2005 [Page 21]
Internet-Draft IPFIX Information Model October 2004
Reference: See RFC 3032.
5.1.29 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
Reference: See RFC 3032.
5.1.30 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
FieldId: 78
Reference: See RFC 3032.
5.1.31 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
Reference: See RFC 3032.
5.1.32 ipNextHopIPv4Address
Description:
The IPv4 address of the next IP hop to which packets of this flow
are forwarded.
Abstract Data Type: ipv4Address
FieldId: 15
Meyer, et al. Expires April 25, 2005 [Page 22]
Internet-Draft IPFIX Information Model October 2004
5.1.33 ipNextHopIPv6Address
Description:
The IPv6 address of the next BGP hop to which packets of this flow
are forwarded.
Abstract Data Type: ipv6Address
FieldId: 62
5.1.34 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
Reference: See RFC 2863 for the definition of the ifIndex object.
5.1.35 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
Reference: See RFC 2863 for the definition of the ifIndex object.
5.1.36 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
Reference: See RFC 1771 for a description of BGB-4 and see RFC 1930 a
definition of the AS number.
Meyer, et al. Expires April 25, 2005 [Page 23]
Internet-Draft IPFIX Information Model October 2004
5.1.37 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
Reference: See RFC 1771 for a description of BGB-4 and see RFC 1930 a
definition of the AS number.
5.1.38 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
Reference: See RFC 1771 for a description of BGB-4 and see RFC 1930 a
definition of the AS number.
5.1.39 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
Reference: See RFC 1771 for a description of BGB-4 and see RFC 1930 a
definition of the AS number.
5.1.40 bgpNextHopIPv4Address
Description:
The IPv4 address of the next BGP hop to which packets of this flow
are forwarded.
Abstract Data Type: ipv4Address
FieldId: 18
Meyer, et al. Expires April 25, 2005 [Page 24]
Internet-Draft IPFIX Information Model October 2004
Reference: See RFC 1771 for a description of BGB-4 and see RFC 1930 a
definition of the AS number.
5.1.41 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
Reference: See RFC 1771 for a description of BGB-4. See RFC 1930 a
definition of the AS number.
5.1.42 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
5.1.43 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
5.1.44 mplsTopLabelIPv6Address
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: 140
Meyer, et al. Expires April 25, 2005 [Page 25]
Internet-Draft IPFIX Information Model October 2004
5.2 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.2.1 exporterIPv4Address
Description:
The IPv4 address of the 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
5.2.2 exporterIPv4Address
Description:
The IPv6 address of the 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
5.3 Min/Max Flow Properties
Information elements in this section are results of minimum or
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
Meyer, et al. Expires April 25, 2005 [Page 26]
Internet-Draft IPFIX Information Model October 2004
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.3.1 minPacketLength
Description:
Length of the smallest packet observed for this flow.
Abstract Data Type: unsigned16
FieldId: 25
Units: octets
5.3.2 maxPacketLength
Description:
Length of the largest packet observed for this flow.
Abstract Data Type: unsigned16
FieldId: 26
Units: octets
5.3.3 minimumTTL
Description:
Minimum TTL value observed for any packet in this flow.
Abstract Data Type: octet
FieldId: 52
5.3.4 maximumTTL
Description:
Maximum TTL value observed for any packet in this flow.
Abstract Data Type: octet
Meyer, et al. Expires April 25, 2005 [Page 27]
Internet-Draft IPFIX Information Model October 2004
FieldId: 53
5.3.5 ipv6OptionHeaders
Description:
IPv6 options in the IP packet headers of this flow. This is
encoded as a bit field.
to be replaced by ASCII drawing
to be replaced by ASCII drawing
to be replaced by ASCII drawing
to be replaced by ASCII drawing
to be replaced by ASCII drawing
to be replaced by ASCII drawing
to be replaced by ASCII drawing
to be replaced by ASCII drawing
to be replaced by ASCII drawing
to be replaced by ASCII drawing
to be replaced by ASCII drawing
Abstract Data Type: unsigned32
Data Type Semantics: flags
FieldId: 64
Reference: To be done.
5.3.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.
to be replaced by ASCII drawing
to be replaced by ASCII drawing
to be replaced by ASCII drawing
to be replaced by ASCII drawing
to be replaced by ASCII drawing
to be replaced by ASCII drawing
to be replaced by ASCII drawing
to be replaced by ASCII drawing
Abstract Data Type: octet
Data Type Semantics: flags
FieldId: 6
Meyer, et al. Expires April 25, 2005 [Page 28]
Internet-Draft IPFIX Information Model October 2004
Reference: See RFC 793 for a definition of the TCP control bits in
the TCP header.
5.3.7 flowCreationTime
Description: The timestamp of the first packet of this flow.
Abstract Data Type: dateTimeSeconds
FieldId: 22
5.3.8 flowEndTime
Description: The timestamp of the last packet of this flow.
Abstract Data Type: dateTimeSeconds
FieldId: 21
5.3.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
Units: seconds
5.3.10 flowInactiveTimeout
Description:
A flow is considered to be timed out if not packet belonging to
the flow has been observed for the number of seconds specified by
this field.
Abstract Data Type: unsigned16
FieldId: 37
Units: seconds
5.3.11 flowEndReason
Description:
The reason for flow termination.
EDITORS' NOTE: This needs to be defined as an enumerated range.
Abstract Data Type: octet
FieldId: 136
Meyer, et al. Expires April 25, 2005 [Page 29]
Internet-Draft IPFIX Information Model October 2004
5.4 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 | octetTotalCount | 135 | droppedPacketTotalCount |
| 2 | inPacketDeltaCount | 19 | outMulticastPacketCount |
| 24 | outPacketDeltaCount | 20 | outMulticastOctetCount |
| 139 | packetDeltaCount | | |
| 86 | packetTotalCount | | |
+-------+-------------------------+-------+-------------------------+
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 |
+-------+-------------------------+-------+-------------------------+
Meyer, et al. Expires April 25, 2005 [Page 30]
Internet-Draft IPFIX Information Model October 2004
5.4.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
Units: octets
5.4.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
Units: octets
5.4.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
Units: octets
5.4.4 octetTotalCount
Description:
Number of observed octets for a pre-defined permanent flow.
Meyer, et al. Expires April 25, 2005 [Page 31]
Internet-Draft IPFIX Information Model October 2004
EDITOR'S NOTE: clarification required.
Abstract Data Type: unsigned64
Data Type Semantics: runningCounter
FieldId: 85
Units: octets
5.4.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
Units: packets
5.4.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
Data Type Semantics: deltaCounter
FieldId: 24
Units: packets
5.4.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
Units: packets
Meyer, et al. Expires April 25, 2005 [Page 32]
Internet-Draft IPFIX Information Model October 2004
5.4.8 packetTotalCount
Description:
Number of observed packets for a pre-defined permanent flow.
EDITOR'S NOTE: clarification required.
Abstract Data Type: unsigned64
Data Type Semantics: runningCounter
FieldId: 86
Units: packets
5.4.9 droppedOctetDeltaCount
Description:
The number of octets in packets of this flow dropped by packet
treatment.
Abstract Data Type: unsigned64
Data Type Semantics: deltaCounter
FieldId: 132
Units: octets
5.4.10 droppedOctetTotalCount
Description:
The number of octets in packets of this flow dropped by packet
treatment.
Abstract Data Type: unsigned64
Data Type Semantics: runningCounter
FieldId: 133
Units: octets
5.4.11 droppedPacketDeltaCount
Description:
The number of packets of this flow dropped by packet treatment.
Abstract Data Type: unsigned64
Data Type Semantics: deltaCounter
FieldId: 134
Meyer, et al. Expires April 25, 2005 [Page 33]
Internet-Draft IPFIX Information Model October 2004
Units: packets
5.4.12 droppedPacketTotalCount
Description:
The number of packets of this flow dropped by packet treatment.
Abstract Data Type: unsigned64
Data Type Semantics: runningCounter
FieldId: 135
Units: packets
5.4.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
Units: packets
5.4.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
Units: octets
5.4.15 observedFlowTotalCount
Description:
The number of flows observed so far in the observation domain.
Abstract Data Type: unsigned64
Data Type Semantics: runningCounter
Meyer, et al. Expires April 25, 2005 [Page 34]
Internet-Draft IPFIX Information Model October 2004
FieldId: 3
Units: flows
5.4.16 exportedOctetTotalCount
Description:
The number of all octets reported by the exporting process to this
collecting process.
Abstract Data Type: unsigned64
Data Type Semantics: runningCounter
FieldId: 40
Units: octets
5.4.17 exportedPacketTotalCount
Description:
The number of all packets reported by the exporting process to
this collecting process.
Abstract Data Type: unsigned64
Data Type Semantics: runningCounter
FieldId: 41
Units: packets
5.4.18 exportedFlowTotalCount
Description:
The number of all flows records reported by the exporting process
to this collecting process.
Abstract Data Type: unsigned64
FieldId: 42
Units: flows
Meyer, et al. Expires April 25, 2005 [Page 35]
Internet-Draft IPFIX Information Model October 2004
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.
Vendor specific extensions may be made by vendors with an SMI network
management private enterprise code defined by IANA at
http://www.iana.org/assignments/enterprise-numbers. Vendor-specific
field IDs do not need to be registered by IANA. The definition of a
vendor-specific information element MUST specify the vendor ID as
well as the vendor-specified field ID and other mandatory field
properties. Before creating vendor-specific fields, the general
applicability of such information elements should be considered. For
generally applicable fields using IETF and IANA mechanisms for
extendind the information model is recommended.
Meyer, et al. Expires April 25, 2005 [Page 36]
Internet-Draft IPFIX Information Model October 2004
7. IANA Considerations
IANA has to create a new registry for IPFIX fields ID's.
Appendix B defines an XML schema which may be used to create
consistent machine readable extensions to the IPFIX information
model. This schema introduces a new namaspace, which will be
assigned by IANA according to RFC 3688. Currently the name space for
this schema is identified as http://www.ietf.org/ipfix.
Meyer, et al. Expires April 25, 2005 [Page 37]
Internet-Draft IPFIX Information Model October 2004
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 therefor apply appropriate procedures to guarantee the
integrity and confidentiality of the exported information. Such
protocols are defined in separate documents. Specifically the IPFIX
Protocol document.
Meyer, et al. Expires April 25, 2005 [Page 38]
Internet-Draft IPFIX Information Model October 2004
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.
Meyer, et al. Expires April 25, 2005 [Page 39]
Internet-Draft IPFIX Information Model October 2004
10. Open Issues
+-------------------------------------------------------------------+
| Open Issues |
+-------------------------------------------------------------------+
| replace field with IE |
| |
| Are MCOctetCounters delta or running? |
| |
| What about RTP-related IEs? |
| |
| Where to put ingressInterface? |
| |
| Different category for tcpControBits and ipv6OptionHeaders? |
| |
| identificationIPv4 also for IPv6? |
| |
| What is the difference between source/destinationIPv4Mask and |
| source/destinationIPv4Prefix? |
| |
| Add ASCII art to IE specification of tcpControlBits, |
| ipv6OptionHeaders, mplsLabelStackEntry1 |
+-------------------------------------------------------------------+
Meyer, et al. Expires April 25, 2005 [Page 40]
Internet-Draft IPFIX Information Model October 2004
11. References
11.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>.
11.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",
IETF draft work in progress, June 2003,
<http://www.ietf.org/internet-drafts/draft-claise-netflow-9-02.
txt>.
[6] World Wide Web Consortium, "Extensible Markup Language (XML)
1.0", W3C XML, February 1998,
<http://www.w3.org/TR/1998/REC-xml-19980210>.
[7] World Wide Web Consortium, "XML Schema Part 1: Structures", W3C
XML, May 2001,
<http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/>.
[8] World Wide Web Consortium, "XML Schema Part 2: Datatypes", W3C
XML, May 2001,
<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes.h
tml>.
[9] Internet Protocol Detail Record Organization, "Network Data
Management - Usage (NDM-U) For IP-Based Services Version
Meyer, et al. Expires April 25, 2005 [Page 41]
Internet-Draft IPFIX Information Model October 2004
3.1.1", October 2002,
<http://www.ipdr.org/documents/NDM-U_3.1.1.pdf>.
[10] Brownlee, N. and A. Blount, "Accounting Attributes and Record
Formats", RFC 2924, Sept. 2000,
<http://www.ietf.org/rfc/rfc2924.txt>.
[11] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June
1999, <http://xml.resource.org/public/rfc/html/rfc2629.html>.
[12] Hollenbeck, S., Rose, M. and L. Masinter, "Guidelines for the
Use of Extensible Markup Language (XML) within IETF Protocols",
RFC 3470, January 2003, <http://www.ietf.org/rfc/rfc3470.txt>.
[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
Jeff Meyer
PayPal
2211 N. First St.
San Jose, CA 95131-2021
US
Phone: +1 408 976-9149
EMail: jemeyer@paypal.com
URI: http://www.paypal.com
Juergen Quittek
NEC
Kurfuersten-Anlage 36
Heidelberg 69115
Germany
Phone: +49 6221 90511-15
EMail: quittek@netlab.nec.de
URI: http://www.netlab.nec.de/
Meyer, et al. Expires April 25, 2005 [Page 42]
Internet-Draft IPFIX Information Model October 2004
Stewart Bryant
Cisco Systems Ltd
250, Longwater, Green Park
Reading RG2 6GB
United Kingdom
EMail: stbryant@cisco.com
Meyer, et al. Expires April 25, 2005 [Page 43]
Internet-Draft IPFIX Information Model October 2004
Appendix A. Formal Specification of IPFIX Fields
This appendix contains a formal description of the IPFIX information
model XML document. Note that this appendix is of informational
nature, while the text in section 4 generated from this appendix is
normative.
Using a formal and machine readable syntax for the Information model
enables the creation of IPFIX aware tools which can automatically
adapt to extensions to the information model, by simply reading
updated information model specifications.
The wide availability of XML aware tools and libraries for client
devices is a primary consideration for this choice. In particular
libraries for parsing XML documents are readily available. Also
mechanisms such as the Extensible Stylesheet Language (XSL) allow for
transforming a source XML document into other documents. This draft
was authored in XML and transformed according to RFC2629.
It should be noted that the use of XML in exporters, collectors or
other tools is not mandatory for the deployment of IPFIX. In
particular exporting processes do not produce or consume XML as part
of their operation. It is expected that IPFIX collectors MAY take
advantage of the machine readability of the Information Model vs.
hardcoding their behavior or inventing proprietary means for
accomodating extensions.
<?xml version="1.0" encoding="UTF-8"?>
<fieldDefinitions>
<field name="ipVersion" dataType="octet"
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>
</reference>
Meyer, et al. Expires April 25, 2005 [Page 44]
Internet-Draft IPFIX Information Model October 2004
</field>
<field name="sourceIPv4Address" dataType="ipv4Address"
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"
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"
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"
fieldId="29" applicability="option" status="current">
<description>
<paragraph>
The number of contiguous bits that are relevant in the
sourceAddressV6 field.
</paragraph>
</description>
<units>bits</units>
<range>0-128</range>
Meyer, et al. Expires April 25, 2005 [Page 45]
Internet-Draft IPFIX Information Model October 2004
</field>
<field name="sourceIPv4Prefix" dataType="ipV4Address"
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"
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"
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"
fieldId="13" applicability="option" status="current">
<description>
<paragraph>
The number of contiguous bits that are relevant in the
destinationAddressV4 field.
</paragraph>
</description>
<units>bits</units>
<range>0-32</range>
</field>
Meyer, et al. Expires April 25, 2005 [Page 46]
Internet-Draft IPFIX Information Model October 2004
<field name="destinationIPv6Mask" dataType="octet"
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"
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"
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>
<field name="classOfServiceV6" dataType="octet"
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>
Meyer, et al. Expires April 25, 2005 [Page 47]
Internet-Draft IPFIX Information Model October 2004
<field name="flowLabelV6" dataType="unsigned32"
fieldId="31" applicability="all" status="current">
<description>
<paragraph>
The Flow Label of the IPv6 packet header observed in a 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="octet"
dataTypeSemantics="identifier"
fieldId="54" 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="protocolIdentifier" dataType="octet"
dataTypeSemantics="identifier"
fieldId="4" applicability="all" status="current">
<description>
<paragraph>
The protocol number observed for packets of this flow.
The protocol number identifies the IP packet payload.
Protocol numbers are defined in 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
Meyer, et al. Expires April 25, 2005 [Page 48]
Internet-Draft IPFIX Information Model October 2004
http://www.iana.org/assignments/protocol-numbers.
</paragraph>
</reference>
</field>
<field name="sourceTransportPort" dataType="unsigned16"
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>
<field name="destinationtransportPort" dataType="unsigned16"
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>
Meyer, et al. Expires April 25, 2005 [Page 49]
Internet-Draft IPFIX Information Model October 2004
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"
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"
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.
</reference>
</field>
<field name="sourceMacAddress" dataType="octet"
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"
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>
Meyer, et al. Expires April 25, 2005 [Page 50]
Internet-Draft IPFIX Information Model October 2004
<paragraph> to be replaced by ASCII drawing </paragraph>
<paragraph> to be replaced by ASCII drawing </paragraph>
<paragraph> to be replaced by ASCII drawing </paragraph>
<paragraph> to be replaced by ASCII drawing </paragraph>
<paragraph> to be replaced by ASCII drawing </paragraph>
</description>
<reference>
See RFC 3032.
</reference>
</field>
<field name="mplsLabelStackEntry2" dataType="unsigned32"
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
mplsLabelStackEntry1. See the definition of mplsLabelStackEntry1 for
further details.
</paragraph>
</description>
<reference>
See RFC 3032.
</reference>
</field>
<field name="mplsLabelStackEntry3" dataType="unsigned32"
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"
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
Meyer, et al. Expires April 25, 2005 [Page 51]
Internet-Draft IPFIX Information Model October 2004
further details.
</paragraph>
</description>
<reference>
See RFC 3032.
</reference>
</field>
<field name="mplsLabelStackEntry5" dataType="unsigned32"
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
mplsLabelStackEntry4. See the definition of mplsLabelStackEntry1 for
further details.
</paragraph>
</description>
<reference>
See RFC 3032.
</reference>
</field>
<field name="mplsLabelStackEntry6" dataType="unsigned32"
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"
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>
Meyer, et al. Expires April 25, 2005 [Page 52]
Internet-Draft IPFIX Information Model October 2004
<reference>
See RFC 3032.
</reference>
</field>
<field name="mplsLabelStackEntry8" dataType="unsigned32"
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
mplsLabelStackEntry7. See the definition of mplsLabelStackEntry1 for
further details.
</paragraph>
</description>
<reference>
See RFC 3032.
</reference>
</field>
<field name="mplsLabelStackEntry9" dataType="unsigned32"
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"
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>
Meyer, et al. Expires April 25, 2005 [Page 53]
Internet-Draft IPFIX Information Model October 2004
</field>
<field name="ipNextHopIPv4Address" dataType="ipv4Address"
fieldId="15" applicability="data" status="current">
<description>
<paragraph>
The IPv4 address of the next IP hop to which packets of
this flow are forwarded.
</paragraph>
</description>
</field>
<field name="ipNextHopIPv6Address" dataType="ipv6Address"
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"
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"
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>
Meyer, et al. Expires April 25, 2005 [Page 54]
Internet-Draft IPFIX Information Model October 2004
</field>
<field name="ipNextHopAsNumber" dataType="unsigned16"
dataTypeSemantics="identifier"
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"
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"
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"
Meyer, et al. Expires April 25, 2005 [Page 55]
Internet-Draft IPFIX Information Model October 2004
dataTypeSemantics="identifier"
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"
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"
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"
dataTypeSemantics="identifier"
fieldId="46" applicability="data" status="current">
<description>
<paragraph>
Meyer, et al. Expires April 25, 2005 [Page 56]
Internet-Draft IPFIX Information Model October 2004
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"
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="ipV4Address"
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"
fieldId="130" applicability="all" status="current">
<description>
<paragraph>
The IPv4 address of the 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>
Meyer, et al. Expires April 25, 2005 [Page 57]
Internet-Draft IPFIX Information Model October 2004
<field name="exporterIPv4Address" dataType="ipv6Address"
dataTypeSemantics="identifier"
fieldId="131" applicability="all" status="current">
<description>
<paragraph>
The IPv6 address of the 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="minPacketLength" dataType="unsigned16"
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="maxPacketLength" dataType="unsigned16"
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"
fieldId="52" applicability="data" status="current">
<description>
<paragraph>
Minimum TTL value observed for any packet in this flow.
</paragraph>
</description>
</field>
<field name="maximumTTL" dataType="octet"
fieldId="53" applicability="data" status="current">
<description>
<paragraph>
Maximum TTL value observed for any packet in this flow.
</paragraph>
Meyer, et al. Expires April 25, 2005 [Page 58]
Internet-Draft IPFIX Information Model October 2004
</description>
</field>
<field name="ipv6OptionHeaders" dataType="unsigned32"
dataTypeSemantics="flags"
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>
<paragraph> to be replaced by ASCII drawing </paragraph>
<paragraph> to be replaced by ASCII drawing </paragraph>
<paragraph> to be replaced by ASCII drawing </paragraph>
<paragraph> to be replaced by ASCII drawing </paragraph>
<paragraph> to be replaced by ASCII drawing </paragraph>
<paragraph> to be replaced by ASCII drawing </paragraph>
<paragraph> to be replaced by ASCII drawing </paragraph>
<paragraph> to be replaced by ASCII drawing </paragraph>
<paragraph> to be replaced by ASCII drawing </paragraph>
<paragraph> to be replaced by ASCII drawing </paragraph>
<paragraph> to be replaced by ASCII drawing </paragraph>
</description>
<reference>
To be done.
</reference>
</field>
<field name="tcpControlBits" dataType="octet"
dataTypeSemantics="flags"
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>
<paragraph>to be replaced by ASCII drawing</paragraph>
<paragraph>to be replaced by ASCII drawing</paragraph>
<paragraph>to be replaced by ASCII drawing</paragraph>
<paragraph>to be replaced by ASCII drawing</paragraph>
<paragraph>to be replaced by ASCII drawing</paragraph>
<paragraph>to be replaced by ASCII drawing</paragraph>
<paragraph>to be replaced by ASCII drawing</paragraph>
<paragraph>to be replaced by ASCII drawing</paragraph>
Meyer, et al. Expires April 25, 2005 [Page 59]
Internet-Draft IPFIX Information Model October 2004
</description>
<reference>See RFC 793 for a definition of the TCP control bits
in the TCP header.</reference>
</field>
<field name="flowCreationTime" dataType="dateTimeSeconds"
fieldId="22" applicability="data" status="current">
<description>
The timestamp of the first packet of this flow.
</description>
</field>
<field name="flowEndTime" dataType="dateTimeSeconds"
fieldId="21" applicability="data" status="current">
<description>
The timestamp of the last packet of this flow.
</description>
</field>
<field name="flowActiveTimeOut" dataType="unsigned16"
fieldId="36" applicability="all" status="current">
<description>
<paragraph>
The number of seconds after which an active flow is timed out
anyway, even if there is still a continuous flow of packets.
</paragraph>
</description>
<units>seconds</units>
</field>
<field name="flowInactiveTimeout" dataType="unsigned16"
fieldId="37" applicability="all" status="current">
<description>
<paragraph>
A flow is considered to be timed out if not packet belonging
to the flow has been observed for the number of seconds
specified by this field.
</paragraph>
</description>
<units>seconds</units>
</field>
<field name="flowEndReason" dataType="octet"
fieldId="136" applicability="data" status="current">
<description>
<paragraph>
The reason for flow termination.
<list>
Meyer, et al. Expires April 25, 2005 [Page 60]
Internet-Draft IPFIX Information Model October 2004
<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"
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).
The number of octets include IP header(s) and IP payload.
</paragraph>
</description>
<units>octets</units>
</field>
<field name="outOctetDeltaCount" dataType="unsigned64"
dataTypeSemantics="deltaCounter"
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"
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>
Meyer, et al. Expires April 25, 2005 [Page 61]
Internet-Draft IPFIX Information Model October 2004
</field>
<field name="octetTotalCount" dataType="unsigned64"
dataTypeSemantics="runningCounter"
fieldId="85" applicability="all" status="current">
<description>
<paragraph>
Number of observed octets for a pre-defined permanent flow.
</paragraph>
<paragraph>
EDITOR'S NOTE: clarification required.
</paragraph>
</description>
<units>octets</units>
</field>
<field name="inPacketDeltaCount" dataType="unsigned64"
dataTypeSemantics="deltaCounter"
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"
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"
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>
Meyer, et al. Expires April 25, 2005 [Page 62]
Internet-Draft IPFIX Information Model October 2004
</description>
<units>packets</units>
</field>
<field name="packetTotalCount" dataType="unsigned64"
dataTypeSemantics="runningCounter"
fieldId="86" applicability="all" status="current">
<description>
<paragraph>
Number of observed packets for a pre-defined permanent flow.
</paragraph>
<paragraph>
EDITOR'S NOTE: clarification required.
</paragraph>
</description>
<units>packets</units>
</field>
<field name="droppedOctetDeltaCount" dataType="unsigned64"
dataTypeSemantics="deltaCounter"
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="runningCounter"
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"
fieldId="134" applicability="data" status="current">
<description>
<paragraph>
The number of packets of this flow dropped by packet treatment.
</paragraph>
</description>
Meyer, et al. Expires April 25, 2005 [Page 63]
Internet-Draft IPFIX Information Model October 2004
<units>packets</units>
</field>
<field name="droppedPacketTotalCount" dataType="unsigned64"
dataTypeSemantics="runningCounter"
fieldId="135" applicability="data" status="current">
<description>
<paragraph>
The number of packets of this flow dropped by packet treatment.
</paragraph>
</description>
<units>packets</units>
</field>
<field name="outMulticastPacketCount" dataType="unsigned64"
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"
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="runningCounter"
fieldId="3" applicability="data" status="current">
<description>
<paragraph>
The number of flows observed so far in the observation domain.
</paragraph>
</description>
Meyer, et al. Expires April 25, 2005 [Page 64]
Internet-Draft IPFIX Information Model October 2004
<units>flows</units>
</field>
<field name="exportedOctetTotalCount" dataType="unsigned64"
dataTypeSemantics="runningCounter"
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="runningCounter"
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"
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>
Meyer, et al. Expires April 25, 2005 [Page 65]
Internet-Draft IPFIX Information Model October 2004
Appendix B. Formal Specification of Abstract Data Types
This appendix containfs a formal description of the abstract data
types to be used for IPFIX fields and a formal description of the
template used for defining IPFIX fields. Note that this appendix is
of informational nature, while the text in sections 2 and 3 generated
from this appendix is normative.
<?xml version="1.0" encoding="UTF-8"?>
<schema elementFormDefault="qualified"
targetNamespace="http://www.ietf.org/ipfix"
xmlns:ipfix="http://www.ietf.org/ipfix">
<simpleType name="dataType">
<restriction base="string">
<enumeration value="octet">
<annotation>
<documentation>The type "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.
</documentation>
</annotation>
Meyer, et al. Expires April 25, 2005 [Page 66]
Internet-Draft IPFIX Information Model October 2004
</enumeration>
<enumeration value="float32">
<annotation>
<documentation>The type "float32" corresponds to an IEEE
single-precision 32-bit floating point type.
</documentation>
</annotation>
</enumeration>
<enumeration value="boolean">
<annotation>
<documentation>The type "boolean" represents a binary
value.
</documentation>
</annotation>
</enumeration>
<enumeration value="octetArray">
<annotation>
<documentation>The type "octetArray" represents a finite
length string of octets.
</documentation>
</annotation>
</enumeration>
<enumeration value="string">
<annotation>
<documentation>
The type "string" represents a finite length string
of valid characters from the Unicode character
encoding set. Unicode allows for ASCII and many
other international character sets to be used.
It is expected that strings will be encoded in UTF-8
format, which is identical in encoding for USASCII
characters, but also accomodates other Unicode
multibyte characters.
</documentation>
</annotation>
</enumeration>
<enumeration value="dateTimeSeconds">
<annotation>
<documentation>
The type "dateTimeSeconds" represents a time value
having a precision of seconds and normalized to the
GMT timezone. Such types are in common use on many
operating systems and have the advantage that they
Meyer, et al. Expires April 25, 2005 [Page 67]
Internet-Draft IPFIX Information Model October 2004
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>
</enumeration>
Meyer, et al. Expires April 25, 2005 [Page 68]
Internet-Draft IPFIX Information Model October 2004
<enumeration value="runningCounter">
<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>
<enumeration value="flags">
<annotation>
Meyer, et al. Expires April 25, 2005 [Page 69]
Internet-Draft IPFIX Information Model October 2004
<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>
<documentation>
Indicates that the field definition is that the
Meyer, et al. Expires April 25, 2005 [Page 70]
Internet-Draft IPFIX Information Model October 2004
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>
<complexType name="text" mixed="true">
Meyer, et al. Expires April 25, 2005 [Page 71]
Internet-Draft IPFIX Information Model October 2004
<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.
</documentation>
Meyer, et al. Expires April 25, 2005 [Page 72]
Internet-Draft IPFIX Information Model October 2004
</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
lower case letter, e.g., "sourceIpAddress".
Meyer, et al. Expires April 25, 2005 [Page 73]
Internet-Draft IPFIX Information Model October 2004
</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="vendorId" type="nonNegativeInteger"
use="optional">
<annotation>
<documentation>
Meyer, et al. Expires April 25, 2005 [Page 74]
Internet-Draft IPFIX Information Model October 2004
When extension is done outside of the scope of
the IANA IPFIX fieldId range, a vendorId MUST
be provided. Valid values for the vendorID 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>to be done ...</documentation>
</annotation>
</attribute>
<attribute name="status" type="ipfix:status"
use="required">
<annotation>
<documentation>to be done ...</documentation>
</annotation>
</attribute>
</complexType>
</element>
</sequence>
</complexType>
<unique name="fieldIdUnique">
<selector xpath="field"/>
<field xpath="fieldId"/>
</unique>
</element>
</schema>
Meyer, et al. Expires April 25, 2005 [Page 75]
Internet-Draft IPFIX Information Model October 2004
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 (2004). 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.
Meyer, et al. Expires April 25, 2005 [Page 76]
| PAFTECH AB 2003-2026 | 2026-04-24 01:40:52 |