Network Working Group G. Muenz
Internet-Draft University of Tuebingen
Expires: December 21, 2006 June 19, 2006
IPFIX Configuration Data Model
<draft-muenz-ipfix-configuration-00>
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 December 21, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document proposes a configuration data model for IP Flow
Information Export (IPFIX) Devices based on Extensible Markup
Language (XML).
Muenz draft-muenz-ipfix-configuration-00.txt [Page 1]
Internet-Draft IPFIX Configuration Data Model June 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. IPFIX Device Architecture . . . . . . . . . . . . . . . . . . 4
4. Configuration Parameters . . . . . . . . . . . . . . . . . . . 6
4.1. Observation Point . . . . . . . . . . . . . . . . . . . . 6
4.2. Collecting Process . . . . . . . . . . . . . . . . . . . . 7
4.3. Metering Process . . . . . . . . . . . . . . . . . . . . . 7
4.4. Exporting Process . . . . . . . . . . . . . . . . . . . . 8
5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. PSAMP Probe . . . . . . . . . . . . . . . . . . . . . . . 16
6.2. Concentrator . . . . . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 23
Muenz draft-muenz-ipfix-configuration-00.txt [Page 2]
Internet-Draft IPFIX Configuration Data Model June 2006
1. Introduction
IPFIX Devices offer various configuration possibilities that allow
adapting network monitoring to the requirements of the analysis tasks
performed on the exported monitoring data. The use of a common
device-independent configuration data model for IPFIX Devices
facilitates network management and configuration, especially if IPFIX
Devices of different implementers and/or manufacturers are deployed
simultaneously.
The aim of this document is the specification of a device-independent
configuration data model that covers the commonly available
configuration parameters of an IPFIX Device. The proposed data model
is based on Extensible Markup Language (XML) [W3C.REC-xml-20040204],
which allows extending it easily with additional device-specific
parameters. On the other hand, if some configuration parameters of
the common data model are not supported by an IPFIX Device
implementation, they can be simply omitted. Any restrictions and
changes of the configuration data model should be known to the
network management system in order to avoid sending unsupported
configuration data to the devices. Note that the communication of
device capabilities to the network management system is currently out
of scope of this document.
There are various candidate protocols, like the Network Configuration
Protocol (Netconf) [I-D.ietf-netconf-prot] or the Simple Object
Access Protocol (SOAP) [W3C.REC-soap12-part1-20030624], that are
suitable for transferring XML data from a network management system
to the IPFIX Device. However, the configuration data model specified
here is not specific to any of these.
The IPFIX reference model [I-D.ietf-ipfix-architecture] specifies
different functional components within an IPFIX Device. These
components can be linked together in order to form a data path
through the IPFIX Device as described in Section 3. In Section 4, a
set of common configurable parameters is specified for each
component. An XML Schema for the configuration data model is
presented in Section 5, followed by example configurations in
Section 6.
2. Terminology
This document adopts the terminologies used in [I-D.ietf-ipfix-
protocol] and [I-D.ietf-ipfix-architecture] with the exception that
the term IPFIX Device also covers concentrators, proxies etc. (Note
that a corresponding redefinition of the term IPFIX Device is
currently discussed in the IPFIX working group).
Muenz draft-muenz-ipfix-configuration-00.txt [Page 3]
Internet-Draft IPFIX Configuration Data Model June 2006
3. IPFIX Device Architecture
As specified in [I-D.ietf-ipfix-architecture], the functionality of
an IPFIX Device is divided into four types of components: Observation
Points, Metering Processes, Exporting Processes, and Collecting
Processes. [I-D.ietf-psamp-framework] specifies the same
architecture for PSAMP devices. (Note that the term Measurement
Process used in [I-D.ietf-psamp-framework] is to be changed to
Metering Process.)
The different components of the IPFIX Device have inputs and/or
outputs and can be linked to form a data path. In general, many-to-
many relationships are possible between the components: The output of
one component can be linked to the inputs of multiple succeeding
components and the input of a component can be linked to the outputs
of multiple preceding components. However, loops are not allowed in
the data path. For two components linked to two other components,
this is shown in Figure 1.
+---------------+ +---------------+
| Component 1.1 |-+----->| Component 2.1 |
+---------------+ \ -->+---------------+
\/
/\
+---------------+ / -->+---------------+
| Component 1.2 |-+----->| Component 2.2 |
+---------------+ +---------------+
Figure 1: Many-to-many Relationship between Components
Observation Points and Collecting Processes are possible starting
points of the data path through the IPFIX Device, thus they have
outputs but no inputs. Exporting Processes, on the other hand,
represent end points of the data path, i.e. they have inputs but no
outputs. An Observation Point can only be followed by Metering
Processes because it is not possible to export unprocessed raw packet
data. In contrast, a Collecting Process can be followed by Metering
Processes and/or Exporting Processes since it delivers data in form
of records. The output of a Metering Process can be linked to
Metering Processes and/or Exporting Processes.
Figure 2 and Figure 3 depict the possible data paths starting with an
Observation Point and a Collecting Process respectively. Figure 4
shows the example of a monitoring probe consisting of two Observation
Points linked to a Metering Process and an Exporting Process.
Figure 5 displays a proxy where a Collecting Process is directly
followed by an Exporting Process. Such a device can be used to
change the transport protocol. Finally, Figure 6 shows a
Muenz draft-muenz-ipfix-configuration-00.txt [Page 4]
Internet-Draft IPFIX Configuration Data Model June 2006
concentrator receiving flow data from other IPFIX devices and
applying a Metering Process to it for aggregation purposes.
+-------------+ +----------+ +----------+ +-----------+
| Observation |-->| Metering |-...->| Metering |-->| Exporting |
| Point | | Process | | Process | | Process |
+-------------+ +----------+ +----------+ +-----------+
\______________________________/
1..n
Figure 2: Data Path starting with an Observation Point
+------------+ +----------+ +----------+ +-----------+
| Collecting |-->| Metering |-...->| Metering |-->| Exporting |
| Process | | Process | | Process | | Process |
+------------+ +----------+ +----------+ +-----------+
\______________________________/
0..n
Figure 3: Data Path starting with a Collecting Process
+-------------+
| Observation |
| Point |-+
+-------------+ | +----------+ +-----------+
... +->| Metering |-->| Exporting |
+-------------+ | | Process | | Process |
| Observation |-+ +----------+ +-----------+
| Point |
+-------------+
Figure 4: Monitoring Probe
+------------+ +-----------+
| Collecting |-->| Exporting |
| Process | | Process |
+------------+ +-----------+
Figure 5: Proxy
Muenz draft-muenz-ipfix-configuration-00.txt [Page 5]
Internet-Draft IPFIX Configuration Data Model June 2006
+------------+
| Collecting |
| Process |-+
+------------+ | +----------+ +-----------+
... +->| Metering |-->| Exporting |
+------------+ | | Process | | Process |
| Collecting |-+ +----------+ +-----------+
| Process |
+------------+
Figure 6: Concentrator
The proposed configuration data model assigns unique identifiers to
all components by numbering the Observation Points, Collecting
Processes, Metering Processes, and Exporting Processes. As the links
between the data path components are unidirectional, they are
represented by next pointers at a component's output, equaling the
identifier(s) of the succeeding component(s).
4. Configuration Parameters
This section describes the configurable parameters of the different
components. The selected parameters cover most of the configuration
issues discussed in the IPFIX/PSAMP working group documents
[RFC3917], [I-D.ietf-ipfix-architecture], [I-D.ietf-ipfix-protocol],
[I-D.ietf-psamp-framework], [I-D.ietf-psamp-sample-tech], and
integrate the rule-based flow metering approach of [I-D.dressler-
ipfix-aggregation]. Furthermore, the MIB modules CISCO-NETFLOW-MIB
[CISCO-NETFLOW-MIB] and PSAMP-MIB [I-D.ietf-psamp-mib] were taken
into consideration.
4.1. Observation Point
Observation Points are starting points of a data path through the
IPFIX Device. Observation Points observe and capture IP packets from
a certain location in the network. The configuration of an
Observation Point comprises the following parameters:
Observation Domain ID:
Each Observation Point is assigned to an Observation Domain
identified by an Observation Domain ID.
Type and Parameters:
Different types of Observation Points exist, and each type offers
its own set of configurable parameters. As an example, many
software implementations of IPFIX Devices base on the pcap
library. In this case, the type would be "pcap" and the
Muenz draft-muenz-ipfix-configuration-00.txt [Page 6]
Internet-Draft IPFIX Configuration Data Model June 2006
parameters are pcap specific.
Next Pointer:
The raw packet data captured by an Observation Point can be passed
to one or multiple Metering Processes.
4.2. Collecting Process
Similar to an Observation Point, a Collecting Process represents the
starting point of a data path. However, the data are not locally
observed IP packets but records received by other IPFIX Devices. A
Collecting Process has the following parameters:
List of Listeners:
A listening socket that receives data from other IPFIX devices is
determined by a network address, a transport protocol, and a port
number. A Collecting Process can have more than one listening
socket.
UDP Template Lifetime:
If UDP is used as transport protocol, the lifetime of Templates is
limited. Templates that are not renewed by the Exporting Process
must be expired by the Collecting Process.
Next Pointer:
The data received by a Collecting Process can be passed to one or
multiple Metering Processes and/or Exporting Processes.
4.3. Metering Process
Metering Processes perform the data processing within the IPFIX
Device. In case that the input of a Metering Process is raw packets
from Observation Points, the data are processed and transformed into
exportable records. If the input is records received from Collecting
Processes or other Metering Processes, the records are processed and
transformed into a new stream of records.
In principle, packet-based and flow-based metering can be
distinguished. Various packet-based processing techniques are
specified in [I-D.ietf-psamp-sample-tech], and their configurable
parameters are defined in [I-D.ietf-psamp-mib]. [I-D.ietf-psamp-
framework] divides the packet-based Metering Process into a packet
selection process and a reporting process. This is mapped on
corresponding structures in the configuration data model.
Flow-based processing techniques are described in [I-D.ietf-ipfix-
architecture] and [I-D.dressler-ipfix-aggregation]. [RFC3917] gives
an overview on the configurable parameters. [I-D.dressler-ipfix-
Muenz draft-muenz-ipfix-configuration-00.txt [Page 7]
Internet-Draft IPFIX Configuration Data Model June 2006
aggregation] proposes a description language for flow metering rules
(therein called aggregation rules) that define the Flow Keys as well
as the metered and exported flow attributes. This rule-based
description of flow metering can also be applied to devices that do
not support multiple metering rules. For example, if a device
performs flow metering with a single set of Flow Keys only, this can
be mapped to exactly one metering rule.
All in all, the configurable parameters of a Metering Process can be
summarized as follows:
Packet Selection:
Incoming raw packets can be processed in a sequence of filters and
sampling algorithms. The possible filtering and sampling
parameters are defined in [I-D.ietf-psamp-mib].
Packet Reporting:
If the output of the Metering Process are records with packet-
based monitoring data (or PSAMP data), the packet reporting
parameters define the Information Elements that are present in the
records.
Flow Metering:
Flow-based metering can be described by one or more metering
rules. Each metering rule defines the Information Elements that
are present in the resulting records. Two different types of
Information Elements are distinguished: Information Elements that
are used as Flow Keys and Information Elements specifying the
additional information reported for each flow. The application of
a metering rule can be restricted to incoming data matching given
patterns. Apart from metering rules, the flow-based data
processing depends on active and inactive flow timeout values that
control the flow expiration.
Next Pointer:
The output of a Metering Process can be passed to Exporting
Processes and/or to other Metering Processes.
4.4. Exporting Process
The Exporting Process receives records from Metering and/or
Collecting Processes and exports them using the IPFIX protocol.
Depending on the transport protocol in use, it manages the
transmission of the necessary control information (e.g. Templates)
to the Collector. The structure of the Templates is implicitly given
by the record format. In summary, an Exporting Process offers the
following configuration parameters:
Muenz draft-muenz-ipfix-configuration-00.txt [Page 8]
Internet-Draft IPFIX Configuration Data Model June 2006
IPFIX Packet Restrictions:
Under some conditions, it can be reasonable to configure the
maximum size of an IPFIX packet, e.g. to avoid fragmentation.
Furthermore, a maximum delay can be set for the export of records.
This delay allows waiting for the arrival of more records in order
to fill up the exported IPFIX packets and hence reduce the export
overhead.
UDP Template Management:
If UDP is deployed as transport protocol, the Templates in use
have to be retransmitted periodically. There are two parameters
that control the Template retransmissions. The template refresh
timeout defines the time after which a Template is invalidated if
it is not retransmitted. The template refresh rate determines
after how many IPFIX packets a Template in use is retransmitted.
Receiving Collectors:
IPFIX packets can be exported to multiple collectors identified by
their network address, transport protocol, and port number.
5. XML Schema
XML Schema of the configuration data model is specified as follows:
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:ipfix-config"
xmlns="urn:ietf:params:xml:ns:ipfix-config"
elementFormDefault="qualified"
version="1.0">
<xsd:annotation>
<xsd:documentation xml:lang="en">
IPFIX Configuration Data Model Version 1.0
</xsd:documentation>
</xsd:annotation>
<!-- Generic Types -->
<xsd:complexType name="informationElement_type">
<xsd:sequence>
<xsd:element name="enterpriseNumber" type="xsd:unsignedInt"
minOccurs="0" />
<xsd:element name="ieName" type="xsd:string" minOccurs="0" />
<xsd:element name="ieId" type="xsd:unsignedInt"
minOccurs="0" />
<xsd:element name="ieLength" type="xsd:unsignedInt"
minOccurs="0" />
<xsd:element name="match" type="xsd:string" minOccurs="0" />
Muenz draft-muenz-ipfix-configuration-00.txt [Page 9]
Internet-Draft IPFIX Configuration Data Model June 2006
<xsd:element name="modifier" type="xsd:string" minOccurs="0">
<xsd:annotation>
<xsd:documentation xml:lang="en">
Field modifier can be 'mask/X' or 'discard'.
See draft-dressler-ipfix-aggregation-02 for details.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="collector_type">
<xsd:sequence>
<xsd:element name="ipAddressType" type="xsd:unsignedInt">
<xsd:annotation>
<xsd:documentation xml:lang="en">
IANA protocol number (IPv4:4, IPv6: 41)
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="ipAddress" type="xsd:string" />
<xsd:element name="transportProtocol" type="xsd:unsignedInt">
<xsd:annotation>
<xsd:documentation xml:lang="en">
IANA protocol number (UDP:17, TCP:6, SCTP: 132)
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="port" type="xsd:unsignedInt" />
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="next_type">
<xsd:sequence>
<xsd:element name="meteringProcessId" type="xsd:unsignedInt"
minOccurs="0" maxOccurs="unbounded" />
<xsd:element name="exportingProcessId" type="xsd:unsignedInt"
minOccurs="0" maxOccurs="unbounded" />
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="time_type">
<xsd:simpleContent>
<xsd:extension base="xsd:unsignedInt">
<xsd:attribute name="unit" use="optional" default="sec">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="sec" />
Muenz draft-muenz-ipfix-configuration-00.txt [Page 10]
Internet-Draft IPFIX Configuration Data Model June 2006
<xsd:enumeration value="msec" />
<xsd:enumeration value="usec" />
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
<!-- Observation Point -->
<xsd:complexType name="observationPoint_type">
<xsd:sequence>
<xsd:element name="observationDomainId"
type="xsd:unsignedInt" />
<xsd:element name="type" type="xsd:string" />
<xsd:element name="parameters" type="xsd:string"
minOccurs="0" />
<xsd:element name="next" type="next_type" minOccurs="0" />
</xsd:sequence>
<xsd:attribute name="id" type="xsd:unsignedInt" use="required" />
</xsd:complexType>
<!-- Collecting Process -->
<xsd:complexType name="collectingProcess_type">
<xsd:sequence>
<xsd:element name="listener" type="collector_type"
minOccurs="0" maxOccurs="unbounded" />
<xsd:element name="udpTemplateLifetime" type="time_type"
minOccurs="0" />
<xsd:element name="next" type="next_type" minOccurs="0" />
</xsd:sequence>
<xsd:attribute name="id" type="xsd:unsignedInt" use="required" />
</xsd:complexType>
<!-- Metering Process -->
<xsd:complexType name="meteringProcess_type">
<xsd:sequence>
<xsd:element name="packetSelection"
type="packetSelection_type" minOccurs="0"
maxOccurs="unbounded" />
<xsd:element name="packetReporting"
type="packetReporting_type" minOccurs="0"
maxOccurs="unbounded" />
<xsd:element name="flowMetering" type="flowMetering_type"
minOccurs="0" maxOccurs="unbounded" />
Muenz draft-muenz-ipfix-configuration-00.txt [Page 11]
Internet-Draft IPFIX Configuration Data Model June 2006
<xsd:element name="next" type="next_type" minOccurs="0" />
</xsd:sequence>
<xsd:attribute name="id" type="xsd:unsignedInt"
use="required" />
</xsd:complexType>
<!-- Metering Process: Packet Selection -->
<xsd:complexType name="packetSelection_type">
<xsd:annotation>
<xsd:documentation xml:lang="en">
See draft-ietf-psamp-mib-05.txt for details about the packet
selection parameters.
</xsd:documentation>
</xsd:annotation>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element name="countBased" type="countBased_type" />
<xsd:element name="timeBased" type="timeBased_type" />
<xsd:element name="randOutOfN" type="randOutOfN_type" />
<xsd:element name="uniProb" type="uniProb_type" />
<xsd:element name="nonUniProb" type="nonUniProb_type" />
<xsd:element name="flowState" type="flowState_type" />
<xsd:element name="filterMatch" type="filterMatch_type" />
<xsd:element name="filterHash" type="filterHash_type" />
<xsd:element name="filterRState" type="filterRState_type" />
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="countBased_type">
<xsd:sequence>
<xsd:element name="interval" type="xsd:unsignedInt" />
<xsd:element name="spacing" type="xsd:unsignedInt" />
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="timeBased_type">
<xsd:sequence>
<xsd:element name="interval" type="xsd:unsignedInt" />
<xsd:element name="spacing" type="xsd:unsignedInt" />
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="randOutOfN_type">
<xsd:sequence>
<xsd:element name="population" type="xsd:unsignedInt" />
<xsd:element name="sample" type="xsd:unsignedInt" />
</xsd:sequence>
</xsd:complexType>
Muenz draft-muenz-ipfix-configuration-00.txt [Page 12]
Internet-Draft IPFIX Configuration Data Model June 2006
<xsd:complexType name="uniProb_type">
<xsd:sequence>
<xsd:element name="probability" type="xsd:unsignedInt">
<xsd:annotation>
<xsd:documentation xml:lang="en">
The given value must be divided by 4294967295
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="nonUniProb_type" mixed="true">
<xsd:sequence>
<xsd:element name="function" type="xsd:string" />
<xsd:element name="funcParam" type="xsd:string" />
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="flowState_type" mixed="true">
<xsd:sequence>
<xsd:element name="function" type="xsd:string" />
<xsd:element name="funcParam" type="xsd:string" />
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="filterMatch_type">
<xsd:sequence>
<xsd:element name="infoElementId"
type="informationElement_type" minOccurs="0"
maxOccurs="unbounded" />
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="filterHash_type">
<xsd:sequence>
<xsd:element name="addrType" type="xsd:unsignedInt" />
<xsd:element name="headerBits" type="xsd:string" />
<xsd:element name="payloadBytes" type="xsd:unsignedInt" />
<xsd:element name="payloadBits" type="xsd:string" />
<xsd:element name="function" type="xsd:string" />
<xsd:element name="funcParam" type="xsd:string" />
<xsd:element name="inputBits" type="xsd:unsignedInt" />
<xsd:element name="outputBits" type="xsd:unsignedInt" />
<xsd:element name="outputMask" type="xsd:string" />
<xsd:element name="selection" type="xsd:string" />
</xsd:sequence>
</xsd:complexType>
Muenz draft-muenz-ipfix-configuration-00.txt [Page 13]
Internet-Draft IPFIX Configuration Data Model June 2006
<xsd:complexType name="filterRState_type">
<xsd:sequence>
<xsd:element name="function" type="xsd:string" />
<xsd:element name="negate" type="xsd:boolean" />
<xsd:element name="ifIndex" type="xsd:unsignedInt" />
<xsd:element name="startAS" type="xsd:unsignedInt" />
<xsd:element name="endAS" type="xsd:unsignedInt" />
<xsd:element name="vendorFunc" type="xsd:string" />
</xsd:sequence>
</xsd:complexType>
<!-- Metering Process: Packet Reporting -->
<xsd:complexType name="packetReporting_type">
<xsd:sequence minOccurs="0" maxOccurs="unbounded">
<xsd:element name="templateId" type="xsd:unsignedInt"
minOccurs="0" />
<xsd:element name="reportedIE" type="informationElement_type"
minOccurs="0" maxOccurs="unbounded" />
</xsd:sequence>
</xsd:complexType>
<!-- Metering Process: Flow Metering -->
<xsd:complexType name="flowMetering_type">
<xsd:sequence>
<xsd:element name="rule" type="flowMeteringRule_type"
minOccurs="0" maxOccurs="unbounded" />
<xsd:element name="expiration" type="flowExpiration_type"
minOccurs="0" />
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="flowMeteringRule_type">
<xsd:sequence>
<xsd:element name="templateId" type="xsd:unsignedInt"
minOccurs="0" />
<xsd:element name="flowKey" type="informationElement_type"
minOccurs="0" maxOccurs="unbounded" />
<xsd:element name="nonFlowKey" type="informationElement_type"
minOccurs="0" maxOccurs="unbounded" />
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="flowExpiration_type">
<xsd:sequence>
<xsd:element name="activeTimeout" type="time_type" />
<xsd:element name="inactiveTimeout" type="time_type" />
</xsd:sequence>
Muenz draft-muenz-ipfix-configuration-00.txt [Page 14]
Internet-Draft IPFIX Configuration Data Model June 2006
</xsd:complexType>
<!-- Exporting Process -->
<xsd:complexType name="exportingProcess_type">
<xsd:sequence>
<xsd:element name="ipfixPacketRestrictions"
type="ipfixPacketRestrictions_type" minOccurs="0" />
<xsd:element name="udpTemplateManagement"
type="udpTemplateManagement_type" minOccurs="0" />
<xsd:element name="collector" type="collector_type"
minOccurs="0" maxOccurs="unbounded" />
</xsd:sequence>
<xsd:attribute name="id" type="xsd:unsignedInt" use="required" />
</xsd:complexType>
<xsd:complexType name="ipfixPacketRestrictions_type">
<xsd:sequence>
<xsd:element name="maxPacketSize" type="xsd:unsignedInt"
minOccurs="0" />
<xsd:element name="maxExportDelay" type="time_type"
minOccurs="0" />
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="udpTemplateManagement_type">
<xsd:sequence>
<xsd:element name="templateRefreshTimeout" type="time_type"
minOccurs="0" />
<xsd:element name="templateRefreshRate" type="xsd:unsignedInt"
minOccurs="0" />
</xsd:sequence>
</xsd:complexType>
<!-- IPFIX Device Configuration -->
<xsd:element name="ipfixConfig">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="collectingProcess"
type="collectingProcess_type" minOccurs="0"
maxOccurs="unbounded" />
<xsd:element name="observationPoint"
type="observationPoint_type" minOccurs="0"
maxOccurs="unbounded" />
<xsd:element name="meteringProcess"
type="meteringProcess_type" minOccurs="0"
maxOccurs="unbounded" />
<xsd:element name="exportingProcess"
Muenz draft-muenz-ipfix-configuration-00.txt [Page 15]
Internet-Draft IPFIX Configuration Data Model June 2006
type="exportingProcess_type" minOccurs="0"
maxOccurs="unbounded" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
6. Examples
This section shows example configurations conforming to the XML
Schema specified in Section 5.
6.1. PSAMP Probe
<ipfixConfig xmlns="urn:ietf:params:xml:ns:ipfix-config">
<observationPoint id="1">
<observationDomainId>12345</observationDomainId>
<type>pcap</type>
<parameters>eth0 ip</parameters>
<next>
<meteringProcessId>1</meteringProcessId>
</next>
</observationPoint>
<meteringProcess id="1">
<packetSelection>
<countBased>
<interval>10</interval>
<spacing>500</spacing>
</countBased>
<filterMatch>
<infoElementId>
<ieName>destinationIPv4Address</ieName>
<match>10.1.0.0/16</match>
</infoElementId>
<infoElementId>
<ieName>destinationTransportPort</ieName>
<match>80,443</match>
</infoElementId>
</filterMatch>
</packetSelection>
<packetReporting>
<templateId>888</templateId>
Muenz draft-muenz-ipfix-configuration-00.txt [Page 16]
Internet-Draft IPFIX Configuration Data Model June 2006
<reportedIE>
<ieName>sourceIPv4Address</ieName>
</reportedIE>
<reportedIE>
<ieId>313</ieId>
<ieLength>0</ieLength>
</reportedIE>
<reportedIE>
<ieName>flowStartSeconds</ieName>
</reportedIE>
</packetReporting>
<next>
<exportingProcessId>1</exportingProcessId>
</next>
</meteringProcess>
<exportingProcess id="1">
<ipfixPacketRestrictions>
<maxPacketSize>1500</maxPacketSize>
<maxExportDelay unit="msec">500</maxExportDelay>
</ipfixPacketRestrictions>
<udpTemplateManagement>
<templateRefreshTimeout unit="sec">5</templateRefreshTimeout>
<templateRefreshRate>100</templateRefreshRate>
</udpTemplateManagement>
<collector>
<ipAddressType>4</ipAddressType>
<ipAddress>10.2.0.99</ipAddress>
<transportProtocol>17</transportProtocol>
<port>4739</port>
</collector>
</exportingProcess>
</ipfixConfig>
6.2. Concentrator
<ipfixConfig xmlns="urn:ietf:params:xml:ns:ipfix-config">
<collectingProcess id="1">
<listener>
<ipAddressType>4</ipAddressType>
<ipAddress>10.2.0.99</ipAddress>
<transportProtocol>17</transportProtocol>
<port>4739</port>
</listener>
<udpTemplateLifetime unit="sec">15</udpTemplateLifetime>
Muenz draft-muenz-ipfix-configuration-00.txt [Page 17]
Internet-Draft IPFIX Configuration Data Model June 2006
<next>
<meteringProcessId>1</meteringProcessId>
</next>
</collectingProcess>
<meteringProcess id="1">
<flowMetering>
<rule>
<templateId>998</templateId>
<flowKey>
<ieName>sourceIPv4Address</ieName>
<modifier>mask/16</modifier>
</flowKey>
<flowKey>
<ieName>destinationIPv4Address</ieName>
</flowKey>
<flowKey>
<ieName>transportProtocol</ieName>
</flowKey>
<flowKey>
<ieName>sourceTransportPort</ieName>
</flowKey>
<flowKey>
<ieName>destinationTransportPort</ieName>
</flowKey>
<nonFlowKey>
<ieName>flowStartSeconds</ieName>
</nonFlowKey>
<nonFlowKey>
<ieName>flowEndSeconds</ieName>
</nonFlowKey>
<nonFlowKey>
<ieName>octetDeltaCount</ieName>
</nonFlowKey>
<nonFlowKey>
<ieName>packetDeltaCount</ieName>
</nonFlowKey>
</rule>
<rule>
<templateId>999</templateId>
<flowKey>
<ieName>sourceIPv4Address</ieName>
<modifier>mask/16</modifier>
</flowKey>
<flowKey>
<ieName>destinationIPv4Address</ieName>
</flowKey>
<flowKey>
Muenz draft-muenz-ipfix-configuration-00.txt [Page 18]
Internet-Draft IPFIX Configuration Data Model June 2006
<ieName>transportProtocol</ieName>
<match>1</match>
</flowKey>
<nonFlowKey>
<ieName>flowStartSeconds</ieName>
</nonFlowKey>
<nonFlowKey>
<ieName>flowEndSeconds</ieName>
</nonFlowKey>
<nonFlowKey>
<ieName>octetDeltaCount</ieName>
</nonFlowKey>
<nonFlowKey>
<ieName>packetDeltaCount</ieName>
</nonFlowKey>
</rule>
<expiration>
<activeTimeout unit="sec">5</activeTimeout>
<inactiveTimeout unit="sec">10</inactiveTimeout>
</expiration>
</flowMetering>
<next>
<exportingProcessId>1</exportingProcessId>
</next>
</meteringProcess>
<exportingProcess id="1">
<ipfixPacketRestrictions>
<maxPacketSize>1500</maxPacketSize>
<maxExportDelay unit="msec">500</maxExportDelay>
</ipfixPacketRestrictions>
<udpTemplateManagement>
<templateRefreshTimeout>10</templateRefreshTimeout>
<templateRefreshRate>100</templateRefreshRate>
</udpTemplateManagement>
<collector>
<ipAddressType>4</ipAddressType>
<ipAddress>10.3.0.99</ipAddress>
<transportProtocol>17</transportProtocol>
<port>4739</port>
</collector>
</exportingProcess>
</ipfixConfig>
Muenz draft-muenz-ipfix-configuration-00.txt [Page 19]
Internet-Draft IPFIX Configuration Data Model June 2006
7. Security Considerations
The XML Schema has been conceived to enable its usage with many
different IPFIX Device implementations. In order to keep the XML
Schema simple and flexible, no provisions have been made to ensure
that only complete and meaningful configurations can be specified.
For example, most of the elements are declared optional.
Furthermore, the necessary communication of device capabilities and
the corresponding limitations and adaptations of the configuration
data model to the network management system is not specified in this
document. Hence, the XML Schema does not ensure that conforming XML
documents describe configurations that are both complete and
supported by an IPFIX Device. Users have to make sure that
configuration data is validated and checked against the capabilities
of the IPFIX Device before configuring the device. If configuration
data is incomplete, invalid or unsupported, it must be rejected by
the IPFIX Device and the previous configuration should remain active.
In addition, an error message should be returned specifying the
reason for the error of any failed configuration attempt.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[W3C.REC-xml-20040204]
Sperberg-McQueen, C., Maler, E., Bray, T., Paoli, J., and
F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third
Edition)", World Wide Web Consortium
Recommendation http://www.w3.org/TR/2004/REC-xml-20040204,
February 2004.
[I-D.ietf-ipfix-architecture]
Sadasivan, G., "Architecture for IP Flow Information
Export", draft-ietf-ipfix-architecture-10 (work in
progress), May 2006.
[I-D.ietf-netconf-prot]
Enns, R., "NETCONF Configuration Protocol",
draft-ietf-netconf-prot-12 (work in progress), March 2006.
[W3C.REC-soap12-part1-20030624]
Nielsen, H., Gudgin, M., Mendelsohn, N., Hadley, M., and
Muenz draft-muenz-ipfix-configuration-00.txt [Page 20]
Internet-Draft IPFIX Configuration Data Model June 2006
J. Moreau, "SOAP Version 1.2 Part 1: Messaging Framework",
World Wide Web Consortium Recommendation http://
www.w3.org/TR/2003/REC-soap12-part1-20030624, June 2003.
[I-D.ietf-ipfix-protocol]
Claise, B., "IPFIX Protocol Specification",
draft-ietf-ipfix-protocol-21 (work in progress),
April 2006.
[I-D.ietf-psamp-framework]
Duffield, N., "A Framework for Packet Selection and
Reporting", draft-ietf-psamp-framework-10 (work in
progress), January 2005.
[RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander,
"Requirements for IP Flow Information Export (IPFIX)",
RFC 3917, October 2004.
[I-D.ietf-psamp-sample-tech]
Zseby, T., "Sampling and Filtering Techniques for IP
Packet Selection", draft-ietf-psamp-sample-tech-07 (work
in progress), July 2005.
[I-D.dressler-ipfix-aggregation]
Dressler, F., "IPFIX Aggregation",
draft-dressler-ipfix-aggregation-02 (work in progress),
December 2005.
[CISCO-NETFLOW-MIB]
Kundu, N. and P. Aitken, "CISCO-NETFLOW-MIB: Cisco NetFlow
Cache MIB Module", Cisco SNMP Object Navigator http://
tools.cisco.com/Support/SNMP/do/
BrowseMIB.do?local=en&step=2&mibName=CISCO-NETFLOW-MIB,
January 2004.
[I-D.ietf-psamp-mib]
Dietz, T. and B. Claise, "Definitions of Managed Objects
for Packet Sampling", draft-ietf-psamp-mib-05 (work in
progress), October 2005.
Muenz draft-muenz-ipfix-configuration-00.txt [Page 21]
Internet-Draft IPFIX Configuration Data Model June 2006
Author's Address
Gerhard Muenz
University of Tuebingen
Computer Networks and Internet
Auf der Morgenstelle 10C
Tuebingen D-72076
DE
Phone: +49 7071 29-70534
Email: muenz@informatik.uni-tuebingen.de
URI: http://net.informatik.uni-tuebingen.de/~muenz
Muenz draft-muenz-ipfix-configuration-00.txt [Page 22]
Internet-Draft IPFIX Configuration Data Model June 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Muenz draft-muenz-ipfix-configuration-00.txt [Page 23]