Internet Engineering Task Force (IETF) G. Muenz
Request for Comments: 6728 TU Muenchen
Category: Standards Track B. Claise
ISSN: 2070-1721 P. Aitken
Cisco Systems, Inc.
October 2012 Configuration Data Model for the IP Flow Information Export (IPFIX)
and Packet Sampling (PSAMP) Protocols
Abstract
This document specifies a data model for the IP Flow Information
Export (IPFIX) and Packet Sampling (PSAMP) protocols. It is for
configuring and monitoring Selection Processes, Caches, Exporting
Processes, and Collecting Processes of IPFIX- and PSAMP-compliant
Monitoring Devices using the Network Configuration Protocol
(NETCONF). The data model is defined using UML (Unified Modeling
Language) class diagrams and formally specified using YANG. The
configuration data is encoded in Extensible Markup Language (XML).
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6728.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
The configuration data model is designed for use with the NETCONF
protocol [RFC6241] in order to configure remote Monitoring Devices.
With the NETCONF protocol, it is possible to transfer a complete set
of configuration data to a Monitoring Device, to query the current
configuration and state parameters of a Monitoring Device, and to
change specific parameter values of an existing Monitoring Device
configuration.
In order to ensure compatibility with the NETCONF protocol [RFC6241],
YANG [RFC6020] is used to formally specify the configuration data
model. If required, the YANG specification of the configuration data
model can be converted into XML Schema language
[W3C.REC-xmlschema-0-20041028] or DSDL (Document Schema Definition
Languages) [RFC6110], for example, by using the pyang tool
[YANG-WEB]. YANG provides mechanisms to adapt the configuration data
model to device-specific constraints and to augment the model with
additional device-specific or vendor-specific parameters.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
1.1. IPFIX Documents Overview
The IPFIX protocol [RFC5101] provides network administrators with
access to IP Flow information. The architecture for the export of
measured IP Flow information out of an IPFIX Exporting Process to a
Collecting Process is defined in [RFC5470], per the requirements
defined in [RFC3917]. The IPFIX protocol [RFC5101] specifies how
IPFIX Data Records and Templates are carried via a number of
transport protocols from IPFIX Exporting Processes to IPFIX
Collecting Process. IPFIX has a formal description of IPFIX
Information Elements, their name, type, and additional semantic
information, as specified in [RFC5102]. [RFC6615] specifies the
IPFIX Management Information Base, consisting of the IPFIX MIB module
and the IPFIX SELECTOR MIB module. Finally, [RFC5472] describes what
type of applications can use the IPFIX protocol and how they can use
the information provided. It furthermore shows how the IPFIX
framework relates to other architectures and frameworks. Methods for
efficient export of bidirectional Flow information and common
properties in Data Records are specified in [RFC5103] and [RFC5473],
respectively. [RFC5610] addresses the export of extended type
information for enterprise-specific Information Elements. The
storage of IPFIX Messages in a file is specified in [RFC5655].
1.2. PSAMP Documents Overview
The framework for packet selection and reporting [RFC5474] enables
network elements to select subsets of packets by statistical and
other methods, and to export a stream of reports on the selected
packets to a Collector. The set of packet selection techniques
(Sampling, Filtering, and hashing) standardized by PSAMP is described
in [RFC5475]. The PSAMP protocol [RFC5476] specifies the export of
packet information from a PSAMP Exporting Process to a PSAMP
Collector. Instead of exporting PSAMP Packet Reports, the stream of
selected packets may also serve as input to the generation of IPFIX
Flow Records. Like IPFIX, PSAMP has a formal description of its
Information Elements, their name, type, and additional semantic
information. The PSAMP information model is defined in [RFC5477].
[RFC6727] specifies the PSAMP MIB module as an extension of the IPFIX
SELECTOR MIB module defined in [RFC6615].
2. Terminology
This document adopts the terminologies used in [RFC5101], [RFC5103],
[RFC5655], and [RFC5476]. As in these documents, all specific terms
have the first letter of a word capitalized when used in this
document. The following listing indicates in which references the
definitions of those terms that are commonly used throughout this
document can be found:
o Definitions adopted from [RFC5101]:
* Collection Process
* Collector
* Data Record
* Exporter
* Flow
* Flow Key
* Flow Record
* Information Element
* IPFIX Device
* IPFIX Message
* Observation Domain
* Observation Point
* (Options) Template
o Definitions adopted from [RFC5103]:
* Reverse Information Element
o Definitions adopted from [RFC5655]:
* File Reader
* File Writer
o Definitions adopted from [RFC5476]:
* Filtering
* Observed Packet Stream
* Packet Report
* PSAMP Device
* Sampling
* Selection Process
* Selection Sequence
* Selection Sequence Report Interpretation
* Selection Sequence Statistics Report Interpretation
* Selection State
* Selector, Primitive Selector, Composite Selector
* Selector Report Interpretation
The terms Metering Process and Exporting Process have different
definitions in [RFC5101] and [RFC5476]. In the scope of this
document, these terms are used according to the following
definitions, which cover the deployment in both PSAMP Devices and
IPFIX Devices:
Metering Process
The Metering Process generates IPFIX Flow Records or PSAMP Packet
Reports, depending on its deployment as part of an IPFIX Device or
PSAMP Device. Inputs to the process are packets observed at one
or more Observation Points, as well as characteristics describing
the packet treatment at these Observation Points. If IPFIX Flow
Records are generated, the Metering Process MUST NOT aggregate
packets observed at different Observation Domains in the same
Flow. The function of the Metering Process is split into two
functional blocks: Selection Process and Cache.
Exporting Process
Depending on its deployment as part of an IPFIX Device or PSAMP
Device, the Exporting Process sends IPFIX Flow Records or PSAMP
Packet Reports to one or more Collecting Processes. The IPFIX
Flow Records or PSAMP Packet Reports are generated by one or more
Metering Processes.
In addition to the existing IPFIX and PSAMP terminology, the
following terms are defined:
Cache
The Cache is a functional block in a Metering Process that
generates IPFIX Flow Records or PSAMP Packet Reports from a
Selected Packet Stream, in accordance with its configuration. If
Flow Records are generated, the Cache performs tasks like creating
new records, updating existing ones, computing Flow statistics,
deriving further Flow properties, detecting Flow expiration,
passing Flow Records to the Exporting Process, and deleting Flow
Records. If Packet Reports are generated, the Cache performs
tasks like extracting packet contents and derived packet
properties from the Selected Packet Stream, creating new records,
and passing them as Packet Reports to the Exporting Process.
Cache Layout
The Cache Layout defines the superset of fields that are included
in the Packet Reports or Flow Records maintained by the Cache.
The fields are specified by the corresponding Information
Elements. In general, the largest possible subset of the
specified fields is derived for every Packet Report or Flow
Record. More specific rules about which fields must be included
are given in Section 4.3.3.
Monitoring Device
A Monitoring Device implements at least one of the functional
blocks specified in the context of IPFIX or PSAMP. In particular,
the term Monitoring Device encompasses Exporters, Collectors,
IPFIX Devices, and PSAMP Devices.
Selected Packet Stream
The Selected Packet Stream is the set of all packets selected by a
Selection Process.
3. Structure of the Configuration Data Model
The IPFIX reference model in [RFC5470] describes Metering Processes,
Exporting Processes, and Collecting Processes as functional blocks of
IPFIX Devices. The PSAMP framework [RFC5474] provides the
corresponding information for PSAMP Devices and introduces the
Selection Process as a functional block within Metering Processes.
In Section 2 of the document, the Cache is defined as another
functional block within Metering Processes. Further explanations
about the relationship between Selection Process and Cache are given
in Section 3.1. IPFIX File Reader and File Writer are defined as
specific kinds of Exporting and Collecting Processes in [RFC5655].
Monitoring Device implementations usually maintain the separation of
various functional blocks, although they do not necessarily implement
all of them. Furthermore, they provide various configuration
possibilities; some of them are specified as mandatory by the IPFIX
protocol [RFC5101] or PSAMP protocol [RFC5476]. The configuration
data model enables the setting of commonly available configuration
parameters for Selection Processes, Caches, Exporting Processes, and
Collecting Processes. In addition, it allows specifying the
composition of functional blocks within a Monitoring Device
configuration and their linkage with Observation Points.
The selection of parameters in the configuration data model is based
on configuration issues discussed in the IPFIX and PSAMP documents
[RFC3917], [RFC5101], [RFC5470], [RFC5476], [RFC5474], and [RFC5475].
Furthermore, the structure and content of the IPFIX MIB module
[RFC6615] and the PSAMP MIB module [RFC6727] have been taken into
consideration. Consistency between the configuration data model and
the IPFIX and PSAMP MIB modules is an intended goal. Therefore,
parameters in the configuration data model are named according to
corresponding managed objects. Certain IPFIX MIB objects containing
state data have been adopted as state parameters in the configuration
data model. State parameters cannot be configured, yet their values
can be queried from the Monitoring Device by a network manager.
Section 3.2 explains how UML class diagrams are deployed to
illustrate the structure of the configuration data model.
Thereafter, Section 3.3 and Section 3.4 explain the class diagrams
for the configuration of Exporters and Collectors, respectively.
Each of the presented classes contains specific configuration
parameters that are specified in Section 4. Section 5 gives a short
introduction to YANG concepts that allow adapting the configuration
data model to the capabilities of a device. The formal definition of
the configuration data model in YANG is given in Section 6.
Section 7 illustrates the usage of the model with example
configurations in XML.
3.1. Metering Process Decomposition in Selection Process and Cache
In a Monitoring Device implementation, the functionality of the
Metering Process is commonly split into packet Sampling and Filtering
functions performed by Selection Processes, and the maintenance of
Flow Records and Packet Reports is performed by a Cache. Figure 1
illustrates this separation with the example of a basic Metering
Process.
+-----------------------------------+
| Metering Process |
| +-----------+ Selected |
Observed | | Selection | Packet +-------+ | Stream of
Packet -->| Process |---------->| Cache |--> Flow Records or
Stream | +-----------+ Stream +-------+ | Packet Reports
+-----------------------------------+
Figure 1: Selection Process and Cache forming a Metering Process
The configuration data model adopts the separation of Selection
Processes and Caches in order to support the flexible configuration
and combination of these functional blocks. As defined in [RFC5476],
the Selection Process takes an Observed Packet Stream as its input
and selects a subset of that stream as its output (Selected Packet
Stream). The action of the Selection Process on a single packet of
its input is defined by one Selector (called a Primitive Selector) or
an ordered composition of multiple Selectors (called a Composite
Selector). The Cache generates Flow Records or Packet Reports from
the Selected Packet Stream, depending on its configuration.
The configuration data model does not allow configuring a Metering
Process without any Selection Process in front of the Cache. If all
packets in the Observed Packet Stream shall be selected and passed to
the Cache without any Filtering or Sampling, a Selection Process
needs to be configured with a Selector that selects all packets
("SelectAll" class in Section 4.2.1).
The configuration data model enables the configuration of a Selection
Process that receives packets from multiple Observation Points as its
input. In this case, the Observed Packet Streams of the Observation
Points are processed in independent Selection Sequences. As
specified in [RFC5476], a distinct set of Selector instances needs to
be maintained per Selection Sequence in order to keep the Selection
States and statistics separate.
With the configuration data model, it is possible to configure a
Metering Process with more than one Selection Processes whose output
is processed by a single Cache. This is illustrated in Figure 2.
+-------------------------------------+
| Metering Process |
| +-----------+ Selected |
Observed | | Selection | Packet |
Packet -->| Process |----------+ +-------+ |
Stream | +-----------+ Stream +->| | | Stream of
| ... | Cache |--> Flow Records or
| +-----------+ Selected +->| | | Packet Reports
Observed | | Selection | Packet | +-------+ |
Packet -->| Process |----------+ |
Stream | +-----------+ Stream |
+-------------------------------------+
Figure 2: Metering Process with multiple Selection Processes
The Observed Packet Streams at the input of a Metering Process may
originate from Observation Points belonging to different Observation
Domains. By definition of the Observation Domain (see [RFC5101]),
however, a Cache MUST NOT aggregate packets observed at different
Observation Domains in the same Flow. Hence, if the Cache is
configured to generate Flow Records, it needs to distinguish packets
according to their Observation Domains.
3.2. UML Representation
We use UML class diagrams [UML] to explain the structure of the
configuration data model. The attributes of the classes are the
configuration or state parameters. The configuration and state
parameters of a given Monitoring Device are represented as objects of
these classes encoded in XML.
+------------------------------+
| SctpExporter |
+------------------------------+ 0..1 +------------------------+
| name |<>-------| TransportLayerSecurity |
| ipfixVersion = 10 | +------------------------+
| sourceIPAddress[0..*] |
| destinationIPAddress[1..*] | 0..1 +------------------------+
| destinationPort = 4739|4740 |<>-------| TransportSession |
| ifName/ifIndex[0..1] | +------------------------+
| sendBufferSize {opt.} |
| rateLimit[0..1] |
| timedReliability = 0 |
+------------------------------+
Figure 3: UML example: SctpExporter class
As an example, Figure 3 shows the UML diagram of the SctpExporter
class, which is specified in more detail in Section 4.4.1. The upper
box contains the name of the class. The lower box lists the
attributes of the class. Each attribute corresponds to a parameter
of the configuration data model.
Behind an attribute's name, there may appear a multiplicity indicator
in brackets (i.e., between "[" and "]"). An attribute with
multiplicity indicator "[0..1]" represents an OPTIONAL configuration
parameter that is only included in the configuration data if the user
configures it. Typically, the absence of an OPTIONAL parameter has a
specific meaning. For example, not configuring rateLimit in an
object of the SctpExporter class means that no rate limiting will be
applied to the exported data. In YANG, an OPTIONAL parameter is
specified as a "leaf" without "mandatory true" substatement. The
"description" substatement specifies the behavior for the case that
the parameter is not configured.
The multiplicity indicator "[0..*]" means that this parameter is
OPTIONAL and MAY be configured multiple times with different values.
In the example, multiple source IP addresses (sourceIPAddress) may be
configured for a multihomed Exporting Process. In YANG, an attribute
with multiplicity indicator "[0..*]" corresponds to a "leaf-list".
The multiplicity indicator "[1..*]" means that this parameter MUST be
configured at least once and MAY be configured multiple times with
different values. In the example, one or more destination IP
addresses (destinationIPAddress) must be configured to specify the
export destination. In YANG, an attribute with multiplicity
indicator "[1..*]" corresponds to a "leaf-list" with "min-elements 1"
substatement. Note that attributes without this multiplicity
indicator MUST NOT appear more than once in each object of the class.
Attributes without multiplicity indicator may be endued with a
default value that is indicated behind the equality symbol ("="). If
a default value exists, the parameter does not have to be explicitly
configured by the user. If the parameter is not configured by the
user, the Monitoring Device MUST use the specified default value for
the given parameter. In the example, IPFIX version 10 must be used
unless a different value is configured for ipfixVersion. In YANG, an
attribute with default value corresponds to a "leaf" with "default"
substatement.
In the example, there exist two default values for the destination
port (destinationPort) -- namely, the registered ports for IPFIX with
and without transport layer security (i.e., DTLS or TLS), which are
4740 and 4739, respectively. In the UML diagram, the two default
values are separated by a vertical bar ("|"). In YANG, such
conditional default value alternatives cannot be specified formally.
Instead, they are defined in the "description" substatement of the
"leaf".
Further attribute properties are denoted in braces (i.e., between "{"
and "}"). An attribute with property "{opt.}", such as
sendBufferSize in the SctpExporter class, represents a parameter that
MAY be configured by the user. If not configured by the user, the
Monitoring Device MUST set an appropriate value for this parameter at
configuration time. As a result, the parameter will always exist in
the configuration data, yet it is not mandatory for the user to
configure it. This behavior can be implemented as a static device-
specific default value, but does not have to be. Therefore, the user
MUST NOT expect that the device always sets the same values for the
same parameter. Regardless of whether the parameter value has been
configured by the user or set by the device, the parameter value MUST
NOT be changed by the device after configuration. Since this
behavior cannot be specified formally in YANG, it is specified in the
"description" substatement of the "leaf".
The availability of a parameter may depend on another parameter
value. In the UML diagram, such restrictions are indicated as
attribute properties (e.g., "{SCTP only}"). The given example does
not show such restrictions. In YANG, the availability of a parameter
is formally restricted with the "when" substatement of the "leaf".
Another attribute property not shown in the example is "{readOnly}",
which specifies state parameters that cannot be configured. In YANG,
this corresponds to the "config false" substatement.
Attributes without multiplicity indicator, without default value, and
without "{readOnly}" property are mandatory configuration parameters.
These parameters MUST be configured by the user unless an attribute
property determines that the parameter is not available. In YANG, a
mandatory parameter corresponds to a "leaf" with "mandatory true"
substatement. In the example, the user MUST configure the name
parameter.
If some parameters are related to each other, it makes sense to group
these parameters in a subclass. This is especially useful if
different subclasses represent choices of different parameter sets,
or if the parameters of a subclass may appear multiple times. For
example, the SctpExporter class MAY contain the parameters of the
TransportLayerSecurity subclass.
An object of a class is encoded as an XML element. In order to
distinguish between classes and objects, class names start with an
uppercase character while the associated XML elements start with
lowercase characters. Parameters appear as XML elements that are
nested in the XML element of the object. In XML, the parameters of
an object can appear in any order and do not have to follow the order
in the UML class diagram. Unless specified differently, the order in
which parameters appear does not have a meaning. As an example, an
object of the SctpExporter class corresponds to one occurrence of
<sctpExporter>
<name>my-sctp-export</name>
...
</sctpExporter>
There are various possibilities how objects of classes can be related
to each other. In the scope of this document, we use two different
types of relationship between objects: aggregation and unidirectional
association. In UML class diagrams, two different arrow types are
used as shown in Figure 4.
+---+ 0..* +---+ +---+ 0..* 1 +---+
| A |<>------| B | | A |-------->| B |
+---+ +---+ +---+ +---+
(a) Aggregation (b) Unidirectional association
Figure 4: Class relationships in UML class diagrams
Aggregation means that one object is part of the other object. In
Figure 4 (a), an object of class B is part of an object of class A.
This corresponds to nested XML elements:
<a>
<b>
...
</b>
...
</a>
In the example, objects of the TransportLayerSecurity class and the
TransportSession class appear as nested XML elements
<transportLayerSecurity> and <transportSession> within an object of
the SctpExporter class <sctpExporter>.
A unidirectional association is a reference to an object. In
Figure 4(b), an object of class A contains a reference to an object
of class B. This corresponds to separate XML elements that are not
nested. To distinguish different objects of class B, class B must
have a key. In the configuration data model, keys are string
parameters called "name", corresponding to XML elements <name>. The
names MUST be unique within the given XML subtree. The reference to
a specific object of class B is encoded with an XML element <b>,
which contains the name of an object. If an object of class A refers
to the object of class B with name "foo", this looks as follows:
<a>
...
<b>foo</b>
...
</a>
<b>
<name>foo</name>
...
</b>
In Figure 4, the indicated numbers define the multiplicity:
"1": one only
"0..*": zero or more
"1..*": one or more
In the case of aggregation, the multiplicity indicates how many
objects of one class may be included in one object of the other
class. In Figure 4(a), an object of class A may contain an arbitrary
number of objects of class B. In the case of unidirectional
association, the multiplicity at the arrowhead specifies the number
of objects of a given class that may be referred to. The
multiplicity at the arrow tail specifies how many different objects
of one class may refer to a single object of the other class. In
Figure 4(b), an object of class A refers to single object of class B.
One object of class B can be referred to from an arbitrary number of
objects of class A.
Similar to classes that are referenced in UML associations, classes
that contain configuration parameters and that occur in an
aggregation relationship with multiplicity greater than one must have
a key. This key is necessary because every configuration parameter
must be addressable in order to manipulate or delete it. The key
values MUST be unique in the given XML subtree (i.e., unique within
the aggregating object). Hence, if class B in Figure 4(a) contains a
configuration parameter, all objects of class B belonging to the same
object of class A must have different key values. Again, the key
appears as an attribute called "name" in the concerned classes.
A class that contains state parameters but no configuration
parameters, such as the Template class (see Section 4.8), does not
have a key. This is because state parameters cannot be manipulated
or deleted, and therefore do not need to be addressable.
Note that the usage of keys as described above is required by YANG
[RFC6020], which mandates the existence of a key for elements that
appear in a list of configuration data.
The configuration data model for IPFIX and PSAMP makes use of
unidirectional associations to specify the data flow between
different functional blocks. For example, if the output of a
Selection Process is processed by a Cache, this corresponds to an
object of the SelectionProcess class that contains a reference to an
object of the Cache class. The configuration data model does not
mandate that such a reference exists for every functional block that
has an output. If such a reference is absent, the output is dropped
without any further processing. Although such configurations are
incomplete, we do not consider them invalid as they may temporarily
occur if a Monitoring Device is configured in multiple steps. Also,
it might be useful to pre-configure certain functions of a Monitoring
Device in order to be able to switch to a new configuration more
quickly.
3.3. Exporter Configuration
Figure 5 below shows the main classes of the configuration data model
that are involved in the configuration of an IPFIX or PSAMP Exporter.
The role of the classes can be briefly summarized as follows:
o The ObservationPoint class specifies an Observation Point (i.e.,
an interface or linecard) of the Monitoring Device at which
packets are captured for traffic measurements. An object of the
ObservationPoint class may be associated with one or more objects
of the SelectionProcess class configuring Selection Processes that
process the observed packets in parallel. As long as an
ObservationPoint object is specified without any references to
SelectionProcess objects, the captured packets are not considered
by any Metering Process.
o The SelectionProcess class contains the configuration and state
parameters of a Selection Process. The Selection Process may be
composed of a single Selector or a sequence of Selectors, defining
a Primitive or Composite Selector, respectively.
The Selection Process selects packets from one or more Observed
Packet Streams, each originating from a different Observation
Point. Therefore, a SelectionProcess object MAY be referred to
from one or more ObservationPoint objects.
A Selection Process MAY pass the Selected Packet Stream to a
Cache. Therefore, the SelectionProcess class contains a reference
to an object of the Cache class. If a Selection Process is
configured without any reference to a Cache, the selected packets
are not accounted in any Packet Report or Flow Record.
o The Cache class contains configuration and state parameters of a
Cache. A Cache may receive the output of one or more Selection
Processes and maintains corresponding Packet Reports or Flow
Records. Therefore, an object of the Cache class MAY be referred
to from multiple SelectionProcess objects.
Configuration parameters of the Cache class specify the size of
the Cache, the Cache Layout, and expiration parameters if
applicable. The Cache configuration also determines whether
Packet Reports or Flow Records are generated.
A Cache MAY pass its output to one or more Exporting Processes.
Therefore, the Cache class enables references to one or more
objects of the ExportingProcess class. If a Cache object does not
specify any reference to an ExportingProcess object, the Cache
output is dropped.
o The ExportingProcess class contains configuration and state
parameters of an Exporting Process. It includes various
transport-protocol-specific parameters and the export
destinations. An object of the ExportingProcess class MAY be
referred to from multiple objects of the Cache class.
An Exporting Process MAY be configured as a File Writer according
to [RFC5655].
+------------------+
| ObservationPoint |
+------------------+
0..* |
|
0..* V
+------------------+
| SelectionProcess |
+------------------+
0..* |
|
0..1 V
+------------------+
| Cache |
+------------------+
0..* |
|
0..* V
+------------------+
| ExportingProcess |
+------------------+
Figure 5: Class diagram of Exporter configuration3.4. Collector Configuration
Figure 6 below shows the main classes of the configuration data model
that are involved in the configuration of a Collector. An object of
the CollectingProcess class specifies the local IP addresses,
transport protocols, and port numbers of a Collecting Process.
Alternatively, the Collecting Process MAY be configured as a File
Reader according to [RFC5655].
An object of the CollectingProcess class may refer to one or more
ExportingProcess objects configuring Exporting Processes that
reexport the received data. As an example, an Exporting Process can
be configured as a File Writer in order to save the received IPFIX
Messages in a file.