TOC 
Network Working GroupG. Muenz
Internet-DraftUniversity of Tuebingen
Expires: June 24, 2007December 21, 2006


Configuration Data Model for IPFIX and PSAMP
<draft-muenz-ipfix-configuration-01>

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 June 24, 2007.

Copyright Notice

Copyright © The IETF Trust (2006).

Abstract

This document proposes a configuration data model for IPFIX and PSAMP Devices as well as IPFIX concentrators and proxies based on Extensible Markup Language (XML).


Table of Contents

1.  Open Issues

2.  Introduction
    2.1.  IPFIX Documents Overview
    2.2.  PSAMP Documents Overview

3.  Terminology

4.  Structure of the Configuration Data Model

5.  Configuration Parameters
    5.1.  Observation Point
    5.2.  Collecting Process
    5.3.  Metering Process
    5.4.  Exporting Process

6.  XML Schema

7.  Examples
    7.1.  PSAMP Probe
    7.2.  IPFIX Probe
    7.3.  IPFIX Concentrator

8.  Security Considerations

9.  References
    9.1.  Normative References
    9.2.  Informative References

§  Author's Address
§  Intellectual Property and Copyright Statements



 TOC 

1.  Open Issues

General issues:

More open issues are indicated in the text as "[OPEN ISSUE: ...]". The following list summarizes them:


 TOC 

2.  Introduction

IPFIX Devices and PSAMP 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 and PSAMP Devices facilitates network management and configuration, especially if 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 IPFIX Devices and PSAMP Devices, as well as IPFIX concentrators and proxies.

