Network Working Group J. Meyer
Internet-Draft PayPal
Expires: January 17, 2005 J. Quittek
NEC
S. Bryant
Cisco Systems Ltd
July 19, 2004
Information Model for IP Flow Information Export
draft-ietf-ipfix-info-04
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 17, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This memo defines and information model for the IP Flow Information
eXport (IPFIX) protocol. It is used by the IPFIX protocol for
encoding measured traffic information and information related to the
traffic observation point, the traffic metering process and the
exporting process. Although developed for the IPFIX protcol, the
model is defined in an open way that easily allows using it in other
protocols, interfaces, and applications.
Meyer, et al. Expires January 17, 2005 [Page 1]
Internet-Draft IPFIX Information Model July 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Properties of IPFIX Protocol Fields . . . . . . . . . . . . 6
3. Type Space . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1 octet . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 unsigned16 . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3 unsigned32 . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4 unsigned64 . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.5 float32 . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.6 boolean . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.7 octetArray . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.8 string . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.9 dateTimeSeconds . . . . . . . . . . . . . . . . . . . . . . 9
3.10 dataTimeMicroSeconds . . . . . . . . . . . . . . . . . . . . 9
3.11 ipv4Address . . . . . . . . . . . . . . . . . . . . . . . . 9
3.12 ipv6Address . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Flow Attributes . . . . . . . . . . . . . . . . . . . . . . 10
4.1 deltaOctetCount . . . . . . . . . . . . . . . . . . . . . . 10
4.2 deltaPacketCount . . . . . . . . . . . . . . . . . . . . . . 10
4.3 totalFlowCount . . . . . . . . . . . . . . . . . . . . . . . 10
4.4 protocolIdentifier . . . . . . . . . . . . . . . . . . . . . 11
4.5 classOfServiceV4 . . . . . . . . . . . . . . . . . . . . . . 11
4.6 tcpControlBits . . . . . . . . . . . . . . . . . . . . . . . 11
4.7 transportSourcePort . . . . . . . . . . . . . . . . . . . . 12
4.8 sourceAddressV4 . . . . . . . . . . . . . . . . . . . . . . 13
4.9 sourceMaskV4 . . . . . . . . . . . . . . . . . . . . . . . . 13
4.10 ingressInterface . . . . . . . . . . . . . . . . . . . . . . 13
4.11 transportDestinationPort . . . . . . . . . . . . . . . . . . 14
4.12 destinationAddressV4 . . . . . . . . . . . . . . . . . . . . 14
4.13 destinationMaskV4 . . . . . . . . . . . . . . . . . . . . . 15
4.14 egressInterface . . . . . . . . . . . . . . . . . . . . . . 15
4.15 ipNextHopAddressV4 . . . . . . . . . . . . . . . . . . . . . 15
4.16 sourceAsNumber . . . . . . . . . . . . . . . . . . . . . . . 15
4.17 destinationAsNumber . . . . . . . . . . . . . . . . . . . . 16
4.18 bgpNextHopAddressV4 . . . . . . . . . . . . . . . . . . . . 16
4.19 OutMulticastPacketCount . . . . . . . . . . . . . . . . . . 16
4.20 OutMulticastOctetCount . . . . . . . . . . . . . . . . . . . 17
4.21 flowEndTime . . . . . . . . . . . . . . . . . . . . . . . . 17
4.22 flowCreationTime . . . . . . . . . . . . . . . . . . . . . . 17
4.23 deltaOutOctetCount . . . . . . . . . . . . . . . . . . . . . 17
4.24 deltaOutPacketCount . . . . . . . . . . . . . . . . . . . . 18
4.25 minPacketLength . . . . . . . . . . . . . . . . . . . . . . 18
4.26 maxPacketLength . . . . . . . . . . . . . . . . . . . . . . 18
4.27 sourceAddressV6 . . . . . . . . . . . . . . . . . . . . . . 18
4.28 destinationAddressV6 . . . . . . . . . . . . . . . . . . . . 19
4.29 sourceMaskV6 . . . . . . . . . . . . . . . . . . . . . . . . 19
4.30 destinationMaskV6 . . . . . . . . . . . . . . . . . . . . . 19
Meyer, et al. Expires January 17, 2005 [Page 2]
Internet-Draft IPFIX Information Model July 2004
4.31 flowLabelV6 . . . . . . . . . . . . . . . . . . . . . . . . 19
4.32 icmpTypeCode . . . . . . . . . . . . . . . . . . . . . . . . 20
4.33 igmpType . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.34 flowActiveTimeOut . . . . . . . . . . . . . . . . . . . . . 20
4.35 flowInactiveTimeout . . . . . . . . . . . . . . . . . . . . 21
4.36 exportedOctetCount . . . . . . . . . . . . . . . . . . . . . 21
4.37 exportedPacketCount . . . . . . . . . . . . . . . . . . . . 21
4.38 exportedFlowCount . . . . . . . . . . . . . . . . . . . . . 21
4.39 sourcePrefixV4 . . . . . . . . . . . . . . . . . . . . . . . 22
4.40 destinationPrefixV4 . . . . . . . . . . . . . . . . . . . . 22
4.41 mplsTopLabelType . . . . . . . . . . . . . . . . . . . . . . 22
4.42 mplsTopLabelIPAddressV4 . . . . . . . . . . . . . . . . . . 23
4.43 minimumTTL . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.44 maximumTTL . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.45 identificationV4 . . . . . . . . . . . . . . . . . . . . . . 23
4.46 sourceMacAddress . . . . . . . . . . . . . . . . . . . . . . 24
4.47 ipVersion . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.48 ipNextHopAddressV6 . . . . . . . . . . . . . . . . . . . . . 24
4.49 bgpNextHopAddressV6 . . . . . . . . . . . . . . . . . . . . 25
4.50 ipv6OptionHeaders . . . . . . . . . . . . . . . . . . . . . 25
4.51 partialMPLSLabelStackEntry1 . . . . . . . . . . . . . . . . 26
4.52 partialMPLSLabelStackEntry2 . . . . . . . . . . . . . . . . 26
4.53 partialMPLSLabelStackEntry3 . . . . . . . . . . . . . . . . 27
4.54 partialMPLSLabelStackEntry4 . . . . . . . . . . . . . . . . 27
4.55 partialMPLSLabelStackEntry5 . . . . . . . . . . . . . . . . 27
4.56 partialMPLSLabelStackEntry6 . . . . . . . . . . . . . . . . 28
4.57 partialMPLSLabelStackEntry7 . . . . . . . . . . . . . . . . 28
4.58 partialMPLSLabelStackEntry8 . . . . . . . . . . . . . . . . 28
4.59 partialMPLSLabelStackEntry9 . . . . . . . . . . . . . . . . 29
4.60 partialMPLSLabelStackEntry10 . . . . . . . . . . . . . . . . 29
4.61 runningOctetCounter . . . . . . . . . . . . . . . . . . . . 29
4.62 runningPacketCounter . . . . . . . . . . . . . . . . . . . . 30
4.63 bgpNextHopAsNumber . . . . . . . . . . . . . . . . . . . . . 30
4.64 ipNextHopAsNumber . . . . . . . . . . . . . . . . . . . . . 30
4.65 exporterAddressV4 . . . . . . . . . . . . . . . . . . . . . 31
4.66 exporterAddressV6 . . . . . . . . . . . . . . . . . . . . . 31
4.67 droppedOctetDeltaCount . . . . . . . . . . . . . . . . . . . 31
4.68 droppedPacketDeltaCount . . . . . . . . . . . . . . . . . . 32
4.69 droppedOctetTotalCount . . . . . . . . . . . . . . . . . . . 32
4.70 droppedPacketTotalCount . . . . . . . . . . . . . . . . . . 32
4.71 flowEndReason . . . . . . . . . . . . . . . . . . . . . . . 32
4.72 classOfServiceV6 . . . . . . . . . . . . . . . . . . . . . . 33
5. Extending the Information Model . . . . . . . . . . . . . . 34
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 35
7. Security Considerations . . . . . . . . . . . . . . . . . . 36
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37
Normative Reference . . . . . . . . . . . . . . . . . . . . 38
Informative Reference . . . . . . . . . . . . . . . . . . . 39
Meyer, et al. Expires January 17, 2005 [Page 3]
Internet-Draft IPFIX Information Model July 2004
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 40
A. Formal Specification of IPFIX Fields . . . . . . . . . . . . 41
B. Formal Specification of Abstract Data Types . . . . . . . . 63
Intellectual Property and Copyright Statements . . . . . . . 73
Meyer, et al. Expires January 17, 2005 [Page 4]
Internet-Draft IPFIX Information Model July 2004
1. Introduction
The IP Flow Information eXport (IPFIX) protocol serves for
transmitting information related to measured IP traffic over the
Internet. The protocol specification in [IPFIX-PROTO] defines how
information elements are transmitted. For information elements, it
specifies the encoding of a set of basic data types. However, the
list of fields that can be transmitted by the protocol, such as flow
attributes (source IP address, number of packets, etc.) and
information about the metering and exporting process (packet
observation point, smapling rate, flow timeout interval, etc.), is
not specified in [IPFIX-PROTO].
This document complements the IPFIX protocol specification by
providing the IPFIX information model. The main part of this
document is Section 5 defines the (extensible) list of fields to be
transmitted by the IPFIX protcol. Section 2 defines a template for
specifying IPFIX fields that is used in Section 4. Section 3 defines
the set of abstract data types that are available for IPFIX fields.
Section 5 discusses extensibility of the IPFIX information model.
The main bodies of Sections 2, 3 and 4 were generated from XML
documents. The XML-based specification of template, abstract data
types and IPFIX fields can be used for automatically checking
syntactical correctness of the specification of IPFIX fields.
Further it can be used for generating IPFIX protocol implementation
code that deals with processing IPFIX fields. Also code for
applications that further process traffic information transmitted via
the IPFIX protocol can be generated with the XML specification of
IPFIX fields.
For that reason, the XML document that served as source for Section 4
and the XML schema that served as source for Sections 2 and 3 are
attached to this document in Appendices A and B.
Note that although partially generated from the attached XML
documents, the main body of this document is normative while the
appendices are informational.
Meyer, et al. Expires January 17, 2005 [Page 5]
Internet-Draft IPFIX Information Model July 2004
2. Properties of IPFIX Protocol Fields
Fields of the IPFIX protocol carrying information about traffic
measurement are modeled as elements of the IPFIX information model
and specified in Section 4. For defining the fields, a template is
used that is specified below.
All fields specified for the IPFIX protocol either in this document
or by an extension MUST have the following properties defined:
name - A unique and meaningful name for the field. The preferred
spelling for the name is to use mixed case if the name is
compound, with an initial lower case letter. (E.g.
"sourceIpAddress").
fieldType - A numeric identifier administered by IANA. This is used
for compact identification of an information item when encoding
templates in the protocol.
description - The semantics of this information element. Describes
how this field is derived from the flow or other information
available to the observer.
dataType - One of the types listed in the "Type Space" section. The
type space for attributes is constrained to facilitate
implementation. The existing type space does however encompass
most basic types used in modern programming languages, as well as
some derived types (such as IPAddress) which are common to this
domain and useful to distinguish.
dataTypeSemantics - The integral types may be qualified by additional
semantic details. Qualifying the fields as 'quantity', 'counter',
'identifier' or 'flags'.
applicability - to be done ...
status - to be done ...
All fields specified for the IPFIX protocol either in this document
or by an extension MAY have the following properties defined:
vendorId - When extension is done outside of the scope of the IANA
IPFIX fieldId range, a vendorId MUST be provided. This identifier
is based on IANA assigned enterprise identifiers.
usage - to be done ...
Meyer, et al. Expires January 17, 2005 [Page 6]
Internet-Draft IPFIX Information Model July 2004
units - If the field is a measure of some kind, the units identify
what the measure is.
enumeratedRange - Some items may have a specific set of numeric
identifiers associated with a set of discrete values this element
may take. The meaning of each discrete value and a human readable
name should be assigned.
range - Some elements may only be able to take on a restricted set of
values which can be expressed as a range (e.g. 0 through 511
inclusive). If this is the case, the valid inclusive range should
be specified.
reference - Identifies additional specifications which more precisely
define this item or provide additional context for its use.
Meyer, et al. Expires January 17, 2005 [Page 7]
Internet-Draft IPFIX Information Model July 2004
3. Type Space
The following subsections describe the abstract data types that can
be used for the specification of IPFIX fields in Section 4.
3.1 octet
The type "unsignedByte" represents a non-negative integer value in
the range of 0 to 255.
3.2 unsigned16
The type "unsigned16" represents a non-negative integer value in the
range of 0 to 65535.
3.3 unsigned32
The type "unsigned32" represents a non-negative integer value in the
range of 0 to 4294967295.
3.4 unsigned64
The type "unsigned64" represents a non-negative integer value in the
range of 0 to 18446744073709551615.
3.5 float32
The type "float32" corresponds to an IEEE single-precision 32-bit
floating point type.
3.6 boolean
The type "boolean" represents a binary value.
3.7 octetArray
The type "octetArray" represents a finite length string of octets.
3.8 string
The type "string" represents a finite length string of valid
characters from the Unicode character encoding set. Unicode allows
for ASCII and many other international character sets to be used. It
is expected that strings will be encoded in UTF-8 format, which is
identical in encoding for USASCII characters, but also accomodates
other Unicode multibyte characters.
Meyer, et al. Expires January 17, 2005 [Page 8]
Internet-Draft IPFIX Information Model July 2004
3.9 dateTimeSeconds
The type "dateTimeSeconds" represents a time value having a precision
of seconds and normalized to the GMT timezone. Such types are in
common use on many operating systems and have the advantage that they
can be stored in 32-bit integers.
3.10 dataTimeMicroSeconds
The type "dateTimeSeconds" represents a time value having a precision
of microseconds and normalized to the GMT timezone.
3.11 ipv4Address
The type "ipv4Addr" represents a value of an IPv4 address. These
addresses are typically stored as 32-bit integers.
3.12 ipv6Address
The type "ipv6Addr" represents a value of an IPv6 address.
Meyer, et al. Expires January 17, 2005 [Page 9]
Internet-Draft IPFIX Information Model July 2004
4. Flow Attributes
4.1 deltaOctetCount
Description:
The number of octets in (incoming) packets observed for this flow
at the observation point since the previous report (if any). The
number of octets include IP header(s) and IP payload.
Abstract Data Type: unsigned64
Data Type Semantics: deltaCounter
Field Id: 1
Units: octets
4.2 deltaPacketCount
Description:
The number of (incoming) packets observed for this flow at the
observation point since the previous report (if any).
Abstract Data Type: unsigned64
Data Type Semantics: deltaCounter
Field Id: 2
Units: packets
4.3 totalFlowCount
Description:
The number of flows observed so far in the observation domain.
Abstract Data Type: unsigned64
Data Type Semantics: runningCounter
Field Id: 3
Units: flows
Meyer, et al. Expires January 17, 2005 [Page 10]
Internet-Draft IPFIX Information Model July 2004
4.4 protocolIdentifier
Description:
The protocol number observed for packets of this flow. The
protocol number identifies the IP packet payload. Protocol numbers
are defined in the IANA Protocol Numbers registry.
In Internet Protocol version 4 (IPv4) this is carried in the
"Protocol" field. In Internet Protocol version 6 (IPv6) this is
carried in the "Next Header" field in the last extension header of
the packet.
Abstract Data Type: octet
Data Type Semantics: identifier
Field Id: 4
Reference:
See RFC 791 for the specification of the IPv4 protocol field. See
RFC 2460 for the specification of the IPv6 protocol field. See
list of protocol numbers assigned by IANA at http://www.iana.org/
assignments/protocol-numbers.
4.5 classOfServiceV4
Description:
The value of the IPv4 TOS field observed for packets of this flow.
Abstract Data Type: octet
Data Type Semantics: identifier
Field Id: 5
Reference: See RFC 791 for the definition of the IPv4 TOS field.
4.6 tcpControlBits
Description:
Meyer, et al. Expires January 17, 2005 [Page 11]
Internet-Draft IPFIX Information Model July 2004
TCP control bits observed for packets of this flow. The value of
this field is the result of a logical OR operation over the flags
observed in all packets of the flow. This implies that a 0 value
for a bit indicates that the respective bit was not set in any of
the observed packets of this flow.
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| | | | | | | |
| Reserved | URG | ACK | PSH | RST | SYN | FIN |
| | | | | | | |
+-----+-----+-----+-----+-----+-----+-----+-----+
Reserved: Reserved for future use by TCP.
Must be zero.
URG: Urgent Pointer field significant
ACK: Acknowledgment field significant
PSH: Push Function
RST: Reset the connection
SYN: Synchronize sequence numbers
FIN: No more data from sender
Abstract Data Type: octet
Data Type Semantics: flags
Field Id: 6
Reference: See RFC 793 for a definition of the TCP control bits in
the TCP header.
4.7 transportSourcePort
Description:
A source port identifier in the transport header. For transport
protocols UDP, TCP and SCTP this is the source port number given
in the respective header. This field MAY also be used for future
transport protocols that have 16 bit source port identifiers.
Abstract Data Type: unsigned16
Data Type Semantics: identifier
Field Id: 7
Meyer, et al. Expires January 17, 2005 [Page 12]
Internet-Draft IPFIX Information Model July 2004
Reference:
See RFC 768 for the 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.
4.8 sourceAddressV4
Description:
IPv4 source address taken from the IP packet header of a packet of
this flow.
Abstract Data Type: ipv4Address
Field Id: 8
Reference: See RFC 791 for the definition of the IPv4 source address
field.
4.9 sourceMaskV4
Description:
The number of contiguous bits that are relevant in the
sourceAddressV4 field.
Abstract Data Type: octet
Field Id: 9
Units: bits
4.10 ingressInterface
Description:
The index of the IP interface (ifIndex) where packets of this flow
are being received.
Abstract Data Type: unsigned32
Data Type Semantics: identifier
Meyer, et al. Expires January 17, 2005 [Page 13]
Internet-Draft IPFIX Information Model July 2004
Field Id: 10
Reference: See RFC 2863 for the definition of the ifIndex object.
4.11 transportDestinationPort
Description:
A destination port identifier in the transport header. For
transport protocols UDP, TCP and SCTP this 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
Field Id: 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.
4.12 destinationAddressV4
Description:
IPv4 destination address taken from the IP packet header of a
packet of this flow.
Abstract Data Type: ipv4Address
Field Id: 12
Reference: See RFC 791 for the definition of the IPv4 destination
address field.
Meyer, et al. Expires January 17, 2005 [Page 14]
Internet-Draft IPFIX Information Model July 2004
4.13 destinationMaskV4
Description:
The number of contiguous bits that are relevant in the
destinationAddressV4 field.
Abstract Data Type: octet
Field Id: 13
Units: bits
4.14 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
Field Id: 14
Reference: See RFC 2863 for the definition of the ifIndex object.
4.15 ipNextHopAddressV4
Description:
The IPv4 address of the next IP hop to which packets of this flow
are forwarded.
Abstract Data Type: ipv4Address
Field Id: 15
4.16 sourceAsNumber
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
Meyer, et al. Expires January 17, 2005 [Page 15]
Internet-Draft IPFIX Information Model July 2004
Data Type Semantics: identifier
Field Id: 16
Reference: See RFC 1771 for a description of BGB-4 and see RFC 1930 a
definition of the AS number.
4.17 destinationAsNumber
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
Field Id: 17
Reference: See RFC 1771 for a description of BGB-4 and see RFC 1930 a
definition of the AS number.
4.18 bgpNextHopAddressV4
Description:
The IPv4 address of the next BGP hop to which packets of this flow
are forwarded.
Abstract Data Type: ipv4Address
Field Id: 18
Reference: See RFC 1771 for a description of BGB-4 and see RFC 1930 a
definition of the AS number.
4.19 OutMulticastPacketCount
Description:
The 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.
Meyer, et al. Expires January 17, 2005 [Page 16]
Internet-Draft IPFIX Information Model July 2004
Abstract Data Type: unsigned64
Field Id: 19
Units: packets
4.20 OutMulticastOctetCount
Description:
The 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
Field Id: 20
Units: octets
4.21 flowEndTime
Description: The timestamp of the last packet of this flow.
Abstract Data Type: dateTimeSeconds
Field Id: 21
4.22 flowCreationTime
Description: The timestamp of the first packet of this flow.
Abstract Data Type: dateTimeSeconds
Field Id: 22
4.23 deltaOutOctetCount
Description:
The number of octets in outgoing packets observed for this 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
Meyer, et al. Expires January 17, 2005 [Page 17]
Internet-Draft IPFIX Information Model July 2004
Field Id: 23
Units: octets
4.24 deltaOutPacketCount
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
Field Id: 24
Units: packets
4.25 minPacketLength
Description:
Length of the smallest packet observed for this flow.
Abstract Data Type: unsigned16
Field Id: 25
Units: octets
4.26 maxPacketLength
Description:
Length of the largest packet observed for this flow.
Abstract Data Type: unsigned16
Field Id: 26
Units: octets
4.27 sourceAddressV6
Description:
Meyer, et al. Expires January 17, 2005 [Page 18]
Internet-Draft IPFIX Information Model July 2004
IPv6 source address taken from the IP packet header of a packet of
this flow.
Abstract Data Type: ipv6Address
Field Id: 27
4.28 destinationAddressV6
Description:
IPv6 destination address taken from the IP packet header of a
packet of this flow.
Abstract Data Type: ipv6Address
Field Id: 28
4.29 sourceMaskV6
Description:
The number of contiguous bits that are relevant in the
sourceAddressV6 field.
Abstract Data Type: octet
Field Id: 29
Units: bits
4.30 destinationMaskV6
Description:
The number of contiguous bits that are relevant in the
destinationAddressV6 field.
Abstract Data Type: octet
Field Id: 30
Units: bits
4.31 flowLabelV6
Meyer, et al. Expires January 17, 2005 [Page 19]
Internet-Draft IPFIX Information Model July 2004
Description:
The Flow Label of the IPv6 packet header observed in a packet of
this flow.
Abstract Data Type: unsigned32
Field Id: 31
Reference: See RFC 2460 for a definition of the flow label field in
the IPv6 packet header.
4.32 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
Field Id: 32
Reference: See RFC 792 for a definition of the ICMP type and code
fields.
4.33 igmpType
Description: The type field of the IGMP message.
Abstract Data Type: octet
Field Id: 33
Reference: See RFC 2236 for a definition of the IGMP type field.
4.34 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
Meyer, et al. Expires January 17, 2005 [Page 20]
Internet-Draft IPFIX Information Model July 2004
Field Id: 36
Units: seconds
4.35 flowInactiveTimeout
Description:
A flow is considered to be timed out if not packet belonging to
the flow has been observed for the number of seconds specified by
this field.
Abstract Data Type: unsigned16
Field Id: 37
Units: seconds
4.36 exportedOctetCount
Description:
The number of all octets reported by the exporting process to this
collecting process.
Abstract Data Type: unsigned64
Field Id: 40
Units: octets
4.37 exportedPacketCount
Description:
The number of all packets reported by the exporting process to
this collecting process.
Abstract Data Type: unsigned64
Field Id: 41
Units: packets
4.38 exportedFlowCount
Meyer, et al. Expires January 17, 2005 [Page 21]
Internet-Draft IPFIX Information Model July 2004
Description:
The number of all flows records reported by the exporting process
to this collecting process.
Abstract Data Type: unsigned64
Field Id: 42
Units: flows
4.39 sourcePrefixV4
Description:
IPv4 source address prefix.
EDITOR'S NOTE: to be discussed on ipfix mailing list
Abstract Data Type: ipV4Address
Field Id: 44
Units: flows
4.40 destinationPrefixV4
Description:
IPv4 destination address prefix.
EDITOR'S NOTE: to be discussed on ipfix mailing list
Abstract Data Type: ipV4Address
Field Id: 45
Units: flows
4.41 mplsTopLabelType
Description:
MPLS top label type:
This field identifies the control protocol that allocated the top
of stack label.
Meyer, et al. Expires January 17, 2005 [Page 22]
Internet-Draft IPFIX Information Model July 2004
Abstract Data Type: octet
Data Type Semantics: identifier
Field Id: 46
4.42 mplsTopLabelIPAddressV4
Description:
The IPv4 address of the system that the MPLS top label will cause
this packet to be forwarded to.
Abstract Data Type: ipV4Address
Field Id: 47
4.43 minimumTTL
Description:
Minimum TTL value observed for any packet in this flow.
Abstract Data Type: octet
Field Id: 52
4.44 maximumTTL
Description:
Maximum TTL value observed for any packet in this flow.
Abstract Data Type: octet
Field Id: 53
4.45 identificationV4
Description:
Packet identification field from the first IP packet of this flow.
Abstract Data Type: octet
Data Type Semantics: identifier
Field Id: 54
Meyer, et al. Expires January 17, 2005 [Page 23]
Internet-Draft IPFIX Information Model July 2004
Reference: See RFC 791 for the definition of the IPv4 identification
field.
4.46 sourceMacAddress
Description:
Packet identification field from the first IP packet of this flow.
Abstract Data Type: octet
Field Id: 56
Reference: See RFC 791 for the definition of the IPv4 identification
field.
4.47 ipVersion
Description: The IP version field given in the IP header.
Abstract Data Type: octet
Field Id: 60
Units: flows
Reference:
See RFC 791 for a definition of the version field in the IPv6
packet header. See RFC 2460 for a definition of the version field
in the IPv6 packet header. Additional information on defined
version numbers can be found at http://www.iana.org/assignments/
version-numbers.
4.48 ipNextHopAddressV6
Description:
The IPv6 address of the next BGP hop to which packets of this flow
are forwarded.
Abstract Data Type: ipv6Address
Field Id: 62
Meyer, et al. Expires January 17, 2005 [Page 24]
Internet-Draft IPFIX Information Model July 2004
4.49 bgpNextHopAddressV6
Description:
The IPv6 address of the next BGP hop to which packets of this flow
are forwarded.
Abstract Data Type: ipv6Address
Data Type Semantics: identifier
Field Id: 63
Reference: See RFC 1771 for a description of BGB-4. See RFC 1930 a
definition of the AS number.
4.50 ipv6OptionHeaders
Description:
IPv6 options in the IP packet headers of this flow. This is
encoded as a bit field.
bit IPv6 Option Definition
0 Reserved
1 44 Fragmentation header -
not first fragment
2 43 Routing header
3 44 Fragmentation header -
first fragment
4 Unknown Layer 4 header
(compressed, encrypted,
not supported)
5 Reserved
6 0 Hop-by-hop option header
7 60 Destination option
header
8 108 Payload compression
header
9 51 Authentication Header
10 50 Encrypted security
payload
11 to 31 Reserved
Abstract Data Type: unsigned32
Meyer, et al. Expires January 17, 2005 [Page 25]
Internet-Draft IPFIX Information Model July 2004
Data Type Semantics: flags
Field Id: 64
Reference: To be done.
4.51 partialMPLSLabelStackEntry1
Description:
The label, exp and s fields from the outermost MPLS label stack
entry e.g. the last label that was pushed last.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | Exp |S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label: Label Value, 20 bits
Exp: Experimental Use, 3 bits
S: Bottom of Stack, 1 bit
Abstract Data Type: unsigned32
Field Id: 70
Reference: See RFC 3032.
4.52 partialMPLSLabelStackEntry2
Description:
The label, exp and s fields from the LSE that was pushed
immediately before the LSE that would be reported by
partialMplsLse1. See the definition of partialMplsLse1 for further
details.
Abstract Data Type: unsigned32
Field Id: 71
Reference: See RFC 3032.
Meyer, et al. Expires January 17, 2005 [Page 26]
Internet-Draft IPFIX Information Model July 2004
4.53 partialMPLSLabelStackEntry3
Description:
The label, exp and s fields from the LSE that was pushed
immediately before the LSE that would be reported by
partialMplsLse2. See the definition of partialMplsLse1 for further
details.
Abstract Data Type: unsigned32
Field Id: 72
Reference: See RFC 3032.
4.54 partialMPLSLabelStackEntry4
Description:
The label, exp and s fields from the LSE that was pushed
immediately before the LSE that would be reported by
partialMplsLse3. See the definition of partialMplsLse1 for further
details.
Abstract Data Type: unsigned32
Field Id: 73
Reference: See RFC 3032.
4.55 partialMPLSLabelStackEntry5
Description:
The label, exp and s fields from the LSE that was pushed
immediately before the LSE that would be reported by
partialMplsLse4. See the definition of partialMplsLse1 for further
details.
Abstract Data Type: unsigned32
Field Id: 74
Reference: See RFC 3032.
Meyer, et al. Expires January 17, 2005 [Page 27]
Internet-Draft IPFIX Information Model July 2004
4.56 partialMPLSLabelStackEntry6
Description:
The label, exp and s fields from the LSE that was pushed
immediately before the LSE that would be reported by
partialMplsLse5. See the definition of partialMplsLse1 for further
details.
Abstract Data Type: unsigned32
Field Id: 75
Reference: See RFC 3032.
4.57 partialMPLSLabelStackEntry7
Description:
The label, exp and s fields from the LSE that was pushed
immediately before the LSE that would be reported by
partialMplsLse6. See the definition of partialMplsLse1 for further
details.
Abstract Data Type: unsigned32
Field Id: 76
Reference: See RFC 3032.
4.58 partialMPLSLabelStackEntry8
Description:
The label, exp and s fields from the LSE that was pushed
immediately before the LSE that would be reported by
partialMplsLse7. See the definition of partialMplsLse1 for further
details.
Abstract Data Type: unsigned32
Field Id: 77
Reference: See RFC 3032.
Meyer, et al. Expires January 17, 2005 [Page 28]
Internet-Draft IPFIX Information Model July 2004
4.59 partialMPLSLabelStackEntry9
Description:
The label, exp and s fields from the LSE that was pushed
immediately before the LSE that would be reported by
partialMplsLse8. See the definition of partialMplsLse1 for further
details.
Abstract Data Type: unsigned32
Field Id: 78
Reference: See RFC 3032.
4.60 partialMPLSLabelStackEntry10
Description:
The label, exp and s fields from the LSE that was pushed
immediately before the LSE that would be reported by
partialMplsLse9. See the definition of partialMplsLse1 for further
details.
Abstract Data Type: unsigned32
Field Id: 79
Reference: See RFC 3032.
4.61 runningOctetCounter
Description:
Number of observed octets for a pre-defined permanent flow.
EDITOR'S NOTE: clarification required.
Abstract Data Type: unsigned64
Data Type Semantics: runningCounter
Field Id: 85
Units: octets
Meyer, et al. Expires January 17, 2005 [Page 29]
Internet-Draft IPFIX Information Model July 2004
4.62 runningPacketCounter
Description:
Number of observed packets for a pre-defined permanent flow.
EDITOR'S NOTE: clarification required.
Abstract Data Type: unsigned64
Data Type Semantics: runningCounter
Field Id: 86
Units: packets
4.63 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
Field Id: 128
Reference: See RFC 1771 for a description of BGB-4 and see RFC 1930 a
definition of the AS number.
4.64 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
Field Id: 129
Meyer, et al. Expires January 17, 2005 [Page 30]
Internet-Draft IPFIX Information Model July 2004
Reference: See RFC 1771 for a description of BGB-4 and see RFC 1930 a
definition of the AS number.
4.65 exporterAddressV4
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
Field Id: 130
4.66 exporterAddressV6
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
Field Id: 131
4.67 droppedOctetDeltaCount
Description:
The number of octets in packets of this flow dropped by packet
treatment.
Abstract Data Type: unsigned64
Data Type Semantics: deltaCounter
Field Id: 132
Units: octets
Meyer, et al. Expires January 17, 2005 [Page 31]
Internet-Draft IPFIX Information Model July 2004
4.68 droppedPacketDeltaCount
Description:
The number of packets of this flow dropped by packet treatment.
Abstract Data Type: unsigned64
Data Type Semantics: deltaCounter
Field Id: 133
Units: packets
4.69 droppedOctetTotalCount
Description:
The number of octets in packets of this flow dropped by packet
treatment.
Abstract Data Type: unsigned64
Data Type Semantics: runningCounter
Field Id: 134
Units: octets
4.70 droppedPacketTotalCount
Description:
The number of packets of this flow dropped by packet treatment.
Abstract Data Type: unsigned64
Data Type Semantics: runningCounter
Field Id: 135
Units: packets
4.71 flowEndReason
Description:
Meyer, et al. Expires January 17, 2005 [Page 32]
Internet-Draft IPFIX Information Model July 2004
The reason for flow termination.
EDITORS' NOTE: This needs to be defined as an enumerated range.
Abstract Data Type: octet
Field Id: 136
4.72 classOfServiceV6
Description:
The value of the IPv6 traffic class field observed for packets of
this flow.
Abstract Data Type: octet
Field Id: 135
Reference: See RFC 2460 for the definition of the IPv6 traffic class
field.
Meyer, et al. Expires January 17, 2005 [Page 33]
Internet-Draft IPFIX Information Model July 2004
5. Extending the Information Model
A key requirement for IPFIX is to allow for extending the set of
information items which are reported for flows. This section defines
the mechanism for extending this set.
The IPFIX protocol carries flow records defined by a template.
Multiple templates may be defined for a dialog between an exporter
and a collector. A given template identifies the information items
and their order. The means of identification of information items in
a template is via a field ID. Field Id's are unique identifiers
administered by IANA.
Extension is done by defining new Information elements, including the
set of necessary information 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 IANA
enterprise ID assignments, without registering specific field ID's
with IANA. In these cases the field definiton must specify the
vendor ID as well as the vendor-specified field ID 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 January 17, 2005 [Page 34]
Internet-Draft IPFIX Information Model July 2004
6. 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 January 17, 2005 [Page 35]
Internet-Draft IPFIX Information Model July 2004
7. 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 January 17, 2005 [Page 36]
Internet-Draft IPFIX Information Model July 2004
8. Acknowledgements
The editors thank Stewart Bryant 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 January 17, 2005 [Page 37]
Internet-Draft IPFIX Information Model July 2004
Normative Reference
[1] Claise, B., Fullmer, M., Calato, P. and R. Penno, "IPFIX
Protocol Specification", IETF draft work in progress, January
2004, <http://www.ietf.org/internet-drafts/
draft-ietf-ipfix-protocol-02.txt>.
Meyer, et al. Expires January 17, 2005 [Page 38]
Internet-Draft IPFIX Information Model July 2004
Informative Reference
[2] Quittek, J., Zseby, T., Claise, B. and S. Zander, "Requirements
for IP Flow Information Export", IETF draft work in progress,
January 2004, <http://www.ietf.org/internet-drafts/
draft-ietf-ipfix-reqs-15.txt>.
[3] Sadasivan, G. and N. Brownlee, "Architecture Model for IP Flow
Information Export", IETF draft work in progress, October 2003,
<http://www.ietf.org/internet-drafts/
draft-ietf-ipfix-arch-02.txt>.
[4] Zseby, T., Penno, R., Claise, B. and N. Brownlee, "IPFIX
Applicability", IETF draft work in progress, October 2003,
<http://www.ietf.org/internet-drafts/
draft-ietf-ipfix-as-01.txt>.
[5] Claise, B., "Cisco Systems NetFlow Services Export Version 9",
IETF draft work in progress, June 2003, <http://www.ietf.org/
internet-drafts/draft-claise-netflow-9-02.txt>.
[6] World Wide Web Consortium, "Extensible Markup Language (XML)
1.0", W3C XML, February 1998, <http://www.w3.org/TR/1998/
REC-xml-19980210>.
[7] World Wide Web Consortium, "XML Schema Part 1: Structures", W3C
XML, May 2001, <http://www.w3.org/TR/2001/
REC-xmlschema-1-20010502/>.
[8] World Wide Web Consortium, "XML Schema Part 2: Datatypes", W3C
XML, May 2001, <http://www.w3.org/TR/2001/
REC-xmlschema-2-20010502/datatypes.html>.
[9] Internet Protocol Detail Record Organization, "Network Data
Management - Usage (NDM-U) For IP-Based Services Version
3.1.1", October 2002, <http://www.ipdr.org/documents/
NDM-U_3.1.1.pdf>.
[10] Brownlee, N. and A. Blount, "Accounting Attributes and Record
Formats", RFC 2924, Sept. 2000, <http://www.ietf.org/rfc/
rfc2924.txt>.
[11] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June
1999, <http://xml.resource.org/public/rfc/html/rfc2629.html>.
[12] Hollenbeck, S., Rose, M. and L. Masinter, "Guidelines for the
Use of Extensible Markup Language (XML) within IETF Protocols",
RFC 3470, January 2003, <http://www.ietf.org/rfc/rfc3470.txt>.
Meyer, et al. Expires January 17, 2005 [Page 39]
Internet-Draft IPFIX Information Model July 2004
[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/
Stewart Bryant
Cisco Systems Ltd
250, Longwater, Green Park
Reading RG2 6GB
United Kingdom
EMail: stbryant@cisco.com
Meyer, et al. Expires January 17, 2005 [Page 40]
Internet-Draft IPFIX Information Model July 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="deltaOctetCount" dataType="unsigned64"
dataTypeSemantics="deltaCounter"
fieldType="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="deltaPacketCount" dataType="unsigned64"
dataTypeSemantics="deltaCounter"
fieldType="2" applicability="data" status="current">
<description>
Meyer, et al. Expires January 17, 2005 [Page 41]
Internet-Draft IPFIX Information Model July 2004
<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="totalFlowCount" dataType="unsigned64"
dataTypeSemantics="runningCounter"
fieldType="3" applicability="data" status="current">
<description>
<paragraph>
The number of flows observed so far in the observation domain.
</paragraph>
</description>
<units>flows</units>
</field>
<field name="protocolIdentifier" dataType="octet"
dataTypeSemantics="identifier"
fieldType="4" applicability="all" status="current">
<description>
<paragraph>
The protocol number observed for packets of this flow.
The protocol number identifies the IP packet payload.
Protocol numbers are defined in the IANA Protocol Numbers
registry.</paragraph>
<paragraph>
In Internet Protocol version 4 (IPv4) this is carried in
the "Protocol" field. In Internet Protocol version 6 (IPv6)
this is carried in the "Next Header" field in the last
extension header of the packet.</paragraph>
</description>
<reference>
<paragraph>
See RFC 791 for the specification of the IPv4 protocol field.
See RFC 2460 for the specification of the IPv6 protocol field.
See list of protocol numbers assigned by IANA at
http://www.iana.org/assignments/protocol-numbers.
</paragraph>
</reference>
</field>
<field name="classOfServiceV4" dataType="octet"
dataTypeSemantics="identifier"
fieldType="5" applicability="all" status="current">
Meyer, et al. Expires January 17, 2005 [Page 42]
Internet-Draft IPFIX Information Model July 2004
<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="tcpControlBits" dataType="octet"
dataTypeSemantics="flags"
fieldType="6" applicability="all" status="current">
<description>
<paragraph>
TCP control bits observed for packets of this flow.
The value of this field is the result of a logical OR operation
over the flags observed in all packets of the flow.
This implies that 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>
</description>
<reference>See RFC 793 for a definition of the TCP control bits
in the TCP header.</reference>
</field>
<field name="transportSourcePort" dataType="unsigned16"
dataTypeSemantics="identifier"
fieldType="7" applicability="all" status="current">
<description>
<paragraph>
A source port identifier in the transport header. For transport
protocols UDP, TCP and 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>
Meyer, et al. Expires January 17, 2005 [Page 43]
Internet-Draft IPFIX Information Model July 2004
<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="sourceAddressV4" dataType="ipv4Address"
fieldType="8" applicability="all" status="current">
<description>
<paragraph>
IPv4 source address taken from the IP packet header of a
packet of this flow.
</paragraph>
</description>
<reference>
See RFC 791 for the definition of the IPv4 source address
field.
</reference>
</field>
<field name="sourceMaskV4" dataType="octet"
fieldType="9" applicability="option" status="current">
<description>
<paragraph>
The number of contiguous bits that are relevant in the
sourceAddressV4 field.
</paragraph>
</description>
<units>bits</units>
<range>0-32</range>
</field>
<field name="ingressInterface" dataType="unsigned32"
dataTypeSemantics="identifier"
fieldType="10" applicability="all" status="current">
<description>
<paragraph>
The index of the IP interface (ifIndex) where packets of
this flow are being received.
</paragraph>
</description>
<reference>
See RFC 2863 for the definition of the ifIndex object.
Meyer, et al. Expires January 17, 2005 [Page 44]
Internet-Draft IPFIX Information Model July 2004
</reference>
</field>
<field name="transportDestinationPort" dataType="unsigned16"
dataTypeSemantics="identifier"
fieldType="11" applicability="all" status="current">
<description>
<paragraph>
A destination port identifier in the transport header.
For transport protocols UDP, TCP and SCTP this is the
destination port number given in the respective header.
This field MAY also be used for future transport protocols
that have 16 bit destination port identifiers.
</paragraph>
</description>
<reference>
<paragraph>
See RFC 768 for the definition of the UDP source port field.
See RFC 793 for the definition of the TCP source port field.
See RFC 2960 for the definition of SCTP. </paragraph>
<paragraph>
Additional information on defined UDP and TCP port numbers can
be found at http://www.iana.org/assignments/port-numbers.
</paragraph>
</reference>
</field>
<field name="destinationAddressV4" dataType="ipv4Address"
fieldType="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="destinationMaskV4" dataType="octet"
fieldType="13" applicability="option" status="current">
<description>
<paragraph>
The number of contiguous bits that are relevant in the
destinationAddressV4 field.
Meyer, et al. Expires January 17, 2005 [Page 45]
Internet-Draft IPFIX Information Model July 2004
</paragraph>
</description>
<units>bits</units>
<range>0-32</range>
</field>
<field name="egressInterface" dataType="unsigned32"
dataTypeSemantics="identifier"
fieldType="14" applicability="all" status="current">
<description>
<paragraph>
The index of the IP interface (ifIndex) where packets of this
flow are being sent.
</paragraph>
</description>
<reference>
See RFC 2863 for the definition of the ifIndex object.
</reference>
</field>
<field name="ipNextHopAddressV4" dataType="ipv4Address"
fieldType="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="sourceAsNumber" dataType="unsigned16"
dataTypeSemantics="identifier"
fieldType="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="destinationAsNumber" dataType="unsigned16"
dataTypeSemantics="identifier"
fieldType="17" applicability="all" status="current">
Meyer, et al. Expires January 17, 2005 [Page 46]
Internet-Draft IPFIX Information Model July 2004
<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="bgpNextHopAddressV4" dataType="ipv4Address"
fieldType="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="OutMulticastPacketCount" dataType="unsigned64"
fieldType="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"
fieldType="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>
Meyer, et al. Expires January 17, 2005 [Page 47]
Internet-Draft IPFIX Information Model July 2004
</description>
<units>octets</units>
</field>
<field name="flowEndTime" dataType="dateTimeSeconds"
fieldType="21" applicability="data" status="current">
<description>
The timestamp of the last packet of this flow.
</description>
</field>
<field name="flowCreationTime" dataType="dateTimeSeconds"
fieldType="22" applicability="data" status="current">
<description>
The timestamp of the first packet of this flow.
</description>
</field>
<field name="deltaOutOctetCount" dataType="unsigned64"
dataTypeSemantics="deltaCounter"
fieldType="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="deltaOutPacketCount" dataType="unsigned64"
dataTypeSemantics="deltaCounter"
fieldType="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="minPacketLength" dataType="unsigned16"
fieldType="25" applicability="all" status="current">
<description>
<paragraph>
Length of the smallest packet observed for this flow.
Meyer, et al. Expires January 17, 2005 [Page 48]
Internet-Draft IPFIX Information Model July 2004
</paragraph>
</description>
<units>octets</units>
</field>
<field name="maxPacketLength" dataType="unsigned16"
fieldType="26" applicability="all" status="current">
<description>
<paragraph>
Length of the largest packet observed for this flow.
</paragraph>
</description>
<units>octets</units>
</field>
<field name="sourceAddressV6" dataType="ipv6Address"
fieldType="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="destinationAddressV6" dataType="ipv6Address"
fieldType="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="sourceMaskV6" dataType="octet"
fieldType="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>
</field>
<field name="destinationMaskV6" dataType="octet"
Meyer, et al. Expires January 17, 2005 [Page 49]
Internet-Draft IPFIX Information Model July 2004
fieldType="30" applicability="option" status="current">
<description>
<paragraph>
The number of contiguous bits that are relevant in the
destinationAddressV6 field.
</paragraph>
</description>
<units>bits</units>
<range>0-128</range>
</field>
<field name="flowLabelV6" dataType="unsigned32"
fieldType="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="icmpTypeCode" dataType="unsigned16"
fieldType="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"
fieldType="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>
Meyer, et al. Expires January 17, 2005 [Page 50]
Internet-Draft IPFIX Information Model July 2004
<field name="flowActiveTimeOut" dataType="unsigned16"
fieldType="36" applicability="all" status="current">
<description>
<paragraph>
The number of seconds after which an active flow is timed out
anyway, even if there is still a continuous flow of packets.
</paragraph>
</description>
<units>seconds</units>
</field>
<field name="flowInactiveTimeout" dataType="unsigned16"
fieldType="37" applicability="all" status="current">
<description>
<paragraph>
A flow is considered to be timed out if not packet belonging
to the flow has been observed for the number of seconds
specified by this field.
</paragraph>
</description>
<units>seconds</units>
</field>
<field name="exportedOctetCount" dataType="unsigned64"
fieldType="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="exportedPacketCount" dataType="unsigned64"
fieldType="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="exportedFlowCount" dataType="unsigned64"
fieldType="42" applicability="data" status="current">
<description>
Meyer, et al. Expires January 17, 2005 [Page 51]
Internet-Draft IPFIX Information Model July 2004
<paragraph>
The number of all flows records reported by the exporting
process to this collecting process.
</paragraph>
</description>
<units>flows</units>
</field>
<field name="sourcePrefixV4" dataType="ipV4Address"
fieldType="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="destinationPrefixV4" dataType="ipV4Address"
fieldType="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="mplsTopLabelType" dataType="octet"
dataTypeSemantics="identifier"
fieldType="46" applicability="data" status="current">
<description>
<paragraph>
MPLS top label type:
<list>
<item> 0x01 TE-MIDPT: Any TE tunnel mid-point or tail label</item>
<item> 0x02 Pseudowire: Any PWE3 or Cisco AToM based label</item>
<item> 0x03 VPN: Any label associated with VPN</item>
<item> 0x04 BGP: Any label associated with BGP or BGP routing</item>
<item> 0x05 LDP: Any label associated with dynamically assigned
labels using LDP</item>
</list>
This field identifies the control protocol that allocated the
top of stack label.
</paragraph>
</description>
Meyer, et al. Expires January 17, 2005 [Page 52]
Internet-Draft IPFIX Information Model July 2004
</field>
<field name="mplsTopLabelIPAddressV4" dataType="ipV4Address"
fieldType="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="minimumTTL" dataType="octet"
fieldType="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"
fieldType="53" applicability="data" status="current">
<description>
<paragraph>
Maximum TTL value observed for any packet in this flow.
</paragraph>
</description>
</field>
<field name="identificationV4" dataType="octet"
dataTypeSemantics="identifier"
fieldType="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="sourceMacAddress" dataType="octet"
fieldType="56" applicability="data" status="current">
<description>
<paragraph>
Packet identification field from the first IP packet of this flow.
Meyer, et al. Expires January 17, 2005 [Page 53]
Internet-Draft IPFIX Information Model July 2004
</paragraph>
</description>
<reference>
See RFC 791 for the definition of the IPv4 identification field.
</reference>
</field>
<field name="ipVersion" dataType="octet"
fieldType="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>
</field>
<field name="ipNextHopAddressV6" dataType="ipv6Address"
fieldType="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="bgpNextHopAddressV6" dataType="ipv6Address"
dataTypeSemantics="identifier"
fieldType="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.
Meyer, et al. Expires January 17, 2005 [Page 54]
Internet-Draft IPFIX Information Model July 2004
</reference>
</field>
<field name="ipv6OptionHeaders" dataType="unsigned32"
dataTypeSemantics="flags"
fieldType="64" applicability="all" status="current">
<description>
<paragraph>
IPv6 options in the 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="partialMPLSLabelStackEntry1" dataType="unsigned32"
fieldType="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>
<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="partialMPLSLabelStackEntry2" dataType="unsigned32"
fieldType="71" applicability="all" status="current">
Meyer, et al. Expires January 17, 2005 [Page 55]
Internet-Draft IPFIX Information Model July 2004
<description>
<paragraph>
The label, exp and s fields from the LSE that was pushed
immediately before the LSE that would be reported by
partialMplsLse1. See the definition of partialMplsLse1 for
further details.
</paragraph>
</description>
<reference>
See RFC 3032.
</reference>
</field>
<field name="partialMPLSLabelStackEntry3" dataType="unsigned32"
fieldType="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
partialMplsLse2. See the definition of partialMplsLse1 for
further details.
</paragraph>
</description>
<reference>
See RFC 3032.
</reference>
</field>
<field name="partialMPLSLabelStackEntry4" dataType="unsigned32"
fieldType="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
partialMplsLse3. See the definition of partialMplsLse1 for
further details.
</paragraph>
</description>
<reference>
See RFC 3032.
</reference>
</field>
<field name="partialMPLSLabelStackEntry5" dataType="unsigned32"
fieldType="74" applicability="all" status="current">
<description>
<paragraph>
The label, exp and s fields from the LSE that was pushed
Meyer, et al. Expires January 17, 2005 [Page 56]
Internet-Draft IPFIX Information Model July 2004
immediately before the LSE that would be reported by
partialMplsLse4. See the definition of partialMplsLse1 for
further details.
</paragraph>
</description>
<reference>
See RFC 3032.
</reference>
</field>
<field name="partialMPLSLabelStackEntry6" dataType="unsigned32"
fieldType="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
partialMplsLse5. See the definition of partialMplsLse1 for
further details.
</paragraph>
</description>
<reference>
See RFC 3032.
</reference>
</field>
<field name="partialMPLSLabelStackEntry7" dataType="unsigned32"
fieldType="76" applicability="all" status="current">
<description>
<paragraph>
The label, exp and s fields from the LSE that was pushed
immediately before the LSE that would be reported by
partialMplsLse6. See the definition of partialMplsLse1 for
further details.
</paragraph>
</description>
<reference>
See RFC 3032.
</reference>
</field>
<field name="partialMPLSLabelStackEntry8" dataType="unsigned32"
fieldType="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
partialMplsLse7. See the definition of partialMplsLse1 for
further details.
Meyer, et al. Expires January 17, 2005 [Page 57]
Internet-Draft IPFIX Information Model July 2004
</paragraph>
</description>
<reference>
See RFC 3032.
</reference>
</field>
<field name="partialMPLSLabelStackEntry9" dataType="unsigned32"
fieldType="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
partialMplsLse8. See the definition of partialMplsLse1 for
further details.
</paragraph>
</description>
<reference>
See RFC 3032.
</reference>
</field>
<field name="partialMPLSLabelStackEntry10" dataType="unsigned32"
fieldType="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
partialMplsLse9. See the definition of partialMplsLse1 for
further details.
</paragraph>
</description>
<reference>
See RFC 3032.
</reference>
</field>
<field name="runningOctetCounter" dataType="unsigned64"
dataTypeSemantics="runningCounter"
fieldType="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>
Meyer, et al. Expires January 17, 2005 [Page 58]
Internet-Draft IPFIX Information Model July 2004
<units>octets</units>
</field>
<field name="runningPacketCounter" dataType="unsigned64"
dataTypeSemantics="runningCounter"
fieldType="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="bgpNextHopAsNumber" dataType="unsigned16"
dataTypeSemantics="identifier"
fieldType="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="ipNextHopAsNumber" dataType="unsigned16"
dataTypeSemantics="identifier"
fieldType="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="exporterAddressV4" dataType="ipv4Address"
Meyer, et al. Expires January 17, 2005 [Page 59]
Internet-Draft IPFIX Information Model July 2004
dataTypeSemantics="identifier"
fieldType="130" applicability="all" status="current">
<description>
<paragraph>
The IPv4 address of the 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="exporterAddressV6" dataType="ipv6Address"
dataTypeSemantics="identifier"
fieldType="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="droppedOctetDeltaCount" dataType="unsigned64"
dataTypeSemantics="deltaCounter"
fieldType="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="droppedPacketDeltaCount" dataType="unsigned64"
dataTypeSemantics="deltaCounter"
fieldType="133" 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="droppedOctetTotalCount" dataType="unsigned64"
Meyer, et al. Expires January 17, 2005 [Page 60]
Internet-Draft IPFIX Information Model July 2004
dataTypeSemantics="runningCounter"
fieldType="134" applicability="data" status="current">
<description>
<paragraph>
The number of octets in packets of this flow dropped by packet treatment.
</paragraph>
</description>
<units>octets</units>
</field>
<field name="droppedPacketTotalCount" dataType="unsigned64"
dataTypeSemantics="runningCounter"
fieldType="135" applicability="data" status="current">
<description>
<paragraph>
The number of packets of this flow dropped by packet treatment.
</paragraph>
</description>
<units>packets</units>
</field>
<field name="flowEndReason" dataType="octet"
fieldType="136" applicability="data" status="current">
<description>
<paragraph>
The reason for flow termination.
<list>
<item>idle timeout</item>
<item>end of flow detected (e.g. TCP FIN)</item>
<item>forced end</item>
<item>cache full</item>
</list>
EDITORS' NOTE: This needs to be defined as an
enumerated range.
</paragraph>
</description>
</field>
<field name="classOfServiceV6" dataType="octet"
fieldType="135" applicability="data" status="current">
<description>
<paragraph>
The value of the IPv6 traffic class field observed
for packets of this flow.
</paragraph>
</description>
<reference>
See RFC 2460 for the definition of the IPv6 traffic class field.
Meyer, et al. Expires January 17, 2005 [Page 61]
Internet-Draft IPFIX Information Model July 2004
</reference>
</field>
</fieldDefinitions>
Meyer, et al. Expires January 17, 2005 [Page 62]
Internet-Draft IPFIX Information Model July 2004
Appendix B. Formal Specification of Abstract Data Types
This appendix containfs a formal description of the abstract data
types to be used for IPFIX fields and a formal description of the
template used for defining IPFIX fields. Note that this appendix is
of informational nature, while the text in sections 2 and 3 generated
from this appendix is normative.
<?xml version="1.0" encoding="UTF-8"?>
<schema elementFormDefault="qualified"
targetNamespace="http://www.ietf.org/ipfix"
xmlns:ipfix="http://www.ietf.org/ipfix">
<simpleType name="dataType">
<restriction base="string">
<enumeration value="octet">
<annotation>
<documentation>The type "unsignedByte" represents a
non-negative integer value in the range of 0 to 255.
</documentation>
</annotation>
</enumeration>
<enumeration value="unsigned16">
<annotation>
<documentation>The type "unsigned16" represents a
non-negative integer value in the range of 0 to 65535.
</documentation>
</annotation>
</enumeration>
<enumeration value="unsigned32">
<annotation>
<documentation>The type "unsigned32" represents a
non-negative integer value in the range of 0 to
4294967295.
</documentation>
</annotation>
</enumeration>
<enumeration value="unsigned64">
<annotation>
<documentation>The type "unsigned64" represents a
non-negative integer value in the range of 0 to
18446744073709551615.
</documentation>
</annotation>
Meyer, et al. Expires January 17, 2005 [Page 63]
Internet-Draft IPFIX Information Model July 2004
</enumeration>
<enumeration value="float32">
<annotation>
<documentation>The type "float32" corresponds to an IEEE
single-precision 32-bit floating point type.
</documentation>
</annotation>
</enumeration>
<enumeration value="boolean">
<annotation>
<documentation>The type "boolean" represents a binary
value.
</documentation>
</annotation>
</enumeration>
<enumeration value="octetArray">
<annotation>
<documentation>The type "octetArray" represents a finite
length string of octets.
</documentation>
</annotation>
</enumeration>
<enumeration value="string">
<annotation>
<documentation>
The type "string" represents a finite length string
of valid characters from the Unicode character
encoding set. Unicode allows for ASCII and many
other international character sets to be used.
It is expected that strings will be encoded in UTF-8
format, which is identical in encoding for USASCII
characters, but also accomodates other Unicode
multibyte characters.
</documentation>
</annotation>
</enumeration>
<enumeration value="dateTimeSeconds">
<annotation>
<documentation>
The type "dateTimeSeconds" represents a time value
having a precision of seconds and normalized to the
GMT timezone. Such types are in common use on many
operating systems and have the advantage that they
Meyer, et al. Expires January 17, 2005 [Page 64]
Internet-Draft IPFIX Information Model July 2004
can be stored in 32-bit integers.
</documentation>
</annotation>
</enumeration>
<enumeration value="dataTimeMicroSeconds">
<annotation>
<documentation>The type "dateTimeSeconds" represents a
time value having a precision of microseconds and
normalized to the GMT timezone.
</documentation>
</annotation>
</enumeration>
<enumeration value="ipv4Address">
<annotation>
<documentation>The type "ipv4Addr" represents a value of
an IPv4 address. These addresses are typically stored
as 32-bit integers.
</documentation>
</annotation>
</enumeration>
<enumeration value="ipv6Address">
<annotation>
<documentation>The type "ipv6Addr" represents a value
of an IPv6 address.
</documentation>
</annotation>
</enumeration>
</restriction>
</simpleType>
<simpleType name="dataTypeSemantics">
<restriction base="string">
<enumeration value="quantity">
<annotation>
<documentation>
A quantity value represents a discrete
measured value pertaining to the record. This is
distinguished from counters which represent an ongoing
measured value whose "odometer" reading is captured as
part of a given record. If no semantic qualifier is
given, the integral fields should behave as a quantity.
</documentation>
</annotation>
</enumeration>
Meyer, et al. Expires January 17, 2005 [Page 65]
Internet-Draft IPFIX Information Model July 2004
<enumeration value="counter">
<annotation>
<documentation>
A measurement which is ongoing from the perspective
of the exporter. Basically the same semantics as
counters in SNMP. Counters are unsigned and wrap back
to zero after reaching the limit of the type. E.g. an
unsigned64 with counter semantics will continue to
increment until reaching the value of 2**64 - 1.
At this point the next increment will wrap its value
to zero and continue counting from zero.
</documentation>
</annotation>
</enumeration>
<enumeration value="identifier">
<annotation>
<documentation>
An integral value which serves as an identifier.
Specifically mathematical operations on two
identifiers (aside from the equality operation) are
meaningless. E.g. Autonomous System Id 1 * Autonomous
System Id 2 is meaningless.
</documentation>
</annotation>
</enumeration>
<enumeration value="flags">
<annotation>
<documentation>
An integral value which actually represents a set of
bit fields. Logical operations are appropriate on
such values, but not other mathematical operations.
Flags should always be of an unsigned type.
</documentation>
</annotation>
</enumeration>
</restriction>
</simpleType>
<simpleType name="applicability">
<restriction base="string">
<enumeration value="data">
<annotation>
<documentation>
Used for fields that are applicable to flow records
only.
</documentation>
Meyer, et al. Expires January 17, 2005 [Page 66]
Internet-Draft IPFIX Information Model July 2004
</annotation>
</enumeration>
<enumeration value="option">
<annotation>
<documentation>
Used for fields that are applicable to option records
only.
</documentation>
</annotation>
</enumeration>
<enumeration value="all">
<annotation>
<documentation>
Used for fields that are applicable to flow records
as well as to option records.
</documentation>
</annotation>
</enumeration>
</restriction>
</simpleType>
<simpleType name="status">
<restriction base="string">
<enumeration value="current">
<annotation>
<documentation>
Indicates that the field definition is that the
definition is current and valid.
</documentation>
</annotation>
</enumeration>
<enumeration value="deprecated">
<annotation>
<documentation>
Indicates that the field definition is obsolete, but
it permits new/continued implementation in order to
foster interoperability with older/existing
implementations.
</documentation>
</annotation>
</enumeration>
<enumeration value="obsolete">
<annotation>
<documentation>
Meyer, et al. Expires January 17, 2005 [Page 67]
Internet-Draft IPFIX Information Model July 2004
Indicates that the field definition is obsolete and
should not be implemented and/or can be removed if
previously implemented.
</documentation>
</annotation>
</enumeration>
</restriction>
</simpleType>
<simpleType name="enumRange">
<restriction base="string"/>
</simpleType>
<simpleType name="range">
<restriction base="string"/>
</simpleType>
<complexType name="descriptionList">
<sequence>
<element maxOccurs="unbounded" minOccurs="1"
name="item" type="string">
<annotation>
<documentation>to be done ...</documentation>
</annotation>
</element>
</sequence>
</complexType>
<complexType name="text" mixed="true">
<sequence>
<element maxOccurs="unbounded" minOccurs="0"
name="paragraph" type="string">
<annotation>
<documentation>to be done ...</documentation>
</annotation>
</element>
<element maxOccurs="unbounded" minOccurs="0"
name="list" type="ipfix:descriptionList">
<annotation>
<documentation>to be done ...</documentation>
</annotation>
</element>
</sequence>
</complexType>
<element name="fieldDefinitions">
<complexType>
<sequence>
Meyer, et al. Expires January 17, 2005 [Page 68]
Internet-Draft IPFIX Information Model July 2004
<element maxOccurs="unbounded" minOccurs="1" name="field">
<complexType>
<sequence>
<element maxOccurs="1" minOccurs="1" name="description"
type="ipfix:text">
<annotation>
<documentation>
The semantics of this information element.
Describes how this field is derived from the
flow or other information available to the
observer.
</documentation>
</annotation>
</element>
<element maxOccurs="1" minOccurs="0" name="usage"
type="ipfix:text">
<annotation>
<documentation>to be done ...</documentation>
</annotation>
</element>
<element maxOccurs="1" minOccurs="0" name="units"
type="string">
<annotation>
<documentation>
If the field is a measure of some kind, the
units identify what the measure is.
</documentation>
</annotation>
</element>
<element maxOccurs="1" minOccurs="0" name="reference"
type="ipfix:text">
<annotation>
<documentation>
Identifies additional specifications which more
precisely define this item or provide additional
context for its use.
</documentation>
</annotation>
</element>
<element maxOccurs="1" minOccurs="0"
name="enumeratedRange" type="ipfix:enumRange">
<annotation>
<documentation>
Some items may have a specific set of numeric
Meyer, et al. Expires January 17, 2005 [Page 69]
Internet-Draft IPFIX Information Model July 2004
identifiers associated with a set of discrete
values this element may take. The meaning of
each discrete value and a human readable name
should be assigned.
</documentation>
</annotation>
</element>
<element maxOccurs="1" minOccurs="0" name="range"
type="ipfix:range">
<annotation>
<documentation>
Some elements may only be able to take on a
restricted set of values which can be
expressed as a range (e.g. 0 through 511
inclusive). If this is the case, the valid
inclusive range should be specified.
</documentation>
</annotation>
</element>
</sequence>
<attribute name="name" type="string" use="required">
<annotation>
<documentation>
A unique and meaningful name for the field. The
preferred spelling for the name is to use mixed
case if the name is compound, with an initial
lower case letter. (E.g. "sourceIpAddress").
</documentation>
</annotation>
</attribute>
<attribute name="dataType" type="ipfix:dataType"
use="required">
<annotation>
<documentation>
One of the types listed in the "Type Space"
section. The type space for attributes is
constrained to facilitate implementation.
The existing type space does however encompass
most basic types used in modern programming
languages, as well as some derived types
(such as IPAddress) which are common to this
domain and useful to distinguish.
</documentation>
</annotation>
</attribute>
Meyer, et al. Expires January 17, 2005 [Page 70]
Internet-Draft IPFIX Information Model July 2004
<attribute name="dataTypeSemantics"
type="ipfix:dataTypeSemantics" use="optional">
<annotation>
<documentation>
The integral types may be qualified by additional
semantic details. Qualifying the fields as
'quantity', 'counter', 'identifier' or 'flags'.
</documentation>
</annotation>
</attribute>
<attribute name="fieldType" type="nonNegativeInteger"
use="required">
<annotation>
<documentation>
A numeric identifier administered by IANA.
This is used for compact identification of an
information item when encoding templates in the
protocol.
</documentation>
</annotation>
</attribute>
<attribute name="vendorId" type="nonNegativeInteger"
use="optional">
<annotation>
<documentation>
When extension is done outside of the scope of
the IANA IPFIX fieldId range, a vendorId MUST
be provided. This identifier is based on IANA
assigned enterprise identifiers.
</documentation>
</annotation>
</attribute>
<attribute name="applicability"
type="ipfix:applicability" use="required">
<annotation>
<documentation>to be done ...</documentation>
</annotation>
</attribute>
<attribute name="status" type="ipfix:status"
use="required">
<annotation>
<documentation>to be done ...</documentation>
</annotation>
</attribute>
Meyer, et al. Expires January 17, 2005 [Page 71]
Internet-Draft IPFIX Information Model July 2004
</complexType>
</element>
</sequence>
</complexType>
<unique name="fieldTypeUnique">
<selector xpath="field"/>
<field xpath="fieldType"/>
</unique>
</element>
</schema>
Meyer, et al. Expires January 17, 2005 [Page 72]
Internet-Draft IPFIX Information Model July 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Meyer, et al. Expires January 17, 2005 [Page 73]
Internet-Draft IPFIX Information Model July 2004
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Meyer, et al. Expires January 17, 2005 [Page 74]
