Network Working Group                                           G. Muenz
Internet-Draft                                   University of Tuebingen
Expires: June 24, 2007                                 December 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 (C) 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).









Muenz            draft-muenz-ipfix-configuration-01.txt         [Page 1]

Internet-Draft    IPFIX/PSAMP Configuration Data Model     December 2006


Table of Contents

   1.  Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . .  3

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

   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4

   4.  Structure of the Configuration Data Model  . . . . . . . . . .  4

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

   6.  XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 10

   7.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     7.1.  PSAMP Probe  . . . . . . . . . . . . . . . . . . . . . . . 20
     7.2.  IPFIX Probe  . . . . . . . . . . . . . . . . . . . . . . . 21
     7.3.  IPFIX Concentrator . . . . . . . . . . . . . . . . . . . . 23

   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 25

   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 25
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 26

   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27
   Intellectual Property and Copyright Statements . . . . . . . . . . 28


















Muenz            draft-muenz-ipfix-configuration-01.txt         [Page 2]

Internet-Draft    IPFIX/PSAMP Configuration Data Model     December 2006


1.  Open Issues

   General issues:
   o  Find a consensus of common configuration parameters.
   o  Shall we recommend the usage of Netconf protocol, which provides
      mechanisms for communicating device capabilities, error messages
      etc.?

   More open issues are indicated in the text as "[OPEN ISSUE: ...]".
   The following list summarizes them:
   o  Section 4 Structure of the Configuration Data Model:
      *  Allow consecutive Metering Processes or not?
   o  Section 5.1 Observation Point:
      *  Joint "type" and "parameters" in a single tag?
   o  Section 5.2 Collecting Process:
      *  Do we want to configure template lifetime individually per
         exporter?  This probably won't scale.
   o  Section 5.4 Exporting Process:
      *  Do we need distinct timeouts for Templates and Option
         Templates?
   o  Section 6 XML Schema:
      *  Use primitive type "time"?
      *  Field definition in filterMatch and packetReporting differs
         from PSAMP-MIB.
      *  Template ID is also used as identifier for metering rules.
      *  Are there more/other IPFIX/PSAMP message restriction
         parameters?


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



Muenz            draft-muenz-ipfix-configuration-01.txt         [Page 3]

Internet-Draft    IPFIX/PSAMP Configuration Data Model     December 2006


   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 a monitoring device.  However, the configuration data model
   specified here is not specific to any of these.

2.1.  IPFIX Documents Overview

   [TODO]

2.2.  PSAMP Documents Overview

   [TODO]


3.  Terminology

   This document adopts the terminologies used in
   [I-D.ietf-ipfix-protocol] and [I-D.ietf-psamp-protocol].
   [TODO: copy terminology section]


4.  Structure of the Configuration Data Model

   The IPFIX reference model defined in [I-D.ietf-ipfix-architecture]
   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], the corresponding
   information is given for the PSAMP architecture.  (Note that the term
   Measurement Process used in [I-D.ietf-psamp-framework] 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.



Muenz            draft-muenz-ipfix-configuration-01.txt         [Page 4]

Internet-Draft    IPFIX/PSAMP Configuration Data Model     December 2006


   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].  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 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 and Figure 3 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



Muenz            draft-muenz-ipfix-configuration-01.txt         [Page 5]

Internet-Draft    IPFIX/PSAMP Configuration Data Model     December 2006


   +-----------------+    +-----------------+
   | 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 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].  The configuration of the
   Metering Process follows the flexible rule concept presented in
   [I-D.dressler-ipfix-aggregation].

   +-----------------+    +-----------------+    +-----------------+
   | 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 shows such a data path with
   two consecutive Metering Processes.












Muenz            draft-muenz-ipfix-configuration-01.txt         [Page 6]

Internet-Draft    IPFIX/PSAMP Configuration Data Model     December 2006


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


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], [I-D.ietf-ipfix-architecture],
   [I-D.ietf-ipfix-protocol] and the PSAMP documents
   [I-D.ietf-psamp-framework], [I-D.ietf-psamp-sample-tech].  In
   particular, the corresponding MIB modules IPFIX-EXPORTER-MIB, IPFIX-
   COLLECTOR-MIB [I-D.dietz-ipfix-mib], PSAMP-MIB [I-D.ietf-psamp-mib],
   and CISCO-NETFLOW-MIB [CISCO-NETFLOW-MIB] 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].

   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.

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



Muenz            draft-muenz-ipfix-configuration-01.txt         [Page 7]