The proposed data model is based on Extensible Markup Language (XML) [W3C.REC‑xml‑20040204] (Paoli, J., Maler, E., Sperberg-McQueen, C., Bray, T., 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 a 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] (Gudgin, M., Mendelsohn, N., Hadley, M., Nielsen, H., 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 a monitoring device. However, the configuration data model specified here is not specific to any of these.


 TOC 

2.1.  IPFIX Documents Overview

[TODO]


 TOC 

2.2.  PSAMP Documents Overview

[TODO]


 TOC 

3.  Terminology

This document adopts the terminologies used in [I‑D.ietf‑ipfix‑protocol] (Claise, B., “Specification of the IPFIX Protocol for the Exchange,” November 2006.) and [I‑D.ietf‑psamp‑protocol] (Claise, B., “Packet Sampling (PSAMP) Protocol Specifications,” October 2006.).
[TODO: copy terminology section]


 TOC 

4.  Structure of the Configuration Data Model

The IPFIX reference model defined in [I‑D.ietf‑ipfix‑architecture] (Sadasivan, G., “Architecture for IP Flow Information Export,” September 2006.) specifies the role and function of four types of components: Observation Point, Collecting Process, Metering Process, and Exporting Process. In [I‑D.ietf‑psamp‑framework] (Duffield, N., “A Framework for Packet Selection and Reporting,” January 2005.), the corresponding information is given for the PSAMP architecture. (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 structure of the configuration data model proposed in this document adopts this reference model by defining separate parameter sets for Observation Points, Collecting Processes, Metering Processes, and Exporting Processes. Consequently, the configuration of a monitoring device, such as IPFIX Device, PSAMP Device, IPFIX concentrator, or proxy, is represented by a combination of parameter sets for one or more functional component according to the device's inner architecture.

Devices may support several instances of a functional component, e.g. more than one Metering Process, which have to be distinguished. Also, the linkage of the instances may be configurable. Therefore, the configuration data model uses identifiers to distinguish between different instances. For Observation Points, Metering Processes, and Exporting Processes, the identifier corresponds to the observationPointId, meteringProcessId, and exportingProcessId as specified in [I‑D.ietf‑ipfix‑info] (Quittek, J., “Information Model for IP Flow Information Export,” October 2006.). Furthermore, the parameter sets of Observation Point, Collecting Process, and Metering Process include a pointer to the next component(s) on the data path. The parameter set of the Exporting Process does not need a pointer since it represents the end of a data path where the data leaves the device.

Figure 1 (Configuration of a simple device) depicts the structuring of the configuration data for a simple IPFIX Device or PSAMP Device consisting of one Observation Point, one Metering Process, and one Exporting Process. 


+-----------------+    +-----------------+    +-----------------+
| Parameters of   | +->| Parameters of   | +->| Parameters of   |
| Observation     | |  | Metering        | |  | Exporting       |
| Point 1 (OP1)   | |  | Process 1 (MP1) | |  | Process 1 (EP1) |
+-----------------+ |  +-----------------+ |  +-----------------+
| next: MP1       |-+  | next: EP1       |-+
+-----------------+    +-----------------+
 Figure 1: Configuration of a simple device 

Figure 2 (Configuration of a Device with two Metering Processes) and Figure 3 (Configuration of a Device with two Observation Points) show two configurations with two Metering Processes processing packet streams from one or two separate Observation Points respectively. The first case shows that one component may provide input to multiple following components. 


                       +-----------------+
                    +->| Parameters of   |
                    |  | Metering        |
                    |  | Process 1 (MP1) |
+-----------------+ |  +-----------------+    +-----------------+
| Parameters of   | |  | next: EP1       |--->| Parameters of   |
| Observation     | |  +-----------------+    | Exporting       |
| Point 1 (OP1)   | |                      +->| Process 1 (EP1) |
+-----------------+ |  +-----------------+ |  +-----------------+
| next: MP1, MP2  |-+->| Parameters of   | |
+-----------------+    | Metering        | |
                       | Process 2 (MP2) | |
                       +-----------------+ |
                       | next: EP1       |-+
                       +-----------------+
 Figure 2: Configuration of a Device with two Metering Processes 

+-----------------+    +-----------------+
| Parameters of   | +->| Parameters of   |
| Observation     | |  | Metering        |
| Point 1 (OP1)   | |  | Process 1 (MP1) |
+-----------------+ |  +-----------------+    +-----------------+
| next: MP1       |-+  | next: EP1       |--->| Parameters of   |
+-----------------+    +-----------------+    | Exporting       |
                                           +->| Process 1 (EP1) |
+-----------------+    +-----------------+ |  +-----------------+
| Parameters of   | +->| Parameters of   | |
| Observation     | |  | Metering        | |
| Point 2 (OP2)   | |  | Process 2 (MP2) | |
+-----------------+ |  +-----------------+ |
| next: MP2       |-+  | next: EP1       |-+
+-----------------+    +-----------------+
 Figure 3: Configuration of a Device with two Observation Points 

Figure 4 (Linkage of paremeter sets: simple device) depicts the configuration of an IPFIX concentrator where a Metering Process is used to perform aggregation on flow records received by a Collecting Process [RFC3917] (Quittek, J., Zseby, T., Claise, B., and S. Zander, “Requirements for IP Flow Information Export (IPFIX),” October 2004.). The configuration of the Metering Process follows the flexible rule concept presented in [I‑D.dressler‑ipfix‑aggregation] (Dressler, F., “IPFIX Aggregation,” June 2006.). 


+-----------------+    +-----------------+    +-----------------+
| Parameters of   | +->| Parameters of   | +->| Parameters of   |
| Collecting      | |  | Metering        | |  | Exporting       |
| Process 1 (CP1) | |  | Process 1 (MP1) | |  | Process 1 (EP1) |
+-----------------+ |  +-----------------+ |  +-----------------+
| next: MP1       |-+  | next: EP1       |-+
+-----------------+    +-----------------+
 Figure 4: Linkage of paremeter sets: simple device 

[OPEN ISSUE: allow consecutive Metering Processes or not?]
If flow metering is applied to sampled packets, packet sampling and flow metering can be considered as a PSAMP Metering Process followed by an IPFIX Metering Processes. Figure 5 (Linkage of PSAMP and IPFIX Metering Processes) shows such a data path with two consecutive Metering Processes. 


+-----------------+    +-----------------+
| Parameters of   | +->| Parameters of   |
| Observation     | |  | Metering        |
| Point 1 (OP1)   | |  | Process 1 (MP1) |
+-----------------+ |  +-----------------+
| next: MP1       |-+  | next: MP2       |-+
+-----------------+    +-----------------+ |
                    +----------------------+
                    |  +-----------------+    +-----------------+
                    +->| Parameters of   | +->| Parameters of   |
                       | Metering        | |  | Exporting       |
                       | Process 2 (MP2) | |  | Process 1 (EP1) |
                       +-----------------+ |  +-----------------+
                       | next: EP1       |-+
                       +-----------------+
 Figure 5: Linkage of PSAMP and IPFIX Metering Processes 

 TOC 

5.  Configuration Parameters

This section identifies and describes the configurable parameters of Observation Points, Collecting Processes, Metering Processes, and Exporting Processes covered by the configuration data model. The selected parameters cover the configuration issues discussed in the IPFIX 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,” September 2006.), [I‑D.ietf‑ipfix‑protocol] (Claise, B., “Specification of the IPFIX Protocol for the Exchange,” November 2006.) and the PSAMP documents [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.). In particular, the corresponding MIB modules IPFIX-EXPORTER-MIB, IPFIX-COLLECTOR-MIB [I‑D.dietz‑ipfix‑mib] (Dietz, T., “Definitions of Managed Objects for IP Flow Information Export,” October 2006.), PSAMP-MIB [I‑D.ietf‑psamp‑mib] (Dietz, T. and B. Claise, “Definitions of Managed Objects for Packet Sampling,” June 2006.), and CISCO-NETFLOW-MIB [CISCO‑NETFLOW‑MIB] (Kundu, N. and P. Aitken, “CISCO-NETFLOW-MIB: Cisco NetFlow Cache MIB Module,” January 2004.) were taken into consideration. Consistency between the configuration data model and the MIB modules is the intended goal. Therefore, identical parameters in the MIB modules and the configuration data model should have identical names. Furthermore, the configuration data model enables the definition of multiple flow metering rules as proposed in [I‑D.dressler‑ipfix‑aggregation] (Dressler, F., “IPFIX Aggregation,” June 2006.).

The configuration capabilities of actual device implementations may not comprise all parameters of the configuration data model. In this case, only the supported parameters should be used and the unsupported parameters should be omitted.


 TOC 

5.1.  Observation Point

Observation Points usually represent the starting points of a data path through an IPFIX Device or a PSAMP Device. Within the configuration data model, each Observation Point is identified by its ID (observationPointId [I‑D.ietf‑ipfix‑info] (Quittek, J., “Information Model for IP Flow Information Export,” October 2006.)). The parameter set of an Observation Point comprises the following parameters:


 TOC 

5.2.  Collecting Process

A Collecting Process usually represents the starting point of a data path of an IPFIX concentrator or proxy. A Collecting Process is identified by an ID (there is no equivalent in [I‑D.ietf‑ipfix‑info] (Quittek, J., “Information Model for IP Flow Information Export,” October 2006.)). Its parameter set consists of the following parameters:


 TOC 

5.3.  Metering Process

Within the configuration data model, each Metering Process is identified by its ID (meteringProcessId [I‑D.ietf‑ipfix‑info] (Quittek, J., “Information Model for IP Flow Information Export,” October 2006.)). The function of a Metering Process depends on if it is part of an IPFIX Device, a PSAMP Device, or an IPFIX concentrator. Therefore, the parameter set of a Metering Process is divided into three groups of parameters for packet selection, packet reporting, and flow metering:

Packet selection parameters:

Packet reporting parameters:

Flow metering parameters:

The Metering Process of an IPFIX Device generates Flow Records from packets coming from one or more Observation Points. When configuring this kind of Metering Process, the flow metering parameters of the parameter set are used. In addition, the packet selection parameters are used if sampling and/or filtering is applied to the incoming packets [I‑D.ietf‑ipfix‑architecture] (Sadasivan, G., “Architecture for IP Flow Information Export,” September 2006.). Alternatively, two consecutive Metering Processes for packet sampling and flow metering can be configured as shown in Figure 5 (Linkage of PSAMP and IPFIX Metering Processes).

The Metering Process of a PSAMP Device generates Packet Records from packets coming from one or more Observation Points [I‑D.ietf‑psamp‑protocol] (Claise, B., “Packet Sampling (PSAMP) Protocol Specifications,” October 2006.)[I‑D.ietf‑psamp‑framework] (Duffield, N., “A Framework for Packet Selection and Reporting,” January 2005.). The corresponding configuration contains packet selection and packet reporting parameters.

The Metering Process of an IPFIX concentrator generates a new stream of Flow Records from incoming Flow Records received by one or more Collecting Processes [I‑D.dressler‑ipfix‑aggregation] (Dressler, F., “IPFIX Aggregation,” June 2006.). In this case, the configuration of the Metering Process comprises flow metering parameters only.

The parameter set of the Metering Process includes one or more pointers to the next components on the data path, which are typically Exporting Process(es).


 TOC 

5.4.  Exporting Process

An Exporting Process exports Flow Records and/or Packet Records using the IPFIX/PSAMP protocol and thus represents the usual end point of a data path. Depending on the transport protocol in use, it manages the transmission of the necessary control information (i.e. Templates) to the Collector. The structure of the Templates corresponds to the information contained in the Flow Records or Packet Records. Within the configuration data model, an Exporting Process is identified by its ID (exportingProcessId [I‑D.ietf‑ipfix‑info] (Quittek, J., “Information Model for IP Flow Information Export,” October 2006.)). The parameter set of an Exporting Process comprises the following parameters:


 TOC 

6.  XML Schema

XML Schema of the configuration data model is specified as follows: 

<?xml version="1.0" encoding="UTF-8" ?>
<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.1">

  <xsd:annotation>
    <xsd:documentation xml:lang="en">
      IPFIX/PSAMP Configuration Data Model Version 1.1
      Changes in version 1.1:
        - informationElement_type: ieName -> fieldName,
          ieId -> fieldId, ieLength -> fieldLength
          (as in IPFIX-EXPORTER-MIB)
        - collector_type: transportProtocol -> protocol
          (as in IPFIX-EXPORTER-MIB)
        - collectingProcess_type:
          - udpTemplateLifetime -> udpLifeTimeTemplate
            (similar to IPFIX-COLLECTOR-MIB)
          - new optional Observation Domain ID parameter for
            "virtual" Observation Domain in concentrators
        - packetSelection_type: selector names adapted to PSAMP-MIB
        - filterMatch_type: infoElementId -> field
        - packetReporting_type: reportedIE -> field
        - flowMetering_type: optional precedingRuleTemplateId which
          allows rule chaining as described in
          draft-dressler-ipfix-aggregation-03
        - flowExpiration_type: inactiveTimeout -> idleTimeout
          (as in ipfix-info: flowIdleTimeout)
    </xsd:documentation>
  </xsd:annotation>

  <!-- Generic Types -->
  <!-- Generic Type: Information Element -->
  <xsd:complexType name="informationElement_type">
    <xsd:annotation>
      <xsd:documentation xml:lang="en">
        This type is used to specify packet filters, templates, and
        metering rules.
        - instead of fieldId and fieldLength, fieldName can be used
          as specified ipfix-info.
        - match can be used within flow metering rules as a filter
        - modifier can be 'mask/X' or 'discard'.
          See draft-dressler-ipfix-aggregation-03 for details.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:sequence>
      <xsd:element name="enterpriseNumber" type="xsd:unsignedInt"
        minOccurs="0" />
      <xsd:element name="fieldName" type="xsd:string"
        minOccurs="0" />
      <xsd:element name="fieldId" type="xsd:unsignedInt"
        minOccurs="0" />
      <xsd:element name="fieldLength" type="xsd:unsignedInt"
        minOccurs="0" />
      <xsd:element name="match" type="xsd:string" minOccurs="0" />
      <xsd:element name="modifier" type="xsd:string" minOccurs="0" />
    </xsd:sequence>
  </xsd:complexType>


  <!-- Generic Type: Collector -->
  <xsd:complexType name="collector_type">
    <xsd:annotation>
      <xsd:documentation xml:lang="en">
        This type contains IP address, transport protocol, and port
        number of an IPFIX collector. It is used within Collecting
        Process and Exporting Process.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:sequence>
      <xsd:element name="ipAddressType" type="xsd:unsignedInt" />
      <xsd:element name="ipAddress" type="xsd:string" />
      <xsd:element name="protocol" type="xsd:unsignedInt" />
      <xsd:element name="port" type="xsd:unsignedInt" />
    </xsd:sequence>
  </xsd:complexType>


  <!-- Generic Type: Next -->
  <xsd:complexType name="next_type">
    <xsd:annotation>
      <xsd:documentation xml:lang="en">
        This type contains IDs of Metering Processes and/or
        ExportingProcessesIP as pointers to the next component(s) on
        a data path.
      </xsd:documentation>
    </xsd:annotation>
    <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>


  <!-- Generic Type: Time -->
  <xsd:complexType name="time_type">
    <xsd:annotation>
      <xsd:documentation xml:lang="en">
        This type is used for udpLifeTimeTemplate, activeTimeout
        idleTimeout, maxExportDelay.
        [OPEN ISSUE: Use primitive type "time" instead?]
      </xsd:documentation>
    </xsd:annotation>
    <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>


  <!-- Data Path Component Types -->
  <!-- Observation Point -->
  <xsd:complexType name="observationPoint_type">
    <xsd:annotation>
      <xsd:documentation xml:lang="en">
        This type comprises the parameter of an Observation Point.
        [OPEN ISSUE: Join type and parameters?]
      </xsd:documentation>
    </xsd:annotation>
    <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:annotation>
      <xsd:documentation xml:lang="en">
        This type comprises the parameter of a Collecting Process.
        There is an optional observationDomainId parameter that can be
        used specify a new "virtual" Observation Domain for an IPFIX
        concentrator aggregating flow records from different
        Observation Domains.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:sequence>
      <xsd:element name="observationDomainId" type="xsd:unsignedInt"
        minOccurs="0"/>
      <xsd:element name="listener" type="collector_type" minOccurs="0"
        maxOccurs="unbounded" />
      <xsd:element name="udpLifeTimeTemplate" 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:annotation>
      <xsd:documentation xml:lang="en">
        This type comprises the parameter of a Metering Process.
        It is composed of three parameter groups for packet selection,
        packet reporting, and flow metering, that can be combined as
        needed.
      </xsd:documentation>
    </xsd:annotation>
    <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">
        This type is used to specify the sequence of packet selectors.
        Note that the ordering corresponds to the order in which a
        packet passes the selectors.
        See PSAMP-MIB for details about the packet selection
        parameters.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:choice minOccurs="0" maxOccurs="unbounded">
      <xsd:element name="sampCountBased"
        type="sampCountBased_type" />
      <xsd:element name="sampTimeBased" type="sampTimeBased_type" />
      <xsd:element name="sampRandOutOfN"
        type="sampRandOutOfN_type" />
      <xsd:element name="sampUniProb" type="sampUniProb_type" />
      <xsd:element name="sampNonUniProb"
        type="sampNonUniProb_type" />
      <xsd:element name="sampFlowState" type="sampFlowState_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="sampCountBased_type">
    <xsd:sequence>
      <xsd:element name="interval" type="xsd:unsignedInt" />
      <xsd:element name="spacing" type="xsd:unsignedInt" />
    </xsd:sequence>
  </xsd:complexType>

  <xsd:complexType name="sampTimeBased_type">
    <xsd:sequence>
      <xsd:element name="interval" type="xsd:unsignedInt" />
      <xsd:element name="spacing" type="xsd:unsignedInt" />
    </xsd:sequence>
  </xsd:complexType>

  <xsd:complexType name="sampRandOutOfN_type">
    <xsd:sequence>
      <xsd:element name="population" type="xsd:unsignedInt" />
      <xsd:element name="sample" type="xsd:unsignedInt" />
    </xsd:sequence>
  </xsd:complexType>

  <xsd:complexType name="sampUniProb_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="sampNonUniProb_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="sampFlowState_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:annotation>
      <xsd:documentation xml:lang="en">
        There may be multiple fields within one filter.
        [OPEN ISSUE: This type differs from PSAMP-MIB since
        PSAMP-MIB lacks support for enterprise-specific fields]
      </xsd:documentation>
    </xsd:annotation>
    <xsd:sequence>
      <xsd:element name="field" 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:annotation>
      <xsd:documentation xml:lang="en">
        This type is used to specify the template of the Packet
        Record.
        [OPEN ISSUE: Field type differs from PSAMP-MIB since
        PSAMP-MIB lacks support for enterprise-specific fields]
      </xsd:documentation>
    </xsd:annotation>
    <xsd:sequence minOccurs="0" maxOccurs="unbounded">
      <xsd:element name="templateId" type="xsd:unsignedInt"
        minOccurs="0" />
      <xsd:element name="field" type="informationElement_type"
        minOccurs="0" maxOccurs="unbounded" />
    </xsd:sequence>
  </xsd:complexType>


  <!-- Metering Process: Flow Metering -->
  <xsd:complexType name="flowMetering_type">
    <xsd:annotation>
      <xsd:documentation xml:lang="en">
        This type is used to specify parameters and rules for flow
        metering.
      </xsd:documentation>
    </xsd:annotation>
    <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:annotation>
      <xsd:documentation xml:lang="en">
        This type is used to specify a metering rule.
        See draft-dressler-ipfix-aggregation-03 for details.
        [OPEN ISSUE: Currently, the Template ID is used as a rule
        identifier. We only need to identify a rule if we want to
        organize several rules in a chain (using preceding rule
        template id) where only the first matching rule is applied.
        In order to allow rule chaining without forcing the user to
        assign unique Template IDs, it might be better to have
        separate identifiers for rules and templates.]
      </xsd:documentation>
    </xsd:annotation>
    <xsd:sequence>
      <xsd:element name="templateId" type="xsd:unsignedInt"
        minOccurs="0" />
      <xsd:element name="precedingRuleTemplateId"
        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="idleTimeout" type="time_type" />
    </xsd:sequence>
  </xsd:complexType>


  <!-- Exporting Process -->
  <xsd:complexType name="exportingProcess_type">
    <xsd:annotation>
      <xsd:documentation xml:lang="en">
        This type comprises the parameter of an Exporting Process.
      </xsd:documentation>
    </xsd:annotation>
    <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:annotation>
      <xsd:documentation xml:lang="en">
        According to IPFIX-PROTO, the maximum packet size must be
        configured not to exceed the path MTU to the Collector.
        Maximum export delay restricts the time until a generated
        record must be exported. In case of flow metering, it's the
        maximum time until an expired flow record is exported.
        [OPEN ISSUE: Are these parameters used? Are there other
        parameters?]
      </xsd:documentation>
    </xsd:annotation>
    <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:annotation>
      <xsd:documentation xml:lang="en">
        IPFIX-PROTO only talks about Template refresh timeout.
        CISCO-NETCONF-MIB also comprises the Template refresh rate
        parameter.
      </xsd:documentation>
    </xsd:annotation>
    <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/PSAMP Configuration -->
  <xsd:element name="ipfixConfig">
    <xsd:annotation>
      <xsd:documentation xml:lang="en">
        Root element of the IPFIX/PSAMP configuration data model
      </xsd:documentation>
    </xsd:annotation>
    <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 

7.  Examples

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


 TOC 

7.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>
      <sampCountBased>
        <interval>10</interval>
        <spacing>500</spacing>
      </sampCountBased>
      <filterMatch>
        <field>
          <fieldName>destinationIPv4Address</fieldName>
          <match>10.1.0.0/16</match>
        </field>
        <field>
          <fieldName>destinationTransportPort</fieldName>
          <match>80,443</match>
        </field>
      </filterMatch>
    </packetSelection>
    <packetReporting>
      <templateId>888</templateId>
      <field>
        <fieldName>sourceIPv4Address</fieldName>
      </field>
      <field>
        <fieldId>313</fieldId>
        <fieldLength>0</fieldLength>
      </field>
      <field>
        <fieldName>flowStartSeconds</fieldName>
      </field>
    </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>
      <protocol>17</protocol>
      <port>4739</port>
    </collector>
  </exportingProcess>

</ipfixConfig>

 TOC 

7.2.  IPFIX 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>
      <sampCountBased>
        <interval>100</interval>
        <spacing>20</spacing>
      </sampCountBased>
    </packetSelection>
    <next>
      <meteringProcessId>2</meteringProcessId>
    </next>
  </meteringProcess>

  <meteringProcess id="2">
    <flowMetering>
      <rule>
        <templateId>998</templateId>
        <flowKey>
          <fieldName>sourceIPv4Address</fieldName>
          <modifier>mask/16</modifier>
        </flowKey>
        <flowKey>
          <fieldName>destinationIPv4Address</fieldName>
        </flowKey>
        <flowKey>
          <fieldName>transportProtocol</fieldName>
          <match>6,17</match>
        </flowKey>
        <flowKey>
          <fieldName>sourceTransportPort</fieldName>
        </flowKey>
        <flowKey>
          <fieldName>destinationTransportPort</fieldName>
        </flowKey>
        <nonFlowKey>
          <fieldName>flowStartSeconds</fieldName>
        </nonFlowKey>
        <nonFlowKey>
          <fieldName>flowEndSeconds</fieldName>
        </nonFlowKey>
        <nonFlowKey>
          <fieldName>octetDeltaCount</fieldName>
        </nonFlowKey>
        <nonFlowKey>
          <fieldName>packetDeltaCount</fieldName>
        </nonFlowKey>
      </rule>
      <rule>
        <templateId>999</templateId>
        <precedingRuleTemplateId>998</precedingRuleTemplateId>
        <flowKey>
          <fieldName>sourceIPv4Address</fieldName>
          <modifier>mask/16</modifier>
        </flowKey>
        <flowKey>
          <fieldName>destinationIPv4Address</fieldName>
        </flowKey>
        <flowKey>
          <fieldName>transportProtocol</fieldName>
          <match>1</match>
        </flowKey>
        <nonFlowKey>
          <fieldName>flowStartSeconds</fieldName>
        </nonFlowKey>
        <nonFlowKey>
          <fieldName>flowEndSeconds</fieldName>
        </nonFlowKey>
        <nonFlowKey>
          <fieldName>octetDeltaCount</fieldName>
        </nonFlowKey>
        <nonFlowKey>
          <fieldName>packetDeltaCount</fieldName>
        </nonFlowKey>
      </rule>
      <expiration>
        <activeTimeout unit="sec">5</activeTimeout>
        <idleTimeout unit="sec">10</idleTimeout>
      </expiration>
    </flowMetering>
    <next>
      <exportingProcessId>1</exportingProcessId>
    </next>
  </meteringProcess>

  <exportingProcess id="1">
    <ipfixPacketRestrictions>
      <maxPacketSize>512</maxPacketSize>
      <maxExportDelay unit="msec">500</maxExportDelay>
    </ipfixPacketRestrictions>
    <udpTemplateManagement>
        <templateRefreshTimeout>5</templateRefreshTimeout>
      <templateRefreshRate>100</templateRefreshRate>
    </udpTemplateManagement>
    <collector>
      <ipAddressType>4</ipAddressType>
      <ipAddress>10.2.0.99</ipAddress>
      <protocol>17</protocol>
      <port>4739</port>
    </collector>
  </exportingProcess>

</ipfixConfig>

 TOC 

7.3.  IPFIX Concentrator

<ipfixConfig xmlns="urn:ietf:params:xml:ns:ipfix-config">

  <collectingProcess id="1">
    <observationDomainId>9876</observationDomainId>
    <listener>
      <ipAddressType>4</ipAddressType>
      <ipAddress>10.2.0.99</ipAddress>
      <protocol>17</protocol>
      <port>4739</port>
    </listener>
    <udpLifeTimeTemplate unit="sec">15</udpLifeTimeTemplate>
    <next>
      <meteringProcessId>1</meteringProcessId>
    </next>
  </collectingProcess>

  <meteringProcess id="1">
    <flowMetering>
      <rule>
        <flowKey>
          <fieldName>sourceIPv4Address</fieldName>
        </flowKey>
        <flowKey>
          <fieldName>destinationIPv4Address</fieldName>
        </flowKey>
        <nonFlowKey>
          <fieldName>flowStartSeconds</fieldName>
        </nonFlowKey>
        <nonFlowKey>
          <fieldName>flowEndSeconds</fieldName>
        </nonFlowKey>
        <nonFlowKey>
          <fieldName>octetDeltaCount</fieldName>
        </nonFlowKey>
        <nonFlowKey>
          <fieldName>packetDeltaCount</fieldName>
        </nonFlowKey>
      </rule>
      <expiration>
        <activeTimeout unit="sec">5</activeTimeout>
        <idleTimeout unit="sec">10</idleTimeout>
      </expiration>
    </flowMetering>
    <next>
      <exportingProcessId>1</exportingProcessId>
    </next>
  </meteringProcess>

  <exportingProcess id="1">
    <collector>
      <ipAddressType>4</ipAddressType>
      <ipAddress>10.3.0.99</ipAddress>
      <protocol>132</protocol>
      <port>4739</port>
    </collector>
  </exportingProcess>

</ipfixConfig>

 TOC 

8.  Security Considerations

The XML Schema has been conceived to enable its usage with different 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 to the network management system and the corresponding limitations and adaptations of the configuration data model are 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 a given device. Users should make sure that configuration data is validated and checked against the capabilities of the device before configuring it. If configuration data is incomplete, invalid or unsupported, it must be rejected by the 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 

9.  References


 TOC 

9.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).
[I-D.ietf-ipfix-protocol] Claise, B., “Specification of the IPFIX Protocol for the Exchange,” draft-ietf-ipfix-protocol-24 (work in progress), November 2006.
[I-D.ietf-ipfix-info] Quittek, J., “Information Model for IP Flow Information Export,” draft-ietf-ipfix-info-14 (work in progress), October 2006.
[I-D.ietf-psamp-protocol] Claise, B., “Packet Sampling (PSAMP) Protocol Specifications,” draft-ietf-psamp-protocol-07 (work in progress), October 2006.
[I-D.ietf-psamp-info] Dietz, T., “Information Model for Packet Sampling Exports,” draft-ietf-psamp-info-05 (work in progress), October 2006.

 TOC 

