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]