Internet-Draft    IPFIX/PSAMP Configuration Data Model     December 2006


   ID (observationPointId [I-D.ietf-ipfix-info]).  The parameter set of
   an Observation Point comprises the following parameters:

   o  Observation Domain ID
   o  Type and parameters (room for implementation specific parameters,
      e.g. pcap parameters)
      [OPEN ISSUE: join "type" and "parameters" in a single tag?]
   o  Pointer(s) to next functional component(s) (typically a Metering
      Process)

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]).  Its parameter set consists of the following
   parameters:

   o  One or more listeners (listening sockets), each identified by IP
      address, transport protocol, and port number, that receives IPFIX
      Messages and/or PSAMP Messages.
   o  Lifetime of templates if UDP is used as transport protocol
      (ipfixLifeTimeTemplate [I-D.dietz-ipfix-mib])
      [OPEN ISSUE: do we want to configure template lifetime
      individually per exporter? this probably won't scale]
   o  Pointer(s) to next functional component(s) (typically a Metering
      Process or Exporting Process)

5.3.  Metering Process

   Within the configuration data model, each Metering Process is
   identified by its ID (meteringProcessId [I-D.ietf-ipfix-info]).  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:
   o  Parameters for a sequence of Selection Processes
      [I-D.ietf-psamp-protocol][I-D.ietf-psamp-mib]

   Packet reporting parameters:
   o  Template definition for Packet Records

   Flow metering parameters:
   o  One or more metering rules specifying Flow Keys and non-Flow Keys
      of the Flow Records, as well as filters/patterns restricting the
      application of a rule [I-D.dressler-ipfix-aggregation]



Muenz            draft-muenz-ipfix-configuration-01.txt         [Page 8]

Internet-Draft    IPFIX/PSAMP Configuration Data Model     December 2006


      (Note that the 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.)
   o  Flow timeouts (flowActiveTimeout, flowIdleTimeout
      [I-D.ietf-ipfix-info])

   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].  Alternatively, two
   consecutive Metering Processes for packet sampling and flow metering
   can be configured as shown in Figure 5.

   The Metering Process of a PSAMP Device generates Packet Records from
   packets coming from one or more Observation Points
   [I-D.ietf-psamp-protocol][I-D.ietf-psamp-framework].  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].  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).

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]).  The parameter set of an Exporting Process
   comprises the following parameters:






Muenz            draft-muenz-ipfix-configuration-01.txt         [Page 9]

Internet-Draft    IPFIX/PSAMP Configuration Data Model     December 2006


   o  IPFIX packet export parameters, such as the maximum packet length
      and the maximum delay the Exporting Process is allowed to buffer
      incoming records in order to fill up the exported IPFIX packets
   o  Template retransmission parameters for UDP, such as retransmission
      timeout and refresh rate [CISCO-NETFLOW-MIB]
      (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.)
      [OPEN ISSUE: CISCO-NETFLOW-MIB contains separate parameters for
      Templates and Option Templates.  Do we need this, too?]
   o  One or more destination collectors, identified by IP address,
      transport protocol, and port number


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)



Muenz            draft-muenz-ipfix-configuration-01.txt        [Page 10]

Internet-Draft    IPFIX/PSAMP Configuration Data Model     December 2006


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



Muenz            draft-muenz-ipfix-configuration-01.txt        [Page 11]

Internet-Draft    IPFIX/PSAMP Configuration Data Model     December 2006


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



Muenz            draft-muenz-ipfix-configuration-01.txt        [Page 12]

Internet-Draft    IPFIX/PSAMP Configuration Data Model     December 2006


          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.



Muenz            draft-muenz-ipfix-configuration-01.txt        [Page 13]

Internet-Draft    IPFIX/PSAMP Configuration Data Model     December 2006


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



Muenz            draft-muenz-ipfix-configuration-01.txt        [Page 14]

Internet-Draft    IPFIX/PSAMP Configuration Data Model     December 2006


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



Muenz            draft-muenz-ipfix-configuration-01.txt        [Page 15]

Internet-Draft    IPFIX/PSAMP Configuration Data Model     December 2006


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



Muenz            draft-muenz-ipfix-configuration-01.txt        [Page 16]

Internet-Draft    IPFIX/PSAMP Configuration Data Model     December 2006


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




Muenz            draft-muenz-ipfix-configuration-01.txt        [Page 17]

Internet-Draft    IPFIX/PSAMP Configuration Data Model     December 2006


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



Muenz            draft-muenz-ipfix-configuration-01.txt        [Page 18]

Internet-Draft    IPFIX/PSAMP Configuration Data Model     December 2006


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



7.  Examples

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




Muenz            draft-muenz-ipfix-configuration-01.txt        [Page 19]

Internet-Draft    IPFIX/PSAMP Configuration Data Model     December 2006


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>



Muenz            draft-muenz-ipfix-configuration-01.txt        [Page 20]

Internet-Draft    IPFIX/PSAMP Configuration Data Model     December 2006


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


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



Muenz            draft-muenz-ipfix-configuration-01.txt        [Page 21]

Internet-Draft    IPFIX/PSAMP Configuration Data Model     December 2006


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



Muenz            draft-muenz-ipfix-configuration-01.txt        [Page 22]

Internet-Draft    IPFIX/PSAMP Configuration Data Model     December 2006


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


7.3.  IPFIX Concentrator

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

     <collectingProcess id="1">
       <observationDomainId>9876</observationDomainId>



Muenz            draft-muenz-ipfix-configuration-01.txt        [Page 23]

Internet-Draft    IPFIX/PSAMP Configuration Data Model     December 2006


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



Muenz            draft-muenz-ipfix-configuration-01.txt        [Page 24]

Internet-Draft    IPFIX/PSAMP Configuration Data Model     December 2006


         <protocol>132</protocol>
         <port>4739</port>
       </collector>
     </exportingProcess>

   </ipfixConfig>



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.


9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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



Muenz            draft-muenz-ipfix-configuration-01.txt        [Page 25]

Internet-Draft    IPFIX/PSAMP Configuration Data Model     December 2006


              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.

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,
              <http://www.w3.org/TR/2004/REC-xml-20040204>.

   [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,
              <http://www.w3.org/TR/2003/REC-soap12-part1-20030624>.

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




Muenz            draft-muenz-ipfix-configuration-01.txt        [Page 26]

Internet-Draft    IPFIX/PSAMP Configuration Data Model     December 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.


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
















Muenz            draft-muenz-ipfix-configuration-01.txt        [Page 27]

Internet-Draft    IPFIX/PSAMP Configuration Data Model     December 2006


Full Copyright Statement

   Copyright (C) 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).





Muenz            draft-muenz-ipfix-configuration-01.txt        [Page 28]