Network Working Group P. Calato
Internet-Draft Riverstone Networks Inc
Expires: August 16, 2004 J. Meyer
PayPal
J. Quittek
NEC Europe Ltd.
February 16, 2004
Information Model for IP Flow Information Export
draft-ietf-ipfix-info-03
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 August 16, 2004.
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.
Calato, et al. Expires August 16, 2004 [Page 1]
Internet-Draft IPFIX Information Model February 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Properties of IPFIX Protocol Fields . . . . . . . . . . . . 5
3. Type Space . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1 octet . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 unsigned16 . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3 unsigned32 . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4 unsigned64 . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.5 float32 . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.6 boolean . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.7 octetArray . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.8 string . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.9 dateTimeSeconds . . . . . . . . . . . . . . . . . . . . . . 8
3.10 dataTimeMicroSeconds . . . . . . . . . . . . . . . . . . . . 8
3.11 ipv4Address . . . . . . . . . . . . . . . . . . . . . . . . 8
3.12 ipv6Address . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Flow Attributes . . . . . . . . . . . . . . . . . . . . . . 9
4.1 octetCount . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2 packetCount . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3 flowCount . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.4 protocolIdentifier . . . . . . . . . . . . . . . . . . . . . 9
4.5 classOfService . . . . . . . . . . . . . . . . . . . . . . . 10
4.6 tcpControlBits . . . . . . . . . . . . . . . . . . . . . . . 11
4.7 sourcePort . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.8 sourceAddressV4 . . . . . . . . . . . . . . . . . . . . . . 11
4.9 sourceMask . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.10 ingressInterface . . . . . . . . . . . . . . . . . . . . . . 12
4.11 destinationPort . . . . . . . . . . . . . . . . . . . . . . 12
4.12 destinationAddressV4 . . . . . . . . . . . . . . . . . . . . 13
4.13 destinationMask . . . . . . . . . . . . . . . . . . . . . . 13
4.14 egressInterface . . . . . . . . . . . . . . . . . . . . . . 13
4.15 ipNextHopAddressV4 . . . . . . . . . . . . . . . . . . . . . 13
4.16 sourceAsNumber . . . . . . . . . . . . . . . . . . . . . . . 14
4.17 destinationAsNumber . . . . . . . . . . . . . . . . . . . . 14
4.18 bgpNextHopAddressV4 . . . . . . . . . . . . . . . . . . . . 14
4.19 mcPacketsSent . . . . . . . . . . . . . . . . . . . . . . . 15
4.20 mcOctetsSent . . . . . . . . . . . . . . . . . . . . . . . . 15
4.21 flowEndTime . . . . . . . . . . . . . . . . . . . . . . . . 15
4.22 flowCreationTime . . . . . . . . . . . . . . . . . . . . . . 15
4.23 sourceAddressV6 . . . . . . . . . . . . . . . . . . . . . . 15
4.24 destinationAddressV6 . . . . . . . . . . . . . . . . . . . . 15
4.25 anotherSourceMask . . . . . . . . . . . . . . . . . . . . . 16
4.26 destinationMask . . . . . . . . . . . . . . . . . . . . . . 16
4.27 flowLabel . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.28 icmpTypeCode . . . . . . . . . . . . . . . . . . . . . . . . 17
4.29 igmpType . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.30 samplingInterval . . . . . . . . . . . . . . . . . . . . . . 17
Calato, et al. Expires August 16, 2004 [Page 2]
Internet-Draft IPFIX Information Model February 2004
4.31 samplingAlgorithm . . . . . . . . . . . . . . . . . . . . . 17
4.32 flowReportingInterval . . . . . . . . . . . . . . . . . . . 18
4.33 flowIdleTimeout . . . . . . . . . . . . . . . . . . . . . . 18
4.34 exportedOctetCount . . . . . . . . . . . . . . . . . . . . . 18
4.35 exportedPacketCount . . . . . . . . . . . . . . . . . . . . 18
4.36 exportedFlowCount . . . . . . . . . . . . . . . . . . . . . 19
4.37 ipVersion . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.38 ipNextHopAddressV6 . . . . . . . . . . . . . . . . . . . . . 19
4.39 bgpNextHopAddressV6 . . . . . . . . . . . . . . . . . . . . 20
4.40 bgpNextHopAsNumber . . . . . . . . . . . . . . . . . . . . . 20
4.41 ipNextHopAsNumber . . . . . . . . . . . . . . . . . . . . . 20
4.42 exporterAddressV4 . . . . . . . . . . . . . . . . . . . . . 20
4.43 exporterAddressV6 . . . . . . . . . . . . . . . . . . . . . 21
4.44 droppedOctetCount . . . . . . . . . . . . . . . . . . . . . 21
4.45 droppedPacketCount . . . . . . . . . . . . . . . . . . . . . 21
4.46 flowEndReason . . . . . . . . . . . . . . . . . . . . . . . 21
5. Extending the Information Model . . . . . . . . . . . . . . 23
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 24
7. Security Considerations . . . . . . . . . . . . . . . . . . 25
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
Normative Reference . . . . . . . . . . . . . . . . . . . . 27
Informative Reference . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 29
A. Formal Specification of IPFIX Fields . . . . . . . . . . . . 30
B. Formal Specification of Abstract Data Types . . . . . . . . 43
Intellectual Property and Copyright Statements . . . . . . . 53
Calato, et al. Expires August 16, 2004 [Page 3]
Internet-Draft IPFIX Information Model February 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.
Calato, et al. Expires August 16, 2004 [Page 4]
Internet-Draft IPFIX Information Model February 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 ...
Calato, et al. Expires August 16, 2004 [Page 5]
Internet-Draft IPFIX Information Model February 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.
Calato, et al. Expires August 16, 2004 [Page 6]
Internet-Draft IPFIX Information Model February 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.
Calato, et al. Expires August 16, 2004 [Page 7]
Internet-Draft IPFIX Information Model February 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.
Calato, et al. Expires August 16, 2004 [Page 8]
Internet-Draft IPFIX Information Model February 2004
4. Flow Attributes
4.1 octetCount
Description: The number of observed octets.
Abstract Data Type: unsigned64
Field Id: 1
Units: octets
4.2 packetCount
Description: The number of observed packets.
Abstract Data Type: unsigned64
Field Id: 2
Units: packets
4.3 flowCount
Description: The number of (aggregated) flows.
Abstract Data Type: unsigned64
Field Id: 3
Units: flows
4.4 protocolIdentifier
Description:
The protocol number that 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.
Abstract Data Type: octet
Data Type Semantics: identifier
Calato, et al. Expires August 16, 2004 [Page 9]
Internet-Draft IPFIX Information Model February 2004
Field Id: 4
Reference:
See RFC 791 for the specification of the IPv4 protocol field. See
RFC 1883 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 classOfService
Description:
The class of service.
The definition of classOfService is dependent on the protocol
being observed. Those considered here are:
* For IPv4 packets the class of service is given by the value of
the type of service field in the IPv4 packet header.
* For IPv6 packets the class of service is given by the value of
the traffic class field in the IPv6 packet header.
* For MPLS the class of service is given by the value of the
experimental use (Exp) field in label stack entries. The Exp
field has a length of 3 bits. These are mapped to the three
least valued bits of the classOfService octet. All other bits
of the octet are set to zero.
* For VLAN the class of service is given by the value of the type
of the user_priority field as defined in IEEE802.1q[802.1q] and
IEEE 802.1p[802.1p].
EDITORS' NOTE: THIS NEEDS FURTHER WORK
Abstract Data Type: octet
Data Type Semantics: identifier
Field Id: 5
Reference:
See RFC 791 for the definition of the IPv4 TOS field. See RFC 2460
for the definition of the IPv6 traffic class field. See RFC 3032
for the definition of the Exp field in label stack entries. See
Calato, et al. Expires August 16, 2004 [Page 10]
Internet-Draft IPFIX Information Model February 2004
IEEE802.1q and IEEE 802.1p for the definition of the VLAN
user_priority field.
4.6 tcpControlBits
Description:
The TCP control bits seen for this flow. Note that a 0 value for
each bit only indicates that the flag was not detected (i.e. it
may have occurred but was not detected by the reporting CCE).
EDITORS' NOTE: THIS NEEDS FURTHER WORK. The bit mapping needs to
be specified.
Abstract Data Type: octet
Data Type Semantics: flags
Field Id: 6
Reference: See RFC 793 for a definiton of the TCP control bits in the
TCP header.
4.7 sourcePort
Description: A source port number in the UDP or TCP header,
respectively.
Abstract Data Type: unsigned16
Data Type Semantics: identifier
Field Id: 7
Reference:
See RFC 768 for the definiton of the UDP source port field. See
RFC 793 for the definiton of the TCP source port field. Additional
information on defined UDP and TCP port numbers can be found at
http://www.iana.org/assignments/port-numbers.
4.8 sourceAddressV4
Description: The IPv4 source address in the IPv4 packet header.
Abstract Data Type: ipv4Address
Calato, et al. Expires August 16, 2004 [Page 11]
Internet-Draft IPFIX Information Model February 2004
Field Id: 8
Reference: See RFC 791 for the definition of the IPv4 source address
field.
4.9 sourceMask
Description: The number of contiguous bits that are relevant in the
source address field of the IP packet header (i.e. the subnet mask
in slash notation).
Abstract Data Type: octet
Field Id: 9
Units: bits
4.10 ingressInterface
Description: The index of the IP interface (ifIndex) where packets of
a flow are being received.
Abstract Data Type: unsigned32
Data Type Semantics: identifier
Field Id: 10
Reference: See RFC 2863 for the definition of the ifIndex object.
4.11 destinationPort
Description: A destination port number in the UDP or TCP header,
respectively.
Abstract Data Type: unsigned16
Data Type Semantics: identifier
Field Id: 11
Reference:
See RFC 768 for the definiton of the UDP destination port field.
See RFC 793 for the definiton of the TCP destination port field.
Additional information on defined UDP and TCP port numbers can be
Calato, et al. Expires August 16, 2004 [Page 12]
Internet-Draft IPFIX Information Model February 2004
found at http://www.iana.org/assignments/port-numbers.
4.12 destinationAddressV4
Description: The IPv4 destination address in the IPv4 packet header.
Abstract Data Type: ipv4Address
Field Id: 12
Reference: See RFC 791 for the definition of the IPv4 destination
address field.
4.13 destinationMask
Description:
The number of contiguous bits that are relevant in the destination
address field of the IP packet header (i.e. the subnet mask in
slash notation).
Abstract Data Type: octet
Field Id: 13
Units: bits
4.14 egressInterface
Description: The index of the IP interface (ifIndex) where packets of
a 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 are
forwarded.
Calato, et al. Expires August 16, 2004 [Page 13]
Internet-Draft IPFIX Information Model February 2004
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.
Abstract Data Type: unsigned16
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.
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
are forwarded.
Abstract Data Type: ipv4Address
Data Type Semantics: identifier
Field Id: 18
Reference: See RFC 1771 for a description of BGB-4 and see RFC 1930 a
definition of the AS number.
Calato, et al. Expires August 16, 2004 [Page 14]
Internet-Draft IPFIX Information Model February 2004
4.19 mcPacketsSent
Description: The number of sent multicast packets.
Abstract Data Type: unsigned64
Field Id: 19
Units: packets
4.20 mcOctetsSent
Description: The number of sent multicast octets.
Abstract Data Type: unsigned64
Field Id: 20
Units: octets
4.21 flowEndTime
Description: The timestamp of the last packet of a flow.
Abstract Data Type: dateTimeSeconds
Field Id: 21
4.22 flowCreationTime
Description: The timestamp of the first packet of a flow.
Abstract Data Type: dateTimeSeconds
Field Id: 22
4.23 sourceAddressV6
Description: IPv6 source address taken from the packet header.
Abstract Data Type: ipv6Address
Field Id: 27
4.24 destinationAddressV6
Calato, et al. Expires August 16, 2004 [Page 15]
Internet-Draft IPFIX Information Model February 2004
Description: IPv6 destination address taken from the packet header.
Abstract Data Type: ipv6Address
Field Id: 28
4.25 anotherSourceMask
Description:
The number of contiguous bits that are relevant in the source
address field of the IP packet header (i.e. the subnet mask in
slash notation). This redundant field has the same semantics as
field 9.
Abstract Data Type: octet
Field Id: 29
Units: bits
4.26 destinationMask
Description:
The number of contiguous bits that are relevant in the destination
address field of the IP packet header (i.e. the subnet mask in
slash notation). This redundant field has the same semantics as
field 13.
Abstract Data Type: octet
Field Id: 30
Units: bits
4.27 flowLabel
Description: The Flow Label of the IPv6 packet header.
Abstract Data Type: unsigned32
Field Id: 31
Reference: See RFC 2460 for a definition of the flow label field in
the IPv6 packet header.
Calato, et al. Expires August 16, 2004 [Page 16]
Internet-Draft IPFIX Information Model February 2004
4.28 icmpTypeCode
Description: Type and Code of the ICMP message.
Abstract Data Type: unsigned16
Field Id: 32
Reference: See RFC 792 for a definition of the ICMP type and code
fields.
4.29 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.30 samplingInterval
Description:
Number of packets received as a ratio of number of packets
sampled. For example a value of 100 would mean that one packet in
100 was sampled. EDITORS' NOTE: This will be replaced by the
PSAMP INFO MODEL
Abstract Data Type: unsigned32
Field Id: 34
Units: packets
4.31 samplingAlgorithm
Description:
The following sampling algorithms are defined:
* 1 Deterministic sampling
* 2 Random Sampling
Calato, et al. Expires August 16, 2004 [Page 17]
Internet-Draft IPFIX Information Model February 2004
* 3 Time-based sampling
EDITORS' NOTE: This will be replaced by the PSAMP INFO MODEL
Abstract Data Type: octet
Data Type Semantics: identifier
Field Id: 35
4.32 flowReportingInterval
Description: Interval between reports for an active flow.
Abstract Data Type: unsigned16
Field Id: 36
Units: seconds
4.33 flowIdleTimeout
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.34 exportedOctetCount
Description: The number of octets reported by the exporting process.
Abstract Data Type: unsigned64
Field Id: 40
Units: octets
4.35 exportedPacketCount
Calato, et al. Expires August 16, 2004 [Page 18]
Internet-Draft IPFIX Information Model February 2004
Description: The number of packets reported by the exporting process.
Abstract Data Type: unsigned64
Field Id: 41
Units: packets
4.36 exportedFlowCount
Description: The number of flows reported by the exporting process.
Abstract Data Type: unsigned64
Field Id: 42
Units: flows
4.37 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.38 ipNextHopAddressV6
Description: The IPv6 address of the next IP hop to which packets are
forwarded.
Abstract Data Type: ipv6Address
Field Id: 62
Calato, et al. Expires August 16, 2004 [Page 19]
Internet-Draft IPFIX Information Model February 2004
4.39 bgpNextHopAddressV6
Description: The IPv6 address of the next BGP hop to which packets
are forwarded.
Abstract Data Type: ipv6Address
Data Type Semantics: identifier
Field Id: 63
Reference: See RFC 1771 for a description of BGB-4 and see RFC 1930 a
definition of the AS number.
4.40 bgpNextHopAsNumber
Description: The autonomous system (AS) number of the next BGP hop
the packets are sent to.
Abstract Data Type: unsigned16
Data Type Semantics: identifier
Field Id: 80
Reference: See RFC 1771 for a description of BGB-4 and see RFC 1930 a
definition of the AS number.
4.41 ipNextHopAsNumber
Description: The autonomous system (AS) number of the next IP hop the
packets are sent to.
Abstract Data Type: unsigned16
Data Type Semantics: identifier
Field Id: 81
Reference: See RFC 1771 for a description of BGB-4 and see RFC 1930 a
definition of the AS number.
4.42 exporterAddressV4
Calato, et al. Expires August 16, 2004 [Page 20]
Internet-Draft IPFIX Information Model February 2004
Description:
The IPv4 address of the flow exporter. This is used by the
collecter 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
Field Id: 82
4.43 exporterAddressV6
Description:
The IPv6 address of the flow exporter. This is used by the
collecter 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
Field Id: 83
4.44 droppedOctetCount
Description: The number of octets dropped.
Abstract Data Type: unsigned64
Field Id: 84
Units: octets
4.45 droppedPacketCount
Description: The number of packets dropped.
Abstract Data Type: unsigned64
Field Id: 84
Units: packets
4.46 flowEndReason
Description: The number of packets dropped.
* idle timeout
Calato, et al. Expires August 16, 2004 [Page 21]
Internet-Draft IPFIX Information Model February 2004
* end of flow detected (e.g. TCP FIN)
* forced end
* cache full
EDITORS' NOTE: This needs to be defined as an enumerated range.
Abstract Data Type: octet
Field Id: 84
Calato, et al. Expires August 16, 2004 [Page 22]
Internet-Draft IPFIX Information Model February 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.
Calato, et al. Expires August 16, 2004 [Page 23]
Internet-Draft IPFIX Information Model February 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.
Calato, et al. Expires August 16, 2004 [Page 24]
Internet-Draft IPFIX Information Model February 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.
Calato, et al. Expires August 16, 2004 [Page 25]
Internet-Draft IPFIX Information Model February 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.
Calato, et al. Expires August 16, 2004 [Page 26]
Internet-Draft IPFIX Information Model February 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>.
Calato, et al. Expires August 16, 2004 [Page 27]
Internet-Draft IPFIX Information Model February 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>.
Calato, et al. Expires August 16, 2004 [Page 28]
Internet-Draft IPFIX Information Model February 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
Paul Calato
Riverstone Networks Inc
5200 Great America Parkway
Santa Clara, CA 95054
US
Phone: +1 603 557-6913
EMail: calato@riverstonenet.com
URI: http://www.riverstonenet.com
Jeff Meyer
PayPal
2211 N. First St.
San Jose, CA 95131-2021
US
Phone: +1 408 976-9149
EMail: jemeyer@paypal.com
URI: http://www.paypal.com
Juergen Quittek
NEC Europe Ltd.
Kurfuersten-Anlage 36
Heidelberg 69115
Germany
Phone: +49 6221 90511-15
EMail: quittek@netlab.nec.de
URI: http://www.netlab.nec.de/
Calato, et al. Expires August 16, 2004 [Page 29]
Internet-Draft IPFIX Information Model February 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="octetCount" dataType="unsigned64"
fieldType="1" applicability="data" status="current">
<description>
The number of observed octets.
</description>
<units>octets</units>
</field>
<field name="packetCount" dataType="unsigned64"
fieldType="2" applicability="data" status="current">
<description>
The number of observed packets.
</description>
<units>packets</units>
</field>
<field name="flowCount" dataType="unsigned64"
Calato, et al. Expires August 16, 2004 [Page 30]
Internet-Draft IPFIX Information Model February 2004
fieldType="3" applicability="data" status="current">
<description>
The number of (aggregated) flows.
</description>
<units>flows</units>
</field>
<field name="protocolIdentifier" dataType="octet"
dataTypeSemantics="identifier"
fieldType="4" applicability="all" status="current">
<description>
<paragraph>
The protocol number that 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.</paragraph>
</description>
<reference>
<paragraph>
See RFC 791 for the specification of the IPv4 protocol field.
See RFC 1883 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="classOfService" dataType="octet"
dataTypeSemantics="identifier"
fieldType="5" applicability="all" status="current">
<description>
<paragraph>
The class of service.
</paragraph>
<paragraph>
The definition of classOfService is dependent on the protocol
being observed. Those considered here are:
</paragraph>
<list>
<item>For IPv4 packets the class of service is given by the
value of the type of service field in the IPv4 packet
header.</item>
<item>For IPv6 packets the class of service is given by the
Calato, et al. Expires August 16, 2004 [Page 31]
Internet-Draft IPFIX Information Model February 2004
value of the traffic class field in the IPv6 packet
header.</item>
<item>For MPLS the class of service is given by the value of
the experimental use (Exp) field in label stack entries.
The Exp field has a length of 3 bits. These are mapped
to the three least valued bits of the classOfService
octet. All other bits of the octet are set to
zero.</item>
<item>For VLAN the class of service is given by the value
of the type of the user_priority field as defined
in IEEE802.1q[802.1q] and IEEE 802.1p[802.1p].</item>
</list>
EDITORS' NOTE: THIS NEEDS FURTHER WORK
</description>
<reference>
<paragraph>
See RFC 791 for the definition of the IPv4 TOS field.
See RFC 2460 for the definition of the IPv6 traffic class
field.
See RFC 3032 for the definition of the Exp field in label stack
entries.
See IEEE802.1q and IEEE 802.1p for the definition of the VLAN
user_priority field.
</paragraph>
</reference>
</field>
<field name="tcpControlBits" dataType="octet"
dataTypeSemantics="flags"
fieldType="6" applicability="all" status="current">
<description>
<paragraph>
The TCP control bits seen for this flow. Note that a 0 value
for each bit only indicates that the flag was not detected
(i.e. it may have occurred but was not detected by the
reporting CCE).
</paragraph>
EDITORS' NOTE: THIS NEEDS FURTHER WORK.
The bit mapping needs to be specified.
</description>
<reference>See RFC 793 for a definiton of the TCP control bits
in the TCP header.</reference>
</field>
<field name="sourcePort" dataType="unsigned16"
dataTypeSemantics="identifier"
Calato, et al. Expires August 16, 2004 [Page 32]
Internet-Draft IPFIX Information Model February 2004
fieldType="7" applicability="all" status="current">
<description>
A source port number in the UDP or TCP header, respectively.
</description>
<reference>
<paragraph>
See RFC 768 for the definiton of the UDP source port field.
See RFC 793 for the definiton of the TCP source port field.
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>
The IPv4 source address in the IPv4 packet header.
</description>
<reference>
See RFC 791 for the definition of the IPv4 source address
field.
</reference>
</field>
<field name="sourceMask" dataType="octet"
fieldType="9" applicability="option" status="current">
<description>
The number of contiguous bits that are relevant in the source
address field of the IP packet header
(i.e. the subnet mask in slash notation).
</description>
<units>bits</units>
</field>
<field name="ingressInterface" dataType="unsigned32"
dataTypeSemantics="identifier"
fieldType="10" applicability="all" status="current">
<description>
The index of the IP interface (ifIndex) where packets of a flow
are being received.
</description>
<reference>
See RFC 2863 for the definition of the ifIndex object.
</reference>
</field>
<field name="destinationPort" dataType="unsigned16"
Calato, et al. Expires August 16, 2004 [Page 33]
Internet-Draft IPFIX Information Model February 2004
dataTypeSemantics="identifier"
fieldType="11" applicability="all" status="current">
<description>
A destination port number in the UDP or TCP header,
respectively.
</description>
<reference>
<paragraph>
See RFC 768 for the definiton of the UDP destination port
field.
See RFC 793 for the definiton of the TCP destination port
field.
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>
The IPv4 destination address in the IPv4 packet header.
</description>
<reference>
See RFC 791 for the definition of the IPv4 destination address
field.
</reference>
</field>
<field name="destinationMask" dataType="octet"
fieldType="13" applicability="option" status="current">
<description>
<paragraph>
The number of contiguous bits that are relevant in the
destination address field of the IP packet header
(i.e. the subnet mask in slash notation).
</paragraph>
</description>
<units>bits</units>
</field>
<field name="egressInterface" dataType="unsigned32"
dataTypeSemantics="identifier"
fieldType="14" applicability="all" status="current">
<description>
The index of the IP interface (ifIndex) where packets of a flow
are being sent.
</description>
Calato, et al. Expires August 16, 2004 [Page 34]
Internet-Draft IPFIX Information Model February 2004
<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>
The IPv4 address of the next IP hop to which packets are
forwarded.
</description>
</field>
<field name="sourceAsNumber" dataType="unsigned16"
dataTypeSemantics="identifier"
fieldType="16" applicability="all" status="current">
<description>
The autonomous system (AS) number of the source address in
the IP packet header.
</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">
<description>
The autonomous system (AS) number of the destination address
in the IP packet header.
</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"
dataTypeSemantics="identifier"
fieldType="18" applicability="all" status="current">
<description>
The IPv4 address of the next BGP hop to which packets are
forwarded.
</description>
<reference>
See RFC 1771 for a description of BGB-4 and
Calato, et al. Expires August 16, 2004 [Page 35]
Internet-Draft IPFIX Information Model February 2004
see RFC 1930 a definition of the AS number.
</reference>
</field>
<field name="mcPacketsSent" dataType="unsigned64"
fieldType="19" applicability="data" status="current">
<description>
The number of sent multicast packets.
</description>
<units>packets</units>
</field>
<field name="mcOctetsSent" dataType="unsigned64"
fieldType="20" applicability="data" status="current">
<description>
The number of sent multicast octets.
</description>
<units>octets</units>
</field>
<field name="flowEndTime" dataType="dateTimeSeconds"
fieldType="21" applicability="data" status="current">
<description>
The timestamp of the last packet of a flow.
</description>
</field>
<field name="flowCreationTime" dataType="dateTimeSeconds"
fieldType="22" applicability="data" status="current">
<description>
The timestamp of the first packet of a flow.
</description>
</field>
<field name="sourceAddressV6" dataType="ipv6Address"
fieldType="27" applicability="all" status="current">
<description>
IPv6 source address taken from the packet header.
</description>
</field>
<field name="destinationAddressV6" dataType="ipv6Address"
fieldType="28" applicability="all" status="current">
<description>
IPv6 destination address taken from the packet header.
</description>
</field>
Calato, et al. Expires August 16, 2004 [Page 36]
Internet-Draft IPFIX Information Model February 2004
<field name="anotherSourceMask" dataType="octet"
fieldType="29" applicability="option" status="current">
<description>
<paragraph>
The number of contiguous bits that are relevant in the source
address field of the IP packet header (i.e. the subnet mask
in slash notation). This redundant field has the same
semantics as field 9.
</paragraph>
</description>
<units>bits</units>
</field>
<field name="destinationMask" dataType="octet"
fieldType="30" applicability="option" status="current">
<description>
<paragraph>
The number of contiguous bits that are relevant in the
destination address field of the IP packet header (i.e. the
subnet mask in slash notation). This redundant field has
the same semantics as field 13.
</paragraph>
</description>
<units>bits</units>
</field>
<field name="flowLabel" dataType="unsigned32"
fieldType="31" applicability="all" status="current">
<description>
The Flow Label of the IPv6 packet header.
</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>
Type and Code of the ICMP message.
</description>
<reference>
See RFC 792 for a definition of the ICMP type and code fields.
</reference>
</field>
<field name="igmpType" dataType="octet"
Calato, et al. Expires August 16, 2004 [Page 37]
Internet-Draft IPFIX Information Model February 2004
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>
<field name="samplingInterval" dataType="unsigned32"
fieldType="34" applicability="all" status="current">
<description>
<paragraph>
Number of packets received as a ratio of number of packets
sampled. For example a value of 100 would mean that one packet
in 100 was sampled.
</paragraph>
EDITORS' NOTE: This will be replaced by the PSAMP INFO MODEL
</description>
<units>packets</units>
</field>
<field name="samplingAlgorithm" dataType="octet"
dataTypeSemantics="identifier"
fieldType="35" applicability="all" status="current">
<description>
<paragraph>
The following sampling algorithms are defined:
</paragraph>
<list>
<item>1 Deterministic sampling</item>
<item>2 Random Sampling</item>
<item>3 Time-based sampling</item>
</list>
EDITORS' NOTE: This will be replaced by the PSAMP INFO MODEL
</description>
</field>
<field name="flowReportingInterval" dataType="unsigned16"
fieldType="36" applicability="all" status="current">
<description>
Interval between reports for an active flow.
</description>
<units>seconds</units>
</field>
Calato, et al. Expires August 16, 2004 [Page 38]
Internet-Draft IPFIX Information Model February 2004
<field name="flowIdleTimeout" 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>
The number of octets reported by the exporting process.
</description>
<units>octets</units>
</field>
<field name="exportedPacketCount" dataType="unsigned64"
fieldType="41" applicability="data" status="current">
<description>
The number of packets reported by the exporting process.
</description>
<units>packets</units>
</field>
<field name="exportedFlowCount" dataType="unsigned64"
fieldType="42" applicability="data" status="current">
<description>
The number of flows reported by the exporting process.
</description>
<units>flows</units>
</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.
Calato, et al. Expires August 16, 2004 [Page 39]
Internet-Draft IPFIX Information Model February 2004
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>
The IPv6 address of the next IP hop to which packets are
forwarded.
</description>
</field>
<field name="bgpNextHopAddressV6" dataType="ipv6Address"
dataTypeSemantics="identifier"
fieldType="63" applicability="all" status="current">
<description>
The IPv6 address of the next BGP hop to which packets are
forwarded.
</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"
dataTypeSemantics="identifier"
fieldType="80" applicability="all" status="current">
<description>
The autonomous system (AS) number of the next BGP hop the
packets are sent to.
</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="81" applicability="all" status="current">
<description>
The autonomous system (AS) number of the next IP hop the
packets are sent to.
</description>
Calato, et al. Expires August 16, 2004 [Page 40]
Internet-Draft IPFIX Information Model February 2004
<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"
fieldType="82" applicability="all" status="current">
<description>
<paragraph>
The IPv4 address of the flow exporter. This is used by the
collecter 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="ipv4Address"
fieldType="83" applicability="all" status="current">
<description>
<paragraph>
The IPv6 address of the flow exporter. This is used by the
collecter 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="droppedOctetCount" dataType="unsigned64"
fieldType="84" applicability="data" status="current">
<description>
The number of octets dropped.
</description>
<units>octets</units>
</field>
<field name="droppedPacketCount" dataType="unsigned64"
fieldType="84" applicability="data" status="current">
<description>
The number of packets dropped.
</description>
<units>packets</units>
</field>
<field name="flowEndReason" dataType="octet"
fieldType="84" applicability="data" status="current">
<description>
The number of packets dropped.
Calato, et al. Expires August 16, 2004 [Page 41]
Internet-Draft IPFIX Information Model February 2004
<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.
</description>
</field>
</fieldDefinitions>
Calato, et al. Expires August 16, 2004 [Page 42]
Internet-Draft IPFIX Information Model February 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>
Calato, et al. Expires August 16, 2004 [Page 43]
Internet-Draft IPFIX Information Model February 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
Calato, et al. Expires August 16, 2004 [Page 44]
Internet-Draft IPFIX Information Model February 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>
Calato, et al. Expires August 16, 2004 [Page 45]
Internet-Draft IPFIX Information Model February 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>
Calato, et al. Expires August 16, 2004 [Page 46]
Internet-Draft IPFIX Information Model February 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>
Calato, et al. Expires August 16, 2004 [Page 47]
Internet-Draft IPFIX Information Model February 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>
Calato, et al. Expires August 16, 2004 [Page 48]
Internet-Draft IPFIX Information Model February 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
Calato, et al. Expires August 16, 2004 [Page 49]
Internet-Draft IPFIX Information Model February 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>
Calato, et al. Expires August 16, 2004 [Page 50]
Internet-Draft IPFIX Information Model February 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>
Calato, et al. Expires August 16, 2004 [Page 51]
Internet-Draft IPFIX Information Model February 2004
</complexType>
</element>
</sequence>
</complexType>
<unique name="fieldTypeUnique">
<selector xpath="field"/>
<field xpath="fieldType"/>
</unique>
</element>
</schema>
Calato, et al. Expires August 16, 2004 [Page 52]
Internet-Draft IPFIX Information Model February 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
Calato, et al. Expires August 16, 2004 [Page 53]
Internet-Draft IPFIX Information Model February 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.
Calato, et al. Expires August 16, 2004 [Page 54]