TOC 
Network Working GroupG. Muenz
Internet-DraftUniversity of Tuebingen
Expires: December 24, 2006June 22, 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 24, 2006.

Copyright Notice

Copyright © 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).



Table of Contents

1.  Introduction

2.  Terminology

3.  IPFIX Device Architecture

4.  Configuration Parameters
    4.1.  Observation Point
    4.2.  Collecting Process
    4.3.  Metering Process
    4.4.  Exporting Process

5.  XML Schema

6.  Examples
    6.1.  PSAMP Probe
    6.2.  Concentrator

7.  Security Considerations

8.  References
    8.1.  Normative References
    8.2.  Informative References

§  Author's Address
§  Intellectual Property and Copyright Statements




 TOC 

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] (Sperberg-McQueen, C., Maler, E., Bray, T., Paoli, J., and F. Yergeau, “Extensible Markup Language (XML) 1.0 (Third Edition),” February 2004.), 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] (Enns, R., “NETCONF Configuration Protocol,” March 2006.) or the Simple Object Access Protocol (SOAP) [W3C.REC-soap12-part1-20030624] (Nielsen, H., Gudgin, M., Mendelsohn, N., Hadley, M., and J. Moreau, “SOAP Version 1.2 Part 1: Messaging Framework,” June 2003.), 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] (Sadasivan, G., “Architecture for IP Flow Information Export,” June 2006.) 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 (IPFIX Device Architecture). In Section 4 (Configuration Parameters), a set of common configurable parameters is specified for each component. An XML Schema for the configuration data model is presented in Section 5 (XML Schema), followed by example configurations in Section 6 (Examples).



 TOC 

2. Terminology

This document adopts the terminologies used in [I-D.ietf-ipfix-protocol] (Claise, B., “IPFIX Protocol Specification,” June 2006.) and [I-D.ietf-ipfix-architecture] (Sadasivan, G., “Architecture for IP Flow Information Export,” June 2006.) 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).



 TOC 

3. IPFIX Device Architecture

As specified in [I-D.ietf-ipfix-architecture] (Sadasivan, G., “Architecture for IP Flow Information Export,” June 2006.), 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] (Duffield, N., “A Framework for Packet Selection and Reporting,” January 2005.) specifies the same architecture for PSAMP devices. (Note that the term Measurement Process used in [I-D.ietf-psamp-framework] (Duffield, N., “A Framework for Packet Selection and Reporting,” January 2005.) 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 (Many-to-many Relationship between Components).



+---------------+        +---------------+
| 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 (Data Path starting with an Observation Point) and Figure 3 (Data Path starting with a Collecting Process) depict the possible data paths starting with an Observation Point and a Collecting Process respectively. Figure 4 (Monitoring Probe) shows the example of a monitoring probe consisting of two Observation Points linked to a Metering Process and an Exporting Process. Figure 5 (Proxy) 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 (Concentrator) shows a 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 



+------------+
| 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).



 TOC 

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] (Quittek, J., Zseby, T., Claise, B., and S. Zander, “Requirements for IP Flow Information Export (IPFIX),” October 2004.), [I-D.ietf-ipfix-architecture] (Sadasivan, G., “Architecture for IP Flow Information Export,” June 2006.), [I-D.ietf-ipfix-protocol] (Claise, B., “IPFIX Protocol Specification,” June 2006.), [I-D.ietf-psamp-framework] (Duffield, N., “A Framework for Packet Selection and Reporting,” January 2005.), [I-D.ietf-psamp-sample-tech] (Zseby, T., “Sampling and Filtering Techniques for IP Packet Selection,” July 2005.), and integrate the rule-based flow metering approach of [I-D.dressler-ipfix-aggregation] (Dressler, F., “IPFIX Aggregation,” December 2005.). Furthermore, the MIB modules CISCO-NETFLOW-MIB [CISCO-NETFLOW-MIB] (Kundu, N. and P. Aitken, “CISCO-NETFLOW-MIB: Cisco NetFlow Cache MIB Module,” January 2004.) and PSAMP-MIB [I-D.ietf-psamp-mib] (Dietz, T. and B. Claise, “Definitions of Managed Objects for Packet Sampling,” October 2005.) were taken into consideration.



 TOC 

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 parameters are pcap specific.

Next Pointer:
The raw packet data captured by an Observation Point can be passed to one or multiple Metering Processes.


 TOC 

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.


 TOC 

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] (Zseby, T., “Sampling and Filtering Techniques for IP Packet Selection,” July 2005.), and their configurable parameters are defined in [I-D.ietf-psamp-mib] (Dietz, T. and B. Claise, “Definitions of Managed Objects for Packet Sampling,” October 2005.). [I-D.ietf-psamp-framework] (Duffield, N., “A Framework for Packet Selection and Reporting,” January 2005.) 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] (Sadasivan, G., “Architecture for IP Flow Information Export,” June 2006.) and [I-D.dressler-ipfix-aggregation] (Dressler, F., “IPFIX Aggregation,” December 2005.). [RFC3917] (Quittek, J., Zseby, T., Claise, B., and S. Zander, “Requirements for IP Flow Information Export (IPFIX),” October 2004.) gives an overview on the configurable parameters. [I-D.dressler-ipfix-aggregation] (Dressler, F., “IPFIX Aggregation,” December 2005.) 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] (Dietz, T. and B. Claise, “Definitions of Managed Objects for Packet Sampling,” October 2005.).

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.


 TOC 

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:



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.


 TOC 

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" />
      <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" />
              <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" />
      <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>

  <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>

  <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>
  </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"
          type="exportingProcess_type" minOccurs="0"
          maxOccurs="unbounded" />
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>

</xsd:schema>



 TOC 

6. Examples

This section shows example configurations conforming to the XML Schema specified in Section 5 (XML Schema).



 TOC 

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>
      <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>



 TOC 

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>
    <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>
          <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>



 TOC 

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.



 TOC 

8. References



 TOC 

8.1. Normative References

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).


 TOC 

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-11 (work in progress), June 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 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-22 (work in progress), June 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.


 TOC 

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


 TOC 

Intellectual Property Statement

Disclaimer of Validity

Copyright Statement

Acknowledgment