9.2. Informative References

[W3C.REC-xml-20040204] Paoli, J., Maler, E., Sperberg-McQueen, C., Bray, T., and F. Yergeau, “Extensible Markup Language (XML) 1.0 (Third Edition),” World Wide Web Consortium Recommendation REC-xml-20040204, February 2004 (HTML).
[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] Gudgin, M., Mendelsohn, N., Hadley, M., Nielsen, H., and J. Moreau, “SOAP Version 1.2 Part 1: Messaging Framework,” World Wide Web Consortium Recommendation REC-soap12-part1-20030624, June 2003 (HTML).
[I-D.ietf-ipfix-architecture] Sadasivan, G., “Architecture for IP Flow Information Export,” draft-ietf-ipfix-architecture-12 (work in progress), September 2006.
[I-D.dietz-ipfix-mib] Dietz, T., “Definitions of Managed Objects for IP Flow Information Export,” draft-dietz-ipfix-mib-01 (work in progress), October 2006.
[RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, “Requirements for IP Flow Information Export (IPFIX),” RFC 3917, October 2004.
[I-D.dressler-ipfix-aggregation] Dressler, F., “IPFIX Aggregation,” draft-dressler-ipfix-aggregation-03 (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.
[I-D.ietf-psamp-mib] Dietz, T. and B. Claise, “Definitions of Managed Objects for Packet Sampling,” draft-ietf-psamp-mib-06 (work in progress), June 2006.
[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.
[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.

 TOC 

Author's Address

  Gerhard Muenz
  University of Tuebingen
  Computer Networks and Internet
  Sand 13
  Tuebingen D-72076
  DE
Phone:  +49 7071 29-70534
Email:  muenz@informatik.uni-tuebingen.de
URI:  http://net.informatik.uni-tuebingen.de/~muenz

 TOC 

Full Copyright Statement

Copyright © The IETF Trust (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.

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, THE IETF TRUST 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.

Intellectual Property

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.

Acknowledgment

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).